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.
Papyrus/customizations/robotics/bt
Contents
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 Name and 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 geometry_msgs package).
How to create a new task in form of a behavior tree
Papyrus for Robotics supports graphical modeling of behavior trees. The current implementation supports a subset of BehaviorTree.CPP.
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 OpenGripper; next 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, AskFor HELP.
Export the behavior tree in XML format
Behavior tree models designed in Papyrus for Robotics can be exported to the XML format supported by BehaviorTree.CPP which makes them executable in compatible frameworks such as, e.g., Navigation2.
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 obj_p and target_p, respectively of action nodes FindObj and MoveTo, is renamed to obtain a meaningful blackboard key in the generated XML. Then the model is exported to an XML file with extension .behaviortreeschema.
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.
See also
Complementary information on this subject is about