Driver Station 2010 - Netbook?

[Greg Marra]

This year, many teams encountered issues with their Driver Stations failing due to the electrostatic discharge issue caused by the regolith field. I am sure FIRST will harden the 2010 Driver Stations, but there is also another option.

Dave Flowerday's Virtual Driver Station shows that any laptop can serve a Driver Station. What if instead of a bluebox DS, teams were given a COTS netbook instead? The netbook would have a laptop display instead of a small b+w LCD, so could be used to display a Dashboard during the competition.

Would teams rather have

• The 2009 DS, but built more robustly
• A COTS netbook acting as the DS

It seems like a netbook might cost a little more. What if FIRST made it legal for you to bring-your-own DS like they're doing with FTC this year? Would teams be willing to spend a bit more to get a full fledged laptop as part of their control system?

[Alan Anderson]

My primary concern is ensuring that safety is maintained. Giving teams complete control over a device in the E-STOP loop can end up with no way to disable an out-of-control robot. The communication architecture might have to be revamped somewhat in order to make everything failsafe.

A secondary concern would be trying to prevent the driver station programming from being used to manipulate the robot inputs directly. That's currently against the rules.



I have a completely different suggestion: standardize the operator console. Have a pair of joysticks and a pair of gamepads permanently installed at each station. Maybe include an IIC connection or something for specialized switches/knobs/display devices if teams really want to get fancy.

[MrForbes]

Originally Posted by Alan Anderson

I have a completely different suggestion: standardize the operator console. Have a pair of joysticks and a pair of gamepads permanently installed at each station.

Having driven robots with joysticks, and with a modified RC car pistol controller, I don't like this idea.

I also think that having a standard DS, which costs less than a laptop, and can be replaced at the events, and repaired relatively easily, is probably not so bad after all. I'd hate to blow the one ethernet port on the team's laptop, and have to figure out how to fix it, or come up with $300 or so for a new laptop.

[NickE]

Another problem that I see with the netbook solution is that there is no easy way to plug in digital and analog inputs. (My team, for example, is using no USB ports and has everything wired through the input pins)

Originally Posted by Alan Anderson

I have a completely different suggestion: standardize the operator console. Have a pair of joysticks and a pair of gamepads permanently installed at each station. Maybe include an IIC connection or something for specialized switches/knobs/display devices if teams really want to get fancy.

On the standardization of Driver Consoles, i am extremely against this, as I believe that teams should be able to choose the joysticks, buttons, knobs, etc. that they like to use. For example, I hate driving using the KOP joysticks, however some people love them.

Also, if the driver console was standardized, teams would have to work with a certain number of joysticks, buttons, knobs, etc. Would the system have all the possible input devices and joysticks that each team would need? What if a team needs to use 8 joysticks (4 USB, 4 analog input pins), would it be ready for that? I know that rather than having two gamepads and two standardized joysticks at each station, my team would prefer to have flexibility in operator console design, with the ability to package all of our controls into a lightweight and rugged module.

[MrForbes]

Good point Nick, it would be a pain to try to wire an easy button to a laptop!

[Dave Flowerday]

