Autonomous scripting language

[joelg236]

As a side project, I have written a full scripting language for making autonomous modes based on a script instead of redeploying code. If you're interesting in seeing, the github repo is available here -> https://github.com/joelg236/ScriptReader/

To use it, either pull the repo or download as a zip file, and with netbeans, open the folder that contains the files as a Java project.

The ScriptReader file in src/org/reader/ScriptReader.java contains a static runScript(String) method, and you can use that to run a script. There is a main method that runs a file from the arguments run with. Use whatever you'd like.

There is a zip file that contains script examples and the jar file here -> https://github.com/joelg236/ScriptReader/downloads

Any questions, recommendations and interesting implementation possibilities are welcome. And of course, bugs.

Thanks,
Joel

[Hjelstrom]

Very nice! We have been thinking about something similar for C++. The compile-download cycle is a real limitation when you're tweaking a complicated autonomous routine.

Originally Posted by joelg236

As a side project, I have written a full scripting language for making autonomous modes based on a script instead of redeploying code. If you're interesting in seeing, the github repo is available here -> https://github.com/joelg236/ScriptReader/

To use it, either pull the repo or download as a zip file, and with netbeans, open the folder that contains the files as a Java project.

The ScriptReader file in src/org/reader/ScriptReader.java contains a static runScript(String) method, and you can use that to run a script. There is a main method that runs a file from the arguments run with. Use whatever you'd like.

There is a zip file that contains script examples and the jar file here -> https://github.com/joelg236/ScriptReader/downloads

Any questions, recommendations and interesting implementation possibilities are welcome. And of course, bugs.

Thanks,
Joel

[CodeYeti]

Our team personally doesn't use this, but I think it deserves some exposure. Greyhound Lua provides another way to push code to the robot without restarting it. Bonus: its ALL of your code.

Heres a link to the project on bitbucket:
https://bitbucket.org/zombiezen/greyhound-lua

[apalrd]

Very interesting.

I believe this is the first completely custom scripting language I've seen for FRC that attempts to provide a full programming environment - You have loops and conditional blocks and everything.

Our system executes commands in sequence, with numeric arguments. The majority of the code is LabVIEW native - We simply have a high-level script which guides the high-level actions (such as drive_straight distance speed, stop, turn heading speed, drive_straight distance speed, etc). This closely mirrors the C-function call system we use in VRC, where functions do all of the work and we call them in order with arguments.

I have also seen a system which are time-based - A command will be given with absolute or relative start/stop times, and the system schedules them all, but that system also had the majority of the core code in native blocks instead of the script.

It'd be interesting to debate the merits of putting more or less code into the scripts vs the native functions.

[connor.worley]

Originally Posted by Hjelstrom

Very nice! We have been thinking about something similar for C++. The compile-download cycle is a real limitation when you're tweaking a complicated autonomous routine.

http://www.chiefdelphi.com/forums/sh...d.php?t=105624

Have a look there if you haven't yet. It was definitely interesting to write.

[McGurky]

I would also suggest that you take into account that a lot of last minute changes to strategy might occur in cue for a variety of reasons(if you have ever been on a drive team, you know what I mean). Whatever your solution is for simplifying autonomous selection, make it something that your drivers will be able to change easily and with little hassle.

For us, it was more important for the drivers to focus on strategy than figuring out the binary codes of a selection panel, or a script like you have posted.

For this reason our team integrated the following tab into our dashboard.


This allowed our drivers to simply change the autonomous routine to a (theoretically) infinite amount of choices. It also allowed our team to adapt to nearly any strategy the alliance was planning.

Just my input into the discussion, take it for what its worth!

[vinnie]

Originally Posted by McGurky

I would also suggest that you take into account that a lot of last minute changes to strategy might occur in cue for a variety of reasons(if you have ever been on a drive team, you know what I mean). Whatever your solution is for simplifying autonomous selection, make it something that your drivers will be able to change easily and with little hassle.

For us, it was more important for the drivers to focus on strategy than figuring out the binary codes of a selection panel, or a script like you have posted.

For this reason our team integrated the following tab into our dashboard.


This allowed our drivers to simply change the autonomous routine to a (theoretically) infinite amount of choices. It also allowed our team to adapt to nearly any strategy the alliance was planning.

Just my input into the discussion, take it for what its worth!

This is so much more sophisticated than what we did
We just had a jumper connected to a digital in that would enable or disable autonomous based on whether it was connected or not. We scrapped that in eliminations at Central Valley when we rewrote our autonomous to feed the balls that we had to 1323.

[apalrd]

If we wanted something we didn't already have a script for, or more likely wanted to tweak a script, we could do this in several ways:

-12-position knob on the Kat Box with file name indicator on the Dashboard. The 12 file names are hardcoded, but the string name is sent to Dashboard so we only have to modify the built code to add a new file (we never added a new file during competition). At the end of the season, we had 10 programs, some of them heavily tuned for various driving maneuvers.
-Old/New speed variation control potentiometer, this acted as the hood angle manual override during teleop but was read as old/new in auton
-Change the text file and FTP it to the cRio in the queue - We did this often for delays or ball spacing tweaks and the like.

Using text files allows for very repeatable execution compared to something where you enter the commands every match, easy modification, and easy addition of new scripts.

[Tom Line]

Originally Posted by apalrd

Using text files allows for very repeatable execution compared to something where you enter the commands every match, easy modification, and easy addition of new scripts.

We used this method as well. We used an FTP script that downloaded all our auton files, all our constant files (PID Gains, etc), and then downloaded all the pictures taken on the field (we took a picture every time we pulled the trigger) to the computer for analysis. That really helped our accuracy increase as we got a bigger and bigger picture pool.

Our script was simple. Each 'block' of code had lines for every function on the robot: shooter angle, shooter speed, robot angle, distance to drive, etc.

We couldn't change them at the dashboard on the field, but updating the in the pits was a matter of seconds.

We learned this the hard way at the 2011 champs when we wasted an entire practice field session waiting for new auto code to compile.

[vhcook]

Chris Hibner from 51 had actually done a presentation on this sort of thing (flexible autonomous control using a flat file on the cRIO to pick actions rather than having to completely recompile for changes) for FIRST Conferences in 2011. Here's a link to his presentation and samples.