A System Handle is a plugin that allows a certain middleware or communication protocol to speak the same language used by the eProsima Integration Service, that is, Extensible and Dynamic Topic Types for DDS (xTypes); specifically, Integration Service bases its intercommunication abilities on eProsima's open source implementation for the xTypes protocol, that is, eProsima xTypes.
This repository contains the source code of Integration Service System Handle for the ROS 2 middleware protocol, widely used in the robotics field.
This System Handle can be used for two main purposes:
-
Connection between a ROS 2 application and an application running over a different middleware implementation. This is the classic use-case approach for Integration Service.
-
Connecting two ROS 2 applications running under different Domain IDs.
This section provides a list of the dependencies needed in order to compile ROS 2 System Handle.
- ROS 2: Foxy/Galactic ROS 2 distribution.
Integration Service is configured by means of a YAML configuration file, which specifies the middlewares, topics and/or services involved in the intercommunication process, as well as their topic/service types and the data exchange flow. This configuration file is loaded during runtime, so there is no need to recompile any package before switching to a whole new intercommunication architecture.
To get a more precise idea on how these YAML files have to be filled and which fields they require in order to succesfully configure and launch an Integration Service project, please refer to the dedicated configuration section of the official documentation.
Regarding the ROS 2 System Handle, there are several specific parameters which can be configured for the ROS 2 middleware. All of these parameters are optional, and fall as suboptions of the main five sections described in the Configuration chapter of the Integration Service repository:
-
systems
: The systemtype
must beros2
. In addition to thetype
andtypes-from
fields, the ROS 2 System Handle accepts the following specific configuration fields:systems: ros2: type: ros2 namespace: "/" node_name: "my_ros2_node" domain: 4
-
namespace
: The namespace of the ROS 2 node created by the ROS 2 System Handle. -
node_name
: The ROS 2 System Handle node name. -
domain
: Provides with an easy way to change the Domain ID of the ROS 2 entities created by the ROS 2 System Handle.
-
There are several Integration Service examples using the ROS 2 System Handle available in the project's main source code repository.
Some of these examples, where the ROS 2 System Handle plays a different role in each of them, are introduced here.
In this example, Integration Service uses both this ROS 2 System Handle and the ROS 1 System Handle to transmit data coming from a ROS 2 publisher into the ROS 1 data space, so that it can be consumed by a ROS 1 subscriber on the same topic, and viceversa.
The configuration file used by Integration Service for this example can be found here.
For a detailed step by step guide on how to build and test this example, please refer to the dedicated section in the official documentation.
In this example, Integration Service uses both this ROS 2 System Handle and the Fast DDS System Handle to transmit data coming from a ROS 2 publisher into the DDS data space, so that it can be consumed by a Fast DDS subscriber on the same topic, and viceversa.
The configuration file used by Integration Service for this example can be found here.
For a detailed step by step guide on how to build and test this example, please refer to the dedicated section in the official documentation.
In this example, Integration Service uses both this ROS 2 System Handle and the WebSocket System Handle to transmit data coming from a ROS 2 publisher to a WebSocket Client, and viceversa.
The configuration file used by Integration Service for this example can be found here.
For a detailed step by step guide on how to build and test this example, please refer to the dedicated section in the official documentation.
In this example, Integration Service uses both this ROS 2 System Handle and the FIWARE System Handle to transmit data coming from a ROS 2 publisher and update them in a FIWARE Context Broker MongoDB database, and viceversa.
The configuration file used by Integration Service for this example can be found here.
For a detailed step by step guide on how to build and test this example, please refer to the dedicated section in the official documentation.
In this example, the ROS 2 System Handle tackles the task of bridging a ROS 2 server with one or more client applications, playing the role of a service server capable of processing incoming requests from several middlewares (DDS, ROS1, WebSocket) and producing an appropriate answer for them.
The configuration file used by Integration Service for this example can be found here.
For a detailed step by step guide on how to build and test this example, please refer to the dedicated section in the official documentation.
In this example, Integration Service uses this ROS 2 System Handle to forward the messages sent from a ROS 2 publisher hosted on a participant with domain ID 5 to a subscriber created under domain ID 10.
The configuration file for this example can be found here.
For a detailed step by step guide on how to build and test this example, please refer to the dedicated section in the official documentation.
Besides the global compilation flags available for the whole Integration Service product suite, there are some specific flags which apply only to the ROS 2 System Handle; they are listed below:
-
BUILD_ROS2_TESTS
: Allows to specifically compile the ROS 2 System Handle unitary and integration tests; this is useful to avoid compiling each System Handle's test suite present in thecolcon
workspace, which is what would happen if using theBUILD_TESTS
flag; and thus, minimizing the building time; to use it, after making sure that the ROS 2 System Handle is present in thecolcon
workspace, the following command must be executed:~/is_ws$ colcon build --cmake-args -DBUILD_ROS2_TESTS=ON
-
IS_ROS2_DISTRO
: This flag is intended to select the ROS 2 distro that should be used to compile the ROS 2 System Handle. If not set, the version will be retrieved from the last ROS distro sourced in the compilation environment; this means that if the last ROS environment sourced corresponds to ROS 1, the compilation process will stop and warn the user about it. -
MIX_ROS_PACKAGES
: It accepts as an argument a list of ROS packages, such asstd_msgs
,geometry_msgs
,sensor_msgs
,nav_msgs
... for which the required transformation library to convert the specific ROS 2 type definitions into xTypes, and the other way around, will be built. This list is shared with the ROS 1 System Handle, meaning that the ROS packages specified in theMIX_ROS_PACKAGES
variable will also be built for ROS 1 if the corresponding System Handle is present within the Integration Service workspace. To avoid possible errors, if a certain package is only present in ROS 2, theMIX_ROS2_PACKAGES
flag must be used instead.These transformation libraries are also known within the Integration Service context as
Middleware Interface Extension
ormix
libraries.By default, only the
std_msgs_mix
library is compiled, unless theBUILD_TESTS
orBUILD_ROS2_TESTS
is used, case in which some additional ROS 2 packagesmix
files required for testing will be built.If the user wants to compile some additional packages to use them with Integration Service, the following command must be launched to compile it, adding as much packages to the list as desired:
~/is_ws$ colcon build --cmake-args -DMIX_ROS_PACKAGES="std_msgs geometry_msgs sensor_msgs nav_msgs"
-
MIX_ROS2_PACKAGES
: It is used just as theMIX_ROS_PACKAGES
flag, but will only affect ROS 2; this means that themix
generation engine will not search within the ROS 1 packages, allowing to compile specific ROS 2 packages independently.For example, if a user wants to compile a certain package
dummy_msgs
independently from ROS 2, but compilingstd_msgs
andgeometry_msgs
for both the ROS 1 and ROS 2 System Handles, the following command should be executed:~/is_ws$ colcon build --cmake-args -DMIX_ROS_PACKAGES="std_msgs geometry_msgs" -DMIX_ROS2_PACKAGES="dummy_msgs"
The official documentation for the ROS 2 System Handle is included within the official Integration Service documentation, hosted by Read the Docs, and comprises the following sections:
This repository is open-sourced under the Apache-2.0 license. See the LICENSE file for more details.
If you need support you can reach us by mail at [email protected]
or by phone at +34 91 804 34 48
.