Having competed in for the first time last week, I think finally get why all the robots are falling, ropes are breaking, fields are getting damaged, etc.
This is what I observed:
Teams have put monster power into climbing. Lots of motors, high ratios. They are climbing at 10-20 inches per second and have 4X (sometimes 10X) the stall torque available above and beyond what they need to lift their robots.
AND…
Those climb points are almost always needed to win.
AND…
The touchpad lights give no indication that the touchpad switch has been activated, zero, nada for a full second after the switch is tripped (this is exactly as the rule say it should function but the consequences didn’t hit me until I saw it live).
All of this together means that drivers are keeping their thumbs on their climb buttons for *at least an extra second after they could have let go.
With that much power, that much speed and that much torque, something is going to give: the rope, the robot, a gearbox, the field,…
I think it would behove FIRST to make the following change:
During a match, the Touchpad Lights mirrors exactly the state of the switch with no debounce whatever.
For 1 second after the match, ALL Touchpad Lights turn OFF.
After 1 second and until field reset, the Touchpad Lights reflect whether that Touchpad was SCORED or not (following the timing rules in the FIRST manual)
I think this gives up very little in terms of drama (if anything helps add to the drama), gives up very little in terms of audience confusion, and will help have fewer broken robots and reduce field damage.
Thoughts?
Dr. Joe J.
*sidenote: teams please please give your drivers and your robots a break. Put some sort of stall detection on your climber. It is trivial if you are using a Talon SRX w/CAN to do something with current but a speed sensor can also work for this function.
I’m not sure of the lighting used in the touchpad, but as there are red and blue lights I might be able to assume they’re color changing leds. If that’s the case, light em up white on contact and then the alliance color after 1s
This is what Clinton Bolinger and I have been advocating for on GameSense. Light up the touchpad with a neutral color (yellow, green, white, etc) when the sensor is triggered and change to alliance color when 1 second has elapsed and the climb counts for points.
Edit: clarified above, LED’s are either red or blue. That’s unfortunate. Joe’s suggestion would work.
Climbing the rope is not a difficult challenge. Stopping at the top without damaging or creating significant wear on your robot is.
-If FIRST intended the one second delay in user feedback to be part of the challenge, then I do not think it should change.
-If however, the one second delay was not intended to be part of the challenge and is more so to ease score recognition or something of that sort, then by all means I would like to see instantaneous feedback implemented.
*Even if it is not considered as part of the challenge. Until a team torques up against the davit causing irreparable damage to the field, I don’t believe FIRST will see it as an issue that needs fixing.
And further limit the drive team options when something changes in the dynamics of the climber? With a ratcheting winch, you’re options are already pretty limited once you’ve latched onto that rope. You can’t risk those critical points, especially at that point in the match.
I’m always of the opinion that the drive team should be able to chose if/when they damage components of the robot.
Our nylon rope + CIM + VersaPlanatery + #35 chain and sprocket can take the 2-3 second stall until we are certain that touchpad is pressed and not going to come unpressed. We built the robot to take it; the field should be able to take it.
I a big advocate of automatic systems with manual backup if needed so you’ll not be surprised to learn that our drivers can override the current limit if they believe the situation warrants it.
We will also be working a manual override in to our climbing code. But the plan is to have our robot stop climbing once it has gone far enough to trigger the pad but not far enough to torque against anything rigid.
Adding to this that you don’t even need any of those expensive motor controllers to accomplish it. EVERY robot is REQUIRED to use something that can tell you the current going through any of those motor controllers. The PDP has that functionality built in. USE IT!
Point of reference. I did not know anything about Java programming on an FRC bot until a couple of weeks ago. It took all of 10 minutes to locate how to implement the commands to get the current usage on PDP ports and we had a climber that was fully autonomous once the rope was acquired on the drum. Once it gets to the top and the current increases, it shuts off. If one of the extremely low budget, rural teams that I part-time mentor can figure it out…
We would be delighted with this change. Pad light flickers when pad is activated and goes solid after one second. I could then coach my operator to stop climbing when the light flickers.
Distance based climb cut off? Now you’re scaring me.
I suppose you might do something with a gyro to determine when you start your climb but I have seen so much variation how the ropes wrap on the drum, I think it might get a little confused. And then there is the whole, trig problem of the angle of the rope with respect to the normal to the floor,… seems fraught.
I am still a fan of current. Very close correspondence to torque.
As an intermediate option, we use the current monitoring to drive the rumble in the controller of the driver controlling the climber. The driver can decide to push through it or stop as needed.
A flashing light and a touchpad repeatedly being turned on and off look the same.
Can you just light BOTH red and blue on the touchpad to mirror the state, then change to the alliance color when scored? I know nobody wants more purple lights on the field but it would get the job done.
I agree that this is the cause of many climb failures and broken touchpads.
We will be testing our solution tonight. I will try to remember to come back here and post an update. Pictures perhaps? Hint: The sensor involved reports a Boolean value.