SmartDashboard SendableChooser Unexpected Behavior

I have two examples of the SendableChooser not behaving as it appears on The SmartDashboard.

  1. Select an option other than the Default and use it - that works okay. Then rerunning using the DriverStation Restart Robot Code, the getSelected() initially reports the Default Value then on the next iteration or so reports the previous, showing on the SmartDashboard value. There is that one iteration that has the wrong (not selected Default) value.

  2. Select an option and use it okay. Deploy new robot code instead of Restart Robot Code). The default value is selected even though the previously selected value is still showing. On the attached image notice the discrepancy between the Retained Selected Value ("Auto 2") and the Active Transitory Value ("Auto None").

Neither of these two behaviors is desirable but at least in case 1 it fixes itself in one or so robot iterations.

I don’t understand the usage of Retained and Transitory Values. If there was a way to clear them both out to a known state by the Robot Code, that would be best. Lacking that I think the getSelected() should always select what we see on the SmartDashboard.

I’m pretty sure the 2022 system worked okay last week (at least I never noticed a problem running it many times) so I don’t see how I’m abusing the code today. Any explanation and help is appreciated.


public static enum AutoChoice
      kAuto1, kAuto2, kAuto3, kAuto4, kAuto5, kAuto6, kAuto7, kAuto8

private final SendableChooser<AutoChoice> autoChooser;
autoChooser = new SendableChooser<AutoChoice>();

// in the attached image I have some longer ugly test options that I shortened here
autoChooser.addOption( "Auto 1", AutoChoice.kAuto1);     
autoChooser.addOption( "Auto 2", AutoChoice.kAuto1);     
autoChooser.addOption( "Auto 3", AutoChoice.kAuto1);     
autoChooser.addOption( "Auto 4", AutoChoice.kAuto1);     
autoChooser.addOption( "Auto 5", AutoChoice.kAuto1);     
autoChooser.addOption( "Auto 6", AutoChoice.kAuto1);     
autoChooser.addOption( "Auto 7", AutoChoice.kAuto1);     
autoChooser.setDefaultOption("Auto None", AutoChoice.kAuto8 );
SmartDashboard.putData("Auto choices", autoChooser);

// call this method to retrieve the selection
AutoChoice getAutoChoice ()
    return autoChooser.getSelected();

1 is expected behavior; 2 is not and I will need to investigate and try to reproduce this locally to fix.

The difference between the two keys is that “selected” is what the dashboard sets and “active” is the robot code echoing it back (eg what it thinks is the selected value—what getSelected() will return in the robot code).

1 is expected behavior because it takes time for the client to connect and the selected value to be sent, and the selected value on the robot side is read/updated once per robot iteration. SendableChooser doesn’t just read the selected value when you call getSelected(), the value is getting updated separately.

It looks like for some reason in case 2 that the robot code isn’t realizing that the value has been updated. This points to a potential race condition, but I will dig into it.

1 Like

Thanks very much. I’m running on an “original version 1” roboRIO.

Figured out the cause of case 2, will be fixed in the next WPILib release.

1 Like

I came here to report issue #2, which we’ve been experiencing last year (since we first adopted an Autonomous command chooser). I finally convinced myself it was a WPILib issue and came to discuss it, but I’m pleased to see that it’s already been addressed. I will make sure that we are using updated WPILib.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.