Access the Auto List on Driver Station in Java

Hello All,

Last weekend we had our first competition. We were using the Smart Dashboard with radio buttons to select our various autonomous modes. It didn’t work very well and many others told us they had difficulty using the Smart Dashboard for this purpose. Even though the Smart Dashboard selected the desired autonomous mode I think it had to be selected after the laptop was connected to the robot through the competition system. It was quite error prone for the kids. I would like to use LV Driver Station to choose the autonomous mode.

Under the Drive tab in the driver station there is a blank drop down. Does anyone know how to access this drop dow?. Essentially setup strings and then read from it. I read a little bit, but it all seems to be describing LV to access it via “Auto List” and “Auto Selector”



Here’s some sample code that should get you started.

Class members:
final String defaultAuto = “Default”;
final String customAuto = “My Auto”;
String] autoList = {defaultAuto, customAuto};
String autoSelected;

in robotInit():
NetworkTable table = NetworkTable.getTable(“SmartDashboard”);
table.putStringArray(“Auto List”, autoList);

in autonomousInit():
autoSelected = (String) chooser.getSelected();
System.out.println("Auto selected: " + autoSelected);

in autonomousPeriodic():
switch(autoSelected) {
case customAuto:
//Put custom auto code here
case defaultAuto:
//Put default auto code here

Regarding the SmartDashboard, we’ve had the same issues. We’ve told our drive team to make each selection twice, and that seems to do the trick. We will be moving (running?) away from the SmartDashboard in future events.

Thank you Ruffles for the advice and I appreciate the validation of our troubles Ben. I will try this code the next time the team meets.


Sorry!!! This part of the code is wrong (that’s the code for sendable chooser).

should be something like this instead:
autoSelected = SmartDashboard.getString(“Auto Selector”, defaultAuto);

My team decided to use a hardware solution instead. We put a 12-position rotary switch on the robot. It has a little led to indicate which position is selected and it’s easy to read using an analog input on the Roborio.

We had a similar problem but with only two auto modes (cross low bar or don’t move). We wound up using the throttle on a joystick for it - there is no rule against reading joystick inputs from the driver station during autonomous, just against drivers touching any of them during that period. If you have more than two modes, you might try building a multi-position selector you can hook up over USB using a TI Launchpad.

We had the same issue last year using LabVIEW but after switching to Java this year we’ve had no problems with SmartDashboard or Sendable Choosers.

We are using the SendableChooser and it works great with the SmartDashboard. We have 8 choices in our autonomous. The list is displayed on the SmartDashboard and we can click and select any one of them. Here is our code using it.

Thank you. Does it matter when you make the selection? For instance does it matter for you whether you make the selection prior to the robot being connected at the competition?

It doesn’t matter. The selection actually sticks meaning even for the next match if you don’t select anything else, the previous selection is still in effect until you select something different.

Thank you for sharing your code with me. It is pretty similar to what we have, although yours is more elegant and we put all the code in For some reason we are getting sporadic results. I was thinking that we needed to make sure we toggled the buttons after the robot was connected to the competition system. It was working fine during our normal testing, but something is different when we connect to the competition system. We ended just hard coding the auto choice at our last competition which made it always work, but there were times we needed to change it.

If you get a chance please let me know if you see anything

  • public void robotInit() {
    driveTrain = new DriveTrain();
    ballArm = new BallArm();
    pneumaticArm = new PneumaticArm();
    autoChooser = new SendableChooser();
    autoChooser.addDefault("Do Nothing 15 sec", new DoNothing(15));
    autoChooser.addObject("Front of low bar", new AutoFrontOfLowBarGroup());
    autoChooser.addObject("BW Front of low bar", new AutoFrontOfLowBarBackwardGroup());
    autoChooser.addObject("Drive straight forward", new AutoDriveStraightForwardGroup());
    autoChooser.addObject("Turn right in front of low bar", new AutoTurnRightLowBar());
    autoChooser.addObject("Custom mode", new AutoCustomGroup());
    SmartDashboard.putData("Autonomous mode chooser", autoChooser);
   //autonomousCommand = new DoNothing();
    // OI must be constructed after subsystems. If the OI creates Commands
    //(which it very likely will), subsystems are not guaranteed to be
    // constructed yet. Thus, their requires() statements may grab null
    // pointers. Bad news. Don't move it.
    oi = new OI();
    // instantiate the command used for the autonomous period

//    autonomousCommand = new LookBothWays();

    new DisplayDashboard();

 * This function is called when the disabled button is hit.
 * You can use it to reset subsystems before shutting down.
public void disabledInit(){


public void disabledPeriodic() {

public void autonomousInit() {
    // schedule the autonomous command (example)
	autonomousCommand = (Command) autoChooser.getSelected(); 
	if (autonomousCommand !=null) autonomousCommand.start();

 * This function is called periodically during autonomous
public void autonomousPeriodic() 


Nothing jumps out at me but then again I am not familiar with Command based code. When you said it doesn’t work very well, what were the issues/symptoms? Did you get a null back when calling getSelected()? Did you get an exception? What is the exact failure? From the SmartDashboard and SendableChooser’s point of view, that should work. However, one major difference between your code and ours is that we only “newing” an auto strategy when it is selected whereas you are newing all your strategies (commands) and added them to the chooser. There shouldn’t be anything wrong with it but I am just trying to figure out if the problem lies in the command based code. Again, I am not familiar with command-based code, but depends on what failure you were seeing, you may want to look at it from a different angle.

I appreciate the help thinking through this.

When the game was activated I think it just ran the default of Do Nothing even one of the Low Bar options was selected. No errors that I know of. The one time we did get it to work I was at the driver station and i toggled the buttons back and forth after the robot was connected to the system. After a few failures we just hard coded the one choice.

During practicing at our school the buttons seemed to work fine.

I will look into newing all of the commands.

I wonder if the different behavior you are seeing vs. the other poster is related to you using command based vs. them not. Because your data in each option is an object, it may be considered to be different each time where if there’s is a string or something, the dashboard side may see it as the same. That may trigger the behavior difference, if the list is “different” it’s possible you need to make the selection after the robot links to give you the new value for the object.

I wish I could test this besides during matches. I could set a variable during the polling of the button and use a case statement in AutonomousInit to see if it helps. Thanks for the help.

We just competed in the NY Tech Valley Regional this weekend and had a number of problems with Robot<->FMS<->DS SmartDashboard issues.

Aside from using several SendableChoosers to select auto and speed settings (don’t need full speed for low-bar, do want to catch some air for the rock-wall), we use about 20 tunables on our SmartDashboard to help compensate for limited practice time, and some RoboRIO quirks (3 cameras, what was cam0 could be cam2 or cam3 next reboot). When it worked, it worked well…

It took most of our practice matches to figure out the problems.

Match Scoring Delays - Refs would occasionally hold scores for a match for what seemed like a very long time all weekend long. While this was happening, field reset would be under way and the students are setting up the robot and DS. But because the prior match hasn’t been scored yet, FMS is still configured for the last match. In some instances the MC was announcing teams immediately after the LCD station indicators had changed.

FMS Setup Lag - From the time the FMS starts to setup the field, which seems to start with the changing of the team numbers above the station, it takes at least 30-45s, and sometimes over a minute, to begin to connect the DS to FMS and the Robot to the network.

SmartDashboard / NetworkTables - Because the Robot is online this whole time, it’s broadcasting it’s NetworkTables settings (defaults) to the void. (Remember SmartDashboard is backed by NetworkTables). The DS is doing the same on it’s side of the field, but unable to talk to each other yet. If the DS had been completely shut down since the last time it saw the Robot, it will have no settings, or it will still think it’s NetworkTables are “good” from the last connection to the robot.

Meeting of the Minds - Eventually you’ll get FMS comms, Robot comms, and Robot Code on the DS, and NetworkTables attempts to sync between the DS and Robot. It’s “supposed” to come to a consensus and have a unified view at this point.

The SmartDashboard in lala-land - If you had your DS up, and NetworkTables had to come to consensus and you had your SmartDashboard open before you had Robot Code indication on the DS, this is where things fall off the rails. A good number of times we’d see “stale” settings and values on the SmartDashboard, when looking at the “Default” dashboard table were wrong on the SmartDashboard. Our solution was to tell the drive team to go to the SmartDashboard and File->New at this point after Robot Code is indicated. (You may be able to File->Load instead, but we never had the time to setup a really nice view we wanted to keep, we were adding/removing fields too quickly.)

… At this point you should be ready to configure your auto and any other settings you need. On our Robot we had 3 video cameras, and all too often they would juggle on a reboot. So we used 3 SmartDashboard strings to configure them. It would take the students a few seconds to identify which camera was which, make the settings, and verify, as well as set the auto, and tune the settings for the obstacle they were facing. (Once we had good numbers, this last step became unneeded.) They would also force calibrate the gyro at this point.

But the match started??? This bit us way too many times – because it took some time to get the settings in and calibration to complete, field reset had been finished well before FMS was ready. I had our drive captain go the to Head Ref and explain what was happening (score delay, fast field reset, FMS late setup, and a fast start), and he admitted he hadn’t seen us trying to wave off the start of the match. From that point the 2-3 drive team members not working on the DS were up on the glass with thumbs-down and the refs would check before giving the go-ahead.

TL;DR - SmartDashboard can be in lala land, try File->New once you have Comms. FMS takes too long to setup comms most times, this is worst on a fast field reset, and a long prior-match score delay. Make sure your HR knows you have some setup work to do and SmartDashboard is a bit buggy and use that thumbs-down to hold the match start.

This weekend’s competition we had 100% success using the Smart Dashboard to select different autonomous modes. You need to make your selection after the robot is connected to the competition system.

One thing we did to make things more reliable was to make sure that the Preferences had the last picked autonomous settings. That way the robot can come up and the drivers are confident that the settings they had in queue will be what they see when the robot boots on the field.