Hi Vijay and all.
As part of my visit to Intel Research Pittsburgh I have ported the
Fawkes behavior engine
(
http://www.fawkesrobotics.org/publications/2009/rc2009-lua-behavior-engine/)
to ROS using the recently announced roslua. That's why I figured I could
chime in and give some of our findings.
In short, the BE distinguishes three levels of behavior. At the lowest
level 0 real-time or close-to-realtime control loops and motion
planning, at the middle level 1 basic reactive behaviors and more
complex ones combining several of the simpler actions, and finally on
level 2 an agent program makes strategic decisions to solve the overall
task in the given scenario. We focus on the upper two levels, employing
hybrid state machines on both, though we plan to replace level 2 with a
deliberative component (cf.
http://www.fawkesrobotics.org/publications/2010/aaai2010spring-golog-lua/).
We have decided to use actionlib as the interface between the reactive
layer with the lower level system. For this I have re-implemented
actionlib in Lua (pushed the code to
http://github.com/timn/actionlib_lua yesterday). This way I gained some
insight. I will just present my findings. Maybe I'm totally wrong, but
maybe it can also help to improve things a bit.
First, I like the general actionlib design of specifying actions where
they are implemented, at the low-level components. Having the
description files allows to generate most of the code on-the-fly at
run-time.
Herman Bruyninckx already suggested issues with the state machine, and I
agree with many of those. One specific thing I noticed during
implementation is that there is a straight matching from transitions to
states, meaning that the transition to a state only depends on the
communication input, not on the originating state. So effectively I
assumed any transition can happen at any time, especially with the note
that some states might be skipped which really makes it a pain to
implement properly. I have implemented a FSM in our behavior engine
following the client state machine, and it does not look anywhere close
as pretty as the one in the wiki, this is because of the skipping you
need many more transitions. I can provide a graph image if you want.
For our application we see that the distinction between preempted and
recalled doesn't matter. But what is missing is a way to report failure.
Currently, to indicate an error, we abort the action on the server side.
The terminal states that would be most useful to us are: SUCCEEDED,
FAILED, ABORTED/CANCELED. The ABORTED and CANCELED state can be
distinguished if desired, for the case that the server aborted by it's
own decision, or on a user request. Most of the time, we will consider
either of those as failure.
We have seen performance issues with actionlib. This is due to the many
topics per action. Starting an application which uses about two dozen
actions, a few services and topics, requires quite some time to start up
to register and connect all the topics, even if this happens on the same
host or on hosts with a wired connection. In actionlib_lua I implemented
that you can have reduced action clients. Most actions we have do not
provide feedback, and many cannot be canceled. Therefore, there are
flags not to open these two topics, which improves the situation a bit.
Additionally, status information is sent out at a lower frequency, or if
an event changes the status.
Also, the current implementation easily leads to the habit of writing
action servers similar to service providers, e.g. on receiving a goal a
blocking function goal is initiated lasting for the duration of the
action. Feedback is often not provided and canceling ignored. The first
step of reducing this would be to have better examples that more follow
the pattern of initiating an action with a goal, and have a monitoring
loop which oversees the (preferably step-wise) execution and can
interrupt if canceled.
We would like to see the state machine revised, especially based on
Herman Bruyninckx suggestions. Then, an explicit way of handling errors
would be useful, i.e. having an on failure state It might be worthwhile
to consider making feedback and cancellation optional also on the C++
and Python libraries. It seems that the ROS communication patterns do
not allow for a further reduction of the opened topics, but improvements
here could help if the number of actions keeps growing.
But, despite these issues, we feel that actionlib is a great starting
point. I'll visit Willow Garage in two weeks, so maybe we can have a
chat then.
Tim
--
AllemaniACs RoboCup Team KBSG - Knowledge-Based Systems Group
========================================================================
http://robocup.rwth-aachen.de RWTH Aachen University
http://www.kbsg.rwth-aachen.de Ahornstrasse 55
http://www.fawkesrobotics.org D-52056 Aachen
Currently at:
Carnegie Mellon University, Intel Research Pittsburgh, Personal Robotics
(text/plain)