[ros-users] Current state of SMACH in ROS

[Ingo Lütkebohle]

Hi Markus,

On Fri, Feb 17, 2012 at 4:59 PM, Markus Klotzbuecher
<markus.klotzbuecher at mech.kuleuven.be> wrote:
>> From what I read about rFSM, it does not seem to integrate with
>> actionlib, or other, similar approaches. Is that by design or by
>> accident?
>
> Neither, we _do_ have generic task-level FSM, for instance in
> iTaSC. Integration with actionlib using roslua would be trivial but
> then we don't use ROS much for this purpose...

Thanks for the info about iTaSC. I checked out the user-guide, and
found a "configure, start, runnning, stop" FSM. Is that the one you
refer to?

If it is, that is different from what actionlib and xtt do, because it
does not specify the /communication/ between that FSM and the external
side. The essential aspect of actionlib and xtt, which we have called
the "Task.-State Pattern", is that it provides communication between a
component executing tasks, and one or more components requesting
tasks, in a generic fashion, by publishing state changes.

So, that is different from just describing your internal state using
an FSM. By communicating state transitions in a generic state machine
to the outside world, you provide an interface, a communication
protocol, if you will. There is typically a mapping from the
applications specific, fine-grained states (e.g. the hierarchically
nested parts inside your "running" state) to that generic state
machine.

Furthermore, the communication protocol has more refinements than just
"configure, start, running, stop". It typically includes transitions
for canceling tasks, for updating the configuration and for providing
more fine-grained feedback on execution. You don't have to have all of
those, but for coordination, you need at least some of them.

So, in the context of coordination, we have suggested that such a
common communication protocol simplifies the interaction between parts
of a component-based system, because you can re-use the protocol. Some
people wonder how useful that is, because the goal specifications are
naturally specific to the task, but we found that it reduces
complexity, because it allows to factor out the communication from the
execution.

cheers,

-- 
Ingo Lütkebohle
Bielefeld University
http://www.techfak.uni-bielefeld.de/~iluetkeb/

PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B