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:
>> 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
> This might be a good introduction.
Was there supposed to be a link here?
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. 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?
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
* 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
* 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.
* 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.