Introducing OpenDS: A lightweight cross-platform FRC Driver Station alternative

I am pleased to announce after several years of research and development…OpenDS!

Links: Download (JRE/JDK 8+ required)| Source Code | Website

OpenDS is a fully functional FRC Driver Station alternative for Windows, Linux, and macOS systems. All the features of the official Driver Station are implemented in OpenDS, meaning teams can use it in the place of the official Driver Station when testing robot features away from the competition.

OpenDS is extremely lightweight (about 0.25 MB) and does not require an installation of any kind, unlike the official Driver Station which has a lengthy installation process and heavy install footprint.

NOTE: OpenDS may not be used during FRC-legal competitions as per rules R66 and R88. OpenDS is intended for testing use only.

As this is an early version (v0.2.0) there are likely to be bugs and partially implemented features. Please report these to the issues section of the GitHub repository.

At present OpenDS supports 2020 and 2021 robots with the 2014, 2015, and 2016 protocols implemented but untested. Refer to the GitHub repository above for the latest supported protocols. OpenDS can also be easily modified to include future protocol years.

Special thanks to Team 5818 for letting me test this on a RoboRio!


Rock on! This looks awesome!

1 Like

This is so awesome, kudos for the work that went into this!


does not require an installation of any kind

You must have Java (JRE or JDK) 8 or newer installed (download here)

Slightly misleading… Either way, nice job!

Can you talk a bit about your safety strategy? Specifically how do you make sure that when the robot is commanded to disable it will actually disable, even if the program freezes, crashes etc.

The existing driver station uses space bar for e-stop, the enter key for disable, and []\ for enable. These work even if the window is not in focus. Are these features supported? This is important, for example if one of my students is operating the robot, and the robot starts behaving in an unexpected/unsafe way, I want to be able to smash the enter key without having to worry that the right window is open.


OpenDS uses the same communication protocol as the normal Driver Station. As such it will do the same things as the normal DS would if it crashes, freezes, etc. The robot needs a specific set of data sent to it at specific intervals to enable, otherwise it disables. Thus if the program freezes or loses connection to the robot the robot will automatically disable.

EDIT: The below is no longer correct as of version v0.2.1. The enter and space hotkeys are implemented regardless of window focus (i.e. globally).

The space and enter hotkeys are implemented if the window (or any of the created sub-windows) is/are in focus. Unfortunately Swing (the GUI framework (?) I used) does not support “global” listeners as far as I know, so it’s just while the window is focused. I am looking into writing some native code to make that happen. It’ll probably be with the next release.

1 Like

I understand this point, but it actually is specific to the program implementation. For example, lets sey we have some custom driver station, where, like a good programmer, we separate the UI elements from the business logic. When we hit the enable key, the UI tells the back end to start sending enable packets. Then the UI side freezes. Does the back end recognize this and shut things down? Does it also freeze, thus triggering the timeout as you mention? Or does it keep sending enable packets?

Without reading through the source and testing its hard to say, which is why I wanted to ask here.


The backend runs on a loop that checks the frontend each cycle, so if the backend can’t get (for example) the status of a checkbox from the frontend then the backend won’t do anything. It just stops and doesn’t send anything to the robot.


Please let us know when that out-of-focus spacebar e-stop gets implemented. This type of DS could be in high demand, and I will try it out, but it definitely needs the core safety features of the NI DS - even for a lab setting.


Alright @JesseK @Will_Toth here’s v0.2.1 with the global key listeners. It’s much heavier than I would like, but it will work until I get around to writing my own library.


Version v0.2.2 has been released for compatibility with the 2022 protocol. This release has not been tested extensively on hardware and thus may contain bugs. Please report these to the issues page!


For anyone having trouble running OpenDS on an M1 Mac, version v0.2.3 adds support for M1 Macs.


I love how you say openDS is lightweight, but you use the java runtime which I doubt is lightweight.

In comparison to all the lab view/NI stuff, it is quite light wight.

I avoid downloading lab view on my main machine at all costs.

Depends on whether you bundle all your dependencies and the JVM in an uber jar. That can be at least 100 MB. Performance can vary. Things that need performance generally call into JNI so the fast parts aren’t even Java.

There is also Conductor. A rust based driverstation that is cross platform and extremely performant and matches feature parity for the DS. Conductor


The logic behind calling this lightweight is that it is intended as a development platform. Most teams use Java, so people should have the JVM in some form. Thus it’s only a few hundred KB extra (in size, I am aware that Java is “heavy” on performance) so it’s lightweight. Also yes there is Conductor, but it’s more common to have the JVM installed than Rust (you can download the binary too, I’m just trying to make something cool with OpenDS).

With Conductor you can just download the binaries.


I’d rather have software that is more accessible by extension or utilization than give 2 cents of care about a marginal difference in performance of space/memory/cpu between languages. Java suits FRC’s needs perfectly fine.

1 Like

Version v0.2.4 has been released. Several bugs have been fixed, threaded process management has been optimized, team numbers are persistent, and command line parameters are now supported. Joystick axes can now be mapped to any control axis on the robot, and auto-detection of axis mapping has been improved. The frontend now uses tabs instead of independent windows to minimize screen clutter. Please report any issues to the issues page!


In the process of auditing this, will report back with focus on the safety-critical aspects mentioned.

One things that have really stuck out to me is that the level of integration with the FMS doesn’t seem to be completely 0. I would caution any level of communication with an FMS as a mistake, as even if the DS doesn’t correctly respond to challenge/response (which I highly doubt it does, based on the years-old responses torn from FRCTure), it still opens it up much more to people trying than a blanket “This functionality does not exist”, and the best case that comes from that is dead robots and annoyed FTAs.