What is the advantage of estop over disable though?
Disable does the same thing as estop, except with estop you have to reboot the robot. Which is a pain in the butt 
-RC
Just to review:
F1 enables, enter/return disables, and spacebar estops the robot. When on the field, F1 checks for new joystick insertions and that is it ā no other special keys.
Some History:
In an ideal world, operation in the pits/shop would be identical to the field. An attempt was made to use a dedicated estop button more like the field, but it is difficult to get a reliable button for the kit. When the dedicated and required USB button was dropped, the estop moved to the keyboard where it displaced the disable and took over the spacebar.
Outcome:
Maybe we can all agree that the big button should stop the bot, and it does. This seems good from a safety standpoint when driven by a tired team member or by a newbie or visitor.
That leaves us with the comparison of estop and disable. What is the difference and why.
One goal was for teams to become familiar with estop before they show up to a field ā to know it exists, perhaps use it a few times and understand that it doesnāt just disable the bot. If you use it on the field, you are done.
Another goal was to encourage an inspection. You didnāt just disable the robot, something caused you ESTOP the robot. Perhaps you should do an inspection for cause or for damage before compounding the issue. If you meant to disable but estopped instead, it is a small pain. If something about the robotās behavior truly deserved an estop reaction, you donāt want to repeat that, right? Something probably needs to change. Similarly, an estop in an industrial setting would typically have a reset procedure different from an operator disable.
Iāve observed that many will power cycle the entire robot, and that is fine, but it does take longer. The minimum needed to clear an estop is to hit the physical reset button on the cRIO ā a toothpick works nicely. This leaves the radio powered and your road to learning the difference between estop and disable is a bit shorter.
Greg McKaskle
So then next question is why does the field require this? 10 years ago, it didnāt.
Between the e-stop keeping you from finishing the match and rules that make people afraid of getting red-carded, the e-stop doesnāt get used as much as it should in matches. For example, one year we were having trouble with our autonomous and occasionally we would run into the wall at full speed. We were fine after autonomous and could continue the match. After the second time, the refs warned us that we would get a red card if it happened again. Since it didnāt happen very often, we didnāt want to disable the autonomous. Because of this, we decided that we would hope that it wouldnāt happen again, but if it did, weād take the red card. A much more ideal case would have been for us to be able to hit the e-stop before the robot hit the wall, and un-estop after autonomous was over. This would have been safer for both the field and the robot. Iāve seen many other similar cases too, for example the robot last year (logomotion) that shot straight backwards in autonomous and hit the opponents.
I think, on the field, there are many more uses for an e-stop that is possible to undo then for the current setup.
A piece of industrial equipment would also do something something additional, such as shut off power. Since that isnāt possible, any difference between disable and e-stop is contrived.
The process described sounds like lockout / tagout, where a piece of equipment is turned off and locked in the off position with an identifying tag of the person doing maintenance. For the robot, this could be implemented by using a ābigā key for disable, and a second key to e-stop, after the robot has been disabled. This provides the same level of safety with much higher convenience.
I know in our case, the power button is more easily accessible and doesnāt require special equipment to reach, so it ends up being easier. Of course, the reboot robot on the DS is even easier, but itās disabled when e-stopped.
Iām not trying to be an arse, Iām just trying to get the reasoning behind it.
To me it sounds like e-stop is purely a punitive thing, I understand how FIRST has slightly different viewpoints on it.
Teams are going to be unsafe with the machines if they choose to be negligent, and an estop wont prevent that any more than disable in my opinion.
I know itās a bad practice, but when weāre stressed working on stuff we sometimes take risks in terms of disabling the robot in an emergancy because we donāt want to deal with the time it takes to e-stop, and itās hard to hit the disable key in a jiffy if you arenāt hovering over it.
Iām more serious about safety than the FRC teams that are just a teacher and some students scrapping through their first year, so they are probably taking similar risks more often.
I canāt be the only bad apple.
Itād be nice to just ditch e-stop and use disable for all cases. Or at least make estop not REQUIRE a reboot, maybe merely a 5 second timeout on the enable button (or a text box that pops up and reminds you to check for safety issues, then hit okay).
Before I continue to seemingly defend the estop, let me just say that Iām not its biggest fan either. I know how the conversation goes because these objections are familiar somehow. But seeing as how it canāt defend itself, Iāll give the answers I have, perhaps simply to hone your argument to the point where it will all make sense.
So then next question is why does the field require this? 10 years ago, it didnāt.
Iām not sure this holds water. For instance, I never rode in a car seat growing up. In fact I spent my fair share of time in the bed of a pickup or in the cab of a tractor, but apparently todayās cars are incapable of transporting children below the age of 14 without them sitting on something that costs $100 or more and is a royal pain to install. Standards for safety change over time.
A much more ideal case would have been for us to be able to hit the e-stop before the robot hit the wall, and un-estop after autonomous ā¦
Somehow, I donāt think they will change the rules to let teams step forward during auto to touch stuff, and then continue playing the game as if nothing happened.
A piece of industrial equipment would also do something something additional, such as shut off power.
If the robot had a smart PD, I wouldnāt be surprised if it did kill some power. The next best thing is to have the most trusted piece of the system, the FPGA, withhold all enables and signals.
ā¦ itās hard to hit the disable key in a jiffy if you arenāt hovering over it
Fortunately, the key stuff is done with DirectInput, like video games are. It works pretty well with key smashes, meaning that if you hit other keys that include the right key, it usually works anyway.
It sounds like the primary issue is that the estop is inconvenient. I understand and donāt even disagree, but I think the requirement is to show that the system is safer or at least no less safe without the estop.
Greg McKaskle