Set Auto Selector choices on default dashboard from Java robot code?

Is there a means to set choices for the autonomous selector on the default (LabVIEW) dashboard from the robot’s Java code? The iterative robot example code outlines how to accomplish this when using the Java SmartDashboard; however, for the LabVIEW dashboard it simply recommends reading whatever string the user has entered. Is there a better option?

Don’t use the smart dashboard to set your auto mode if you know whats good for you.

Put a bank of switches on your robot and use them to set your auto.

Can you explain further what issues you have had with using the smart dashboard for this?

Some people have had auto fail, not run at all, computer reboot not allowing you to fit it in time, there are many other reasons to include. But mostly having it be purely robot side will make it start as fast as possible. Some of my teams programmers will have to reply if you need more precise answers, but there are plenty of teams out there that have been burned by relying on the smart dashboard.


Highly recommend the onboard switch method. We had a rotary switch on our robot last year and it worked wonders for setting auto. It allowed us to have an extremely customizable range of autos that we could instantly set and never failed during a match.

It’s not quite as cut-and-dry as Devin makes it sound, but it’s true that we’ve used an auto selector switch in the past with great success.

The main issue with the default WPILib one* (or at least the implementation that many team seem to use) is that it has a network read to figure out what auto mode to run at the start of auto. We don’t want to use that, because we tend to do a lot of buzzer-beater autos (2016 two-ball, 2015 chokehold, 2014 three ball, etc). Having the round trip latency from a network read would have killed us.

Other than that though, we tend not to trust NetworkTables/SmartDashboard. We’ve used them in the past (including last year, just not for auto selection) and have seen a lot of really weird difficult to debug issues. 1678 often ends up distrusting/not using wpilib stuff (I think that this is my second post today about it, and it’s barely lunchtime :P). I don’t mean for this to be a cargo cult thing, but we really have seen a lot of issues with NetworkTables and SmartDashboard. I’ve seen it not connect, not send values, display old values, and randomly decide to stop working.

In the past, we’ve used a bank of switches to select auto modes, because it’s easy and reliable. We may be switching to a custom web dashboard this year, but just because we’re confident that we can pull it off.

Bottom line is that we used a switch bank for autos because it’s reliable and simple, and SmartDashboard is neither of those, in our experience.

*Note that I haven’t actually used this in quite a while, so it’s possible that this has changed.

I highly recommend switches attached to your Driver Station, not to your Robot. Much more time to fix errors in the switches on the DS (up until start of match) than the Robot (can’t get back onto the field).

Use something like this. It works like a USB joystick with a lot of buttons.

I was thinking about this the other day. Isn’t NetworkTables implemented so that it is a server running on the RoboRIO. Meaning that when a value is changed on driver station, the change is pushed immediately to the RoboRIO, and therefore, there would be no network latency from the RoboRIO reading from its local server? I’m not sure if I’m interpreting this correctly.

I second trying to find an alternative way to set your autonomous. Last year at worlds, we didn’t run an autonomous in several matches because we couldn’t get the SmartDashboard to connect before the match started. We will probably stick with it though because it’s just the easiest option.

1 Like

Which is one of many reasons I don’t like Smart Dashboard for use during competition. Debugging/development is fine. Relying upon it for competition is asking for trouble.

Switches on the Robot (either via AIO or DIO) is very easy to do. Switches on the Driver Station is a little harder, and comes with many advantages.

We have had the SmartDashboard “de-sync” in a couple of matches. You can set a default that will run if it does this, but that could lead to not so good things. We’re planning on making a file on the roborio that we can edit before a match and then read from to determine autonomous. The only things we’ll have to watch out for are making sure that the format we use to enter data into the file stays constant and we’ll need to remember to re-create the file if ever we need to re-image the roborio during comp.

We simply used SendableChooser last year. The only problems we had with it were due to SFX being terrible (it required us to double-select everything, and sometimes it forgot our team number, but besides that everything worked fine). There was plenty of time before auto started for NetworkTables to sync.

We have had good success with the dashboard displaying the selection and using joysticks to adjust the choice.

We have had the failure of setting it in the dashboard, and having it not work. This was years ago, so we don’t do that anymore, may work fine now.

*We are a Labview team

Against all the advantages of onboard autonomous selection, doing it at the drive station handles the situation where the gates are closed on the field and everyone realizes that no one set the autonomous mode. You get one last chance to mouse it in…

We have not had problems with disconnects between requested autonomous and what we got, and we had upwards of 80 matches in the last year.

I would also like to chime in and say that we have never had any problems with the smartdashboard not syncing properly and we have been using it to select auto modes for 3 years now.

We have user sendable chooser for years now for auto selection through smart dashboard, haven’t had a problem since 2013 (selected auto mode on dash wasn’t being sent out to the robot randomly and required robot reboot iirc).

Sent from my 6045I using Tapatalk

Argos typically uses switches on the actual robot. We’ve been let down by the dashboard methods in the past. The Huskie Board has DIP switches specifically for this reason, as do other expansion boards. People could forget to flip the switches, obviously, but that hasn’t been an issue for us.


Another real problem with Smart Dashboard during competition, is if you can’t get your Driver Station to connect (for whatever reason), they will give you a generic Driver Station to use. The may not give you time to setup your Smart Dashboard (as it has been a long enough delay waiting to get your DS to connect).

To answer the OP question, the LabVIEW default dashboard does not use a SendableChooser. Rather it requires an array of strings in SmartDashboard called “Auto List” and the user’s choice is a single string “Auto Selector”. The difficulty is that has many methods that are static, but putStringArray() isn’t one of them. Here is a starting point.

public class Robot extends IterativeRobot {
  SmartDashboard dash = new SmartDashboard();//needed for non-static methods
  String AutoModeSelected;
  public void robotInit() {
    dash.putStringArray("Auto List",ArrayOfAutonomousStrings);
  public void autonomousInit() {
    String AutoModeSelected = dash.getString("Auto Selector");

I will say in 2016 the major problem with SmartDashboard.exe is that it independently resolved the RobotIP using mDNS, when the DriverStation program resolved using DNS. mDNS had a tendency not to work often, or take a long time to resolve. The LabVIEW dashboard for sometime, has actually just been given the RobotIP address through TCP port 1741 with the DriverStation program. The option to chose mDNS or the static 10.XX.YY.2 as a way to resolve RobotIP in the SmartDashboard.exe is gone, or at least I can’t find it. So SMartDashboard.exe might be using that TCP port data.

1 Like