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