Driver Station + Space Bar

[phynix]

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.

[RufflesRidge]

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

[ebarker]

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.

[Racer26]

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.

[Alan Anderson]

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.

[Roger]

Originally Posted by ebarker

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

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

[BigJ]

Originally Posted by Roger

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

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

[Roger]

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.

[Tom Line]

Originally Posted by Roger

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.

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.

[Roger]

Originally Posted by Tom Line

From whom did you receive your information regarding FIRST's/NI's intentions about the usage of the driver station as a programming laptop?

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.

[Dave Flowerday]

Originally Posted by Roger

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

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.

[Alan Anderson]

Originally Posted by Roger

I'm also curious that the space key stops the robot even when the driver station program does not have the focus.

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.

[stingray27]

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.

[SuperS_5]

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