"Emergency Stopped" message won't go away

[Greg McKaskle]

The space-bar wasn't an NI decision. I may have implemented it, but at the end of the day, it isn't my name or the NI name on the banners. I do give feedback, however, and that would be that esc and F1 are awfully close to one another to be used to perform opposite functions.

I too have occasionally estopped a robot when I didn't mean to, but it only does this if the robot is enabled. If you disable it first, and then write your memo, it works fine. If you truly think it should be changed, you need to convince FIRST.

Greg McKaskle

[Brandon_L]

Originally Posted by Tom Line

HA!

We tried to use our E-stop button about a year ago (the old style). We discovered that I had been a little over-zealous hot-gluing it down. Evidently, we had gone to multiple competitions with an E-stop button that was about as useful as a paperweight.

ON another note (to National Instruments), PLEASE PLEASE get the e-top button off the spacebar. Trying to type on the drive station and constantly having it e-stop the robot is beyond annoying. Move it to the escape key. It's rarely hit during normal use.

Nothing is safer then having the biggest button on a keyboard as the emergency stop button.

If it were the escape key, and your robot was currently attacking a fellow student, I'd be fumbling around my keyboard for a bit trying to figure out which one it is.

As Greg said, just disable your 'bot before you start typing.

[Gigakaiser]

The space bar has actually saved 987s robot from breaking free and smashing a hole through one of our walls in the past. It is especially useful when there are deadly bugs in autonomous code as well.

[AdamHeard]

Originally Posted by Brandon_L

Nothing is safer then having the biggest button on a keyboard as the emergency stop button.

If it were the escape key, and your robot was currently attacking a fellow student, I'd be fumbling around my keyboard for a bit trying to figure out which one it is.

As Greg said, just disable your 'bot before you start typing.

Space bar being disable is adequate in my opinion.

I also don't understand why an e-stop necessitates a power cycle.

[Chris is me]

Space bar e-stop makes sense from a safety standpoint. It's the biggest, most accessible button.

[AdamHeard]

Originally Posted by Chris is me

Space bar e-stop makes sense from a safety standpoint. It's the biggest, most accessible button.

What is the advantage of estop over disable though?

[R.C.]

Originally Posted by Chris is me

Space bar e-stop makes sense from a safety standpoint. It's the biggest, most accessible button.

Disable does the same thing as estop, except with estop you have to reboot the robot. Which is a pain in the butt

-RC

[Greg McKaskle]

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

[Joe Ross]

Originally Posted by Greg McKaskle

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.

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.

Originally Posted by Greg McKaskle

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.

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.

Originally Posted by Greg McKaskle

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.

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.

[AdamHeard]

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).

[Greg McKaskle]

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