[ros-users] actionlib design questions

[Herman Bruyninckx]

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
> <Herman.Bruyninckx at mech.kuleuven.be> wrote:
>       On Mon, 13 Sep 2010, Vijay Pradeep wrote:
>
>       > I forked this from the "Manipulator control interface"thread<http://code.ros.org/lurker/message/20100913.115000.9afea6e9.en.html>
>       ...
>       >
>       > 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<http://www.ros.org/wiki/actionlib/DetailedDescription>.
>  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"
>  <http://www.ros.org/wiki/actionlib/DetailedDescription>
> 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:
>  <http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/curre
> 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.
> ><mailto:tfoote at willowgarage.com>vpradeep at willowgarage.com<mailto:vpradeep at w
> illowgarage.com>
> >
> >
>