[ros-users] actionlib design questions

Fri Sep 17 14:29:17 UTC 2010

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