I’ve just returned from the West Springfield, MA competition. While there, I noticed that only about 50% of the teams actually had autonomous mode. I came up with an idea - what if autonomous could be simpler? And therefore, this was born:
It’s currently untested, but it’s a proof of concept. This code makes autonomous easy. For example, our autonomous mode this year could be represented as:
chassis drive 1.0 0.0 2.0
“chassis”: the subsystem to be activated.
“drive”: the method to be called.
“1.0”: the amount of power to give the wheels.
“0.0”: the amount to turn.
“2.0”: the number of seconds to run.
The signature of the method is:
Chassis.drive(power, twist)
and the command is run for 2 seconds. It’s quite technical, and not quite polished. As of now you can only use primitive types and Strings for arguments, but it would be easy to add more types.
Thoughts on this system? Does it seem feasible?
if you do command based, yes Its nice to have something like this or a command group. What type of solution could you do for an iterative robot? or even a simple robot? Also most teams that use java/c++ and have the command based robot usually have an autonomous.
Seems like it would be easier to just explain to teams that you want them to have a driving forward autonomous (the most basic for simplicity) and just add
RobotDrive.whateverDrive(value,value);
to their autonomous section. If you were to give an autonomous program to another team hopefully you are only counting on them to be able to drive forward. Anything beyond that and you’re probably asking too much.
Usually almost all teams that don’t have autonomous use iterative. If you could port this to iterative (or even simple) you could make this effective. It seems kind of pointless in command based, though; oversimplifying something already simplified. It’s a great idea you have but it doesn’t seem too feasible, in my opinion.
my point exactly! but i think if we made it any simpler you would see every team with a 20 point auto
Not to be a stick in the mud, but I think that might be a bit presumptuous.
It sounds like a great idea - essentially writing an autonomous scripting language. It would certainly make it easier to reprogram autonomous in the queue.
Also, consider supporting commands which are not time-based, but sensor based, e.g. “drive until both curb feelers hit the scoring platform” or “raise load until the top limit switch is engaged”. It would probably have to be up to the teams to code the sensor monitoring and declare that the command is finished through their isFinished() method. In a 15 second autonomous period, you don’t want to wait for a timeout once you know the result is complete.
I suspect you haven’t done 20-point auto reliably, otherwise you wouldn’t make such a statement.
*It’s a crowded field…
http://www.chiefdelphi.com/media/papers/1619
http://www.chiefdelphi.com/media/papers/2553
http://www.chiefdelphi.com/media/papers/2497
http://www.chiefdelphi.com/media/papers/3081?
http://www.chiefdelphi.com/forums/showthread.php?t=131706
http://www.chiefdelphi.com/media/papers/2611
http://www.chiefdelphi.com/media/papers/2427
http://www.chiefdelphi.com/media/papers/2472
https://www.google.com/?gws_rd=ssl#q=site:chiefdelphi.com+autonomous+script
We actually do something similar to this with Piggy Plotter, our autonomous designer. We use the scripting-like approach because it allows the ability to store autonomouses which can easily be selected/edited/added/removed on a flash drive that’s on the roboRIO, as well as a general file that any robot regardless of language can read from.
Well, I wouldn’t have guessed that there were that many. The concept could easily be ported to iterable. I may add support for sensors later on if anyone wants me to.
On the topic of “everyone with Command-Based Robot has autonomous,” that’s just not true. My team didn’t for three years, and we’ve always used Command-based robot.
The other nice thing about this approach is that one need not be a programmer to use the text-based autonomous.
I don’t care if anyone uses it, but I did have fun making it.
Ether, the thing I’m noticing with those it that none of them are simple text - most are more complicated than Java. The benefit of this system is that anyone who’s played Minecraft and used commands or tinkered with a command line will be able to write autonomous.
One thing to think about when designing a programming language like this (whether or not you think so, you’re designing a programming language) is what use cases are in and what are out.
For example, will you allow:
variables
subroutines
logic (if/then/else)
looping
Another example – what support will you have for detecting errors in the script and communicating them to the user?
Once you decide what is in and what is out, you should compare the effort to do what your scripting language does to the effort needed to write the same thing in the underlying language (Java, in this case). These examples will be good to use when you’re trying to convince people that what you’ve developed makes things so much simpler that they’ll learn your language in addition to Java.
Teams that don’t have any autonomous are definitely not going to be able to program a 20 pt auto in 2 1/2 days. Even if they the entire field to themselves it would take much more time to get tuning right.
Also, no robot is alike, so if you wanted to have any interaction with the game elements the programming would have to be done by a programmer from that team (and if they could’ve they would’ve).
I’d be happy if everyone was able to get a simple robot set! I know the points are low so many have said it isn’t worth it, but keep in mind that with the system working like it does this year every point makes a difference in quals!
Yeah, but the root of this problem seems to be the lack of documentation on the libraries, but to the OP keep up the good work and figure out some way to port this onto simple!
My replies in bold. People seem to mistake this for an entire language - this is a data format that anyone could feasibly understand.
Thank you very much! And WPILib does have documentation. For me it’s in C:\Users<username>\wpilib\java\current\javadoc\index.html.