"Emergency Stopped" message won't go away
 

Soryy if this is covered somewhere else, I searched and could not find anything on this.
We have been through multiple installation process on the driver station, we finally see the compass, everything is green, we are reading battery voltage - so I think we are getting close. However, the driver station says "Emergency Stopped" and we cannot enable anything. What are we doing wrong?

Re: "Emergency Stopped" message won't go away
 

If someone hit the button: Turn off robot and turn back on.

If not: I have no idea, check your code? I dont know if the watchdog does that as I have never been shut down by it. Try running the default code.

Not sure what it says if the button isnt plugged in, but make sure its in also.

Re: "Emergency Stopped" message won't go away
 

Yep, that worked. It was still E-stopped through the driver station update and multiple PC reboots, but it's fine now.

I still can't get the camera working though. Went through the setup process multiple times, and I'm updating the Driver Station for the third time now, but I can't see it on the Driver Station.

Re: "Emergency Stopped" message won't go away
 

have the code running for the robot and it should work, did for us.

Re: "Emergency Stopped" message won't go away
 

For reference once the E-Stop button is pressed, you'll need to hard reboot your robot no matter what. For more details read the control systems manuals.

Re: "Emergency Stopped" message won't go away
 

You must either run code from a developer computer or permanently deploy code to the CRIO for a picture to be visible on the driver station.

Re: "Emergency Stopped" message won't go away
 

To verify I understand what you mean - we have loaded the Java version of the bench test code from the Driver Station to the cRio and are using that to test with. I sounds like you are saying that the camera image will not display on the Driver Station with this configuration.
It sounds like now we need to load another project (TrackerDemo?) to get the camera to display on the Driver Station. Is that correct?
Thanks for the help!

Re: "Emergency Stopped" message won't go away
 

I'm sorry - I can't comment on the Java configuration. I know in Labview for the camera picture to be visible, you have to "run" the code from a developer computer, or permanently deploy it to the CRIO. The vision components come as a standard piece of the default framework that everyone uses.

Sorry I can't help more - hopefully one of the Java programming teams sees the post.

Re: "Emergency Stopped" message won't go away
 

Can you browser to the camera if you hook it directly to the Classmate?
I assume you setup the camera with an FRC/FRC account/password?

Re: "Emergency Stopped" message won't go away
 

We loaded the CircleTrackerDemo code into the cRIO and the camera feed showed up on the DS, so we are on our way (at least for now.)
Thanks for all the great input!

Re: "Emergency Stopped" message won't go away
 

We were getting that same problem regarding the emergency stopped message on our driver console. I saw that everyone was mentioning things about problems with the code? I was wondering if anyone could help me diagnose what kind of problem that would be. Like, what would be the problem with the code that would produce that problem?

Help would be much appreciated!

Thanks!!! :)

Re: "Emergency Stopped" message won't go away
 

Once your robot is E-Stopped it can only be cleared by turning the robot off.
E-Stop is designed that way.

The Driver Station space bar E-Stops the robot now, so avoid using it.
It's easier to Disable your robot using the Enter key.

Re: "Emergency Stopped" message won't go away
 

If you have issues after successfully setting up the camera and then doing a power cycle, it is because you are using the wrong version of the Camera Setup utility. Get and install the update from the NI site and it will correct this problem. The original version of the setup utility released around 2012 kickoff caused this behavior.

Re: "Emergency Stopped" message won't go away
 

If you're using the actual E-stop button on your driverstation:

I was stuck on this issue for hours one day during build season. (we switched laptops, powercycled multiple times, etc) This may sound idiotic but the corner of our driverstation was slightly pressing the e-stop button the entire time.

Re: "Emergency Stopped" message won't go away
 

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.

Re: "Emergency Stopped" message won't go away
 

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

Re: "Emergency Stopped" message won't go away
 

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.

Re: "Emergency Stopped" message won't go away
 

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.

Re: "Emergency Stopped" message won't go away
 

Space bar being disable is adequate in my opinion.

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

Re: "Emergency Stopped" message won't go away
 

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

Re: "Emergency Stopped" message won't go away
 

What is the advantage of estop over disable though?

Re: "Emergency Stopped" message won't go away
 

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

-RC

Re: "Emergency Stopped" message won't go away
 

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

Re: "Emergency Stopped" message won't go away
 

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.

Re: "Emergency Stopped" message won't go away
 

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

Re: "Emergency Stopped" message won't go away
 

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.

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.

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.

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.

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