Call for updates - Driver Station Best Practices


Last year I coordinated the Driver Station Best Practices paper, and it’s time for an update. Please post any suggestions you have for the document in this thread.

Your focus should be on the Driver Station, and what the minimum practical requirements are for a machine dedicated for that use.

Just like last year, if your suggestion is adopted, you become a contributor and get credit in the document.


Plugging your computer directly into the RoboRIO over USB is just asking for trouble. Always run through your radio to avoid causing DHCP wierdness, and as an added bonus, diagnose connection issues before you even step on the field.


We commonly connected our programming laptop through USB to deploy code changes and reset a few functions on the robot that were not easily completed with the robot powered off using Shuffleboard buttons. Part of that reasoning was both ethernet ports on the radio are utilized. Truthfully these ports are not built for the hi frequency of plug-unplug cycles and we took extra precautions to secure these connections. Even the USB port could start to fail when to many rushed plug in cycles accumulate but at least you won’t likely drop comms in a match due to a USB port. That is why it is also a good idea to use a USB brakeout cable to protect the $400 investment.

We have observed VERY STRANGE behaviors if we unplug a joystick from our driverstation to tether USB to the robot. When the robot is enabled the robot code seen random buttons pressed from the no longer connected joystick(was a launchpad in this case)


If you unplug a joystick while the robot is enabled, the driver station should automatically disable the robot. Was this not what you experienced?


Sorry i was not clear.

While in the pits we wished to tether to the robot using the USB. Our Driverstation only has 3 USB ports and is using all three. Since the action we wanted to test is not on the Launchpad we used that port to USB tether. When we enable the robot a command that is mapped to a launchpad button executed.

When we must test item’s like vision we temporarily this year added a network switch. During matches we removed the switch(one less item that could fail)

We had only one dropped connection this year week zero


-USB to ethernet adapters can be tricky sometimes, in FIRST Canada we recommend using this one from Amazon Basics. Teams should make sure to bring their own, as the ones your fields may or may not have have likely had some wear and tear.

-Sometimes when you tether to your robot at competitions, IPs may not reconfigure automatically. When you get to the field your robot may not connect, the solution we’ve found works for us up north here is releasing and renewing the IP

-Try and get a driver station that has enough USB ports for you, USB hubs create more points of failure.

-Replace the laptop you get in the KOP, as they get updated they slow down, too often this year at the events I FTAA’d we had to wait for teams not because they weren’t ready, but because their laptop wasn’t booted yet.

-You cannot upload code through the field network. Don’t try it.

-Close other applications that connect to the robot that you don’t need when you get to the field (ex. webcam configurations, programming softwares, etc.)

Steve, if you’re looking to add more troubleshooting related items to the paper, send me a message and I’ll gladly send you some stuff.


Interestingly enough we were actually able to download code through the field network using VS Code at our last offseason event (Battleship Blast). I’m not sure if this is something with the FMS at this particular event or if it has something to do with the 2019 Beta.




Offseason events don’t always enforce the firewall rules that block it. If you read the FMS whitepaper the port that deploy uses is implicitly blocked. If you were to change the port though to a team-acceptable one…it’d work though.


Pardon my ignorance, I’m not a network guy, but what’re the issues associated with tethering via USB? We did that this year and didn’t have any problems that I know of, but we might’ve just dodged a bullet. It was mighty convenient.


This is because you were connected to an offseason FMS. In 2019, GradleRIO will also put out a verbose warning if you try to deploy on the field: “You can’t deploy code while connected to the FMS! Ask the FTA to allow you to tether your robot.”


Interesting, if the event was running the Off-Season (Lite) version of FMS that might be why it allowed you to do that. At one of the events I FTAA’d at (ONT District - McMaster U Event) a team tried to deploy code through the field and when the FMS denied it it crashed their laptop (to be fair it was one of the small netbooks from the KOP), thankfully we were slightly ahead of schedule at that point and had time for them to tether and fix their code.

The second moral of that story is it doesn’t take a lot to crash one of the KOP laptops from what I’ve seen.


Bah, nvm. We set the power settings at the competition rather than before the competition. Looks like the doc has laptop power settings covered in the pre-competition section.


Ryan – thanks for the offer. I’m trying to keep the whitepaper focused on prep and setup, so that it stays a reasonable length. Troubleshooting is covered pretty exhaustively in the FTAA guide to field connectivity. I’m wary about recommending >2 USB ports, because it really starts to narrow the set of machines available. I will put in a comment about fastening down the USB hub.



make sure when you interact with the robot through a browser that it is internet explorer. other browsers like chrome and Microsoft edge will not work properly and pose errors. also make sure you disable the firewall in the driver station computer as it sometimes causes errors in driver station


Good question. I’ve seen it before where the DHCP system gets screwed up by USB, and I’ve also seen it mess up the Driver Station through both connection (since USB is a mDNS address), and the Joysticks can do weird things since the DriverStation software hasn’t switched over.

As I said, these things are rare, but they are an unnecessary risk.