A Script System and Path Editor for Autonomous ... - SynapticNulship

A Script System and Path Editor for Autonomous Mobile Robots Samuel H. Kenyon March 30, 2004 Presented at IEEE Region 1 Student Conference on April 18, 2004 (minor changes on May 13, 2004)

Abstract There are no universal multi-platform standards for programming robots, even in educational hobby robotics. A quicker and easier way was needed for both programmers and non-programmers to create autonomous programs for a specic microcontroller-based robot control system. The solution was to create a scripted engine framework, along with a graphical path editor to create the executable scripts for mobile robots using the PIC-based Innovation First robot controllers. The system is extensible to new features like simulation and integration into behavioral control systems. Experimental results were positive but indicated a trend towards more esoteric commands as opposed to generic commands.

1 1.1

Introduction The Problem

During a particular team's experiences in the 2003 FIRST robotics competitions, the author noted that the programming of the robot autonomous control system could be improved for the 2004 season. Specically, it could be made much easier if the user could simply draw a path in a graphical user interface(GUI) on an external computer, specifying when the robot should be using dead reckoning through line-sensing, timing (the robot had no real odometry), etc. This would also allow the non-programmers and strategists of the team to actually create autonomous programs, and do it quickly. The potential of this system seemed in many ways benecial, not just as a competitive advantage but also as an educational tool. Compared to the coding, compiling, debugging process, drawing a path and pressing a button to see it executed is instantly gratifying, which is especially important for younger participants.

1

1.2

Other Robot Control Languages

One of the oldest educational robotic programming systems is LOGO [1], which was originally designed to control a physical machine (the turtle), but was eventually modied to control a virtual turtle on a computer screen. Although this was often used just to make interesting graphics, it still represented an easy way to control the motion of a mobile robot. It was also part of a study on how children can develop mental skills from programming [2]. Named after a book by the creator of LOGO [3], LEGO's Mindstorms is a more recent robotic education and hobby toy. Mindstorms does has a scripting language, which is called Mindscript.

The process is abstracted further with

graphical programming approaches. An alternative for programming the LEGO Mindstorms programmable bricks is Not Quite C [4], but while it may be simpler than ANSI C, it is still not as simple as the simple AutonScript commands which are built on underlying C code. Graphical code is not just for children but is in use by engineers and scientists such as with the block diagram technique of Labview. Robotic examples include LOGO Blocks[5], and NEC's Scenario Editor and Robot Script Language for their PaPeRo robot [6]. National Instruments, Tufts University, and LEGO Educational Division (formerly Dacta) actually did make a Labview-based system called Robolab [7][8][9]. Another educational robot programming development environment is Pyro, created for undergraduates with little experience in robotics/programming [10]. Although it uses Python script as the language, all the control systems are written in Python.

Pyro also has support for OpenGL visualizations/simulations

too, through Python.

So it is not using the script-engine model attempted

herein that allows a much simpler script to be separated from and interpreted in the pre-written robot control code. A system that was going straight for professional applications used two layers of abstraction: a lower-level signal-processing language called SIGNAL and a higher-level graphical interpreted language called PILOT [11]. Besides not having more advanced commands that are esoteric to particular sensors, none of the aforementioned systems were readily portable to the desired robot and its onboard controller, so AutonScript was born.

1.3

AutonScript

This paper describes the AutonScript system. AutonScipt is a script execution framework written in C (Microchip C18 dialect) and a GUI path editor (currently only on Windows) written in VisualBasic (but could easily be rewritten with Java or QT). The path editor generates the script, which is uploaded to the memory of the embedded microcontroller on the robot. The robot controller is already running the AutonScript code, so it can immediately execute the the new script.

2

2

Why Scripting?

2.1

Scripting Advantages

Software engines allow the content to be seperated to some degree from the program. Ideally in this case the script can be changed to completely redene what the robot will do without having to modify the embedded code.

The

process would be much slower and more likely to introduce bugs the old way. The old way consists of:



modifying the code (usually hastily)



recompiling



xing compilation errors, if any



cross-assembling



downloading (or uploading depending on your point of view) to the embedded control processor



