A description of this architectural pattern can be found here. The architecture is a generic architecture for robotics behavior. In terms of the abstraction levels, this pattern addresses task and skill levels; in terms of concerns, it addresses coordination and configuration.

See also:

• Task-Level Composition for Robotic Behavior

Service robots act in unstructured and open-ended environments that require flexibility and adaptability in execution for the robotic behavior. The basic robot functionality is realized by software components. Software components are typically general software building blocks that are independent of a specific application or scenario. By contrast, the robot’s behavior is highly application-specific and depends on the desired tasks that the robot is supposed to perform and the expected environments where the robot will operate in.

• A static sequence of actions is too inflexible for coping with the dynamics of the real world where each single action can fail or can produce unexpected results
  • Robust behaviors require several alternative strategies for performing a task whose combinatorial combination easily explodes if statically designed in advance
• Robot behaviors need to be expressed on different levels of abstraction (i.e. high-level tasks such as e.g. “make coffee” are refined to more specific sub-tasks such as e.g. “approach kitchen”, “operate the coffee machine”, etc.)
• Components are active system parts that continuously exchange data while robot behaviors are event-driven, passive parts that react to events for switching into adequate successive behavior steps (depending on the so far successfully executed actions or failures in execution)
  • A robot behavior bridges between continuous execution in components and event-driven coordination on task plot (level)

Robotic Behavior spans across several levels:

• Robotic behavior is about continuous vs. discrete (see here)
• task-plot description (i.e. hierarchical task-tree)
• using external solvers as experts on demand (i.e. symbolic planer), see deliberative layer here

This pattern is supported by the SmartSoft World via SmartTCL and Dynamic State Charts

…

This document contains material from:

• Lotz2018 Alex Lotz, "Managing Non-Functional Communication Aspects in the Entire Life-Cycle of a Component-Based Robotic Software System", Dissertation, Technische Universität München, München 2018.
• Lutz2017 Matthias Lutz, “Model-Driven Behavior Development for Service Robotic Systems: Bridging the Gap between Software- and Behavior-Models,” 2017. (unpublished work)
• Stampfer2018 Dennis Stampfer, "Contributions to System Composition using a System Design Process driven by Service Definitions for Service Robotics". Dissertation, Technische Universität München, München, Germany, 2018.