Skip to main content
Jump to: navigation, search

Difference between revisions of "Papyrus/customizations/robotics/ros2"

(Created page with "=== ROS2 === ==== ROS2 code generation ==== Papyrus for robotics supports the generation of (C++) code for ROS2. The code generation can be triggered via the "Robotics" conte...")
 
(ROS2)
Line 1: Line 1:
=== ROS2 ===
+
= ROS2 =
==== ROS2 code generation ====
+
 
 +
== Mapping RobMoSys concepts to ROS2 ==
 +
 
 +
=== Communication patterns ===
 +
 
 +
One of the primary issues in mapping RobMoSys concepts to ROS2 is how to map RobMoSys interaction patterns to ROS2 . In the sequel, we outline this for each [[https://robmosys.eu/wiki/_media/modeling:metamodels:patternsemmantics.png communication pattern]] in RobMoSys.
 +
 
 +
==== QUERY pattern ====
 +
 
 +
The QUERY pattern is a classical client/server pattern with one server and n clients. The clients execute a request and expect a response. There are two ways, how a client can handle responses: either with a blocking wait or by receiving a callback with the response (this option primarily affects the activity definition within a component). Both options are supported by ROS2 services. On the server side, a service request is executed within a handler. In case of ROS2, requests are always executed by a ROS2 multi-threaded executor that calls the request handler. 
 +
 
 +
==== SEND pattern ====
 +
 
 +
The SEND pattern in RobMoSys is an asynchronous service request without expecting a response. While it seems conceptually close to service requests, it cannot be mapped to ROS2 services that always require a response (while either request or response may be empty, a server always has to send a response, even if empty).
 +
 
 +
==== PUSH pattern ====
 +
 
 +
The PUSH pattern in RobMoSys is an asynchronous message publication with one publisher and n subscribers. This is directly mapped to ROS2 publish/subscribe with messages. A publisher can directly push messages without queuing to subscribed consumers.
 +
 
 +
==== EVENT pattern ====
 +
 
 +
The EVENT patterns enables asynchronous, filtered event handling. It is currently not supported by the ROS2 mapping.
 +
 +
== ROS2 code generation ==
  
 
Papyrus for robotics supports the generation of (C++) code for ROS2. The code generation can be triggered via the "Robotics" context menu when a component definition or a system (component assembly) is selected.
 
Papyrus for robotics supports the generation of (C++) code for ROS2. The code generation can be triggered via the "Robotics" context menu when a component definition or a system (component assembly) is selected.
  
If a component is selected, a ROS2 package is generated for this component. Currently, each RobMoSys component is mapped to a dedicated ROS2 package containing the code for a node. The generated package contains generated build files (package.xml and CMakeLists.txt), as well as a src-gen folder with the C++ code that instantiates a ROS2 node when executed. On the RobMoSys level, the behavior of a component is described by activities which in turn are broken down into functions. The code of these functions can be embedded into the model and will be copied into the generated code.
+
Let's look at an example, the dummy_joint_states component that is part of the standard ROS2 demos. The following figure shows the RobMoSys view of this component. As the source code creates a publisher with the topic "joint_states" and the message type "JointState", the RobMoSYs model of this components contains a provided PUSH port with the respective name and type.
 +
 
 +
<center>
 +
[[Image:Papyrus-customizations-robotics-dummy_joint_states.compdef.png|950px]]<br/>
 +
dummy_joint_states component, modeled with Papyrus for Robotics
 +
</center>
 +
 
 +
The original source code performs an initialization of a message and then enters a loop. In this loop, it modifies an entry of the message and performs a wait. The mapping to RobMoSys implies splitting this code into two parts, the initialization of the message and the periodic publication of the modified message. The result is an Activity with two functions that take over the respective part. The period length is modeled via a periodic timer.
 +
 
 +
Compared to the monolithic source code that contained the creation of a publisher port, the initialization of a message and then a periodic loop with a hard-coded period, the corresponding model separates these aspects into a modeled port and two reusable (composable) functions.
 +
 
 +
If a component is selected, a ROS2 package can be generated for this component, as shown in the following dialog.
 +
 
 +
<center>
 +
[[Image:Papyrus-customizations-robotics-menu-gencode.png]]<br/>
 +
Context menu for generating code
 +
</center>
 +
 
 +
Currently, each RobMoSys component is mapped to a dedicated ROS2 package containing the code for a node. The generated package contains generated build files (package.xml and CMakeLists.txt), as well as a src-gen folder with the C++ code that instantiates a ROS2 node when executed. On the RobMoSys level, the behavior of a component is described by activities which in turn are broken down into functions. The code of these functions can be embedded into the model and will be copied into the generated code.
  
 
If a system is selected, code is generated for all components within the system. In addition, a python launch script that brings-up the robotic system is generated. It references a yaml file that contains the required port remappings and references a yaml file taking into account parameter values that override the default ones for the component.
 
If a system is selected, code is generated for all components within the system. In addition, a python launch script that brings-up the robotic system is generated. It references a yaml file that contains the required port remappings and references a yaml file taking into account parameter values that override the default ones for the component.
  
==== ROS2 reverse ====
+
== ROS2 reverse ==
  
 
In order to start creating ROS2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS2 messages. These have been made available in a model library in form of RobMoSys compliant communication objects and service definitions. This library has been obtained by a reverse functionality within Papyrus for robotics that scans the available list of ros messages and services. If the message is not already existing, it will be created.
 
In order to start creating ROS2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS2 messages. These have been made available in a model library in form of RobMoSys compliant communication objects and service definitions. This library has been obtained by a reverse functionality within Papyrus for robotics that scans the available list of ros messages and services. If the message is not already existing, it will be created.
  
 
It is also possible to create a set of component definitions from the currently running ROS nodes. This reverse mechanism is currently limited to the structural part of a component, i.e. its ports along with the provided or required service definitions.
 
It is also possible to create a set of component definitions from the currently running ROS nodes. This reverse mechanism is currently limited to the structural part of a component, i.e. its ports along with the provided or required service definitions.
 +
 +
The following screenshots shows the context menus for starting reverse engineering.
 +
 +
<center>
 +
[[Image:Papyrus-customizations-robotics-menu-reverse.png]]<br/>
 +
Context menu for generating code
 +
</center>

Revision as of 05:58, 4 December 2019

ROS2

Mapping RobMoSys concepts to ROS2

Communication patterns

One of the primary issues in mapping RobMoSys concepts to ROS2 is how to map RobMoSys interaction patterns to ROS2 . In the sequel, we outline this for each [communication pattern] in RobMoSys.

QUERY pattern

The QUERY pattern is a classical client/server pattern with one server and n clients. The clients execute a request and expect a response. There are two ways, how a client can handle responses: either with a blocking wait or by receiving a callback with the response (this option primarily affects the activity definition within a component). Both options are supported by ROS2 services. On the server side, a service request is executed within a handler. In case of ROS2, requests are always executed by a ROS2 multi-threaded executor that calls the request handler.

SEND pattern

The SEND pattern in RobMoSys is an asynchronous service request without expecting a response. While it seems conceptually close to service requests, it cannot be mapped to ROS2 services that always require a response (while either request or response may be empty, a server always has to send a response, even if empty).

PUSH pattern

The PUSH pattern in RobMoSys is an asynchronous message publication with one publisher and n subscribers. This is directly mapped to ROS2 publish/subscribe with messages. A publisher can directly push messages without queuing to subscribed consumers.

EVENT pattern

The EVENT patterns enables asynchronous, filtered event handling. It is currently not supported by the ROS2 mapping.

ROS2 code generation

Papyrus for robotics supports the generation of (C++) code for ROS2. The code generation can be triggered via the "Robotics" context menu when a component definition or a system (component assembly) is selected.

Let's look at an example, the dummy_joint_states component that is part of the standard ROS2 demos. The following figure shows the RobMoSys view of this component. As the source code creates a publisher with the topic "joint_states" and the message type "JointState", the RobMoSYs model of this components contains a provided PUSH port with the respective name and type.

Papyrus-customizations-robotics-dummy joint states.compdef.png
dummy_joint_states component, modeled with Papyrus for Robotics

The original source code performs an initialization of a message and then enters a loop. In this loop, it modifies an entry of the message and performs a wait. The mapping to RobMoSys implies splitting this code into two parts, the initialization of the message and the periodic publication of the modified message. The result is an Activity with two functions that take over the respective part. The period length is modeled via a periodic timer.

Compared to the monolithic source code that contained the creation of a publisher port, the initialization of a message and then a periodic loop with a hard-coded period, the corresponding model separates these aspects into a modeled port and two reusable (composable) functions.

If a component is selected, a ROS2 package can be generated for this component, as shown in the following dialog.

Papyrus-customizations-robotics-menu-gencode.png
Context menu for generating code

Currently, each RobMoSys component is mapped to a dedicated ROS2 package containing the code for a node. The generated package contains generated build files (package.xml and CMakeLists.txt), as well as a src-gen folder with the C++ code that instantiates a ROS2 node when executed. On the RobMoSys level, the behavior of a component is described by activities which in turn are broken down into functions. The code of these functions can be embedded into the model and will be copied into the generated code.

If a system is selected, code is generated for all components within the system. In addition, a python launch script that brings-up the robotic system is generated. It references a yaml file that contains the required port remappings and references a yaml file taking into account parameter values that override the default ones for the component.

ROS2 reverse

In order to start creating ROS2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS2 messages. These have been made available in a model library in form of RobMoSys compliant communication objects and service definitions. This library has been obtained by a reverse functionality within Papyrus for robotics that scans the available list of ros messages and services. If the message is not already existing, it will be created.

It is also possible to create a set of component definitions from the currently running ROS nodes. This reverse mechanism is currently limited to the structural part of a component, i.e. its ports along with the provided or required service definitions.

The following screenshots shows the context menus for starting reverse engineering.

Papyrus-customizations-robotics-menu-reverse.png
Context menu for generating code

Back to the top