Hello all,
I am currently trying to think of a way for my drivers to pick what autonomous code to use before a match, preferably queuing. I was wondering what would be a good way to do this. I was thinking that while the robot is disabled, I display what autonomous to pick in the SmartDashboard. What do you guys think?
Yup, the SendableChooser object in C++/Java/Python works great for this sort of thing.
Thanks man, works great!
One of the most important factor in this game is the PROGRAMMER. According to the Alliance the programmer must be able to redo their autonomous game to suit the alliance.
What do you think?
Yeah, I like the variety that the autonomous code must accommodate.
For that reason, I’d like to utilize my experimental auto scripting language, as I think it will be important to quickly modify auto modes during an event.
I was even considering some kind of graphical interface to quickly build and modify auto modes. Like maybe have a diagram of the field, and simply plot points that the robot should go to, and add actions at each point. It’s certainly something I’ll experiment with.
We will be using some kind of scripting this year, most likely Lua, for auton. The drive team will need some kind of UI to select what to do, but it needs to be quick and easy for them. The programmers will have more time to write and debug complex interactions then the drive team will have just before a match. It is my hope that the programming team will get it down to just a handful (<=5) of SendableChooser objects.
In past years, our team has put 2 mechanical switches on the robot, and for every configuration of the switch (ON ON, ON OFF, OFF ON, OFF OFF), you could have a different autonomous code. All you had to do was put the code in an if statement and write a notecard out to the drivers explaining what flipping the switches would do for the autonomous. You could have as many as you wanted, but 4 seemed to be the magic number for us. This method worked the best when we didn’t have any programmers, but a team full of mechanical kinds of people.
However, we’ve been experimenting in recent years with the SmartDashboard, and if you want a more updated method, picking straight from there is the way to go. 
Just today our team put together a way of selecting autonomous programs through the SmartDashboard. We’re not using a command-based framework, so we made it work using pointers to functions. You just make a function for each possible autonomous mode, use a SendableChooser to pick a function, and have the actual AutonPeriodic function just run the chosen function. Anyone who’s curious can check it out on github here.
Function pointers are unholy magic though, so stick to Commands if you’re not lazy and old-fashioned like us.
So much work!
We just used A and Y to swap between modes.
Yep. Just put some selection code in the disabledPeriodic() looping method and have some cycle button on your joystick be used to cycle through the Auton modes. It would probably be a good idea to have some text display the currently selected mode on the dashboard too. I never understood why people made more work by actually mounting switches on their robot, this is so easy to implement.
I like using the SmartDashboard, rather than joystick controls, because there’s no button mapping to keep track of. We can add as many auton programs as we want and add each to the chooser with a single line of code. Anyone using the driver station can see the list of the choices, with names/descriptions, and click one to choose it, without having to know the button scheme (or even have a controller). Also, compared to your code I have to say it seems a little simpler; we don’t even need an array to keep track of all of our auton programs. (Although of course I have not ruled out the possibility that your code is simply more fancy than ours.)
scripting via LUA?
jeez, have fun friend. LUA is a major pain, speaking from personal experience.
We used the driver station digital inputs to select our autonomous mode last year. We originally had a physical 3-stage switch on our driver station which was wired into the Cypress which was connected to our driver station laptop, however, our Cypress stopped working so we literally just clicked an individual digital Input on the driver station, under “D I/O” and referenced each digital input in our autonomous code, so different digital inputs would correspond to a different auton mode. I mean…it worked…
Sparkfun has a great 10 position switch and a breakout board for it that would make it quite simple to add up to 10 different Auto modes to you drive’s station.
You can use the TI LaunchPad from the KOP as another HID device and connect all 10 inputs to it if you needed that many.
Sorry to revive this thread after a couple weeks, haven’t checked this thread in while 
Anyway, i have made a system in java where it loads a autonomous mode inheriting a base class, makes it pretty simple to create. It also loads depending on the robot, since our team uses multiple robots 
When would one actually select the autonomous routine desired when using the SmartDashboard? Do you do it after connecting into the FMS but before you have to step behind the line, or in the queue line, or in the pit before leaving for the match?
I am unclear as to when the autonomous mode selection would be made given that we need to connect into the FMS.
Thanks.
You can select and change your mind up until you have to step back.
In Autonomus Init, you read the input, and setup Autonomus to execute accordingly.
So you setup the robot and power on on the field. In the meantime one member of the drive team is setting up the drivers station. When connected to the FMS, then you can select the autonomous mode?
We make our Dashboard selectable autonomous choice in the pit.
The robot code just reads the Dashboard values whenever it is running and connected via network to the Driver station.
FMS doesn’t have anything to do with any of this.
FMS only tells the Driver station what mode (Disabled/Enabled/Teleop/Auto) it wants it to be in.
Yes, when your robot connects and starts running code, it posts to the Driver’s Station (robot init). At that point, the input field can be edited. Once Autonomous Starts (autonomus init), the robot reads the input field and sets up parameters, and runs the appropriate code (autnomous periodic).
In theory, you can do this while tethered in the que (after you have discussed with your alliance members who is doing what, who is starting where). However, in the event of a last minute change (problem with robot on the field), you can change up until the start of Autonomus.
This is most helpful during practice matches when there can be a lot of changes on the field. By the time you get to qualification matches, you have a good idea going onto the field who is doing what.