[ros-users] Current state of SMACH in ROS

[Herman Bruyninckx]

On Fri, 17 Feb 2012, Ingo Lütkebohle wrote:

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

I agree with the splitting up of FSMs to keep explosion under control. But
then "the art" I was talking about becomes necessary: one should make FSMs
that are _robust_ against event-evaluation ordering! It's the same skill
that is needed in object-oriented design, when trying to make the "most
cohesive" class libraries: tough, but it discriminates the good programmer
from the skilled one :-)

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

Methods: the BRICS Component Model :-) A JOSER article is under
preparation, that should contain elaborate motivation about the method.
Tools: none of the ones I would like to use already exists... :-(

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

The "end user" need not see any tool or design; the "expert developer"
should, well, be an expert that understand which tools to use when and why,
and not hope that a tool will solve the problems for him/her :-)

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

ROS is a lot about "spirit", but not enough about "standards". (The same
hold for Orocos, by the way, at least as a framework.) Because it is only
"standards" that allow to have something really in "common".

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

By design. Because rFSM is meant to be as "restricted" as possible, and to
only one thing: pure coordination. Don't think that we advocate it as the
solution to everything and the kitchen sink :-)

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

This is a very good question, that I can, unfortunately, not answer in a
satisfying way... To me, it seems that (i) making your state machines is
still an art, and (ii) I can not even say what a "good" state machine is...

> cheers,
>
> -- 
> Ingo Lütkebohle

Herman