On Fri, Feb 17, 2012 at 6:11 AM, Herman Bruyninckx wrote: > Yes: . Thanks! That is very interesting work, and nice to see that its also based on state-charts, like we are using. btw, at this point a comment to the poster who mentioned Petri-Nets: I should have made that clear, but intended to subsume them under "state machines" as variants of the general approach "discrete state with discrete transitions". This is not meant to be simplifying, but simply to distinguish them from other approaches which are based on continuous states or planning. In that regard, petri-nets have much more similarity to state-charts and even simple FSMs, than to the others. > 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. I guess we are saying the same thing here, but I'm not quite sure. When I speak about scalability, I mean the scalability of the development process. With state-machine-based approaches, once the number of states and transitions grows, my personal experience has been that they become unwieldy and hard to make correct. Parallel state-machines can help a bit (by decomposing the problem space), but also have their own problems (such as event-evaluation ordering), which need to be accounted for. Therefore, my interpretation of the behavior languages of the 80s is that they have been an attempt to model the desired coordination structure at a higher level. They were, quite often, still executed on a state-machine, whose structure is the result of a transformation. >> So, Herman, what do you think needs to be added, functionality wise? > Nothing! There are lots of things that have to be removed. Well, I didn't meant to SMACH as such, but more in the vein of: Which other tools and methods do we need in addition to what SMACH/rFSM/Bonsai/... provide. I know that you'd rather do away with some of the features full-blown state-charts provide, and that is certainly important for the design, but I'm more interested in what kind of functionality /for the user/ of these tools do we need, to achieve the developer scalability mentioned above. > 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. Totally agreed here. However, as mentioned in my earlier mail, I think that ROS's actionlib, and similar approaches, already go a long way towards making the components easier to integrate. I know that you criticized actionlib's state-machine, and I certainly agree with some of those points, but I mention it more in the spirit of having a common state-machine for communicating action progress. >From what I read about rFSM, it does not seem to integrate with actionlib, or other, similar approaches. Is that by design or by accident? > It's not about whether you use state machines or not, but about _how_ you > use them. And you need _very_ little infrastructure, really. Totally agreed again. I guess what I'm asking for is some methodical support for the design of state-machines. 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