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

Tasks describe via which steps (what: the ordering of steps) and in which manner (how: the kind of execution) to accomplish a particular job. This is done in an abstract manner by just refering to skills (using a domain-specific skill vocabulary). In this way, a task plot can be used with any robot that provides all the required skills. This allows the behavior developer to engineer task plots as a solution for a particular job to be done by a robot independently of the very concrete robot finally used in the deployment.

A skill provides access to functionalities realized by components. It is the bridge between generic descriptions of capabilities (independent of a particular implementation) and behavior interfaces (configuration: resources, parameters, wiring; coordination: modes, lifecycle, events) of a (set of) component(s) to achieve that capability (specific to the used components). A skill lifts the level of abstraction from a component-specific level to a generic level. Thus, different implementations for the same capabilities become replaceable as they are accessed in a uniform way.

Tasks and skills are domain-specific as they refer to domain-specific vocabularies. Nonetheless, a software component can be used in skill sets of different domains. Of course, one can also define a domain that holds generic tasks and skills that can then be used from within different domains.

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.