Driver Station + Space Bar
 

All you people who do not like accidentally e-stopping your robot...

We are currently trying to use WindRiver C++ to program our robot...and, of course, this language requires the use of the space bar (GASP). Now, everyone knows that the space bar is equivalent to e-stop - even when focus isn't being given to the Driver Station.

My question to you all: Is there any way to prevent the driver station from doing this? The simplest solution would be if there is some kind of hidden option to disable e-stop.

However, not being able to find such an option, I am resorting to more...messy...means.

From what I've seen, it seems the only way the Driver Station could be doing this is through the use of hooks (http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx) to intercept ALL system events--not just ones that are in its current process. However, when I load the Driver Station, along with the Windows Process Explorer (external download from Microsoft), it shows that the Driver Station is not loading any other dlls--which cannot be the case. Global hooks can only be implemented through DLLs. I could not find any windows hook callbacks in the several DLLs that are in the same directory as the driver station exe file.

Any ideas would be much appreciated, likely to any team that has this same problem.

Re: Driver Station + Space Bar
 

Disabling your robot while you are writing code seems way easier and WAY safer than trying to remove the e-stop.

Re: Driver Station + Space Bar
 

The change of using an external button to using the space bar as an e-stop solved a lot of problems, namely manufacture, distribution, maintenance, etc of e-stops buttons.'

It other words, using the space bar is a good move. e-stop is part of the system robot control FMS architecture and is there for good reason.

I'd look at changing how humans interact with the DS, not with changing the DS architecture.

Re: Driver Station + Space Bar
 

Or, y'know, program it with some laptop other than the driver's station machine. The classmate's have a hard enough time being a stable drivers station. Laptops aren't expensive these days, an adequate off-lease Thinkpad or something could be had for around $200-300.

Re: Driver Station + Space Bar
 

The e-stop can only happen when the robot is enabled. As RufflesRidge suggested, it's a very good idea to disable your robot when you're programming it.

It would probably be an even better idea to use something besides your driver station as your programming computer. You're probably going to want to tweak the code during a competition, and you wouldn't want to lose access to the programming environment every time the robot goes out for a match.

Re: Driver Station + Space Bar
 

... because it is infinitely easier to change fixed human habit than changing "because we thought it was a good idea and will not change it". *

I agree with all those saying using the driver station to program on is not the best of arrangements, but sometimes driving the robot on your programming laptop may be the only way to be testing the robot. And sometimes one person is, say, testing the joysticks and another is, say, changing the numbers for the next download.

* I'm currently waiting for the next version of Adobe Reader, when all the habits and methods I've built up from previous versions prior to "X" will get put back after taken out of "X" -- "because we thought it was a good idea".

Re: Driver Station + Space Bar
 

If someone is driving while another person is coding, they can't see the dashboard anyway and would not be able to disable/estop. :(

Re: Driver Station + Space Bar
 

We've done it, not on a classmate, but with a laptop and additional screen. Like I said, not the best of arrangements, but sometimes that's the only way.

The point being, of course, that if it can be done, someone will do it. Look at all the different robot designs every year, the "lawyering", and rule changes.

The decision to use the space key as an e-stop was made because the classmate was pre-decided to be a driver station only, and never thought of as a programming computer. "We didn't design it for that." "We never thought of that." But notice over the years how many people program with it? See also unintended consequences.

Re: Driver Station + Space Bar
 

From whom did you receive your information regarding FIRST's/NI's intentions about the usage of the driver station as a programming laptop? We have discussed this exact issue on the beta test forums, and the NI reps fully understand that teams use the classmate for programming.

