[ros-users] Current state of SMACH in ROS

[Ingo Lütkebohle]

On Fri, Feb 17, 2012 at 6:11 AM, Herman Bruyninckx
<Herman.Bruyninckx at mech.kuleuven.be> wrote:
> Yes: <http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html>.

Thanks! That is very interesting work, and nice to see that its also
based on state-charts, like we are using.

btw, at this point a comment to the poster who mentioned Petri-Nets: I
should have made that clear, but intended to subsume them under "state
machines" as variants of the general approach "discrete state with
discrete transitions". This is not meant to be simplifying, but simply
to distinguish them from other approaches which are based on
continuous states or planning. In that regard, petri-nets have much
more similarity to state-charts and even simple FSMs, than to the
others.

> The _design_ must be scalable, not the framework. And that's exactly why
> coordination is an art, and _the_ number one aspect of a software framework
> with industrial strength. The rFSM approach has this scalability at the
> core of its design; in one line: only "pure coordination" is scalable.

I guess we are saying the same thing here, but I'm not quite sure.
When I speak about scalability, I mean the scalability of the
development process. With state-machine-based approaches, once the
number of states and transitions grows, my personal experience has
been that they become unwieldy and hard to make correct. Parallel
state-machines can help a bit (by decomposing the problem space), but
also have their own problems (such as event-evaluation ordering),
which need to be accounted for.

Therefore, my interpretation of the behavior languages of the 80s is
that they have been an attempt to model the desired coordination
structure at a higher level. They were, quite often, still executed on
a state-machine, whose structure is the result of a transformation.

>> So, Herman, what do you think needs to be added, functionality wise?
> Nothing! There are lots of things that have to be removed.

Well, I didn't meant to SMACH as such, but more in the vein of: Which
other tools and methods do we need in addition to what
SMACH/rFSM/Bonsai/... provide.

I know that you'd rather do away with some of the features full-blown
state-charts provide, and that is certainly important for the design,
but I'm more interested in what kind of functionality /for the user/
of these tools do we need, to achieve the developer scalability
mentioned above.

> But again, I
> hope that ROS is not going to suffer from the Not Invented Here syndrom,
> and work towards being integratable with other frameworks.

Totally agreed here.

However, as mentioned in my earlier mail, I think that ROS's
actionlib, and similar approaches, already go a long way towards
making the components easier to integrate. I know that you criticized
actionlib's state-machine, and I certainly agree with some of those
points, but I mention it more in the spirit of having a common
state-machine for communicating action progress.

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

> It's not about whether you use state machines or not, but about _how_ you
> use them. And you need _very_ little infrastructure, really.

Totally agreed again. I guess what I'm asking for is some methodical
support for  the design of state-machines.

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