[ros-users] actionlib design questions
Herman Bruyninckx
Herman.Bruyninckx at mech.kuleuven.be
Wed Sep 15 09:41:07 UTC 2010
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>
> >
> >
>
More information about the ros-users
mailing list