[ros-users] Current state of SMACH in ROS

[Dominick Vanthienen]

On 02/17/2012 06:11 AM, Herman Bruyninckx wrote:
> On Thu, 16 Feb 2012, Ingo Lütkebohle wrote:
>
>> On Thu, Feb 16, 2012 at 9:36 PM, Herman Bruyninckx
>> <Herman.Bruyninckx at 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>.
or more easily: orocos.org/rfsm
We're organizing a workshop and hands-on tutorial on rFSM (and iTaSC, which makes extensive use of it) on the European Robotics Forum, beginning of March.
More info can be found on:
http://www.orocos.org/wiki/orocos/european-robotics-forum-2012-workshops
http://www.europeanrobotics12.eu/program.aspx
>
>> 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
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users