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/reverse
Contents
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
Context menu for generating code
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 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).
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, the following parameter lists have been obtained.
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.