An open-source, cross-platform Driver Station...



During the last months, I have been working in a cross-platform and open source alternative to the FRC Driver Station. Currently, the application is able to run on Windows, Mac and Linux. However, I am also implementing a mobile version, which would work on Android, iOS and Windows Phone.

This driver station supports the 2015 protocol, however, I have made it relatively easy to implement different communication protocols, since I separated the UI and the Communication library into different projects.

While there is still a lot of work (and testing) to do, I would really appreciate if you could test the application and send me some feedback about it. As you may expect, code is always welcome.

Please note that the mobile version is still under heavy development, so for the moment there are no binaries/installers available. I will upload them when the application is fully functional and thoroughly tested.

By the way, you can drive the robot with a “real” joystick or with your keyboard :cool:


(edit) For everyone who downloaded the application before November 8th:

I strongly recommend you to download it again, as I updated it to include an auto-updater and fixed some bugs with the keyboard/virtual joystick.


  • Both the mobile and desktop version use the same library to communicate and manage the robot.
  • In the desktop version, joystick input is done via SDL2. If you decide to test this application, PLEASE
    check how SDL maps the joystick (in the same way as you do with the official Driver Station). Avoid involuntary robot movements! If you are unsure about this, use the “virtual joystick” option before testing it with a real joystick. - This project is written in C++ using the Qt toolkit.



This is awesome!. I love open source projects. When I get access to a robot on Monday, I will try it out on Windows, OS X, and iOS.


Thank you very much for your interest in the project! You are welcome to try out the application on iOS, however, please note that the mobile version is still in the alpha stage:

  • For the moment, you will need to compile it by yourself. I have included the build instructions in the readme file of the repository.
  • Some features will be missing and you will
    encounter bugs in the mobile application


I’m speechless… this is awesome


I’m also excited to try this out on a robot. This should save my team a bunch of table space. That may seem like an odd thing to say, but our solution to the the problems of the driver station not running on Linux and E-stopping on spacebar has been to use twice as many computers, half for development, half for running the driver station. This should solve both of those problems.

I’ve successfully built and started the program on Ubuntu 15.04. For others who are trying this I would recommend the following command:

sudo apt-get install libsdl2-dev qtcreator && git clone && cd QDriverStation && qmake && make && sudo make install

I tried installing the proper Qt development libraries piecewise without Qt Creator and I got to a place where it wasn’t obvious what part I was missing, but Qt Creator must have depended on it because installing it solved things.


I’m not huge into code, so forgive my ignorance…

Is there any way that this could run on windows rt? The processor (ARM cpu) can’t run .exe so are you going to turn this into a windows app or anything like that? Thanks.


AFAIK, I can compile the application for Windows RT. If so, I will upload a RT installer the following week.


This is awesome! I have worked on an Android driver station, but haven’t had time to finish it. Your application looks like it can (or will be able to do) everything I need.

I’m working on an Arch Linux package for the desktop version, which I’ll upload to the AUR, in case anyone wants to use it.


I finished the Arch Linux package (at the expense of the timely completion of my homework), available here.


I can confirm that it installs correctly. Awesome work. :smiley:

Also Awesome work to you spat!


This looks really awesome! Do you know if the drivers station would work on the raspberry pi or would the pi not have the power to run it? If it could it would open up some cool opportunities.


Well, it runs on Linux and it does not consume too much RAM memory (approx. 15 MB on my laptop). If the current version is too heavy for it, I could easily make a “terminal” version of it, as I implemented the code that communicates and manages the robot in a separate library. In other words, I would only need to write the UI/GUI part :slight_smile:


I love this! Any advice for (potential) contributors?


Imagine if you could run this on the RoboRIO itself over ssh…


The way the communications between the DS and the robot work would make this relatively difficult. But, given the appropriate network configuration, you could drive a robot with another robot… :cool:


You could run the DS on a Raspberry Pi attached to the robot.

