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 >> 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: . 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@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users