Bridge communication between ROS 1 and ROS 2

This package provides a network bridge which enables the exchange of messages between ROS 1 and ROS 2.

The bridge is currently implemented in C++ as at the time the Python API for ROS 2 had not been developed. Because of this its support is limited to only the message/service types available at compile time of the bridge. The bridge provided with the prebuilt ROS 2 binaries includes support for common ROS interfaces (messages/services), such as the interface packages listed in the ros2/common_interfaces repository and tf2_msgs. See the documentation for more details on how ROS 1 and ROS 2 interfaces are associated with each other. If you would like to use a bridge with other interfaces (including your own custom types), you will have to build the bridge from source (instructions below), after building and sourcing your custom types in separate ROS 1 and ROS 2 workspaces. See the documentation for an example setup.

For efficiency reasons, topics will only be bridged when matching publisher-subscriber pairs are active for a topic on either side of the bridge. As a result using ros2 topic echo <topic-name> doesn’t work but fails with an error message Could not determine the type for the passed topic if no other subscribers are present since the dynamic bridge hasn’t bridged the topic yet. As a workaround the topic type can be specified explicitly ros2 topic echo <topic-name> <topic-type> which triggers the bridging of the topic since the echo command represents the necessary subscriber. On the ROS 1 side rostopic echo doesn’t have an option to specify the topic type explicitly. Therefore it can’t be used with the dynamic bridge if no other subscribers are present. As an alternative you can use the --bridge-all-2to1-topics option to bridge all ROS 2 topics to ROS 1 so that tools such as rostopic echo, rostopic list and rqt will see the topics even if there are no matching ROS 1 subscribers. Run ros2 run ros1_bridge dynamic_bridge -- --help for more options.

Supported ROS and Ubuntu Versions

⚠️ Important Compatibility Notice

• ros1_bridge requires ROS 1, which has reached end-of-life (EOL) as of May 2025 for ROS Noetic.
• Ubuntu 24.04 LTS does not support ROS 1, and therefore is not compatible with ros1_bridge.

To use ros1_bridge, you must use a system where both ROS 1 and ROS 2 are installable and buildable. Mixing ROS distributions across unsupported Ubuntu versions is not recommended and may lead to broken builds or missing dependencies.

Prerequisites

In order to run the bridge you need to either:

• get prebuilt binaries or
• build the bridge as well as the other ROS 2 packages from source.

After that you can run both examples described below.

For all examples you need to source the environment of the install space where the bridge was built or unpacked to. Additionally you will need to either source the ROS 1 environment or at least set the ROS_MASTER_URI and run a roscore.

The following ROS 1 packages are required to build and use the bridge:

• catkin
• roscpp
• roslaunch (for roscore executable)
• rosmsg
• std_msgs
• as well as the Python package rospkg

To run the following examples you will also need these ROS 1 packages:

• rosbash (for rosrun executable)
• roscpp_tutorials
• rospy_tutorials
• rostopic
• rqt_image_view

Prerequisites for the examples in this file

In order to make the examples below portable between versions of ROS, we define two environment variables, ROS1_INSTALL_PATH and ROS2_INSTALL_PATH. These are defined as the paths to the installation location of their respective ROS versions.

If you installed Noetic in the default location, then the definition of ROS1_INSTALL_PATH will be /opt/ros/noetic.

Building the bridge as described below requires you to build all of ROS 2. We assume that you have downloaded it to ~/ros2_rolling, and that is where you plan on building it. In this case, ROS2_INSTALL_PATH will be defined as ~/ros2_rolling/install.

If you’ve chosen to install either or both versions of ROS somewhere else, you will need adjust the definitions below to match your installation paths.

Because these definitions are used continuously throughout this page, it is useful to add the following lines to your shell startup file (~/.bashrc if you are using bash, ~/.zshrc if you are using zsh). Modify these definitions as appropriate for the versions of ROS that you’re using, and for the shell that you’re using.

export ROS1_INSTALL_PATH=/opt/ros/noetic
export ROS2_INSTALL_PATH=~/ros2_rolling/install

Note that no trailing ‘/’ character is used in either definition. If you have problems involving paths, please verify that you have the correct path to the installation location, and that you do not have a trailing ‘/’ in either definition.

Building the bridge from source

Before continuing you should have the prerequisites for building ROS 2 from source installed following these instructions.

In the past, building this package required patches to ROS 1, but in the latest releases that is no longer the case. If you run into trouble first make sure you have at least version 1.11.16 of ros_comm and rosbag.

The bridge uses pkg-config to find ROS 1 packages. ROS 2 packages are found through CMake using find_package(). Therefore the CMAKE_PREFIX_PATH must not contain paths from ROS 1 which would overlay ROS 2 packages.

Here are the steps for Linux and OSX.

You should first build everything but the ROS 1 bridge with normal colcon arguments.

File truncated at 100 lines see the full file

Any contribution that you make to this repository will be under the Apache 2 License, as dictated by that license:

5. Submission of Contributions. Unless You explicitly state otherwise,
   any Contribution intentionally submitted for inclusion in the Work
   by You to the Licensor shall be under the terms and conditions of
   this License, without any additional terms or conditions.
   Notwithstanding the above, nothing herein shall supersede or modify
   the terms of any separate license agreement you may have executed
   with Licensor regarding such Contributions.

Contributors must sign-off each commit by adding a Signed-off-by: ... line to commit messages to certify that they have the right to submit the code they are contributing to the project according to the Developer Certificate of Origin (DCO).