Subsumption architecture with Robolab 2.5

1. Motivation:

As many robot builders before us, we noticed major problems that occured every time we designed a robot which had to fulfill different tasks simultanously, especially when these were accessing sensors, actuators or global variables together.

Many kinds of conflicts appeared: 

• the robot did not choose the desired reaction on a sensor-input
• it started jiggling as the result to opposite motor-commands
• a global variable took intermediary values if operations were applied to it ...

There are many ways to overcome these problems. Most of them obey to the rule of the growing complexity, but some are quite easy to manipulate:

• event-orientated programming for best sensor-management
• output-access-control through task-hierarchy and output-monitoring
• combining local and temporary variables with global variables

Complexity appears when these approaches have to be linked. For example LEGO describes its new RCX-firmware 2.0 in the paper Command Overview released with the beta-version, writing: "When event monitoring is used in combination with access control across several tasks, a complicated regime must be implemented ..."  Follows a two-dimensional [ 7 x 5 ] array of events, states and reactions.

Robolab 2.5 offers the 2.0-firmware-based features of event-monitoring and access-control. 

As we are using Mindstorms with secundary students, we think that we have to simplify the concepts. We found out that the event-monitoring is a perfect system to use across more tasks. But besides the complicated combination-possibility, the Robolab access-control has the major disadvantage that the hierarchical acquiring of the output-access is only a one-way-process. The ouput-control does not return automatically to the task which had to release the control due to the request of a task with a higher priority!

So we looked around and decided to try a Robolab-implementation of the SUBSUMPTION ARCHITECTURE. This robot-programming technique developped by Rodney Brooks at MIT in the late 1980s may well be combined to the event-monitoring. We do not want to develop the whole paradigm here, but only the major ideas. For more explicit information there exist a lot of explaining web-sites. Have also a look at Jonathan KNUDSEN's book "The Unofficial Guide to LEGO Mindstorms Robots" (USA, 2000), pages 179ff.

2. Principle idea:

In simple words: let a certain condition NOT produce a reaction directly, but only NOTIFY that the specific reaction should happen. A special arbitration-task decides according to the hierarchy of the notifications which of the reaction-pool must be fulfilled. Thus every running tasks tells the arbitrate the kind of reaction it requests. The arbitrate then checks all the requests and discernes the most important reaction, then activates the output-control-subroutine.

This will be clearer through an example:

We want to program a mobile robot that will run forward until it hits an obstacle (1) then avoid this obstacle and continue its way (2).

This can be done in several ways. Here some examples in pseudo-code :

This system works without ambiguity with two tasks, but what, if we add another mission: follow a given compass-direction (3). The following scenario works, but shows some trouble during the transition time, as the motor-control passes from one task to another.

The subsumption architecture will give us a quite different scenario:

Each task has a special control-variable which may adopt various values:

command_forward = 1

command_reverse = 2

command_left = 3

command_right = 4

command_stop = 5

comand_float = 6

(Note that the picture below uses command_rectify and command_avoid, which are only representatives of such commands; note also that the absolute values are not relevant.)

Most important is the command_none = -1, which informs the arbitrate that the task does not request any motor_control.

The very special arbitrate-task operates the dispatching of the control-notifying.

Only the motor-control subroutine has direct access to the outputs and executes something like: 

if motor_command = command_forward then turn on the driving motor(s) fwd

if motor_command = command_back then turn on the driving motor(s) rev

...

where the variable motor_command transports the correct command-value.

The advantages are clear:

• there is no conflict of motor-access because the arbitrate assigns always the highest priority control-value to the motor-command-variable
• the release of output-access is given without ambiguity and the control returns to the requesting task with the highest priority
• the program-complexity does not grow too much by adding new tasks

3. Implementation:

In order to implement this robot-programming technique into Robolab, we designed some useful sub.vis :

Here the detail of the arbitrate-task:

TO DOWNLOAD THE FILES: CLICK HERE

4. Example Wall-avoider:

Note that the third command-line is connected to the second, because there are only two tasks operating. An event-orientated compass-rover will follow soon !

Main Page