empirical testing



xing whatever physically broke

Repeat these steps every time the user wants a slight change in operation. Ridiculous?

Perhaps.

One small change in the control code could create

bugs and/or undesirable robot activity. 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. A similar activity is the use of game engines not only for dierent products but for scientic research [12].

2.2

Simple Yet Powerful

Scripting with a proven software engine is useful because it allows already tested code to be used in dierent ways simply be changing the initial input data. Except when you are adding new abilities, there is no reason to change the code when you can just change the data, which is stored externally.

This process

makes rapid development even quicker if:



The external data is simple.



The external data is easily editable.

That is why AutonScript is not only an ASCII human-readable le made up of descriptive command mnemonic / operand pairs, but also includes a GUI path/action planner which automatically generates the script commands.

3

3

The AutonScript Framework

The embedded code for the AutonScript framework was written in the Microchip C18 dialect of ANSI C with a small amount of inline PIC assembly language. The target microcontroller was a Microchip PIC 18F8520. This was actually the user processor embedded in an Innovation First 2004 Robot Controller which included the device programming circuitry/software.

Both the EDU-Kit and

the Full-Size versions of the Robot Controller were used in testing AutonScript. Script command execution is handled inside a nite state machine (FSM). As shown in Fig. 1, the FSM is actually made up of two parts: an initialization state and a currently-executing state, both of which are coded with C

switch

statements. Although AutonScript could be used as a closed-loop control system, and the initial tests indeed used no feedback, it was designed to be an open-loop system. Many of the script commands assume that the underlying C code is using sensor data to accomplish the task. For instance, commands that move the robot's arm elevation continually check a potentiometer with calibrated values to keep it in the desired position. To command the robot to autonomously grab a mobile goal (see Fig. 2) the program used feedback from a downward-looking Sharp infrared distance sensor.

Upon sensing something of the correct height o the oor, the robot

engages the pneumatics to close the nger on the object. It would then stop moving forward and go on to the next state, which in some cases was to grab a beach ball expected to be on top of this goal with the arm (which has claws), or to keep driving forward while pushing the mobile goal, or to just remain still until user control.

3.1

Initialization and Execution State Machines

The command interpretation is straightforward: get the next command from memory, and increment the command pointer.

The individual states in the

initialization state machine handle getting the operand (stored in the same byte string in memory) and incrementing the command pointer again.

This slight

redundancy allows commands to have any number of operands including zero. The initialization states set the initial values for state descriptors, such as the desired velocity. They also reset global accumulators such as timing variables, etc.

3.2

Script Language

AutonScript is not a language denition, it is a framework consisting of embedded code, a path editor, and the concept of simple commands stored as a byte string in the robot controller's memory. So at the moment the only requirement of the commands is that they be representable by a byte-length number and any parameters (here called operands) are bytes as well, although there is no enforcement so one could store and retrieve multi-byte operands.

4

The actual

Figure 1: AutonScript Embedded Engine Flowchart

5

Figure 2: Photo of the robot grabbing the mobile goal (photo courtesy of Mary Newell DePalma)

implemented commands changed from conception to actual use, and are still uctuating.

The undened nature of the scripting language means it has to

be redened per robot situation.

Obviously if humans are writing this script

externally and/or writing the GUI path editor to generate this script, they all have to be consistent. In practice the script codes were given mnemonics with C preprocessor

#define 3.3

statements, which also made them consistent with the FSM code.

The Path Editor

The path editor, as shown in Fig. 3, is a GUI for generating scripts and downloading them directly to the robot. It was still too rudimentary to be used at the 2004 competitions, but there is no reason to suspect that it will not make AutonScript far more useful when it is more well-tested. A future extension that was always expected was to have simple simulation, if nothing but watching an animation of the path the robot will take. After attempting some LOGO-like controls, the current interface was designed to allow easy arbitrary path generation. line drawing by connecting dots together.

The user constructs a vector

The application churns out script

commands; sometimes multiple commands have to be generated at once for each new line segment, e.g.

turn and then go forward.

The ability to draw

