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...")
Revision as of 23:04, 3 December 2019
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.
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.
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.
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.