I think a hybrid approach would be great. Base it around a COTS netbook so we can take advantage of the high-volume production to get a product that costs basically the same as a DS with a much better screen, built-in battery (which would be *perfect* for pit testing/demos/in-queue use), WiFi (no reason we couldn't go direct from Netbook to Robot for at-home testing and skip the Access Point in the KOP).

Add to the netbook a custom USB device that would include some digital and analog inputs for custom controls, a few real LEDs for feeback (they're easier for field crews to see than the LCD screen), E-Stop, and an Auto/Driver switch.

As for Alan's concern about safety on the field, a USB-connected E-Stop isn't any less safe than the DS today. Today's DS still relies on reading the switch input and adjusting its network packets correctly. To further enhance safety, however, I'd have an E-Stop connected to the field hardware cabinet (not to the netbook) at competitions, and require the robot to receive a "you're enabled" packet from FMS to keep going. If FMS stops sending the "You're enabled" packets, the robot shuts down, regardless of what the DS is doing.

Additionally, to address concerns about teams changing the DS code (which was entirely possible this year, BTW): it isn't that hard to give teams a standard firmware image that they must boot from (if everyone uses the same netbook), and do some code signing and authentication to confirm to the FMS that the netbook's code is what was shipped.

[NickE]

Originally Posted by Dave Flowerday

I think a hybrid approach would be great. Base it around a COTS netbook so we can take advantage of the high-volume production to get a product that costs basically the same as a DS with a much better screen, built-in battery (which would be *perfect* for pit testing/demos/in-queue use), WiFi (no reason we couldn't go direct from Netbook to Robot for at-home testing and skip the Access Point in the KOP).

Add to the netbook a custom USB device that would include some digital and analog inputs for custom controls, a few real LEDs for feeback (they're easier for field crews to see than the LCD screen), E-Stop, and an Auto/Driver switch.

As for Alan's concern about safety on the field, a USB-connected E-Stop isn't any less safe than the DS today. Today's DS still relies on reading the switch input and adjusting its network packets correctly. To further enhance safety, however, I'd have an E-Stop connected to the field hardware cabinet (not to the netbook) at competitions, and require the robot to receive a "you're enabled" packet from FMS to keep going. If FMS stops sending the "You're enabled" packets, the robot shuts down, regardless of what the DS is doing.

Additionally, to address concerns about teams changing the DS code (which was entirely possible this year, BTW): it isn't that hard to give teams a standard firmware image that they must boot from (if everyone uses the same netbook), and do some code signing and authentication to confirm to the FMS that the netbook's code is what was shipped.

This sounds much better. The usb dongle for connecting analog and digital inputs really completes it. The laptop will be very handy for diagnostics as well.

[RyanCahoon]

Originally Posted by Dave Flowerday

I think a hybrid approach would be great. Base it around a COTS netbook so we can take advantage of the high-volume production to get a product that costs basically the same as a DS with a much better screen, built-in battery (which would be *perfect* for pit testing/demos/in-queue use), WiFi (no reason we couldn't go direct from Netbook to Robot for at-home testing and skip the Access Point in the KOP).

[snip]

Additionally, to address concerns about teams changing the DS code (which was entirely possible this year, BTW): it isn't that hard to give teams a standard firmware image that they must boot from (if everyone uses the same netbook), and do some code signing and authentication to confirm to the FMS that the netbook's code is what was shipped.

I would really like to see this, then have a similar facility as on the robots, where teams could write and load their own dashboard code that would run concurrently to the competition code. Getting technical for a moment, the team's code could be run inside a virtual machine on the DS, that way all network traffic could be monitored (and restricted if necessary, as it was this year), and if the team code crashed, seg-faulted the operating system, etc, it wouldn't hurt the safety or reliability of the rest of the system.

--Ryan

[JesseK]

I'm against the idea of requiring teams to have a standardized laptop, notebook, or any netbook. It doesn't matter if the cost is comparable, I'd rather have my own choice of laptop as a driver's station. A limited CPU/graphics/screen size notebook would eliminate a huge portion of the possibilities for human-robot interfaces. I'm not just talking about how to control the bot, but also displays for state data, target tracking, and aesthetics (which are all important in industry). Try putting all of that onto a miniature 10" screen with a mobile celeron processor...

So I suppose I'd rather have a hardened version of this year's DS with the ethernet ports as they are, minus the ESD. This setup forces teams to get creative if they want fancy driver controls and doesn't limit the data display aspect of the overall system. I'm quite surprised I haven't seen more use of softpots, touch sensors, etc on the drivers station.

[Greg Needel]

I really like this idea.

What about processor slowdown with multiple applications running on the netbook, if teams can start writing apps or running things, I would hate to see a team's robot stop working because windows crashed.

Also we would need some mechanism to ensure that wireless communications on the laptops are disabled during matches otherwise adhoc networks could be used for external communications both good and malicious intent.

I think there is some serious potential there just needs to be alot of things to consider with this transition.

[Dave Flowerday]

Originally Posted by JesseK

I'm not just talking about how to control the bot, but also displays for state data, target tracking, and aesthetics (which are all important in industry). Try putting all of that onto a miniature 10" screen with a mobile celeron processor...

Assuming the netbook is a replacement for the DS, why couldn't you still include your fancy laptop as a Dashboard, just like this year?

[JesseK]

I guess I'm just resistant to this change upon the basis that I'd estimate that most teams get what they want out of the current DS already. The cool, nifty brainstormed ideas we have for next year are mostly based upon what we have learned about the data interfacing from this year. Changing the setup means that there is additional complexity added to what we may or may not want to do next year, which is already complicated.

I agree, most of the possible arguments I could present have ways to design around them (increased latency to the display, data corruption by the netbook, deadlocks). Yet with the current DS we all already have something that works for every team who wants to do anything from the simplest of simplest to the (somewhat) intricately complicated.

[Tom Bottiglieri]

Our robots communicate over wifi with relative safety. Why can't the driver's station? There goes the ESD problem.

[Tom Bottiglieri]

Originally Posted by Tom Bottiglieri

Our robots communicate over wifi with relative safety. Why can't the driver's station? There goes the ESD problem.

Just thought about this again. This doesn't solve the tethering in the pits issue, where the ESD incidents are occuring.

[Paul Copioli]

.... Or how about a company who already solved the USB hub problem without the need of an ooperating system make the driver station next year ...

I think many of us put too much stock in COTS solutions. How about those orbit balls? A solution from a supplier that has a vested interest in the success of its customers has always proven to be a better approach. In my real job, the suppliers that give us the most troubles are the suppliers that are larger than us and provide a COTS solution for our needs. Often times I find that an angineered solution for our problem is much less expensive and more reliable.