Virtual Driver Station

[Dave Flowerday]

I started working on this last week before the Midwest Regional, and lately I've seen some discussion on CD about the possibility of doing something like this so I figured it might be a good time to post a preliminary version. There's a lot more I'd like to do with it but it's usable now for some basic things. This is a preliminary/preview version only at this point.

So what is it? It's a program that runs on your Windows PC and emulates (most of) the FRC Driver Station. It will connect up to a robot and send commands to it just like a real DS, including reading values from joysticks on your PC. Right now it simply reads joysticks in the order it finds them, though one of the first things I plan to enhance is to allow you to assign a particular joystick to a particular DS port (this is important to my team as we use ports 1 and 3 but not 2). Additionally you can control the driver station digital inputs (analog inputs yet to be implemented) by using keys on the keyboard. Finally, it will also send data to the Dashboard computer. See the readme.txt file inside the .ZIP for more information.

As far as usability, I make no guarantees at this point. Our drivers drove 111's practice robot for a half hour or so using this software and couldn't tell a difference between this and the real thing. However, if you use different joysticks than we do it's possible it might not map them correctly. If you find this to be the case, please let me know.

A word of caution: since this software can control the robot, it could be dangerous if not used correctly. I've implemented it to start up in a disabled state, and require a 2-key sequence to enable it. Even still, do not use this software while anyone is near the robot. Make sure everyone is a safe distance away, and make sure you are able to disconnect the network cable from your computer if something doesn't work right.

Hopefully some people will find some use in this. Given all the problems with the real driver stations, I think it could be useful (we have 2 DSes and both have failed in a different way). If you only have 1 DS and need to send it in for repairs, it's possible you might be able to use this to practice with in the meantime.

Attached below is a picture of what it looks like while running and the .ZIP file containing the program. Please see the readme.txt file contained within the program for more details. Again, with a limited amount of hardware to test with I can't make any guarantees that it will work for you. Also, again I will say to please be cautious when using it and make sure no one is nearby when you run it. Thanks.

[Jared Russell]

Awesome work. This will be VERY useful in the coming weeks...

[StephenB]

Actually, this already exists. We used it at NI for months before the DS company made the DS and got us a few. It is a LabVIEW application called the 'soft driver station'

I'm not going to just give it out because I bet if it wasn't public... there is a reason. I'll check into it and get back to you.

I applaud the effort you have put into this already, nice work.

[EricVanWyk]

Originally Posted by StephenB

I'm not going to just give it out because I bet if it wasn't public... there is a reason. I'll check into it and get back to you.

There is a very good reason it isn't public - it allows you to create unsafe situations. That code is in need of serious polishing before it can be unleashed.

[dpeterson3]

Nice job. You beat me by about a week (homework and the robot code have been cutting into my coding time lately). What language is yours in?

[Dave Flowerday]

Originally Posted by dpeterson3

What language is yours in?

C++. One of my goals was to have a stand-alone, small .exe that didn't need any extra DLLs or other junk with it, so that it can easily be run from a USB stick or whatever. I considered Python but honestly all the bit-manipulation is easier done in C anyway.