curves was left as a future project, as was the ability to draw velocity curves. The user can also insert actions at any point, which allows for any functionality that is provided in the robot controller script engine.

An example would be

to have a sensor subsystem search for a target (the mobile goal) and latch an

6

Figure 3: Screenshot of the AutonScript path editor

appendage on to it.

4 4.1

Empirical Results Knowing What Commands to Implement

An easier way to implement the commands would be usefulsomeone has to hard code them with some knowledge of the underlying low-level system. Low level code for sensor subsystems is essential. A logical and portable solution to the necessary low-level coding would probably have to include a specic hardware platform attributes, in which case it would only be portable to robot control systems assembled after the standard was released. Perhaps one could make a hardware abstraction layer compiler for a limited number of know hardware makes and models (processors, circuit boards, sensors, actuators, connectors,

7

etc.) so that the only human coding would be completely abstract. Until then, somebody has to write code for a specic processor and robot platform that controls everything at a low level.

To make it worse, it is not known from

the outset what all the dierent activities the various robot subsystems will be expected to do beyond their designed purpose. As discovered with AutonScript, knowing what commands to implement in the FSM engine was challenging. Even though most of the subsystem control code was nished, that code still has to be controlled and used in ways that make up the script commands. There is a myriad number of possible script commands, but a lot of them would be useless, redundant, dangerous, or unwanted for a given situation. So how does one make a command set? Since AutonScript is for mobile robots, basic movement commands were assumed essential. In practice, it turned out that turning was not needed and in fact going straight was highly desired. So variations on the forward command persisted. The reverse command was there but it was never needed. The turnin-place commands were there but they were not tested or used in competition. That does not mean it was wasteful to create these commands and all the variations for using timing and odometry to go specic distances. Another empirical lesson was that in this short amount of autonomous time (and the fact that some code was being shared with the tele-operated usercontrol code), actuator commands with parameters such as an angle amount were abandoned for commands that specically set actuators to a specic place. For example, in autonomous mode the robot's arm elevated to a horizontal position from its lower starting position while the robot's drive train accelerated forward. This example is also an example of a hurried inclination towards more complex esoteric commands instead of simple single-action generic commands.

4.2

Esoteric Versus Generic Commands

The concatenation of what may have been multiple commands into single commands was done in part to have parallel autonomous execution on the robot. They various actions were not really in parallel computational threads; that is one of the benecial reasons for using a state machine and state descriptorsto simulate multiple processes on one processor. But the extent of simultaneous actions was not foreseen as it should have been. The envisioned (generic) script commands gave way in the hours of competition to esoteric and more complicated commands. Of course what was practical then was constrained by time (a matter of minutes or hours), the need to not break what already works, and the need to achieve specic goals without care for potentially better commands that would not be used immediately.

4.3

Sequential Steps Versus Parallel Steps

Perhaps if the whole system was re-oriented towards parallel steps instead of sequential steps that can modify global state descriptors it would be more ap-

8

propriate and result in less esoteric complex commands and back to the more generic simple ones. Some inspiration could come from interval scripts [13]. The problem of mutually exclusive simultaneous events in interactive environments is similar the the robot control problem. As [13] states, nite state machines and event loops have no history of event/state interaction and the resultant state descriptors require too much maintenance as the control code becomes more complex. It remains to be seen whether the AutonScript framework needs to become completely temporal constraint based like interval scripts, or if it will remain simple enough to survive with a pure FSM engine with global state descriptors. At the very least, the concept of reliable time constraints per command should be thoroughly debugged and supported.

4.4

Path Commands Dependent on Odometry

A persistent vexing problem of this team's robots is autonomous velocity control. The robot mechanically does not go in a straight line when applying the same voltage to all four drive motors. Also, there is a lot of slippage when turning and due to obstacles. Hence, it was not possible to control the robot to move a specic distance accurately. During the competitions in which AutonScript was tested, the robot was programmed to use rough timing for distance and used wheel encoders to attempt to correct the left and right sides so it would travel in a straight line.

The wheel encoders were composed of optical close-

