Text-based Autonomous POC

Defensoft3585 · #1 07-03-2015, 20:59

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:
https://github.com/JavaMatrix/TextBasedAutonomous
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?

Fauge7 · #2 07-03-2015, 22:40

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.

TimTheGreat · #3 07-03-2015, 23:05

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

Code:

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.

Ozuru · #4 07-03-2015, 23:21

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.

Fauge7 · #5 08-03-2015, 00:23

Quote:

Originally Posted by Ozuru

Usually almost all teams that don't have autonomous use iterative.

my point exactly! but i think if we made it any simpler you would see every team with a 20 point auto

dellagd · #6 08-03-2015, 03:22

Quote:

Originally Posted by Fauge7

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.

virtuald · #7 08-03-2015, 10:38

Quote:

Originally Posted by Fauge7

my point exactly! but i think if we made it any simpler you would see every team with a 20 point auto

I suspect you haven't done 20-point auto reliably, otherwise you wouldn't make such a statement.

TimTheGreat · #8 08-03-2015, 17:34

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).

GeeTwo · #9 08-03-2015, 10:08

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.

Ether · #10 08-03-2015, 10:52

Oromus · #11 08-03-2015, 11:57

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.

Defensoft3585 · #12 08-03-2015, 15:22

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.

Defensoft3585 · #13 08-03-2015, 15:24

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.

MrRoboSteve · #14 08-03-2015, 15:34

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.

Defensoft3585 · #15 10-03-2015, 14:52

Quote:

Originally Posted by MrRoboSteve

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 No, this is supposed to be simple.

subroutines No, this is supposed to be simple.

logic (if/then/else) No, this is supposed to be simple.

looping No, this is supposed to be simple.

Another example -- what support will you have for detecting errors in the script and communicating them to the user? If you read the code, it already has this feature.

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.

My replies in bold. People seem to mistake this for an entire language - this is a data format that anyone could feasibly understand.

Thread Tools
Show Printable Version Email this Page
Display Modes	Rate This Thread
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode	Rate This Thread: