Hi Herman,

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?

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?

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.

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.
 <tfoote@willowgarage.com>vpradeep@willowgarage.com