range infrared digital-output sensor/emitter packages which were aimed at a black and white patterned disk attached to the wheel drive shafts; the code accumulated incremental wheel revolution data through external interrupts (see [14] and [15]). The concept of a robot following LOGO-like directional commands was almost obtained with a small test robot that had the same robot control computer. But a 130-pound four-wheel-drive tank-steering behemoth with with poor odometry is not going to know where it is.

Dead reckoning without the reckoning

is just dead. The odometry and dead reckoning were improved during competitions, but the situation highlights the necessity for underlying systems to be working properly for anything built on top of them to work well.

5 5.1

Conclusion Successful?

AutonScript was successful as an autonomous control system for short periods of time with an arbitrary number of steps and simultaneous actuation states. The empirical results were educational as they showed that the system did in fact work but there was a trend towards more esoteric, parallel commands than the originally anticipated generic in-series commands. Also, these robot competitions were not testing the full AutonScript system, as the PathEditor GUI was not complete, so more testing needs to be done.

9

The dependence on good underlying subsystem code became very evident. The script should not use functionality that has not been physically tested and debugged. AutonScript only allows rapid development and testing after a lot of the hard work of slower development and testing of sensor and actuator subsystems, and doing that all at once only adds a slight advantage over nonscripted engine approaches.

5.2

Educational Potential

AutonScript was inspired by and designed initially for the FIRST competition, which is an educational program. So this was indirectly supporting education of high school students. But really any framework designed to allow a robot to be controlled more abstractly and easily will at least promote interest in robot control issues. Of course, once it is proven to be useful for educational purposes, it may then end up being used for research purposessimple reliable systems are often used and built on instead of wallowing in complexity and diculty.

5.3

Commercial Potential

If robots now are indeed analogous to what computers were in the late 1970s [17], then perhaps now is the time to establish a simple (to the end-user) robotic control system. Once expensive tools that only large companies could aord, computers for the most part entered the consumer, hobby, and educational markets in the 1970s all at once. That seems to be happening now for robotics, through various popular competitions (FIRST, BattleBots), consumer robots (autonomous vacuum cleaners and lawn mowers), hobby/educational projects(LEGO Mindstorms, Robosapiens), military (iRobot Packbots and unmanned aerial, underwater, and ground vehicles), and health care. The scripting system described in this paper is certainly not of the same scale or purpose as a standard software platform for robotics, e.g., Evolution Robotics' ERSP architecture [16]. Although AutonScript is extensible to any type of autonomous behavior, it is not designed to be the tool to generate AI programs much beyond discrete steps. For instance, it is entirely expected to want script commands to enter into completely sensor-based modes where the behavior is not always the same, for instance searching for an object. the underlying code for this routine still has to be written.

But

It could be as

simple as checking a single sensor input or it could be a complex external multiagent program, or part of a subsumption network, or any other AI algorithm. That reveals the main caveat of this framework: the script will run perfectly in software, but the behavior of the robot from this script is only as good as the underlying command code. Furthermore, the underlying command code is dependent on the sensor subsystems, etc.

of the robot.

For instance, if one

has line-following code that is buggy, the script with a command putting it into a line following state followed by picking up the object at the end of the line may not execute as expected. Likewise, if the line-following code is robust and

10

bug-free but the line sensors are not being read correctly, one gets unexpected results. However, if the main nite state machine was also scripted or externally congurable, even less time would have to be spent writing internal C code. If the AutonScript framework evolved, approaching a very easily modiable (through scripts and GUI editors) and portable system, then it could have some commercial potential, possibly as a educational/hobby control system that is more advanced and portable/scalable than LOGO Blocks but not as complicated as professional/proprietary systems. Most likely it will remain a free project.

5.4 5.4.1

Future Work Path Editor Improvements

The path editor needs to be nished, furthermore implementing a simulation capability would make it even more useful. Although simple at rst, one could extend the simulation capabilities into a complete realistic physics-based 3D environment, such as in [18].

Accessing the script memory of the embedded

microcontroller without reprogramming needs to be nalized as that would make the whole system more ideal as it was intended.

Also, the notion of parallel

events needs to be added somehow. Of course, the script and engine also have to have a notion of parallel events too, perhaps beyond the current state descriptor system (such as a graphically-describable temporal scheme like that of [13]).

