Hi all,

I think Ingo's TSP is definitelly a step in the right direction. In particular the separation of concerns is one important aspect here. I think we are asking ourselves the same questions. Please also refer to our IROS 2011 paper (chapter 5 on pages 3-4 and in particular figure 5):
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6094732&tag=1

Here you can see how we manage task execution variants with "event driven task execution". In our system the sequencer (e.g. SmartTCL, StateCharts, ...) has the control over the whole system. The sequencer is responsible to generate a sequence of actions to be executed depending on the current situation and context. Therefore the sequencer orchestrates components by (i) sending commads (like "move robot to <location>"), (ii) sending parameters (like "use long-term map of <location>"), (iii) configuring the data flow between components using our dynamic-wiring (to select alternative components), (iv) controlling resource consumption of components using their state automatons (each component has at least a generic "lifecycle-state-automaton" similar to those of RT-Component in RT-Midlleware). Feedback from the components is signaled with events (like "goal reached" from path planner). Thus the sequencer bridges between continuous processing (e.g. motion control, path planning) and event-driven task execution (discrete states).

With that we can coordinate our tasks on a high level, by orchestrating the components without any need to control the whole data-flow in the system. We control the system by setting it into a certain mode (like "interact with a person", "navigate into room", etc). Thus we have task blocks, which are completelly independent of the low level coordination (and are thus fully reusable). The high level tasks map/expand to several low level tasks which encapsulate details of certain robot platforms for example. For more deatails on our state-automaton and dynamic-wiring, please refer to our book-chapter http://www.iconceptpress.com/01/site/publication.downloadPaper.php?paperID=101215045543 (sections 3.5 and 3.6 on pages 15-18).

The important point here is, that we are not restricted to SmartSoft at all. We think these are generic concepts, valuable to be discussed in a broader community. We are interested in both, getting feedback to further refine our ideas and to contribute to the community with our experience.

Cheers,
Alex and Andreas

---
M.Sc. Alex Lotz,
University of Applied Sciences Ulm
http://www.hs-ulm.de/lotz
http://www.zafh-servicerobotik.de/
http://www.youtube.com/user/roboticsathsulm
http://smart-robotics.sourceforge.net/