Using A Scripting Language To Script Robot Behaviour

[JamesBrown]

Originally Posted by Ether

Another example would be automotive smart actuators, but for a different reason: with the high volumes, pennies matter. Coaxing the required performance out of an inexpensive microcontroller often means you can't even afford the overhead of a commercial RTOS, let alone an interpreter. Coding for such an environment requires a unique set of skills.

This applies to nearly any consumer electronic device. I can tell you for a fact that there are almost no mass produced toys that are coded in a scripting language.

[Foster]

TomLine has had the best set of comments about scripting. In my world I program at five different levels:

Bare metal - This is low level microprocessor code, it's running on the processor there is no OS involved. I program in C so the steps are compile, download, test. But I have a PIC development environment so I can also do some interactive debugging on my desk before I download code to the hardware.

Robot code on the cRio - Low level code, while there is a kernel OS running, the system needs to be restarted to test. So the code cycle is the same as bare metal

Code on an OS that needs to be restarted - Java and C where the application needs to be stopped and restarted. There is a huge selection of tools that can be used to develop with interactive debuggers to make the development process much faster

Code on an OS that does not need to be restarted - The land of scripts. There is a interpreter process that runs all the time processing the script. When there is new production code the interpreter process is directed to the new script and it runs that. I program mostly in TCL for that environment.

Programs that do X out of the box, but I need to extend the functions. In most cases the company has allowed me to call some "scripting language" from points in their product. For example the proxy server I use allows me to call Lua code to do specific processing of a message. The short fragments allow me to have custom code without rewriting the entire product.

Some of the "faster in scripts" has to do with the functions built into the scripting language or libraries, not with the code. Perl and TCL have some great array and string functions built in so there is less code to write. But there are great Java and C libraries that you can use so the code effort is almost the same.

The key difference in my world is that we use a structured methodology to programming. Analysis, design, code, test, implement. Half the time in analysis and design, 1/4 in code, 1/3 in test. Always the same, C, Java, TCL, Lua. Now there are mentions to "hacking away", just jumping in and cutting code. And those people will take more time because they are not doing the analysis and design up front, they do it and re do it as they go. So there is a good deal of rework as they go along.

But because it's ongoing code, test, code, test, they don't see the embedded analysis and design time. (And I'm a big fan of agile methods (I'm a certified Scrum master) but there is analysis and design going on)

Blake makes a good point about "hacking away" and safety. Not on his plane, maybe on the robot if he's out of the way. Nothing to do with the "language" in use. I can write equally good code in C or TCL, the testing process is what makes the difference.

Greg McKaskle makes a good point to start with the core C calls. If I was going to do your project I would pick a scripting language that can be embedded in a C program (like TCL) or Java (like Lua). I'd build the core infrastructure (API calls) that runs the motors and IO ports and let them be called by the scripting language. Make a way to stop and restart the core program externally so the script can be changed.

My big points are:
* Planned code development isn't that much different from language to language.
* Ad hoc development (hacking) is fine if you don't need to depend on the results.
* Scripting is attractive to our robot worlds IF it would end the long compile / reboot cycles.
* There is no silver bullet. (The Lone Ranger is an actor with a mask)

Keep us posted on how your scripting kernel works out.

[Al3+]

Originally Posted by demosthenes2k8

First, I'm glad I'm not the only one with this bad idea.

Same here. I'd be interested to hear if anything comes of this.

[apalrd]

Integrating a scripting language is not a bad idea, depending on usage.

If you are trying to do a lot of programming that you don't modify much, then scripting is NOT the answer. You can write an interface that acts like a scripting language in C/C++ and compile it.

However...

Autonomous is often modified, so scripting autonomous may be a good idea. I think that the best way would be to create an XML definition for waypoints which the robot will navigate between on its own. You could then use a high-level scripting language to evaluate expressions, such as speed. Example: You are playing Overdrive and must knock down the trackball (or two) of your color. However, you want to slow down until the mechanism to knock it down is ready.

<waypoint x=35 y=8>
       <curve>0</curve>
       <elev_state>knock</elev_state>
       <speed>14</speed>
</waypoint>

This assumes you want to go 14 ft/sec. With scripting, you could also do:

<waypoint x=35 y=8>
       <curve>0</curve>
       <elev_state>knock</elev_state>
       <speed script=1>= 14 - ( (35 - nav_d__remain) * elev_error * .1 )</speed>
</waypoint>

Then the robot could evaluate the script to find the desired speed, based on how far the elevator is off and how far the nav distance remains to the target. This would allow it to slow down less when it has more time to get there. The waypoint also has a flag to set the elevator state to "knock".

Using a scripting language in this case would allow the programmer to modify autonomous variables quickly and save the .xml file to the filesystem, eliminating the need for compiling, downloading, and rebooting to make small auto changes.

HOWEVER - you might not need this. A simple XML parser will probably provide everything you need. It all depends on the game.

PS. If anyone does write a Python or other scripting language interpreter interface for LabVIEW, I want a copy.

[Robototes2412]

