On Thu, 16 Feb 2012, Ingo Lütkebohle wrote:

> On Thu, Feb 16, 2012 at 9:36 PM, Herman Bruyninckx
> <Herman.Bruyninckx@mech.kuleuven.be> wrote:
>> On Thu, 16 Feb 2012, Edwards, Shaun M. wrote:
>>
>>> Herman,
>>>
>>> I definitely agree.  I had Orocos in mind for the hard realtime aspects.
>>> Could you elaborate more on the "Coordination via FSM" or provide a web
>>> link?
>>
>>
>> This might be a good introduction.
>
> Was there supposed to be a link here?

Yes: <http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html>.

> I'd also be interested in what people expect in coordination
> currently. My personal impression is that frameworks based on state
> machines are a great start in formalizing this aspect, but they have
> scalability limits.

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.

> This is probably also the limit for SMACH, as it
> currently stands. In other words, I think the problem for SMACH is not
> so much that it is not developed further, but that it is unclear in
> what direction to develop it.
>
> So, Herman, what do you think needs to be added, functionality wise?

Nothing! There are lots of things that have to be removed. 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.

> My knowledge in this area is a bit limited, but my own work is at
> least related to coordination and here is a (very short) summary of
> the various approaches, as I see them:
>
> * Early on, state-machines of various forms were the dominant
> approach for realizing coordination, but, as mentioned above, that
> alone is not sufficient.
>
> * Roundabout the 80s, various forms of "behavior" languages
> (unfortunate term, because they are not really only for behavior-based
> architectures)  arose, which essentially boiled down (in my
> interpretation) to domain-specific-languages for specifying
> state-machines. One could interpret that as an answer to the
> scalability issue, but I wonder if people still think it is a good
> one.
>
> * The planning community also seems to have taken the floor in this
> area, but without producing something which is as straightforward to
> apply as the state-machine approaches. The original aims also seems to
> have been scalability, but I doubt whether they are anywhere close to
> that.
>
> * For my part, obviously, I tend to think that the Task-State pattern
> -- http://bit.ly/yn29yE -- is a step in making the various components
> play better together and make coordination engines easier to
> implement, because it provides a common interface usable for (but not
> solving) coordination of diverse components. ROS's actionlib is also
> an instance of that pattern, and SMACH is based on that, as is the
> SCXML-based coordination engine that I myself have built (part of my
> XTT work). Thus, we are back with state-machines, in combination with
> state-based interaction protocols ;-) That solves some of the
> scalability issues, but certainly not all.

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

> * For the small research systems we build, directly specifying the
> state machines works well, but there are already some recurring
> patterns which would make sense to formalize better.
>
> cheers,

Herman