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
(text/plain)