Papyrus/customizations/robotics/reverse

ROS 2 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.

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 ROS 2 messages

In order to start creating ROS 2 compatible components with Papyrus for Robotics, it is important to enable referencing standard ROS 2 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 ROS 2 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 ROS 2 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 ROS 2 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 ROS 2 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 ROS 2 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.

The parameter section of the navigation2 AMCL component within Papyrus for Robotics

Reverse nodes from running system

The analysis of a running ROS 2 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.