Re: SmartSoft / CORBA next release

Hi,

On Tue, 3 Dec 2002, Christian Schlegel wrote:

> [...]
> Boris, could you please again mail the short documentation on our finite
> state automaton task coordination mechanism which runs on top of the
> communication patterns ?

Sorry for the delayed answer. I'll try to briefly present the ideas.

Think of having a collection of components which can fulfill several
tasks, depending on the state of each component (by "state of a component"
I mean "state of activity of a component" or perhaps more clearly the
"configuration of a component"; as I understand it, this is the topic
addressed by the SmartSoft state pattern). Now we want to coordinate the
action of these components, for example performing a sequence as "find
bottle on table", "graps bottle", "put bottle in storage area", with
exception handling. Resource allocation changes during sequence execution:
during the "find bottle on table" part, we want to give most computing
resources to the vision system, while during the "grasp bottle" part a
manipulator has to be controlled etc.

The idea is that such simple sequences could be accomplished by a finite
state automaton, where the automaton interacts with the components by
(a) setting the states of components and sending queries and commands to
components, and (b) receiving events, query answers and pushed data from
the components.

We implemented this concept for integrating several components to create
small demos, like the table clearing example above. In the remainder of
this posting I'll give details on the automaton. Source code can be
obtained from
http://www-info1.informatik.uni-wuerzburg.de/de/mitarbeiter/kluge.html/software/fsmctrl.tar.bz2
Note that this source code uses an older version of SmartSoft. It won't
compile with Orocos::SmartSoft. However, there is a PostScript file
included which might give further details.

The automaton is a hierarchical finite state machine, i.e. one may use a
sub-automaton as a state in a superordinate automaton. This is a rather
straight-forward use of the compound design pattern (state generalizes
automaton, automaton contains states).

Each state of the automaton declares which components it requires in what
component state. Since an automaton A containing a state S is also a
state A (state is a generalization of automaton), conflicts may arise, if
A and S require the same component to be in different states. The designer
of a specific automaton is responsible for avoiding such conflicts. On
automaton state transitions, the automaton ensures that the component
states are changed accordingly.

The base class for an automaton state has several virtual methods which
are called on specific occasions and which are empty by default (template
method design pattern). The occasions are: state entered, event received,
state left. From within these methods you can communicate with the
components: send them commands or query requests, and (un)subscribe to
pushed data (that is, communicate via the SmartSoft communication
patterns).

Data returned by the components is passed to the automaton for
processing. This data may be (a) an event from a component, (b) a query
result, and (c) pushed data. Initially, the data is passed to the most
specific current state of the automaton (the current state of the
automaton which is not a sub-automaton itself). If the event reception
method consumes the data, we're done. Otherwise, the data is sucessively
passed to the enclosing automata where it may induce a state transition
which consumes the data and terminates dispatching.

This is more or less what we implemented and used.
There are two further ideas which might be interesting to investigate.
First, a finite state automaton is sometimes a bit too restricted. Why not
give it a stack? This will be beneficial if we want to be able to
cancel a running task execution when the environment is not yet in a
"clean" state (e.g. the robot is holding a bottle in its manipulator while
the user interrupts it, wanting it to go to another place). The stack
could encode what has to been cleaned up before the new task is started.
Second, since an automaton is a component, too, such automata may be of
use if one decides to use a different type of toplevel components. One
could encode simple subtasks as automata which are activated by the actual
toplevel component.

Cheers,
Boris
--
Boris Kluge
Research Institute for Applied Knowledge Processing
Helmholtzstr. 16, D-89081 Ulm, Germany
phone: +49 731 501-674, fax: +49 731 501-999