During 2003 and 2004, I worked on FIRST robots. I was a college student, but Northeastern University hosted a team supporting multiple high schools. FIRST competition robots are radio controlled, however autonomous routines activated by the operator are allowed and would be hugely advantageous. But most teams never got to that point, and were lucky to have much beyond the default code.
I also started making my own robots. I had hacked at robots before, but I hadn’t made my own that actually worked until 2003. First I used parts from the IFI Edukit that came with one of the FIRST robotics kits to make some little experimental robots and one that was intended for a Micromouse competition (but wasn’t finished in time). Eventually I made my own microcontroller based board which I attached to an RC truck chassis.
In all of these cases, I started to realize that a lot of basic things that we wanted these robots to do could be represented with simple scripts.
Coding vs. Scripting
I also realize that instead of having to hard code every new behavior or experiment or whatever, that a script would make programming the robot a lot easier. The typical hobby/amateur robot programming procedure is:
- Modify the code (usually hastily).
- Fix compilation errors.
- Download to the robot computer.
- Empirical testing.
- Fix whatever broke.
Rinse, repeat. Indeed, repeat when you realize the robot didn’t do what you wanted. Repeat every time the user wants a slight change in operation. Repeat every time your one small code change introduced a major bug. Et cetera ad nauseum.
But if the control code is well-tested and proven to work, a script being interpreted by this code will not break the code. One may still create undesirable robot activity, but it will be more obvious why something unexpected happened.
Script Engines for Robots
The key idea is that you have a robust hard-coded core (the engine) which can be used in many ways just by changing the input data.
The concept of a software engine running scripts is not new (nor was it in 2004). A lot of video games use that model (of course a lot of the non-engine code is compiled in, but hopefully you get the point). And scripting in general is usually a lot less painful for certain kinds of tasks.
Ideally a script can be changed to completely redefine what the robot will do without needing to modify the embedded code (embedded means the compiled code running on the robot). Preferably, it is also hard to break anything with malicious scripts.
So in 2004 I hacked together a simple scripting framework for mobile robots. Originally I called it AutonScript; later I called it SIRCS (Scripted Intelligent Real-time Control System). It doesn’t remove the necessity to develop the basic low-level routines and states. But if you have at least some robot behavior code working on a particular robot, scripting is a great way to take advantage of that.
For instance, a typical low level robot behavior might be to drive. And then you will want to be able to turn, and to drive / turn for a certain distance, and so on. The scripting framework doesn’t specify feedback loops or how anything gets done. How good these little behaviors are depends on what you’re doing. A script composed of badly working behaviors may still be good enough.
The script engine is basically a couple of state machines, and of course the code to achieve those states which is specific to the robot.
In my implementation, I eventually ended up also having meta-states, although they were not all fully implemented and tested:
- Script: Default mode. Running a script.
- Immediate: Controlled in real time by a remote user without scripts.
- Mission/Goal: Running a mission comprised of multiple scripts.
- Configuration: Special mode for configuring by a programmer. Or something—I don’t remember.
Interfacing the Framework to Higher Levels
I envisioned interfacing this framework with higher level abilities such as missions and a high-level arbitrator to choose when multiple internal commands were attempted simultaneously.
Eventually I came up with this design of a semi-autonomous framework. The diagram is arranged so that the topmost boxes are remote (at the user) and as you go downwards, the boxes become more robot embedded. The Arbitrator may be remote, it may be embedded, or maybe there are arbitrators at both places.
Scripting also enables certain graphical interfaces for easy robot autonomy configuration. For instance, my original interface for this was a path editor, in which a user just drew a path overlaid on a map image and this was supposed to automatically create the correct robot control script.
That was the alpha version. Here’s a screenshot of a slightly more advanced GUI intended for use by a FIRST robotics team:
The idea is that the user would draw a simple vector-style path, and the dead reckoning command script would be autogenerated. The user could also insert actions at various points, such as Grab Goal, which was a routine specific to that robot and that competition. And script would of course be auto generated for actions as well.
Parallel operations can sometimes become problems. There are often ways on microcontrollers to deal with this without having to resort to a multithreaded OS solution, for instance interrupts or just adding things to a main loop. An easy way to have multiple states changing at once with this scripting framework would be to maintain various global states that are always getting checked in the main loop, and some script commands may simply set the target for one of those states and set the flag to allow the next command to be processed. In those cases, the next state to be set doesn’t have to wait for any previous ones to finish.
In the next post I will describe the last robot in 2004 I made which used this framework.
For more info:
- Source Code: SIRCS Github Repo
- S. Kenyon, “A Script System and Path Editor for Autonomous Mobile Robots,”
2004 IEEE Region 1 Student Conference at Stony Brook University, April 2004