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