ROS1 has borne the burden of supporting applications for robots for well over a decade. May 2025 will be the EoL for ROS Noetic — the latest and the last ROS1 distro. Doing what we do at Black Coffee Robotics, I often interact with robotics businesses and developers and every project kick-off brings up the question — ROS1 or ROS2?
Motivation
There’s still no single correct answer to that question, but that’s not why we’re here, sorry! We are in fact here to talk about how you can use ROS1 AND ROS2 together. One of our recent works involved developing a multi-robot navigation system for movement in a shared environment. We were required to use our existing ROS2 based Fleet Management System (FMS) to facilitate the collaborative movement of these robots whilst utilizing the ROS1-based navigation system already present on each robot.
One of the key requirements of our FMS was to relay messages across these robots to/from a central server. Some of these messages required absolute reliability (such as sending global paths) in Quality of Service (QoS) while some other messages could be afforded to be “lost” (stream of logs, or robot poses). What added a little extra complexity is that the number of robots in the system could be changed on the fly — robots could be sent for battery swapping, repairs, and more robots could be introduced to accommodate the load during workflow, etc.
TLDR; We needed multiple instances of a ROS2<->ROS1 conversion with,
- The ability to strictly control the QoS of each topic
- Introduce new topics to the system dynamically
- Fast compile time to support low-cost edge devices
Our first instinct was to utilize the existing ROS1Bridge for this purpose. Unfortunately, we faced a few issues pertaining to QoS tunability, message latching, dynamic configuration of additional topics as well as compilation times on several edge devices. Despite some concerns regarding the existing bridge for our use-case, we drew a lot of inspiration and came up with a slimmer version of ROS1<->ROS2 message transport — slim_bridge!
slim_bridge
Developed and tested with ROS1-Noetic and ROS2-Foxy, slim_bridge can either be installed by source or using a Dockerfile (It’s pretty neat!). Topics and their QoS settings are fully parameterized using a .yaml file. Additional topics to be bridged can be added at runtime using ROS1/ROS2 topic APIs.
Recently, we ran into another use case for bridging messages across ROS1/2. During the development process, there’s a constant need to run software stack on a robot in a headless mode. Often this setup is run and tested using ssh and over an office/personal WiFi. If there are multiple developers and robots over the same network, the transport of LiDAR/Camera data to rviz on a laptop can be laggy and choke the entire network. We can use slim_bridge to facilitate “best effort” “best effort” transport QoS for sensor data over DDS (which uses UDP) instead of setting up multi-machine ROS1 setup which predominantly uses TCP. In our experience, this has tremendously helped in getting rid of network choke-holds. Use of Docker in this case allows the bridge to seamlessly work the with core navigation stack, and the install dependencies remain unchanged.
It gets better…we’re making our communication bridge open source! It’s right here.
Conclusion
We expect all ROS1 robots to be phased out of development (if not production) in the coming two to three years. However, up until that point, there are several use-cases where ROS1 and ROS2 can co-exist — these are the cases where we have found message bridging to be tremendously helpful. Currently, we only support bridging over ROS1/2 topics, and not services/actions, but these features are lined up for subsequent releases. If you run into a situation where bridging messages across ROS1<->ROS2 solves your problem, give slim_bridge a shot!
Need more help? Get in touch with us!
.jpg)
