Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
- 1 Task and skill concepts
- 2 How to define a new skill
- 3 How to create a new task in form of a behavior tree
- 4 Export the behavior tree in XML format
- 5 Realization of skills by components
- 6 See also
Task and skill concepts
The skill abstraction interfaces the task level and the level in which software components are executed (called the service level in the RobMoSys parlance, see Separation of Levels and Concerns in RobMoSys).
Skills make the functionalities realized by components accessible to the task level, without binding the behavior models to concrete components. The system sequencer, which is in charge of executing the task description, demands to the components the execution of their skills by means of a well-defined configuration and coordination interface. This approach conforms to the RobMoSys Architectural Patterns for Task-Plot Coordination and for Component Coordination.
How to define a new skill
Papyrus for Robotics provides a graphical modeling language that enables the definition of skills as specified by the RobMoSys Skill Definition Metamodel.
Once the skill definition artifact is selected from the palette and dropped into a skill definition set element, it can easily be renamed and its attributes can conveniently be specified via the
Skills tab in the property view. Configurable properties of skill attributes include
Attribute Type, which is normally a communication object in a Service Definition Model. Several skill results can be defined, with configurable name, type and description.
The video below (click on the picture to open the animated gif) shows the definition of skill
MoveTo, which takes one input attribute named
target_p of type
Pose (from ROS
How to create a new task in form of a behavior tree
The video below (click the picture to open the animated gif) shows how to use Papyrus for Robotics to compose existing skills and build a simple behavior tree. The tree composes 4 skills in a sequence to fetch a bottle: first
FindObj, that takes
BOTTLE as object identifier and outputs a grasp pose for the bottle; then
MoveTo the computed grasp pose; finally
CloseGripper. If the sequence fails,
Export the behavior tree in XML format
The video below (click the picture to open the animated gif) shows how to do it and the resulting XML code. First, the connector between ports
target_p, respectively of action nodes
MoveTo, is renamed to obtain a meaningful blackboard key in the generated XML. Then the model is exported to an XML file with extension
Realization of skills by components
The realization of a skill is not bound to concrete components, but to a coordination interface that conforms to the RobMoSys Architectural Pattern for Component Coordination. Concrete components realize the coordination interface and hence the skill.
The current implementation supports a subset of coordination mechanisms specified by the architectural pattern, namely Activation (with goal specification), Information Query and Results.
Bind a skill to a coordination interface
The video below (click the picture to open the animated gif) shows how the skill definition
MoveTo is bound to a (simple) coordination service
MoveToCoordServ, which specifies a
geometry_msgs::msg::Pose as goal and gets no information (
std_msgs::msg::Empty) as information queries and results.
Bind the coordination interface to the component internals
The video below (click the picture to open the animated gif) shows how the coordination service
MoveToCoordServ is bound to a component, through the coordination port
NavigateToPose that provides the service. The port is connected to one activity, which wraps the component functions.
To realize the skill, functions can access the component service ports, e.g., laser scan and odometry to produce a velocity command. The approach conforms to the RobMoSys Component Development.
Other components with different provided/required services will realize the same coordination interface in a different way.
Complementary information on this subject is about