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/