The ROS Translator is a docker compose project that setups up a ros1_bridge 🔗 build and runtime context in Ubuntu 22.04. This project has boilerplate code to automatically format and translate ROS1 Noetic and ROS2 Iron packages and message to and from ROS2.
In principle ROS1 messages do not need to be modified to be translated to and from ROS2.
Why would you want to use this project?
- Publish an arbitrary/custom topic in ROS 1 NOETIC and subscribe to it in ROS 2 IRON
- Publish an arbitrary/custom topic in ROS 2 IRON and subscribe to it in ROS 1 NOETIC
- Docker build context that compiles ROS 1 NOETIC and ros1_bridge 🔗
- Docker compose runtime context to run the ros1_bridge 🔗
- This context has ROS 1 NOETIC and ROS 2 installed side-by-side on a Ubutnu 22.04 host
- Message package auto-generation. ROS 1 message packages can be auto-converted to a ROS 2 message package.
This project contains a package generation tool that automatically takes ROS1 packages and translates them to a valid ROS2 package.
ROS1 message packages are submodules placed in the ros1_packages directory. All packages in this directory are converted to an identical ROS2 package. Only packages containing selected messages defined in the bridged_msgs.txt are converted to a ROS2 package. All generated ROS2 packages use bridge_workspace/src/template as the template package. Once generated the output is placed in bridge_workspace/src/bridge_workspace/bridge_packages.
Only messages explicitly listed in bridged_msgs.txt will be
available in the ros1_bridge
.
All message packages in ros1_packages will be build with ROS1.
Messages can have different package names, message names, and data types. Message mappings are defined in the mapping_rules.yaml.
Review https://github.com/ros2/ros1_bridge/blob/master/doc/index.rst for more information on this configuration.
The following is a minimum example mapping_rules.yaml
file:
- enable_foreign_mappings: true
ros1_package_name: 'adore_if_ros_msg'
ros1_message_name: 'Action'
ros2_package_name: 'adore_if_ros_msg'
ros2_message_name: 'Action'
This assumes the package names, message names and type defs are identical.
Basic setup allows bridging/translation of ROS std_msgs data types. a std_msgs data type can be published on a ROS1 node and received by a ROS2 node or published by a ROS2 node and received by a ROS1 node.
- clone the project:
git clone --recurse-submodules git@gitlab.dlr.de:csa/ros2/ros_translator.git
⚠️ Warning:Failing to update submodules will result in build failures!
- Build the ROS translator:
cd ros_translator
make build
- Run the ros translator
make start
- View the published topics:
make rostopic_list
This will run rostopic list
in the context of ROS1 and ros2 topic list
in
the context of ROS2.
This project provides ROS2 message package generation capabilities.
- Add the ROS1 submodule to ros1_packages with:
cd ros1_packages
git submodule add ...
-
Define the messages that should be bridged by adding the file names to bridged_msgs.txt.
-
Update the
ros1_bridge
mapping rules in the file mapping_rules.yaml. The mapping rules need to be updated if one of the following questions is true:
- Are the package names of the ROS1 and ROS2 packages different?
- Are message names different?
- Are parameter names different?
- Add the ROS1 submodule to ros1_packages with:
cd ros1_packages
git submodule add ...
- Add the ROS2 submodule to ros2_packages with:
cd ros2_packages
git submodule add ...
- Update the
ros1_bridge
mapping rules in the file mapping_rules.yaml. The mapping rules need to be updated if one of the following questions is true:
- Are the package names of the ROS1 and ROS2 packages different?
- Are message names different?
- Are parameter names different?