Last year, my team decided that creating our autonomous mode was taking too long. We had to change code, download, restart the CRio, etc. EVERY TIME. So, my mentors encouraged me to find a way to speed up the process, and I believe the result is quite helpful. It’s a set of classes that can be extended to automatically set up a way to edit autonomous code on the fly so you don’t have to re-download and restart the CRio just to change a simple variable. This makes having multiple autonomous sequences easy to manage, and brings extreme flexibility to that section of the game. The only downside that it only works for teams using the command base, and it is a little tricky to set up.
Here’s how it works: Using the SmartDashboard and RobotPreferences, the robot is provided by a real-time stream of data which the user can change. The user can enter a string of numbers and letters symbolizing a sequence of commands, and the robot will automatically parse the string and create an autonomous command, and it can be changed at a moments notice.
For example, you could input
D 1,5,5; B 2;
And it could mean drive for 1 second at speed 5 left and right, then use the bucket for 2 seconds.
D and B would be linked to certain commands, so the parser knows what they mean;
And, if you change it to
D 1,4,4; B 2
The parser will recognize the change and create a new autonomous command which is ready to be used immediately.
Note that command-based code wasn’t used at competition due to internal conflicts, but it all worked great and was quick and easy to develop. Also, alot of the classes used were basically being rushed in the middle of build season so theres alot that has been improved. (The way we did auton before (and still do untill 2014) is through a gigantic switch loop which didn’t work untill our third competition and was hard as all hell to debug. Linked code worked on first deploy)
Our autonomous WAS complicated. It was
Camera track to the low goal.
Line up with the goal
Drive to a certain distance from the goal
Dump frisbees
Turn around
Drive at a specific angle
Also, I looked at your code. I didn’t see any SmartDashboard reference, where was it? And btw, the FRC java has a built-in wait command, just so ya know
But my point is that, the way you set it up, if you change the command sequence, which happens a lot in testing, you have to re-download the code onto the robot; a timely event. With MY setup, you don’t have to restart the robot.
I removed all of the SmartDashboard references as i mainly only use them for debugging (see my other thread i replied on), that project is supposed to be a cleaned version. Yeah i know theres a FRC wait command, I just felt like making my own
Yours doesn’t sound that complicated…
Targeting.process()
Drive.drive(3000,0.5)
Shooter.dump() //Havent seen your robot, not sure what you exactly mean by dump.
Drive.rotate(180 + “specific angle”) driving the angle with motors would cause the robot to doughnut
Drive.drive(3000, 0.5)
cam;dr:3000;sh;rot:180;dr:3000
If you have a programming team (not just you), setup a GitHub organization and ask for a micro account, they gave us 10 free private repos.
It was more like
“D 1,-7,-7;G 10,-9,120,-0.7;S;PA;F;D .5,6,6;Y 2,-7,140;Y 2,-10,0;X .5;”
But my point isn’t to reduce complexity. The point of this is MAINLY to allow testing without restarting the robot in between tests. The fact that it also develops a string you can use as autonomous at the same time is a bonus. We actually had three strings, and and switched them out based on the situation. Sometimes while the robot was on the field. We didn’t have a cleaned version because the “Cleaned version” Was inputting the string we wanted to run and running it.
Actually one of our mentors is related to an owner of Atlassian Bitbucket, so we use that instead of Git
Also, I’m not saying YOUR team specifically should use my setup. You seem to have it all worked out. This is mainly for the teams that don’t really have time to test lots of autonomous stuff and don’t really know how to set it up. Almost all of the tournaments we were at the most we saw for autonomous was 3 shots maybe, or a drive into the wall and use inertia to drop frisbees.
That’s my code not the teams. The actual team code (2013Iterative) was only working as 3disc until worlds when we got 5disc lol (don’t ask). My main issue with the parser is that it can be hard to read and as long as you get the procedure done, you can just use sd to change the values, but I guess if it worked for you everyone’s different.
Ohhh I see what you mean. But you don’t actually have to read the parser
But still, very few teams know about the SmartDashboard, and very few teams have Autonomous. The ones that do are usually the more impressive ones who, like your team, have a 5-disc auto or something equal. I mostly want to help out the teams that don’t have as much. They just have to drop these into their project, extend from them, fill out the abstract methods in the commands, And pass in a list of those commands in RobotInit.
(next year will be a command-based structure like the earlier link)
My code follows similar structure, you just drop in TimedCommandGroup.java and add commands, in the 2014 code I’ve added a simple little command generator that will allow me to run 1-8 motors/relays/solenoids/etc at whatever desired value. Your code might be faster to write, but mine is easier to read and better support for multiple modes plus once you learn to FTP, changing values without SD doesn’t take too long
I don’t know about better at supporting multiple modes, we had had a couple different strings we could use, and just put in the relevant one once we had the robot on the field. But, I agree that it is probably easier to read.
Either way, the stuff in this thread should be good for jump-starting a team who has 0 autonomous.
Here’s some scripting stuff I worked on a while back so that files can be deployed over FTP with no reboot. I haven’t touched it since but it’d be interesting to see something similar in Java (not sure about yacc/lex equivalents).
Well it seems like it’s the same basic idea as both of our scripting programs… however, I can’t say for sure because I have know experience with regular expressions or yacc/lex.
As for ftp, I’m pretty arhowk mentioned that he does that, and I guess I could use it if I needed to, the RobotPreferences is just a file on the CRio. But I don’t see a reason to use Ftp over SD because SD is so convenient(Some teams mentioned that they weren’t allowed to use SD, so in that case FTP is, obviously, preferable for changing autonomous seconds before the match starts)
plus once you learn to FTP, changing values without SD doesn’t take too long
