[ros-users] actionlib design questions

[Herman Bruyninckx]

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.

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>