5.4.2

As a Subsystem in a Reactive Autonomous Control System

AutonScript could be extended to be part of a larger autonomous control system. If the human computer interaction (HCI) aspect is replaced with an AI planner, the resulting system would still have an underlying low-level command interpreter that can be debugged separately from the higher-level planning software. In essence, one has a layer making abstract commands for a less-abstract layer. It might be similar to [19], in which planning and task renement layers produce scripts that end up executing through low-level modules (although in that context script has a slightly dierent meaning).

But the AutonScript

extension could be reactive, if its behaviors are dened with short scripts that still allow it to respond in real time. Or the behaviors could directly modify the current state(s) in the FSM engine. An upper level planner could also generate/choose/modify scripts running on the FSM engine and then an arbitrator might be needed, as in Fig. 4.

11

Figure 4: Diagram showing a potential extension of AutonScript as a hybrid reactive/planning autonomous control system

12

References [1] What

is

Logo?

index.html

http://el.media.mit.edu/logo-foundation/logo/

http: //www.papert.org/articles/AnEvaluativeStudyofModernTechnology. html

[2] S. Papert, An Evaluative Study of Modern Technology in Education,

[3] S. Papert, Mindstorms: Children, Computers, and Powerful Ideas, Basic Books, 1980. [4] "NQC - Not Quite C,"

http://bricxcc.sourceforge.net/nqc/

http://llk.media.mit.edu/projects/ cricket/doc/help/logoblocks/LBtutorialRCX.htm

[5] Introduction to Logo Blocks,

Robot PaPeRo 2003, http://www.incx.nec.co.jp/robot/ 2003papero/english/gijyutu4.html

[6] Personal

ROBOLAB Software, http://www.lego.com/eng/education/ mindstorms/home.asp?pagename=robolab

[7] The

[8] LEGO ROBOLAB - Education Initiatives,

robolab.htm

[9] ROBOLAB,

http://www.ni.com/company/

http://www.ceeo.tufts.edu/graphics/robolab.html

[10] D. Blank, L. Meeden, and D. Kumar, Python robotics: an environment for exploring robotics beyond LEGOs, January 2003 ACM SIGCSE Bulletin, Proceedings of the 34th SIGCSE technical symposium on Computer science education, Volume 35 Issue 1. [11] E.

Le

SIGNAL: 4th

Rest, A

ISMCR,

J.L.

Fleureau,

Complete Bratislava,

and

L.

Programming Slovaquie,

Marc'e, System

[online],

From For

1995.

PILOT

Robotics, Available:

to in url-

http://citeseer.ist.psu.edu/130371.html. [12] M. Lewis and J. Jacobson, Game Engines in Scientic Research, Communications of the ACM, Vol. 45, Issue 1, pp. 27-31, Jan. 2002. [13] C. S. Pinhanez and A. F. Bobick,

Interval scripts:

a programming

paradigm for interactive environments and agents, Personal and Ubiquitous Computing, pp. 1-21, 2003. [14] J. L. Jones and A. M. Flynn, Mobile Robots: Inspiration to Implementation, A K Peters, Wellesley, MA, 1993. [15] J. Borenstein, H. R. Everett , and L. Feng, Where am I? Sensors and Methods for Mobile Robot Positioning, The University of Michigan, 1996.

13

[16] P.

Pirjanian,

Toward

a

Standard

Software

Platform

for

Consumer

Robotics, presented at Emerging Robotics Technologies and Applications Conference, Cambridge, MA, 2004. [17] R. Brooks, Adaptive, Intelligent Robotics Systems: Societal and Commercial Implications, keynote presentation at Emerging Robotics Technologies and Applications Conference, Cambridge, MA, 2004. [18] T. L. Dunn and A. Wardhani, A 3D Robot Simulation for Education, ACM, pp. 277-278, 2003. [19] R. Chatila, R. Alami, B. Degallaix, and H. Laruelle, Integrated Planning and Execution Control of Autonomous Robot Actions, Proc. IEEE International Conference on Robotics and Automation, pp. 2689-2696, May 1992.

14