[ros-users] Current state of SMACH in ROS

[Markus Klotzbuecher]

Hi Ingo,

On Fri, Feb 17, 2012 at 06:40:24PM +0100, Ingo Lütkebohle wrote:
> 
> 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.

There is explicit communication between the FSM instances, although it
is not clearly shown in the figure. This is partly because the
documentation is still WIP, but also because this communication is not
something that needs to be changed by an iTaSC user.

> 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.

Note that I am not the author of iTaSC-ng, but AFAIK there are indeed
similar states to found.

> 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.

Thanks for your explanation, what you suggest seems a bit like a
component life-cycle FSM on steroids? I agree it is worthwhile to
"standardize" this pattern, although I wonder if it encourages
creating "fatter" componentents opposed to lighter (and hence more
reusable) smaller ones? Have you gained any insights in this respect?

Best regards
Markus