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

Hello!

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:

Links:

• Contact me by e-mail: alex_spataru@outlook.com
• Official website: http://qdriverstation.sf.net
• Download beta installers (Mac & Windows): http://sourceforge.net/p/qdriverstation
• GitHub Repository (desktop version): https://github.com/wint-3794/qdriverstation
• GitHub Repository (mobile version): https://github.com/wint-3794/ds-mobile
• GitHub Repository (communication library): https://github.com/wint-3794/libds
• Facebook page (brand new, for updates regarding development and features): http://facebook.com/qdriverstation

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

Notes:

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

Greetings!

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

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.

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

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

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

I'm speechless... this is awesome

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

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:

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.

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

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.

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

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

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

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.

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

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

Also Awesome work to you spat!

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

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

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

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

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

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

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

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:

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

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

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

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

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

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.

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

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?

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

Networking...

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!

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

I will definately try giving the IP address of the robot to the station. That would be an easy fix.

Regarding the gamepad, for some reason I was thinking that the Logitech F310 was what came in the kit last year, which is why I was surprised that it didn't work. Looking it up I see it was the Xbox controller. Now I get why it might not work right out of the box.

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

I changed the code that reads the joystick in such a way that it does not apply any kind of mapping, in other words it will use the values reported by the kernel. Especially if you are running Linux or Mac OSX.

Be advised, while your joystick might work, it may report the order of axes/buttons differently than the official Driver Station. Please take that in consideration before enabling the robot.

As a side note, I have tested the application with gNewSense 3.1, since Unity and/or Gnome run very slow on my computer.

You can download the latest snapshot of the code here. You can check the Travis build file to compile the DS.

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

I'm happy to hear your statements on the safety issue. I wasn't making claims directly about your DS implementation, by the way, just more generally making sure that people don't get carried away and forget about the potential for harm.

You mention different keys. With any implementation, things may need to adapt. This is no issue as long as people in charge of the robot know the procedures for the one they are using.

Greg McKaskle

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

Slightly off topic, but in terms of having the e-stop key mapped to the shift key, this seems (to me) like a really sensible thing to do given spat's explenation. Is there any reason why future offical driver stations can't re-map e-stop to the shift (or maybe have it on both space and shift for historical consistency)

Also, I'd like to raise a concern in that the keyboard mapped e-stop dosen't seem to work when connected to the FMS. Normally, this is not an issue as the FMS has e-stops. However I was doing some testing recently with some robots and FMS light, and through some combination autonomous became activated when it shouldn't have been. We then had a robot running wild, while I madly mashed the space bar. Thankfully no-one was injured.

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

Remapping keys:
This sounds like a good thing at first, but imagine if the brake and accelerator pedals, the blinkers, horn, and other key features could be remapped in a consumer car. The user/consumer would then be in charge and would have a more custom and arguably better experience -- until a valet or stranger needed to drive their car. My car lets me remap a few roller buttons, but they are never to critical features or safety features. Even those changes cause confusion sometimes since I'm not certain what they do at that moment.

Similarly, I'd prefer that DSes try to match the ad hoc standards of the official DS. I haven't heard back from Spat yet, but it sounds like an implementation issue and not a "better" standard. If it is, we will certainly consider something like you mention.

Of course if a device doesn't have a keyboard, it still needs safety actions, and those will have nothing to do with a spacebar. So I hope that a few folks will develop good standards and others will generally follow them.

Offseason Estop:
If I correctly understood your request, I think you'll see it implemented this season, much as you requested.

Greg McKaskle

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

Or implement it in Javascript and have it delivered to a Chromebook via a web server on the robot.

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

As the readme in the project says, the aim of the LibDS library and the QDriverStation itself is too look and behave as close as possible as the official Driver Station.

The problem about the e-stop trigger key is an implementation issue. I would like to follow the 'standards' of the official DS and be able to stop the robot with the spacebar.

