Driver Station on Linux

Hi, I’m looking for a way to use the FRC Driver Station to deploy robot code from my laptop, which runs Linux (Fedora 31). I can’t really find anything helpful. I’m also not interested in using WINE.

Any help would be greatly appreciated

As far as developing and deploying code goes, WPI have a setup guide for running vscode with the WPILib libraries and everything on Linux here:
https://wpilib.screenstepslive.com/s/currentCS/m/java/l/1027503-installing-c-and-java-development-tools-for-frc

If what you actually mean is not deploying code and you wish to control the robot from your Linux computer (as you don’t need the driver station to deploy code), unfortunately the only officially supported platform in windows, so no luck there.
However, while certainly not competition legal or endorsed by FIRST, some clever people have reverse engineered the communication protocols so I’m sure someone has created a driver station for Linux, I know I knocked a very basic driver station up in Python so it’s certainly possible.

Edit: As a side not to developing code, you may have trouble with some vendor libraries that don’t run on Linux.

Please use docs.wpilib.org, as that link will be invalid and 404 in about a week.

Also, look into rs-ds, a rust based driver station. It’s quite nifty.

Although this is outdated and doesn’t work with 2018 or 2019 robots, this is worth mentioning: https://github.com/FRC-Utilities/QDriverStation

If you’re talking about deploying code, look into setting up WPILib and GradleRIO.
If you’re talking about using a driver station to drive a robot, there are libraries like LibDS that you can use to make your own. Alternatively, you can do it from scratch, as the FRC driver station just sends UDP packets to the robot (which you can replicate). https://frcture.readthedocs.io/en/latest/index.html if you’re interested.

I’m in a similar situation. I’ve done a fair amount of research into this, since our team can’t devote many resources to buying laptops, we’re left with whatever’s donated. Best way to squeeze more life out of em is to run a lightweight Linux distro, but I digress.

Point is, I’ve done a lot of research. While we had QDriverStation for a while, but that’s out of date.

We also have LibDS, but from what I can tell, it only works with 2015/2016. I haven’t really dived into the protocol that much, otherwise, I’d have just built something myself. (I’m still not opposed to this, but to really test it, I’d have to get my hands on a dedicated RIO, which kinda nullifies the point of everything. :confused: )

Point is, it appears that we have one option for a DriverStation on Linux, until FRC decides to release support. Hopefully they’ll get around to it, but I’m not holding my breath.

Wine. Yeah, it sucks, but for testing, it should be fine.


What we really need is first-class support for something like protocol documentation or a C library from the devs.

Interesting that today you can walk into Walmart and buy a new Windows laptop for $200.

Used ones cost even less?

And the specs to run the driver station are not very big.

So, that means you must want do to this mostly for the challenge, or because you really really don’t like Windows. Either one of these is a valid reason. I hope you get it figured out.

I did all of my development on Linux last year without any problem, a pleasant surprise.

I used VirtualBox for the drivers station and the RIO imaging utility. This is less of a issue for us because we have a dedicated laptop for only using as a driver station, so I very rarely had to use it on my development machine.

If you have older machines, you can buy SSDs on Amazon for about $35. It makes a big difference.

I personally hate using windows, my computer is well specced anyways. I’m up for the challenge as well

Can confirm, have run the driver station quite fine on a $129 laptop.

Thankyou for the reminder, still getting used to it!

If it’s a passion project of yours to get a driverstation working on linux, go right ahead. But if you are just looking for the ability to drive the robot from a linux machine, running a VM is the way to go.

I want to add a little caution to this. Last year we used a windows 10 tablet for our driver station and while it worked fine for our testing and drive practice, its CPU was pegged at competition. The FMS triggers a lot more logging on driver station computers and it caused us lots of problems. We switched it out with a Microsoft Surface and had no further problems.

I would not recommend a mobile processor, atom, or celeron for a driver station and I’d recommend an i5 or better. I would also recommend at least 4 GB of RAM to be safe.

3 Likes

Yeah, I’m aware. I’m just trying to avoid forking out personally. We have a stupid budget allocation issue… (0% for laptops)

The concern in our case is that when testing multiple iterations of the bot, we’ll need multiple driverstation machines, since you can’t control more than one robot from a single laptop. So, that $200 per laptop becomes $400 for our use case.

It seems that we have this thread every couple of years. At the end of the day, if the driverstation software wasn’t written in the abomination known as LabView, we wouldn’t be having this discussion, but I digress.

Making a robust driver station application is much harder than it sounds, regardless of language. It’s hard to make it robust even when only targeting one platform; multi-platform robustness is exponentially harder and would require significantly more development resources. Most of the stuff the DS does is very platform specific: joysticks, network interfaces, firewall control, etc, so about the only truly multi-platform “common” code is the network protocol implementation, which is a very small part of the overall application. Every platform has its own quirks and challenges: firewalls on windows, joysticks on anything other than windows (although windows is very complex too–there’s 3 OS frameworks to talk to joysticks!), Mac is its own special world, every platform has its own GUI framework, etc. You would basically end up nearly writing the entire DS over again for each platform for it to be as robust as the Windows version on each platform.

2 Likes

I was simply remarking on the fact that it would likely work much better on Wine for testing if we weren’t stuck with the labview runtimes.

Again, I’m not looking for something to take to competition. I’m looking for something to test code with in the classroom.