labview can do file i/o?

[apalrd]

LV can do file IO, and has built-in functions to handle XML parsing, CSV and other spreadsheet-type files as well as raw binary and string files (plus a file dialog box if you are on a target that has a GUI). It has an advanced section with tons of file properties, move,delete, etc. too.

It's actually quite a powerful language once you get to know it. It can create threads like nothing (just drag and create a new loop, and it runs in a new thread, great for kicker timing and whatnot), manages locking of variables between threads for you, has calls to lots of thread operations like Notifier, Semaphore, Rendevous, Occurrences, etc, has tons of helpful interfaces like RT-FIFO, TCP-IP (or UDP-IP), remote front panels when debugging, graphs on those front panels in realtime, and a PID block.

[gblake]

Originally Posted by apalrd

...
Using a scripting language in this case would allow the programmer to modify autonomous variables quickly and save the .xml file to the filesystem, eliminating the need for compiling, downloading, and rebooting to make small auto changes.
...

That's not all a scripting language will let you do. It will also let you quickly introduce mistaeks.

Originally Posted by gblake

...
A good programmer will know how to succeed at both styles of coding, and will be wise enough to know the differences between them, and to know when each is appropriate/useful.
...

I'm still not saying either method is "the best". I am suggesting that you think carefully before using scripting in a high-pressure environment without also implementing some error-checking that can be executed before putting the robot on the real field.

Blake

[Foster]

I don't know apalrd, have no idea where apalrd is, etc, etc. Apalrd, humans do not write in XML. Humans should NEVER write any form of a language that looks like XML. Humans should never write or read a language that has more punctuation than value.

XML has been foisted on the masses by inept computer people that can not write simple parsers.

way point_x=35
way point_y=8
curve=0
elev_state=knock
speed=14

Much better than XML like brace stuff

XML is for computer to computer stuff. Write in a human language for humans.

And for those of you that write in XML because "chuck" at tool I use dot Borg designed it that way. Check up on Chuck, he may have gone "missing" There is a world wide stamp out of XML by people in action.

[gblake]

Originally Posted by Foster

... simple parsers...

I have some samples of using Java's StreamTokenizer class to read text files, parse their contents into keywords and parameters, and then use that info to configure/control what the rest of my software does. If I can figure it out, it can't be hard.

I'm sure Foster has (or can whip up) examples too.

Let us know if you want to see some code.

Blake

[StevenB]

Originally Posted by Foster

I don't know apalrd, have no idea where apalrd is, etc, etc. Apalrd, humans do not write in XML. Humans should NEVER write any form of a language that looks like XML.

A language like... HTML? The "language" that the entire web is built on - much of it by hand, or at least with major human interaction?

I'll be the first to agree that the Unix/Linux config file style that you describe is a more human-readable format. Comments are simple (typically a # sign), the options are clear, and the layout is simple. However, XML has a lot of things going for it:
- Parsers are freely available (Xerces, expat, Java's JAXP, and others)
- XML can be validated against a schema to ensure that only valid configurations are specified. Yes, you can do this with a custom parser too, but schema validation is already done and is pretty easy to implement.
- It is human-readable, even if not perfectly so. And there are a lot of good tools to help (Eclipse's XML editor seems pretty cool, although I don't know enough to give an expert opinion on it).

[gblake]

Originally Posted by StevenB

A language like... HTML? The "language" that the entire web is built on - much of it by hand, or at least with major human interaction?
...

I'm going to guess that his anwer is, "Yes - For the obvious reason already given."

Blake

[apalrd]

1. I was not intending to writing raw XML. I was intending to write another program to write the XML files based on a map of waypoints and data. In a pinch, you could edit the raw XML files. Also, the authoring program could simulate the expressions that would be run through the scripting engine, with user-set variables and such to determine the expected result and error state.

2. If you had an autonomous editor, you could punch in coordinates of each waypoint and it would generate the XML file, and you could then go to each waypoint and set the states of mechanisms, scripts to be evaluated for values, check the results of the scripts given simulated data, check for errors, etc.

3. On error, you could revert to a alt. value, so the line that determined speed could look like this:

<speed script=1 alt=12>= 14 - ( (35 - nav_d__remain) * elev_error * .1 )</speed>

[gblake]

Originally Posted by apalrd

1. I was not intending to writing raw XML. ...
2. If you had an autonomous editor, ...
3. On error, ...

That all sounds entirely reasonable; but the complications might detract from those benefits of using a scripting language that made you consider using one in the first place.

Regardless, have fun; and learn something.

Good luck on the fields,
Blake
PS: For my money, if I couldn't run any autonomous on a practice field, I would want to see the entire script run and get used to draw the route (and label the other actions) in a GUI; before I put the robot into a match with an untested, freshly-edited script. The graphics API would be substituted for the real robot's API inside the cRIO. Switching between sending the script's outputs to the graphics API or the real robot API(s) would be a mistake-proofed, 1-line change and would be reflected in the state of something you could see (an LED) if you briefly turn on the robot before a match.