However, the behavior of the application when the spacebar was pressed depended on which widget was focused/selected. In other words, you could never be certain if the spacebar would trigger the e-stop, and a driver should be able to stop a misbehaving robot immediately.

Until I find a fix for this issue, I allowed users to trigger the e-stop function when pressing any of the shift keys. Of course, the option will be remapped to the spacebar when I find a safe method of detecting keyboard input (maybe with SDL, which also gets joystick input).

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

The user interface looks great. I've been wanting a Mac based driver system for a long time, and I'm looking forward to putting this to work.

I'm afraid I also can't connect to my roboRIO. I am able to ping and ssh to my mDNS address. I tried updating the custom address to the actual IP, but that didn't help.

I am currently seeing the following error messages:

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

I tested the DS a few days ago (rev 8c65fc4df43e4f644d8939f0fee5978e82dad794) and it did not work. I could ping the roboRIO, but the DS didn't connect. I did not check the console output. I was using Arch Linux.

I'll test the latest revision sometime in the next few days.

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

I have checked this issue, mDNS does not play very well with Qt...so I am currently making my own implementation for it to work on mobile and desktop devices (without the need of installing Bonjour or Avahi).

If you compile the latest version, you will need to set a custom/static IP for the robot to work, since my implementation is able to send query messages, but I still haven't put the code for interpreting response messages. Of course, this will be solved when I release the next binary installers.

As a side note, the development release will change the color of the communications LED to yellow if the DS is able to ping the robot, but does not receive any responses to the DS packets.

You can get the latest code here.

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

The error messages are the logs of the auto-updater, they do not have anything to do with the DS/robot stuff.

On some systems (e.g. OS X 10.11 and Android) mDNS failed to report the robot IP to the Driver Station. To avoid this issue and to make the DS work on mobile devices, I began implementing an integrated mDNS responder, which will be available on the next major release, hopefully fixing these issues on all operating systems.

If the DS fails to connect to the robot, you can:

- Compile the latest version (code and instructions are here) and try it out. If so, you will need to set the custom IP, since I implemented the code to send mDNS queries, but I still have to work on interpreting mDNS responses...this will be fixed before the next binary release

- If you don't want to go through the compilation procedure, the QDriverStation will notify you when I upload the binary installers (which will be in one week or two from now). Just be sure to launch the DS with a working Internet connection from time to time.

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

Looks like this project is really getting along. That's awesome, maybe I'll get to try it sometime.

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

I tested the DS a few days ago (on Arch Linux) and was able to control a robot, but there were a few issues.

There seems to currently be no way to rearrange joysticks, unless I am missing something. I was able to work around this by unplugging the joysticks and reconnecting them in the right order.

When I first enabled the robot, it started driving away without user input, but was able to be stopped using the emergency stop. We spent around 30 minutes practicing with the robot afterward and this never happened again, but it still makes me a little scared.

After the robot was e-stopped, I could not reenable it until I had restarted both the driver station and the robot at the same time. I think this was because the DS immediately e-stopped the robot when it reconnected. I'm not sure if this is the intended behavior or a bug.

Thanks for your work on this project.

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

I was messing around and made a deb file on Ubuntu 15.10 to install the Driver Station. There is no .desktop file right now. So to launch it you have to type qdriverstation in the terminal.

https://drive.google.com/file/d/0Bwm...ew?usp=sharing

For those who are curious, I made the package running this command:

$ sudo apt-get install libsdl2-dev qtcreator qtmultimedia5-dev libqt5multimediawidgets5 libqt5multimedia5-plugins libqt5multimedia5 && git clone https://github.com/WinT-3794/QDriverStation.git && cd QDriverStation && qmake && make && sudo make install

$ checkinstall

after i answer all of checkinstall questions it built the deb file.


if you have a problem building you might have to set qt5 as default if you have multiple version installed which you can do with " sudo apt-get install qt5-default ".