Can there be more than 1 SendableChooser? The second one seems to replace the first on the dashboard.
It should work. Are both named something unique?
we are using 3.
Can anyone with multiple choosers point to their code online? We are thinking of adding a couple of Sendables as well in order to add more customization to our autonomous. We’d like to do it in a way that doesn’t create a million options on the Smart Dashboard, but still allows for a lot of configuration before the match.
Yes, you can use multiple sendable choosers. This code on github shows working code with multiple SendableChoosers. It also shows how to use non-command types in the choosers. (We use an integer in one of our extras and a boolean in another)
Just in case you aren’t aware of auto-boxing (introduced in Java 5), that’s what lets you put primitives in an object. Java automatically promotes it to a wrapper object so boolean becomes Boolean automatically.
Feel free to ask questions about the code!
I think you’re just experiencing a rendering issue… I noticed on the newest SD that send able choosers don’t seem to provide valid layout hints to whatever style class they are using. If you CTRL + e and drag the chooser away you should be able to find the additional choosers under the first
Awesome, thanks for the link! Love how you have auto for the Portcullis and Cheval de Frise. I was a little surprised you didn’t have a choice for the low bar, but perhaps your bot is tall? We have thought about writing one for the Portcullis and CdF but haven’t yet. Because we have the low bar and B and D defenses, we can always do auto but would be fun to try the category A defenses too, but have invested our time elsewhere for now.
The reason we were interested in multiple choosers is that we are working on an auto where we cross our defense (cat B, D or E), turn left or right, travel to the Sally Port / Drawbridge and come back through it halfway and hold the door for teams to start crossing it immediately in teleop. (Like a lot of teams, we have wasted time on the field either waiting during teleop for this little bit of teamwork and thought perhaps it would be a helpful mode when we are aligned with teams with no auto.) So the choosers would be our existing one for the defense (looks almost identical to yours!) and then the direction of the cat C defense (left or right) and then how many stalls over it is.
Out of curiosity, what do you use the operatorChooser for? I didn’t see its use in the code.
The Smart Dashboard chooser was taking up too much real estate on the screen. We made a USB device to plug into the Driver Station. It has 15 button capability (plus one button for Turbo, but that has a predefined action).
We got these buttons to go with it (you want latching buttons, not momentary contact, also round is easier to cut out a mounting hole than rectangular):
http://smile.amazon.com/gp/product/B00E0L2AG2
The device installed automatically with Windows 10. Driver station recognized it immediately as a JoyStick. No problems using WPLIB/C++ to read the button values.
You can either setup your code to:
- Buttons tell robot how far to drive, turn, etc.
- Buttons tell: i) which position is the robot in; ii) which defense is in front of it; iii) whether to shoot or not; iv) whatever, and let the code figure out what sequence of commands to execute.
When are you reading this data? I always thought the software blanked any joystick data coming from the driver station during autonomous. Or am I being betrayed by my memories of the IFI system?
Correct. Our robot is physically incapable of going under the low bar so no need to have an auton for it.
Our primary operator prefers the up arrow to mean a different thing than the backup operator based on the video games he plays. We dealt with this by having the command check which mode it is in. We didn’t want to have to load code based on who the operator is.
Sendable choosers are great, but I would caution teams against using them. At GTRC we were rarely able to establish coms through the smart dashboard, and many other teams were having this problem as well. Smart dashboard is not a very reliable option, so I would warn against using it to select your auto. We ended up changing our selected auto through a code re-upload before every match, although we’ll be using a set of physical switches on the robot in the future.
What programming language do you use?
We had big issues with SmartDashboard last year when we were using LabVIEW.
We switched to Java this year and have had no issues with SmartDashboard or SendableChoosers (we use 6) through 2 competitions.
We’ve used Java and Sendable Choosers for 2 years now. Last year it was horrible. There were multiple matches at all of our competitions where we ended up without field-centric driving on our swerve drive because we used a SendableChooser to indicate which direction the robot was facing at the start of the match.
This year it has worked without any problems for us, and we have 3 SendableChoosers.
We’re programming in Java. While you might not have problems in a particular year, I’d really advise against it. You never know when it’s going to act up, and this can change from event to event. One of our mentors was the volunteer that diagnosed some of the larger SD problems in 2014, and he feels it’s poorly written and prone to problems.