Skip to main content

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.

Jump to: navigation, search

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

(Reverse node from a C++ body file)
Line 1: Line 1:
 
== ROS2 reverse ==
 
== ROS2 reverse ==
  
There are three different reverse mechanisms integrated into Papyrus for Robotics, as shown in the following screenshot - additional context menu entries in the package explorer. In the sequel, we will discuss each of these
+
There are three different reverse mechanisms integrated into Papyrus for Robotics, as shown in the following screenshot - additional sub-menu (Papyrus for Robotics) in the project and package explorer. In the sequel, we will discuss each of these.
  
 
<center>
 
<center>
 
[[Image:Papyrus-customizations-robotics-menu-reverse.png]]<br/>
 
[[Image:Papyrus-customizations-robotics-menu-reverse.png]]<br/>
Context menu for generating code
+
Context menu for reversing nodes (in project explorer)
 
</center>
 
</center>
 +
 +
The visibility of the sub-menu entries depends on the selected element, as outlined in the sequel.
  
 
=== Reverse ROS2 messages ===
 
=== Reverse ROS2 messages ===
Line 12: Line 14:
 
In order to start creating ROS2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS2 messages, services or actions. These have been made available in a set of model library in form of RobMoSys compliant communication objects and service definitions. These libraries have been obtained by a reverse functionality within Papyrus for robotics that scans the available list of ROS2 messages and services.
 
In order to start creating ROS2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS2 messages, services or actions. These have been made available in a set of model library in form of RobMoSys compliant communication objects and service definitions. These libraries have been obtained by a reverse functionality within Papyrus for robotics that scans the available list of ROS2 messages and services.
  
The reverse mechanism is based on the ROS2 command line utility, in particular on the output of "ros2 interface list" (and show, respectively). For each of the different ROS2 packages, e.g. "geometry_msgs", a new Eclipse project with the same name is created. This project contains a service-definition model (in the models/services subfolder) with the services and communication objects of that message package. The reverse mechanism uses name based XML ids instead of random ones. This assures that references remain valid when the model is recreated from ROS packages (provided that names do not change).
+
The reverse mechanism will create new models corresponding to the message packages found. Therefore, the context menu entry is only visible, if a folder is selected: the reversed models will be created in this folder.
 +
 
 +
The reverse mechanism is based on the ROS2 command line utility, in particular on the output of "ros2 interface list" (and show, respectively). For each of the different ROS2 packages, e.g. "geometry_msgs", a new service definition model with the same name is created. Message packages which exist already are skipped (existing models must be accessible via a pathmap in order to be detected). The plugin "org.eclipse.papyrus.robotics.ros2.library.base" provides a list of models corresponding to the message packages provided by a basic ROS2 installation without optional packages.
 +
The reversal "sees" packages accessible via the environment variable AMENT_PREFIX_PATH. Make sure that this variable is correctly setup, before starting the reverse mechanism, e.g. by "sourcing" the install/setup.bash file before starting Papyrus4Robotics.
 +
 
 +
The reverse mechanism uses name based XML ids instead of random ones. This assures that references remain valid when the model is recreated from ROS packages (provided that names do not change).
  
 
=== Reverse nodes ===
 
=== Reverse nodes ===

Revision as of 11:00, 1 April 2020

ROS2 reverse

There are three different reverse mechanisms integrated into Papyrus for Robotics, as shown in the following screenshot - additional sub-menu (Papyrus for Robotics) in the project and package explorer. In the sequel, we will discuss each of these.

Papyrus-customizations-robotics-menu-reverse.png
Context menu for reversing nodes (in project explorer)

The visibility of the sub-menu entries depends on the selected element, as outlined in the sequel.

Reverse ROS2 messages

In order to start creating ROS2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS2 messages, services or actions. These have been made available in a set of model library in form of RobMoSys compliant communication objects and service definitions. These libraries have been obtained by a reverse functionality within Papyrus for robotics that scans the available list of ROS2 messages and services.

The reverse mechanism will create new models corresponding to the message packages found. Therefore, the context menu entry is only visible, if a folder is selected: the reversed models will be created in this folder.

The reverse mechanism is based on the ROS2 command line utility, in particular on the output of "ros2 interface list" (and show, respectively). For each of the different ROS2 packages, e.g. "geometry_msgs", a new service definition model with the same name is created. Message packages which exist already are skipped (existing models must be accessible via a pathmap in order to be detected). The plugin "org.eclipse.papyrus.robotics.ros2.library.base" provides a list of models corresponding to the message packages provided by a basic ROS2 installation without optional packages. The reversal "sees" packages accessible via the environment variable AMENT_PREFIX_PATH. Make sure that this variable is correctly setup, before starting the reverse mechanism, e.g. by "sourcing" the install/setup.bash file before starting Papyrus4Robotics.

The reverse mechanism uses name based XML ids instead of random ones. This assures that references remain valid when the model is recreated from ROS packages (provided that names do not change).

Reverse nodes

There are two different (and complementary) ways to obtain RobMoSys component definitions from nodes in existing ROS2 packages - either to obtain information from a running system, or to analyze the source code of a C++ node.

Reverse node from a C++ body file

If the source code of a node is available, and -if it is written in C++- Papyrus for Robotics can analyze the source code. This analysis is based on the abstract syntax tree obtained via the Eclipse C++ development tools (CDT). A prerequisite of this operation is therefore that the source code has been imported into Eclipse as A CDT Makefile project. Even if you do not compile the code from within Eclipse, it is required to setup CDT in a way that it finds basic include files (in /opt/include/<your ROS2 distribution>). Otherwise some of the template definitions are wrongly parsed by CDT and the AST analysis would fail.

The information that is obtained are the provided and required ports and the parameters, along with default value, type and description. In case of the navigation2 component AMCL for instance, more than 50 parameters have been obtained from the file amcl_node.cpp, an excerpt is shown in the following figure.

Papyrus-customizations-robotics-amcl-parameters.png
The parameter section of the navigation2 AMCL component within Papyrus for Robotics

Reverse nodes from running system

The analysis of a running ROS2 system has two objectives: (1) to obtain a RobMoSys component definition for each of the components participating in the system and (2) obtain a system assembly, i.e. a set of component instances along with the connections between ports.

The analysis of the running nodes is also based on the ROS2 command line utility, notably the retrieval of the list of nodes via "ros2 node list" and subsequent information about each node via "ros2 node info". This reverse mechanism is limited to the externally visible part of a component, i.e. its ports along with the provided or required service definitions and the parameters that it supports. Besides of the principal limitations of analyzing a running system, two aspects are not reported by the ros2 command line tool: the package name and the default value of each parameter. A good strategy is therefore to start with the source code analysis (if source code is available) and obtain the system assembly from the running system.

Back to the top