On Wed, 15 Sep 2010, Eric Perko wrote: > I've got a few questions for you. See inline. ("In line" should be the default way of replying in a mailing list, so no need to make that explicit :-) It _would_ make sense to use clear text-only markers to indicate your contributions, e.g., levels of ">"...) > On Wed, Sep 15, 2010 at 2:11 AM, Herman Bruyninckx > wrote: > On Mon, 13 Sep 2010, Vijay Pradeep wrote: > > > I forked this from the "Manipulator control interface"thread > ... > > > > Thank you for your feedback about actionlib, but I was hoping > you could elaborate a bit on your points.  For actionlib, we > definitely have hardcoded two state machines: A server-side FSM > and a client-side FSM.  Are these the "templates" that you refer > to?  Also, could you be more specific as to which states you > think are wrong? > > > > I am assuming you are basing this off of the information on the > detailed actionlib > description. >  Maybe there's an issue with this documentation that is making > actionlib seem unclear or incorrect? > > > > To start with: there is this figure "Server State Transitions" >   > that has five(!) terminal states. That's impossible, because how do > you go > further? Moreover, naming a state after the name of the event by which > you > reached this state (e.g., "Succeeded") is semantically wrong, and > leads to > decoupling problems. An FSM should have one single End state, and its > name > should reflect the _activity_ your system is performing in the state. > > > I'm a bit confused. Firstly, why do we have to go further from a terminal > state? Because your robot will live on, so somewhere it will continue with something else. Practically speaking, that means that another FSM will take over, in one way or another; but having half a dozen of termination states only leads to a combinatorial explosion of how to go on with the next FSM... > Isn't the lack of an outgoing transition for a state part of that > state being a terminal state? > Secondly, what is the problem with having > multiple terminal states? As I recall (and wikipedia backs me > up: http://en.wikipedia.org/wiki/Finite_state_machine#Mathematical_model), a > state machine is basically a set of states, an initial state, a set of > transitions between states and a set of states marked as end states. I've > never really seen a requirement that there must only be one terminal state > for an FSM to be valid. That's right. But there is a practical difference between mathematical models and usable code! Having multiple terminal states leads to exponential "fan out"... In other words, it makes sense to reduce the number of termination states; a lot of sense. In addition, (and that's my other comment in the previous post), the _meaning_ of the state machine shown in the ROS documentation is not far away from one single terminal state; it has just not been explained that way, because of the semantic confusion ("error" rather...) of naming states according to the event that led to them. Again, a state must be called according to what activity the state represents. (This is also not "mathematical necessary", but just good practice :-) > Now, I'll grant you that, perhaps that for an actionlib server itself, the > FSM describing the server should only have one terminal state (namely, > program about to terminate). In that case, I'd expect that the figure > describing "Server State Transitions" is more of a diagram for the FSM that > handles a given goal within that server. In this case, it makes sense to me > to have multiple terminal states. And that sense might be what, exactly? In other words, what would we really gain by having multiple terminal states? > One terminal state has some issues in my > mind. For example, say the FSM has handled a goal and reached the terminal > state. I make a request of the server to query that goal's status. I here see _maybe_ some confusion that comes from the (at least) two different interpretation of the term "state": one is the state in a FSM, the other is the "state of the world" at the end of the activity in the FSM state. The latter can, of course, have "multiple" versions; infinitely many basically. Maybe your "goal status" is what I call the "state of the world"? > If the > server's state for the processing of that goal doesn't have multiple > terminal states (or keeping around the transition that got me to that > terminal state, which seems, to me, equivalent to having a separate terminal > state anyways (Moore vs Mealy Machine)), how can it reply with whether the > goal I queried about succeeded, failed or any other states that indicate > that the server will not be doing any more processing of that goal? The _event_ that brought you in that 'terminal state' already provided that information! If you have to keep it in memory (which is often not a bad thing to do) then you have to store that in the "world model" stat(e)(us), and not waste a FSM state for that purpose. Summarizing: - a FSM is a way to coordinate "activities" of my robot(s), sensor(s), planner(s),... - it does that by lumping together several pieces: - the activities being executed in each state - this includes updating the "world model" information - and the monitoring of constraints whose violation gives rise to events - the events will possibly trigger state transitions in the FSM, _and_ in other components active in the system (e.g., the world model). - FSM are to be combined in (only) two fundamental ways: hierarchy and paralles states. - having only singly entry and exit states keeps the combinatorial explosion of these combinations of FSMs under control. Just to make sure: I do not claim to have said the final word on these issues, but it's been a research topic as well as a component design guideline in our group since a couple of years. I am _always_ open to be proven wrong :-) (After all, that's the only way of _really_ learning something...) I am looking forward to further common progress in these issues, since I think they are the major factor in keeping the runtime complexity of our modern robot systems under control... Because that's what ROS currently does _not_ provide: control over the whole set of dozens and hundreds of nodes... My (personal) interpretation of our experiments with ROS on the PR2 is that it is a "nice exercise" in "emergent behaviour"... But probably only for psychologists, not for me, frankly speaking :-) Herman > > - Eric > > > To go further (on a basically still unresolved issue, also in > Orocos!): our > robots need distributed software components, and we need to > coordinate > them; state machines are potentially ok for that, but one should > not make a > design that wipes the fact under the carpet that the _detection_ > of > transition triggers in itself will be a distributed thing, that > takes time; > the same thing holds for the transitions themselves. Hence, the > current > state machines that I see (including those in Orocos > applications) are not > robust against distribution. (Also not against distribution over > processes > on the same CPU...) > > > I don't have much experience with Orocos, but I was having > trouble trying > > to find more information about FSM support in Orocos.  Is > there an > > overview of this somewhere on the Orocos site? > > The documentation for the recent 2.0 is till to be updated, so you > will > have to do for now with the "ancient" 1.x docs: >   nt/doc-xml/orocos-devel-manual.html#id468964> > > > We're definitely interested in getting a better understanding of > what > > issues people are having with using actionlib and what we can do to > > improve it in the future.  We're considering the current > > implementation/API of actionlib to be relatively stable, but we > > definitely can incorporate any larger design changes into a future > > actionlib redesign. > > Since FSMs for Coordination are a active research issue in our context > too > (not just Orocos code; we have two PhDs working on that at this > moment), I > am looking forward to shared (re)design efforts :-) > > The research issues I mentioned are basically the following: > - what are the _minimal_ FSMs and FSM features that one needs to do > robust, >   platform-independent, reusable, portable coordination? > - how to apply this to the "resource allocation" problem? Going from >   allocation of external resources, to the internal coordination of > the >   arms, head and platform in the PR2. > > A first discussion topic _could_ be: what (specification and > execution) > semantics do we really need, and how can we document them completely? > We > have learned that this is tough, since _all_ FSM implementations have > different semantics... For exmaple, the UML FSM specification has lots > of > "semantic deviation points" as they call them, meaning that each > implementor can do what (s)he likes with it. It also has way too many > "features". > > Herman > > > > Thank you, > > Vijay Pradeep > > > >> This raises an important _design_ discussion: the action interface > is in > >> many ways not a good design for coordination of activities. For > example, > >> the documentation on line gives examples of a "template" for a > state > >> machine that contains lots of "wrong" states (i.e., some states > should be > >> the same, but they have been giving wrong names) and (hence) misses > >> appropriate state transitions. > >> > >> It could be nice to redesign ROS' action interface together with > the FSM > >> support in Orocos.... > >> > >> Herman > > > > -- > > Vijay Pradeep > > Systems Engineer > > Willow Garage, Inc. > >vpradeep@willowgarage.com illowgarage.com> > > > > >