Alternative to NI's FRC driver station?

Hi, recently I have noticed how much NI’s FRC driver station just kills my laptop’s batter and takes up significantly larger amounts of resources than I would expect for basically I client interface. Are there any alternatives?

I have also been debating trying to create my own version of it that
a) doesn’t hog resources
b) doesn’t need to be installed with the entire NI package
c) doesn’t have labview a dependency (I strongly dislike bloatware)

If there isn’t an alternative, would other people be up to collaborating and creating a better driver station?

One more question, if we did create another driver station, can we use it in competition? Or would we risk having issues with the field system?

Ok, so only NI Driverstation for actual competition and Conductor (driverstation alternative) is disabled on Windows for safety issues. And apparently NI Driverstation is actually doing a lot behind the scenes. Duly noted.

I’ll let somebody else take care of the rest, but the answer to this is a firm no. You must use the NI Driver Station at competitions.


Conductor is a good option for an alternative driver station from what I’ve heard. It’s cross-platform and open-source, so your point about collaboration has already been done.

You must use NI’s driver station in competition. If you’re having trouble running NI’s driver station on your team’s driver station laptop, I highly recommend an upgrade.

I’m a bit confused on these points. The Driver Station doesn’t require installing all of LabVIEW. Despite the “LabVIEW Update Suite” branding, it can be installed on its own without anything else.


Please note that Conductor is intentionally disabled on Windows.

sudo Can we have an open source driver station?


Could you be more specific? I just fired up DS and stock dashboard (granted I don’t have a robot to connect to) and combined they’re taking up 2.3% CPU cycles and 110 MB of RAM, which I don’t think is too bad. And the driver station runs on those Classmate laptops they gave everyone, so it can’t be THAT much of a resource hog.


Since it’s open-source, it looks like you could get around that by commenting out the block starting on line 30 in and building it yourself:
Do not do this, at the moment E-stop is broken on Windows.

But based on the fact that it’s intentional and appears to have been done at the request of you, a WPILib developer, I assume there’s a very good reason for it.

1 Like

Wait how do I install it on its own? I used the NI installer and it installed labview and I can’t uninstall labview without uninstalling the driverstation.

Why is it disabled on windows?

This is my battery usage from earlier today after using it for about 2 hours.

and somehow, IDLE, driverstation is using more CPU than chrome
This is without even being connected to a robot.

1 Like

I don’t know exactly how Windows computes “battery usage”, but considering all the stuff the driver station has to do in the background (polling for USB HID, trying to find a robot with IPv4, IPv6, zeroconf…), I don’t think you could write a program that does all the same stuff with significantly less CPU usage. Also, Chrome is using few cycles when idle, which is what you want with a browser. On my computer, the Chrome CPU usage spikes up to 12% for a few seconds when I just open a new blank tab. FWIW, my install of Win10 thinks that the driver station’s power usage is “low”, but I don’t know how that’s calculated either.

Please don’t do that. For safety reasons. Global keyboard shortcuts for Estop and disable will not work, making this workaround very unsafe.

1 Like

Theres actually not a whole ton of difference between not being connected to a robot and being connected to a robot. Its all just done over UDP, and because of how the DS protocol works it is just sending the normal packets at the normal rate, and then using if a reply was received to detect if a robot is connected or not. At the same time, it keeps attempting a TCP connection to what should be the FMS, to know if there is an FMS connected. So the difference between connected and disconnected isn’t much. And as said above me, theres actually a lot of work being done to make everything work and be responsive on the field. Holding a 20ms timer requires turning up the windows timer resolution, which will increase battery usage. A web page doesn’t actually have to do anything when idle, unlike when the DS is idle, where it still has to do work.

As for installation, you don’t need the full labview install to install the DS. The FRC Game Tools package includes the runtime and everything needed to install the full DS. Now if you have installed full LabVIEW, is probably not super easy to remove it, rather then just removing it all, and then just installing the game tools by itself.


This is actually due to developer not wanting their application to be even have the chance of mistakeingly being used in a competition setting. There is also safety features that straight up don’t work on Windows (spacebar e-stop).

Please don’t work around it. Use the NI driver station and just deal with it or get a better machine… Or change OSes if you care that much.


Why leave the DriverStation up for 2 hours? I just close it whenever done with it (you will have less problems too!).

This covers it, see Windows global keybinds by TheTripleV · Pull Request #13 · Redrield/Conductor · GitHub for more details


Well, I was working on robot code for 2 hours

1 Like

Given that cross-platform DS has been coming up a lot lately, any chance it will get official attention?

Judging by what I’ve seen, I’d say it has received official attention. But nobody official wants to pour paid time and effort into it.

I think that’s a fair position for NI. After all, they have other priorities too, and what would everyone actually gain from such effort?

I see a benefit for low resource teams inheriting old hardware. WIndows is expensive. When I was working with 5499 we would have totally used Linux if we could. Instead we ended up acquiring Windows through less-than-official means.