Our team asked if the e-stop could be moved to a different key because we also dislike occasionally hitting it by accident. They used the biggest key on the keyboard for a reason. They also made it a part of the driverstation (non-changeable) for a reason. We can argue their reasons (because that's what engineers do), but I completely disagree that they somehow didn't understand how the computers are used.

Re: Driver Station + Space Bar
 

Pure guessing. Sorry if it looked like I had inside info; it was only from what see and read. The first year it came out weren't there many questions here on Chief Delphi about using the classmate for a programming computer? Honestly, it's been years ago when the classmate came out, so I don't remember if there was the general assumption that it was a "driver station only".

Also, to make the distinction, it is a classmate (computer) to be used as a driver station (a program) and for programming (another program), not a driver station for programming. My computer here at work is also a driver station, not that I drive robots while I draft plans.

I'm sorry also to phynix for derailing the question. My Windows programming skills are minimal, but I would think adding a program to intercept the spacekey seems to me would make more problems than solve them. A quick search online did find similar questions and answers for "intercept key", and there are also programs out there that convert keys to different uses.

I'm also curious that the space key stops the robot even when the driver station program does not have the focus. Not that I doubt you, but that is rather "grabby" of the DS, and the original intention (ha!) of Windows. I'll have to try that. (We use LabVIEW so spacekey use is minimal.)

My only suggestion would be to build a little cardboard box to cover the spacekey, and make one of these to use as a spacekey. Though would the DS intercept it?

Maybe in the long run, phynix, you should get a separate computer.

Re: Driver Station + Space Bar
 

Years ago before we had the Classmate (when the Driver Station was a blue box with USB and Ethernet ports), I created a Windows app that emulated the driver station. Given that a 130 pound robot moving at up to 20fps can do some real damage to people or property, I was very concerned about the safety issues in releasing it. From the start, the spacebar and ESC keys were used for disable - ESC being an obvious choice, and the spacebar being a nice big easy target to hit quickly. In my first version, I had code that detected if the window lost focus (and thus wouldn't receive the keystrokes), and if so it disabled the robot. In a later version, I replaced it with code that would catch keystrokes regardless of which window was active and if the spacebar was hit it would disable. I was really worried otherwise that someone would pull up some other app on top of the DS and then be unable to disable the robot quickly in an emergency.

It's been a few years since I've worked with the Labview driver station, but as I recall it worked almost exactly the same way that my virtual driver station did regarding the spacebar for disable. I've never been quite sure if this was simply a coincidence or if the developers of the Labview DS borrowed that feature from my virtual DS from 2009...

As for it being "grabby" - you bet. FRC robots are extremely dangerous. There's been countless close calls and a few very serious injuries with people working on the robots. Given that danger, whatever is being used to control the robot needs to have a 100% reliable, always available action that will disable it immediately. Making the spacebar not work just because you pulled up WindRiver or something is a really bad idea.

To the original poster: PLEASE don't try to override this functionality. It was made that way for a good reason. Just think about how you'd feel if something went wrong with your robot and a friend of yours (or you) got seriously injured because someone couldn't disable the robot quickly due to your override hack. Also, consider that you could become legally liable if someone gets hurt due to the changes you're trying to implement. It's just not worth it. Disable the robot when you need to work on your code if you must share the DS laptop.

Re: Driver Station + Space Bar
 

It is extremely important for the emergency stop function to be available regardless of anything else the computer running the Driver Station might be doing.

Re: Driver Station + Space Bar
 

Originally I thought that the Space Bar E-stop function was a huge pain. But after a year of it, I finally think it is a really good idea for the following reasons:

First, as others mentioned it is the biggest key on the keyboard and therefore VERY hard to miss - if in an emergency, you just smash your hand toward the keyboard and you are bound to hit it.

Second, when programming on the driver station (in which we use the same laptop for programming and the driver station due to how the driver station ALWAYS comes with the robot and therefore we always have the code with us), it is much better having the e-stop button as the space bar instead of another button such as the enter key. We usually try to change a value such as a control in Labview with the code running and sometimes forget to hit the disable key or believe it is fine to just let it keep running. With the enter key being the disable key, when we enter to change the control's value, it disables the robot and therefore slows us down and makes us make sure everything is safe before we proceed. The spacebar is almost NEVER used while programming because we rarely use string controls in our code.

Lastly, if anyone ever had to guess what would shut down a robot if they had no idea what/how to shut it down, the space bar seems like the easiest/first guess someone would take.

Personally I think it would be a very bad idea to disable or cover up your eStop button. It may seem like a good idea at the time to make sure your robot doesnt shut down when you dont want it too, but keep in mind you will be sorry for that ONE time something goes wrong and you can't eStop it. It is really easy to change the behavior of the user, it isn't that easy to predict the behavior of the robot.

Re: Driver Station + Space Bar
 

To the original poster, I'm impressed with your curiosity, and I'm glad you are asking for input on the topic.

The DS was written with safety as a top concern. Historically, people working with dangerous machinery love to remove safety guards in order to improve their efficiency, and SW is no different. So, I'm not going to give you directions on how to remove the safety guard, and if you find a way, I encourage you to tell me or FIRST rather than telling your friends and then watching them get hurt using a less safe system.

I freely admit that the space bar makes it a bit too easy to estop the robot, and it takes more time than you'd like in order to undo the estop. I've done it myself, plenty of times, and it is worth discussing if there is a better estop, but not worth disabling.

As others have mentioned, the sure way to avoid estop is to use a different computer, or to disable the robot before using the laptop for other purposes.

Dave, some aspects of the DS were inspired by your emulator, like the I/O button names, but the spacebar is just one of those coincidences. It is interesting to hear that you made the same safety decisions in yours.

Greg McKaskle

Re: Driver Station + Space Bar
 

Something that doesn't seem to be understood by many so far is the differences between disabling and e-stopping the robot.

Disable - Stops the execution of code for now
E-Stop - Changes robot state to disabled and sets something in the cRIO that prevents it from being enabled again.

Under normal (non-competition usage) there is no reason for the functionality of the e-stop button. Unless it does something I'm unaware of, it disables the robot in the same way as the disable button. Disabling the robot until a power cycle serves little purpose other than to slow development down considerably.

I seem to remember a time where the space button disabled the robot and the enter button e-stopped the robot. This only changed last year, causing a fair amount of confusion among team members.
If both buttons are actually necessary, a way to either switch the mapping or select your own mapping would be extremely helpful.

Re: Driver Station + Space Bar
 

See Mark's note below. That's a good question for the NI guys though: I'd like to know more about the differences too.

There is a fairly good argument why the mapping should not be changed. If everyone in FIRST knows the mapping, then anyone in FIRST can stop your robot by smacking the spacebar/enter key. Safety is one of those items where you have to take the attitude that, if it can happen, it will.

Re: Driver Station + Space Bar
 

I think a good solution to the problem may be a better way to un-e-stop the robot beside a reboot.

Would there be some way to hit a specific combination of keys (ctrl+shift+alt+U ?) that could then disengage the e-stop? I should note, I have very little knowledge of how the DS is built or what the e-stop is actually doing when it is engaged.

-Brando

Re: Driver Station + Space Bar
 

Neither one actually stops code execution on the cRIO.
The user code continues to hum along blissfully.
I just tested it to make sure.

Re: Driver Station + Space Bar
 

Estop is simply a latched disable. Neither of them bother to abort user code, but instead they will both set outputs to safe values, ignoring user code settings. Sensors and other features continue to operate as normal. Ideally, estop would kill power, but that isn't something the system can easily achieve.

When FIRST stopped using the estop USB button, which wasn't a very robust button anyway, the decision was made to remap the buttons. Previously space disabled the robot, and I believe enter did as well. The estop button emitted ctl-shift-enter, so that combo would estop the robot no matter what keyboard it came from.

The new mapping is that enter disables and space estops. F1 will actually enable the robot, and while running will enumerate the joysticks again in case something came unplugged, etc.

As for another way to un-estop the robot, it has been discussed many times, and the folks who own the decision feel that it is very important to enforce good safety processes. Part of that process is to walk to the robot and give it a visual inspection after an estop. It is also good to give it some thought before you repeat the steps that led to an estop you are currently recovering from. If you are in such a hurry that an estop was necessary, perhaps that is too much of a hurry.

As for the value of estop when not in a competition? The argument is that this allows teams to learn about estop before an event. If, in a practice setting, you estop your robot, it is rather permanent -- ditto for the competition field. If a team became used to the inconsistent practice setup, perhaps even using this as a driving technique, that would be unfortunate. So, the controls are as consistent to the field conditions as budget will allow. If it were feasible to ship large red mushroom buttons or panic triggers or other equipment, that would also likely be a part of the practice and development setup as well.

Greg McKaskle

Re: Driver Station + Space Bar
 

@Greg McKaskle

Interesting information on the F1 button and enumeration. Where did you find this info?

Also, I think the space bar estop is here to stay even if a budgeting allows for an external button like the ones on the field. From a safety perspective two buttons is better than one and the other this is the space bar can not easily be covered or accidentally be pressed by someone who is not at the controls. I know some teams in 2010 opted to cover their button so it would not be accidentally be pressed. This presents a huge safety hazard.

Re: Driver Station + Space Bar
 

Lore, word of mouth, oral tradition, and several years of intimate familiarity with the control system. :)

Oh, and it's described in both the "Getting Started with the 2012 FRC Control System" document and the FMS White Paper. I'm sure it was in one of the 2011 setup documents too. Someone on each team should have read those, right?

Re: Driver Station + Space Bar
 

"Where did you find this info?" From a reliable source of course.

If an external estop is detectable, it could be used as a key -- the robot wouldn't run without it. At that point I'm pretty sure you could have the space bar back.

Greg McKaskle

Re: Driver Station + Space Bar
 

While I would like 1+ external e-stops, I wouldn't want to remove the spacebar as one. There would be no guarantee that an external e-stop is anywhere near the person that is enabling the robot. (As even USB buttons could be on long extensions, or under the table, etc.) I think the current use of the spacebar is the most appropriate as an e-stop even with the reintroduction of external e-stops.

Sent from my AT100 Using ForumTouch for Android