[ros-users] actionlib design questions

Wed Sep 15 08:04:40 UTC 2010

Herman,

I've got a few questions for you. See inline.

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? 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.

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. 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. 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?

- 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/current/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 willowgarage.com>
> >
> >
>
> --
> --
>   K.U.Leuven, Mechanical Eng., Mechatronics & Robotics Research Group
>     <http://people.mech.kuleuven.be/~bruyninc> Tel: +32 16 328056
>   EURON Coordinator (European Robotics Research Network) <
> http://www.euron.org>
>   Open Realtime Control Services <http://www.orocos.org>
>   Associate Editor JOSER <http://www.joser.org>, IJRR <http://www.ijrr.org
> >
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100915/cb50254c/attachment-0003.html>