add palette-datatypes.png

Signed-off-by: aradermache <ansgar.radermacher@cea.fr>

bt/task-modelling.adoc

+[[task_and_skill_concepts]]
+== 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 https://robmosys.eu/wiki/general_principles:separation_of_levels_and_separation_of_concerns[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 https://robmosys.eu/wiki/general_principles:architectural_patterns:robotic_behavior[Task-Plot Coordination] and for https://robmosys.eu/wiki/general_principles:architectural_patterns:component-coordination[Component Coordination].
+
+[[how_to_define_a_new_skill]]
+== How to define a new skill
+
+Papyrus for Robotics provides a graphical modeling language that enables the definition of skills as specified by the https://robmosys.eu/wiki/modeling:metamodels:skill-definition[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 link:Papyrus/customizations/robotics/servicedef[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).
+
+image:figs/DefinitionOfSkill.gif[Skill definition, 850]
+
+[[how_to_create_a_new_task_in_form_of_a_behavior_tree]]
+== How to create a new task in form of a behavior tree
+
+Papyrus for Robotics supports graphical modeling of [https://en.wikipedia.org/wiki/Behavior_tree_(artificial_intelligence,_robotics_and_control) behavior trees]. The current implementation supports a subset of https://github.com/BehaviorTree/BehaviorTree.CPP[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`.
+
+image:figs/DefinitionOfBT.gif[Definition of BT, 850]
+
+[[export_the_behavior_tree_in_xml_format]]
+== Export the behavior tree in XML format
+
+Behavior tree models designed in Papyrus for Robotics can be exported to the XML format supported by https://github.com/BehaviorTree/BehaviorTree.CPP[BehaviorTree.CPP] which makes them executable in compatible frameworks such as, e.g., https://navigation.ros.org/[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`.
+
+image:figs/ExportBT.gif[Export BT, 850]
+
+[[realization_of_skills_by_components]]
+== 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 https://robmosys.eu/wiki/general_principles:architectural_patterns:component-coordination#solution[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]]
+=== 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.
+
+image:figs/SkillCS.gif[Skill coord service,850]
+
+[[bind_the_coordination_interface_to_the_component_internals]]
+=== 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.
+
+image:figs/ComponentCS.gif[Component coord service,850]
+
+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 https://robmosys.eu/wiki/modeling:views:component_development[RobMoSys Component Development].
+
+Other components with different provided/required services will realize the same coordination interface in a different way.
+
+[[see_also]]
+== See also
+
+Complementary information on this subject is about
+
+* link:Papyrus/customizations/robotics/compdef[Component Definition]
+* link:Papyrus/customizations/robotics/servicedef[Service Definition]
+* link:Papyrus/customizations/robotics/ros2[Code-Generation Process]