Best Driver Station Alternative

You can just run the driver station software on the windows machine and do all the coding and deploying on your Mac.

2 Likes

What a coincidence! Thanks, I’m going to try to do the make again tonight and create that issue.

1 Like

Quick Question, how did you install WebKitGTK on Mac. I’m not exactly sure how to build it from that website cause I am not totally familiar with make or CMAKEing something?

Yes, but sometimes I don’t have access to that computer or it is dead because it barely lasts five minutes.

The Windows-only compatibility is most likely because the driver station is built on top of lab view

This was a bad decision by FIRST and NI. The tool could be electron or QT based to have compatibility across all platforms

Recently, labview libraries stopped working on my laptop and after several hours of debugging and trying to fix, the solution that worked was to Reimage the laptop

2 Likes

Do you know OpenDS? I never tested it, but it received a protocol update of 2022.

  1. The DS is designed and built by NI. LabView is a natural choice for NI to use, for obvious reasons.
  2. The DS was initially designed in 2009 to run on the Classmate netbook (Atom-based). Electron did not exist, and isn’t a good choice for hard real time applications anyway.
  3. Compatibility across all platforms is more complicated than just the dev environment / windowing toolkit. Joystick consistency (button and axis mapping and how things enumerate) is notoriously bad across platforms. The DS also does a lot more than just read joysticks and send them to the robot. For example, for robustness at events, the DS does some low level (platform specific) things with DHCP leases and network interfaces.
  4. NI only supports USB connections to the Rio on Windows. The Rio and radio imaging tools only run on Windows. Etc. So Windows is required for more than just the DS.
  5. It’s much easier for support reasons for FIRST to require a single OS at competition events. That way when issues happen at the field the FTA and CSAs only have to know debugging/common fixes for one platform. Similarly, from a development perspective, it is significantly easier to only need to isolate issues and develop and test changes on one platform rather than multiple.
  6. Windows is by far the most common platform used by teams. A typical WPILib release will have 5-7x the number of Windows downloads to the number of Mac downloads (and that’s likely an undercount, as it’s more likely that one Windows download is installed on multiple team machines).
8 Likes

x86_64 only I believe. I will try when I get home.

Hey! I’m the author of OpenDS. It in theory should work on arm-based systems as well. The networking is all in Java (which is cross platform/architecture) and the joysticks are through the Linux API. Open an issue on github if it doesn’t work, and I can look into it.

2 Likes

I made one

Those are all fair points, however you know all of those points, with the exception of #5, just require some development. The DS was designed in 2009, but the new control system came out in 2015. I know electron wasn’t out by then, but I still think we should’ve received a new DS.

The current DS is good, and for the most part there are very little problems with it. But I would much rather have a linux or mac machine run the driver station, than a windows machine. I have a lot of reliability issues with windows. And again, with today’s technology stacks, I don’t feel like it would be too difficult to start making new, platform-agnostic apps. I do not think it’s reasonable to have to install Labview dependencies for something that is, for the most part, network based.

2 Likes
3 Likes

We could also go crazy, and use QUIC instead of UDP and TCP to handle the communication. Nobody would be crazy enough to try that :wink:

thad is there something you would like to share with the class?

3 Likes

As a team that has limited tech support. I feel the cross platform networking and hardware support is the biggest thing I like about Windows only FIRST support for the DS.

The number of network issues that can occur combined with the panic of not being able to connect successfully in the pits or on the feild make the combination of #3 and #5 huge. This comes from a team that has both been one of the only Labview teams at an event and the only one running Python (in different years).

We have had CSAs look at our setup and say, “Oh, I am not sure I can help then.” I understand this too.

There is a reality to needing to be able to explain exactly what the problem is and is not when asking for help at an event with a system people do not fully understand.

A bit more on topic, can you use Glass as a practice/test alternative? Or does that only work with the simulator?

Glass doesn’t have the DS bits, that’s only a feature of the sim GUI.

1 Like

I see well, I thought it was worth a shot. That is entirely understandable.

It’ll likely never happen, but I’ve been playing around testing it, and checking latencies.

1 Like

I don’t buy points 5 and 6. Between WPILib and the vendor ecosystem there’s already rich cross-platform support for both tools and simulation. What would it take to bring the DS into this ecosystem? I’d love to see things like

actually be possible instead of being blocked on NI.

1 Like

Rewriting something that is extensively tested, working, and stable is generally not a good investment of limited time and resources… see the above post re: “Things You Should Never Do”. A new DS for non-Windows platforms is clearly doable technically, but it’s not going to be anywhere near as robust as the official DS across joystick and network environments, and it’s also (without significant work and testing) not going to be as safe as the official DS. Plus it would introduce inconsistencies–yes, you can drive your robot, but be prepared for surprises when joystick axes and button numbering changes when you need to switch to the Windows DS for competition (yes, this is true for simulation as well, but simulation is unfortunately still not very widely used).

I’m not seeing how WPILib cross platform support really argues against my points 5 and 6? 6 is a fact–most teams by far use Windows with WPILib and so can easily use the Windows DS. 5 is about support at events. WPILib support at events mostly boils down to robot code support (what’s running on the Rio)–the Rio is the same platform regardless of what desktop OS you’re running, and VS Code is nearly identical across platforms. That’s a lot different than a FTA needing to tweak network settings while trying to get a team connected to the field so they can play a match. I’ve quite frequently seen a FTA do exactly that (jump into network settings, etc).

2 Likes