Note I do not condone doing such thing. There is a very good reason they don’t allow you to enable robots without having the driver station connected. Rogue randomly moving robots are VERY dangerous. Having the DS on the robot might sound like a good idea, until its randomly driving away towards a crowd of people and you have no way to stop it…


I’m glad I’m not the only one concerned by the DS discussions on this thread.

The FRC robots can be very inspiring. Or they can hurt people – permanently.

Especially when others are around your robot, please be sure that you all know how to operate it safely. That means whatever DS you are using works reliably and all present team reps know how to stop a robot being driven by, oh maybe, your grandma or a show-off teenager who thinks they are playing GTA with your robot.

Also consider making a demo-mode, with scaled down speeds and removing pointy things and spring-loaded whammies.

FIRST has left the protocol open, meaning that you can build your own DS. The robot code will default to safe if the DS crashes or the communications gets scrambled. But it will not be safe if the DS is unresponsive to the operator or goes into a loop sending commands with no way to stop it except for a tackle.

Please be safe. Test whatever DS you are using, and think of it as an important safety feature.

Greg McKaskle


I agree with you.

As for this application, I have implemented a watchdog timer that will disable the robot and “reset” the communications if no robot response is received. As for the sending part, I do not use any loops, instead, I use some timers that run on a separate thread (to ensure that they are triggered at the correct time frames).

Our team has tested the application thoroughly, and at least with the robots of my team, we did not have any issues. Just as a side note, you can trigger the emergency stop by pressing the SHIFT key, not the SPACE key. The reason behind that is that some widgets or the OS itself may reserve the use of the spacebar key.

As for the discussion of a robot driving another robot, I stated that it is possible (theoretically), however, I would not want to try it and I do not condone such behavior.

Finally, I also agree with you about the “demo-mode”. The robots that we use for public presentations have an option in the SmartDashboard to control the maximum speed that the motors/actuators can have, this can be useful for presentations, testing and in the competition itself.

Every team member should also have basic knowledge about how to operate a robot, being safe while driving it and know what to do when the robot misbehaves.


Since I mentioned that I was excited to try this out I thought I’d give an update. At our latest meeting one of our students tried the program out on Ubuntu 14.04 and here’s what he found:

  1. Our robot wouldn’t connect.
  2. Our switch panel wasn’t recognized.
  3. Gamepad inputs were mishandled.

We haven’t taken the time to really dig into it, so it these might all be things that could be easily overcome but the out of the box experience was a bit underwhelming. I’ll now elaborate a bit about the problems:

  1. Maybe we had a network misconfiguration somewhere? I don’t know; we’ve been able to download code to it from the computer we used. I guess I’ll have an excuse to teach people how to use Wireshark.

  2. We’ve never tried to do anything with our switch panel on Linux before so it might be a driver issue rather than a bug in the program. There are some diagnostics we can run. But since our switch panel is TI Launchpad-based and not doing anything unusual software-wise this seems like something that other users might run into as well.

  3. We had some axes turned into only three values: 0%, 50% and 100%. We used a Logitech F310, (the most common one). When we talk directly to the kernel we get the proper values out so the issue is somewhere in userland. I’m confident that this could be either fixed or worked around. However, the fact that this wasn’t working right makes me suspect that nobody had tried our OS/library version combo with a robot before.

Has anybody else tried the program out with a robot? If so, how did it go for you? And can you describe your setup?



The 2015 protocol relies on mDNS for finding the IP of the robot, however, it may not work neatly with every OS. I am working with that issue. For the moment, try to ping your robot and put the IP of the robot in the “custom address” field in the preferences dialog.

About the joysticks
Our team does not have your kind of joysticks, we only have Xbox 360 joysticks. The problem is that I have not made a mapping for your joystick, and the application will apply an Xbox 360 mapping to “un-mapped” joysticks.

I will see if I can get your joystick to test it, if so, expect an application update soon. For the moment, try to use an Xbox 360 controller or configure the keyboard/virtual joystick.

Thanks for your feedback!