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