Change (or reset) of a SendableChooser value as Autonomous starts?

[sataylor000]

I can't confirm if this is true (it's based on a verbal recounting of the issue), and don't have logs available to back up the assertion... but my team had a very strange occurence on the field during a match at Bedford NH yesterday. It is unlikely that this is an actual bug in the SendableChooser, but read on and see if this makes any sense whatsoever...

In the course of debugging an issue with using DriverStation getAlliance() (See wpilibsuite/allwpilib#499), we changed our code to instead choose the alliance color manually using a SendableChooser object. Essentially, we choose both an autonomous mode AND set the alliance color manually before the match begins.

We need the alliance color to modulate our code to turn the correct direction due to the field mirroring. The code assumes the Red alliance, and if we are on the Blue side, it inverts the turn and crab directions... otherwise it uses the programmed values.

We create the SendableChooser objects in our Robot.java's robotInit() function. The auto mode has been working just fine for multiple seasons using this method. The alliance color chooser uses .addDefault for the Red choice, and addObject for the blue choice.

In this particular match, the alliance color was manually selected by the drive team to be "blue". The team stood back behind the line for the beginning of Auto, so nobody was touching the controls and the system was under FMS control. The driver was watching the screen, and says that he watched the selection CHANGE from blue to red (The default) JUST AS THE MATCH WAS STARTING. The robot then proceeded to run the "red" routine instead of the previously selected blue routine.

He didn't see any indication of the robot code restarting on the DS application, and we have no evidence that his has occurred with the robot up until that point.

I don't have any other reason to believe that something would reset the sendable choice, and we only called addDefault/addObject in robotInit, and only getSelected() in the autonomous Command's initialize() function... so there was never any code that changes the value in the robot code.

I don't know if the described sequence is even remotely possible, and it would be difficult to figure out which robot log file would correspond to the match (And the robot is currently bagged and inaccessible)... but I promised I would log the issue and get the discussion started in case this was an issue that has been seen before.

Note: Given the related getAlliance() issue mentioned above, it is possible that there is an entirely different problem that is causing the red vs blue execution behavior... but the fact that the driver claims to have watched the selection dynamically CHANGE was enough for me to log the issue officially.

Thanks for any comments you can provide. I can provide a pointer to the code, which is on GitHub, but the current instance of the code was subsequently modified (by commenting out the getSelected() and going with a purely hard-coded choice... ouch), but the original implemented code is still present as commented-out lines of code.

[AustinShalit]

The issue you are seeing could be related to having multiple SmartDashboards open at the same time.

Also, what is your team number?

[sataylor000]

1735 (Green Reapers from Burncoat)

I can see how that might happen, and we have had some inconsistencies in the past year or two with the SmartDashboard auto-starting on the driver station, so sometimes the driver has had to manually start it. Thus, if there was a significant delay in its autostart, we could quite possibly have had two instances. I'm not sure if it's possible to confirm that from stored log files.

-Scott

[bradamiller]

Also, just so you are aware, there is a method DriverStation.getAlliance() method that will return the alliance color.