Events, object state machines and the execution engine...
Herman Bruyninckx <[email protected]>
| Newsgroups | gmane.science.robotics.orocos.user |
|---|---|
| Message-ID | <Pine.LNX.4.44.0206161636020.7654-100000@pc25-213.mech.kuleuven.ac.be> |
One of the infrastructure topics Orocos is working on is the `execution
engine'. The execution engine is that part of the infrastructure
software that is responsible for the correct sequencing and
synchronization of tasks.
Toulouse has already a version working for many years, and they are
now making a new version for use in Orocos (and other things). In
Leuven, we are interesting in having a version that can be used in
real-time and can have a file interface for (compliant) motion tasks.
State machines and events are important parts of the execution engine.
Therefore, it might be interesting to take a look at the event and
state machine documentation that the OMG (Object Management Group) has
available on these subjects. Their specs are quite extensive
(including activity and action object state machines), but still not
too big. The document is on
<http://www.omg.org/cgi-bin/doc?formal/01-09-73>
A little summary of events and state machines:
- events are `fired', and handled by a `listener', which possibly also
has a `completor' that can issue callbacks (among other things).
- state machines can be of two types:
- activity machines (Moore machines): when in a state, the process
performs a certain function. This function need not have zero
execution time, as is often silently assumed in mathematical and
electronics state machines.
- action machines (Mealy machine): the process takes a certain (very
short) action when it is transiting from one state to the other.
- it can be worthwhile to have `entry' and `exit' functions in each
state. These are like the constructors and destructors of the object
that handles a state transition event.
As always, it is my suggestion to use the OMG terminology and specs
whenever they are appropriate (and they most probably are in this
case), because this saves us a lot in writing documentation and
definitely helps us not to make some design mistakes or forgetting
things.
So, expect to hear more from this field in the following months; I'm
working on a design document about how to implement these things in a
code efficient manner. Peter has already an event library in the
current core.
Herman
--
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc> +32 16 322480