On Fri, 17 Feb 2012, Ingo Lütkebohle wrote: > 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. I agree with the splitting up of FSMs to keep explosion under control. But then "the art" I was talking about becomes necessary: one should make FSMs that are _robust_ against event-evaluation ordering! It's the same skill that is needed in object-oriented design, when trying to make the "most cohesive" class libraries: tough, but it discriminates the good programmer from the skilled one :-) > 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. Methods: the BRICS Component Model :-) A JOSER article is under preparation, that should contain elaborate motivation about the method. Tools: none of the ones I would like to use already exists... :-( > 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. The "end user" need not see any tool or design; the "expert developer" should, well, be an expert that understand which tools to use when and why, and not hope that a tool will solve the problems for him/her :-) >> 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. ROS is a lot about "spirit", but not enough about "standards". (The same hold for Orocos, by the way, at least as a framework.) Because it is only "standards" that allow to have something really in "common". > 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? By design. Because rFSM is meant to be as "restricted" as possible, and to only one thing: pure coordination. Don't think that we advocate it as the solution to everything and the kitchen sink :-) >> 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. This is a very good question, that I can, unfortunately, not answer in a satisfying way... To me, it seems that (i) making your state machines is still an art, and (ii) I can not even say what a "good" state machine is... > cheers, > > -- > Ingo Lütkebohle Herman