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.
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.
Robotic Behavior spans across several levels:
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: