Hi Herman,

I forked this from the "Manipulator control interface" thread...

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