For those interested, here's some of the things I'm working on to improve it:
- GUI to set DS digital inputs
- GUI sliders to set value of DS analog inputs
- Display of DS digital outputs
- Prompt for team # at startup so you don't need to provide it as a program argument
- Map real joysticks to DS USB ports
- Virtual joystick support (a joystick widget that can be manipulated on-screen via mouse)
- Ability to run without needing to change your Ethernet IP address settings (I prefer to just leave my Ethernet port on DHCP)
- Adding an RC simulator (already have a basic version of this since it's hard to find time to test with the actual robot)
- Properly emulate DS's ability to randomly stop working when it detects static charge in the air (just kidding)

[Daniel_LaFleur]

Originally Posted by Dave Flowerday

C++. One of my goals was to have a stand-alone, small .exe that didn't need any extra DLLs or other junk with it, so that it can easily be run from a USB stick or whatever. I considered Python but honestly all the bit-manipulation is easier done in C anyway.

For those interested, here's some of the things I'm working on to improve it:
- GUI to set DS digital inputs
- GUI sliders to set value of DS analog inputs
- Display of DS digital outputs
- Prompt for team # at startup so you don't need to provide it as a program argument
- Map real joysticks to DS USB ports
- Virtual joystick support (a joystick widget that can be manipulated on-screen via mouse)
- Ability to run without needing to change your Ethernet IP address settings (I prefer to just leave my Ethernet port on DHCP)
- Adding an RC simulator (already have a basic version of this since it's hard to find time to test with the actual robot)
- Properly emulate DS's ability to randomly stop working when it detects static charge in the air (just kidding)

Could you add a virtual e-stop (just in case) and a watchdog (in case windows decides to not talk to the virtual DS)?

[Dave Flowerday]

Originally Posted by Daniel_LaFleur

Could you add a virtual e-stop (just in case) and a watchdog (in case windows decides to not talk to the virtual DS)?

E-Stop: I suppose, but what's the advantage of this over simply disabling? The spacebar or ESC can both be used to disable the robot (they are not toggles - if you hit either of them it sets the state to disabled no matter what the current state is). There is no E-Stop on the real DS either unless you're connected to the field control system (unless I'm mistaken?).

Watchdog: I'm not sure exactly what you're asking for here. It's already set up such that if it misses more than 5 packets from the robot (approximately 100ms), it disables the robot and takes it out of autonomous mode.

[Daniel_LaFleur]

Originally Posted by Dave Flowerday

E-Stop: I suppose, but what's the advantage of this over simply disabling? The spacebar or ESC can both be used to disable the robot (they are not toggles - if you hit either of them it sets the state to disabled no matter what the current state is). There is no E-Stop on the real DS either unless you're connected to the field control system (unless I'm mistaken?).

Watchdog: I'm not sure exactly what you're asking for here. It's already set up such that if it misses more than 5 packets from the robot (approximately 100ms), it disables the robot and takes it out of autonomous mode.

E-stop: Didn't see this in any of your posts. Only saw a 2 key enable.

Watchdog: If the program hangs (not responding), how does it send the disable/teleop bits?

[Dave Flowerday]

Originally Posted by Daniel_LaFleur

E-stop: Didn't see this in any of your posts. Only saw a 2 key enable.

It's in the readme.txt file included in the .zip.

Watchdog: If the program hangs (not responding), how does it send the disable/teleop bits?

If it hangs, it's not sending any packets. If it's not sending packets, the watchdog on the robot will take care of disabling things, just like if the real DS hangs or if things become unplugged, etc.

[writchie]

Originally Posted by Dave Flowerday

... I considered Python but honestly all the bit-manipulation is easier done in C anyway.

Perhaps you overlooked python struct. It doesn't get easier than struck.unpack_from(), especially in cross-endian situations.

Great job!

[Dave Flowerday]

Originally Posted by writchie

Perhaps you overlooked python struct. It doesn't get easier than struck.unpack_from(), especially in cross-endian situations.

I'm well aware of struct in Python. It operates on bytes, not bits. Several things in the data stream are bitfields, and it's hard to beat a C struct with each bit individually named that you can just set to 1 or 0. Python structs don't allow this that I'm aware of.

[writchie]

Originally Posted by Dave Flowerday

I'm well aware of struct in Python. It operates on bytes, not bits. Several things in the data stream are bitfields, and it's hard to beat a C struct with each bit individually named that you can just set to 1 or 0. Python structs don't allow this that I'm aware of.

Not built in. But a relatively simple class like that discussed here keeps it pretty easy.

http://code.activestate.com/recipes/113799/

I'm not trying to start a flame war. Either C++ or python are good choices, depending on portability requirements. Which is easier depends on the person and the tools at hand.

[EricVanWyk]

Originally Posted by Dave Flowerday

- Properly emulate DS's ability to randomly stop working when it detects static charge in the air (just kidding)

Let me know if you need help with this. I did turn an early prototype of the PD into a static sensor - the blown breaker LEDs would glow when something statically charged approached the robot. If only I could do this on purpose...

[Dave Flowerday]

Originally Posted by EricVanWyk

Let me know if you need help with this. I did turn an early prototype of the PD into a static sensor - the blown breaker LEDs would glow when something statically charged approached the robot. If only I could do this on purpose...

Heh. A couple of years ago, I was working on board bring-up and the bootloader for a brand new PowerPC control board that we were developing for our 2-way radio networks. Things were good except for a mysterious reset that occurred randomly that I couldn't track down for about a week. I'd leave the board up and running all night and it would be fine, but as soon as I got to work the next morning it would reset within a half hour or so. After a while of trying to figure out if there was some funky network traffic at 8am or something, I happened to notice the reset LED sequence after standing up from my chair. Sure enough, with the board sitting about 3 feet away from me I could reliably reset it by simply standing up out of my chair. The static buildup from the fabric chair was enough to do it, and the reset was occurring when I stood up to go get a cup of coffee each day. That was definitely an interesting bug.