The Robotic Behavior Metamodel defines structures for modeling task-plots of a robot (see figure below). Task-plots define sequences of tasks required to achieve certain goals at run-time. Each task itself can contain another task-plot. This introduces hierarchy into the task-plot modeling where high level tasks (such as e.g. making-coffee) are refined into lower level tasks (such as e.g. approach the kitchen, operate the coffee machine and bring the coffee back to the customer). At the lower end of the abstraction hierarchy, tasks eventually operate (i.e. to coordinate and configure) according software components that do the actual “work” of a task. In this sense, tasks are passive, they just delegate the work to components in the system and await the results (i.e. success or failure). The interaction between task-plots and components is over skills. In this sense, a skill abstracts the technical coordination interface of a component and makes it accessible for task-plots. A skill by itself might “inject” additional task-plots. This feature is particularly useful for modeling alternative behaviors in case of contingencies in the overall behavior. For example, a skill commanding a navigation component to approach a room might get the result that the navigation component failed to do so (e.g. due to a blocked hallway). In this situation, the according skill might inject an alternative strategy, namely to first go to another location and to try the current task later (or whatever other strategy might be appropriate here).
A service robot is a physical entity that needs to cope with the physical constraints of the real-world. For instance, actions of the robot, once performed, might be irreversible and always can fail. This also means that at each point in time, the control hierarchy on the robot must be clear. Simply speaking, a robot cannot decide in parallel to go to left and to right at the same time (for most of the robots, this is physically impossible). In consequence, there is typically only one entity on each robot that is responsible for executing the robotic behavior models namely the sequencer (see this page for further details on sequencing).
For the interaction between the behavior model and the software components in a system, the robot behavior uses the “Master-Behavior-Interface”. Each component in the system by default implements the counter part “Slave-Behavior-Interface” (not displayed in the figure). Therefore, the robot-behavior depends on the system-component-architecture for the interaction with the according component-instances.