We had a nightmare of a time trying to figure out what was wrong with our autonomous modes. We were using a SendableChooser to get our auto modes, but with some debugging, we found out that the SendableChooser->GetSelected() was returning null.
We agonized over this for a while, but then we discovered that if the name of your auto mode had 16 characters or more, the sendable chooser would not return the assosiated command.
WPILib has been discussing this internally, and we aren’t yet sure what the cause is (Small-string optimization for strings, which may use 16 bytes; an issue with llvm::StringMap; SendableChooser not being thread-safe). Are you calling SendableChooser functions from different threads?
My team 1967 had troubles with this earlier this season. We had 3 different SendableChoosers on the dashboard - each with their own ‘entries’. All of the entries seemed to work just fine except one. I had noted with one of the programmers that the entry at issue had 11 characters and I wondered if that tripped over an edge of some kind. I don’t believe we had 16 as a magic number.
Ours were all created/populated from a single thread, btw.
I think they shortened the names and it worked so that’s good, but I don’t feel super great about such an issue hanging around. If there’s a solution, I’d love to re-test and see the issue disappear for the team.
Can you connect with OutlineViewer or shuffleboard and display the contents of the NetworkTable for that chooser? In the video at the 45 second mark, it looks like an option is added with the name “567890123456”, which is not one that you added. It’d be good to see the full contents of the table for better troubleshooting.
After updating everything (Rio firmware, eclipse plugins, etc.), we can no longer reproduce the problem. It appears that there was some issue with earlier versions of the plugin that were causing this.