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.
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.
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.
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)
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.
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.
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…
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.
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.
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.
Cool! this will be nice if we blow another ds!
Could I have the source? this would be really useful. Also, can you plug in a flashdrive, and update firmware? THAT, would be Awesome!
This is a great tool, I can’t wait till the joysticks selection feature is released.
I’m very surprised that FIRST did not release a softDS instead of giving them out to 1500 teams. It would have been allot cheaper for them, they could have just had driver stations with the field and had USB breakout that uses HID.
EDIT: Having played with this a for about 2 hours tonight I would like to upgrade this from great to AWESOME!
The only thing it needs is the Joystick Selection and Feedback for DS Outputs.
This sounds like just what we need. We have two cRIOs and only one driver station. We are planning on using the second cRIO for demonstrations at our upcoming regional and the DS will be occupied.
Can a Labview front panel be running and displaying data in another window while the virtual driver station is running?
OK, I’ve got the next version ready for anyone who wants to try it out. It’s a pretty big change over the previous one. Here’s the features I’ve added:
- 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 (previous value remembered)
- Map real joysticks to DS USB ports
- Labels for DS inputs/outputs that are saved
Check it out and let me know what you think. I added another safety feature which is that the mouse must remain on top of the window or the robot will be disabled. This may be a bit too paranoid (and can be annoying), but without that feature it’s possible to click in another window and give it focus, and then the spacebar and/or ESC key no longer works to quickly disable the robot. Additionally, I had to change the key to change LCD screens from TAB to F1, and the reboot command is temporarily disabled.
There are labels for each of the digital inputs and outpus which can be edited. These will be saved when the program exits. Additionally, the team # that you are prompted for at startup will be saved as well.
Attached is a screenshot that shows the new version.
We don’t use Labview so I can’t say for sure, but I don’t see why not. When you say “front panel” is that the Dashboard or some other Labview thing? The catch with the Dashboard is that you need to set your computer’s IP address to the address the DS would use (10.xx.yy.5), and the dashboard data is sent to 10.xx.yy.6. A revision to come soon will allow you to override the dashboard and robot IP addresses to help with this problem. In the meantime if you know what you’re doing you can add the Dashboard IP address to your Ethernet network adapter in Windows (so it will have 2 address, 10.xx.yy.5 and 10.xx.yy.6) which should make it work.
The front panel is like a user interface; you can both view data from the cRIO as well as provide input. Others can describe it better. For our purposes, the virtual driver station would have to lose focus, so we’ll try using two laptops.
