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? 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 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. * 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, -- Ingo Lütkebohle Bielefeld University http://www.techfak.uni-bielefeld.de/~iluetkeb/ PGP Fingerprint 3187 4DEC 47E6 1B1E 6F4F  57D4 CD90 C164 34AD CE5B