Tutorial request: How to set up and use ros1_bridge in RoboStack environment

[wuxiaoqiang12]

First of all, thank you so much for your amazing work on RoboStack. It's incredibly useful and has greatly simplified the installation of ROS and integration with AI-related tools.

I'm working with a setup where my robot runs ROS1 Noetic nodes, while my host machine uses ROS2 Humble nodes. To connect these systems, I need to set up the ros1_bridge on my host machine.

I'm specifically working with Ubuntu 22.04 and have both ROS1 Noetic and ROS2 Humble installed through RoboStack. However, I'm not sure about the proper steps to install and configure the ros1_bridge in this environment.

Could you please provide a tutorial or detailed instructions on:

How to install ros1_bridge in a RoboStack environment with both ROS1 and ROS2 Any specific configuration needed for Ubuntu 22.04 Basic usage examples to verify the bridge is working correctly

I would greatly appreciate your guidance on this. Thank you in advance for your time and support!

[Tobias-Fischer]

Have you tried installing noetic and humble in the same environment, and then building the bridge from source? That should work, but untested as far as I know.

[wuxiaoqiang12]

First, thank you for your great work on this project and for your respons.

I'm trying to set up ros1_bridge to integrate a ROS 2 system with an existing ROS 1 system, and I've run into some issues. I'd like to detail my setup and the methods I've tried so far.

Background: I have a robotic dog that runs a ROS 1 Noetic master and publishes several ROS 1 topics. I've connected an Orange Pi (running Ubuntu 22.04 on aarch64) to the robot's network. On this Orange Pi, I need to run ROS 2 Humble applications to control a robotic arm that I've mounted on the dog. The control software for the arm is already in ROS 2, with no ROS 1 version available. Therefore, ros1_bridge seems like the ideal solution.

My ROS_MASTER_URI on the Orange Pi is correctly set to the robot dog's IP address, and the dog's roscore is running as the master.

Here are the two main approaches I've attempted using Robostack:

---

Attempt 1: Separate Conda Environments for ROS 1 and ROS 2

My first thought was to keep ROS Noetic and ROS Humble in separate Robostack environments.

Method 1.1: Activate ROS 1 env, then source ROS 2 env

1. Activate the ROS 1 environment: conda activate ros1_env
2. In the same terminal, source the ROS 2 environment's setup file: source /path/to/miniforge3/envs/ros2_env/setup.bash
3. Attempt to build ros1_bridge in its workspace: colcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure

This failed during compilation, which was not surprising. I realized this was the incorrect approach, as ros1_bridge is a ROS 2 package and its build environment should be sourced from the primary ROS 2 Conda environment.

Method 1.2: Activate ROS 2 env, then source ROS 1 env (Corrected approach)

1. Activate the ROS 2 environment: conda activate ros2_env
2. In the same terminal, source the ROS 1 environment's setup file: source /path/to/miniforge3/envs/ros1_env/setup.bash
3. Build ros1_bridge using colcon build --symlink-install --packages-select ros1_bridge --cmake-force-configure. This step completed successfully.
4. Source the new setup file: source install/setup.bash
5. Run the bridge: ros2 run ros1_bridge dynamic_bridge

This is where I hit a runtime error. The bridge fails to launch with the following message:

/root/ros1_bridge_ws/install/ros1_bridge/lib/ros1_bridge/dynamic_bridge: symbol lookup error: /usr/local/miniforge3/envs/ros2_env/lib/libspdlog.so.1.15: undefined symbol: _ZN3fmt3v116detail10vformat_toERNS1_6bufferIcEENS0_17basic_string_viewIcEENS0_17basic_format_argsINS0_7contextEEENS1_10locale_refE
[ros2run]: Process exited with failure 127

This seems to be a library linking or version mismatch issue, possibly related to how the two environments interact.

---

Attempt 2: A Single Conda Environment for Both ROS 1 and ROS 2

Following some advice, I tried to install both ROS distributions into a single Conda environment.

Method 2.1: Install desktop versions of Noetic and Humble

I attempted to create a single environment with the full desktop installs:

mamba create -n ros_bridge_full_env
conda activate ros_bridge_full_env
conda config --env --add channels conda-forge
conda config --env --remove channels defaults
conda config --env --add channels robostack-noetic
conda config --env --add channels robostack-humble
mamba install ros-noetic-desktop ros-humble-desktop

This failed due to unsolvable package conflicts. mamba reported numerous incompatibilities, particularly with dependencies like libprotobuf, gtest, and poco. Here's a snippet of the error:

error    libmamba Could not solve for environment specs
    The following packages are incompatible
    ├─ ros-humble-desktop =* * is installable with the potential options
    │  ├─ ros-humble-desktop 0.10.0 would require
    │  │  ├─ ros-humble-rqt-common-plugins =* * with the potential options
    │  │  │  ├─ ros-humble-rqt-common-plugins 1.2.0 would require
    │  │  │  │  └─ ros-humble-rqt-image-view =* * with the potential options
    │  │  │  │     ├─ ros-humble-rqt-image-view 1.2.0 would require
    │  │  │  │     │  └─ ros-humble-cv-bridge =* * with the potential options
    │  │  │  │     │     ├─ ros-humble-cv-bridge 3.2.1 would require
    │  │  │  │     │     │  └─ py-opencv >=4.10.0,<5.0a0 * with the potential options
    │  │  │  │     │     │     ├─ py-opencv [4.10.0|4.11.0] would require
    │  │  │  │     │     │     │  └─ libprotobuf >=5.28.3,<5.28.4.0a0 *, which can be installed;
    │  │  │  │     │     │     ├─ py-opencv 4.10.0 would require
    │  │  │  │     │     │     │  └─ libprotobuf >=5.28.2,<5.28.3.0a0 *, which can be installed;
    │  │  │  │     │     │     ├─ py-opencv 4.10.0 would require
    │  │  │  │     │     │     │  └─ libprotobuf >=5.27.5,<5.27.6.0a0 *, which can be installed;
    │  │  │  │     │     │     ├─ py-opencv 4.10.0 would require
    │  │  │  │     │     │     │  └─ libprotobuf >=4.25.3,<4.25.4.0a0 *, which can be installed;
    │  │  │  │     │     │     ├─ py-opencv [4.11.0|4.12.0] would require
    │  │  │  │     │     │     │  └─ libprotobuf >=5.29.3,<5.29.4.0a0 *, which can be installed;
    │  │  │  │     │     │     ├─ py-opencv 4.12.0 would require
    │  │  │  │     │     │     │  └─ libprotobuf >=6.31.1,<6.31.2.0a0 *, which can be installed;
    │  │  │  │     │     │     └─ py-opencv 4.10.0 conflicts with any installable versions previously reported;
    │  │  │  │     │     ├─ ros-humble-cv-bridge 3.2.1 would require
    │  │  │  │     │     │  └─ ros2-distro-mutex =0.7 humble_*, which can be installed;
    │  │  │  │     │     └─ ros-humble-cv-bridge [3.0.3|3.2.1] would require
    │  │  │  │     │        └─ ros2-distro-mutex =0.1 *, which requires
    │  │  │  │     │           └─ poco =1.11 *, which can be installed;
    │  │  │  │     ├─ ros-humble-rqt-image-view 1.2.0 would require
    │  │  │  │     │  └─ ros2-distro-mutex =0.7 humble_*, which can be installed;
    │  │  │  │     └─ ros-humble-rqt-image-view 1.2.0 would require
    │  │  │  │        └─ ros2-distro-mutex =0.1 *, which can be installed (as previously explained);
    │  │  │  ├─ ros-humble-rqt-common-plugins 1.2.0 would require
    │  │  │  │  └─ ros2-distro-mutex =0.7 humble_*, which can be installed;
    │  │  │  └─ ros-humble-rqt-common-plugins 1.2.0 would require
    │  │  │     └─ ros2-distro-mutex =0.1 *, which can be installed (as previously explained);
    │  │  └─ ros2-distro-mutex =0.6 humble_*, which requires
    │  │     └─ libprotobuf =5.28.2 *, which conflicts with any installable versions previously reported;
    │  ├─ ros-humble-desktop 0.10.0 would require
    │  │  ├─ ros-humble-ros-base =* * with the potential options
    │  │  │  ├─ ros-humble-ros-base 0.10.0 would require
    │  │  │  │  └─ ros-humble-ros-core =* * with the potential options
    │  │  │  │     ├─ ros-humble-ros-core 0.10.0 would require
    │  │  │  │     │  └─ ros2-distro-mutex =0.6 humble_*, which cannot be installed (as previously explained);
    │  │  │  │     ├─ ros-humble-ros-core 0.10.0 would require
    │  │  │  │     │  └─ ros-humble-ament-cmake-gtest =* * with the potential options
    │  │  │  │     │     ├─ ros-humble-ament-cmake-gtest 1.3.11 would require
    │  │  │  │     │     │  └─ ros2-distro-mutex =0.6 humble_*, which cannot be installed (as previously explained);
    │  │  │  │     │     ├─ ros-humble-ament-cmake-gtest 1.3.12 would require
    │  │  │  │     │     │  └─ gtest >=1.17.0,<1.17.1.0a0 *, which can be installed;
    │  │  │  │     │     └─ ros-humble-ament-cmake-gtest 1.3.2 would require
    │  │  │  │     │        └─ ros2-distro-mutex =0.1 *, which can be installed (as previously explained);
    │  │  │  │     └─ ros-humble-ros-core 0.10.0 would require
    │  │  │  │        └─ ros2-distro-mutex =0.1 *, which can be installed (as previously explained);
    │  │  │  ├─ ros-humble-ros-base 0.10.0 would require
    │  │  │  │  └─ ros2-distro-mutex =0.6 humble_*, which cannot be installed (as previously explained);
    │  │  │  └─ ros-humble-ros-base 0.10.0 would require
    │  │  │     └─ ros2-distro-mutex =0.1 *, which can be installed (as previously explained);
    │  │  └─ ros2-distro-mutex =0.7 humble_*, which can be installed;
    │  └─ ros-humble-desktop 0.10.0 would require
    │     └─ ros2-distro-mutex =0.1 *, which can be installed (as previously explained);
    └─ ros-noetic-desktop =* * is not installable because it requires
       └─ ros-noetic-robot =* *, which requires
          ├─ ros-noetic-diagnostics =* *, which requires
          │  └─ ros-noetic-diagnostic-analysis =* *, which requires
          │     └─ ros-noetic-rosbag =* *, which requires
          │        └─ ros-noetic-rosbag-storage =* *, which requires
          │           └─ ros-noetic-roslz4 =* *, which requires
          │              └─ ros-distro-mutex =0.6 noetic_*, which requires
          │                 └─ libprotobuf =5.28.3 *, which conflicts with any installable versions previously reported;
          ├─ ros-noetic-filters =* *, which requires
          │  └─ ros-noetic-roslib =* *, which requires
          │     └─ ros-noetic-catkin =* *, which requires
          │        └─ gtest >=1.15.2,<1.15.3.0a0 *, which conflicts with any installable versions previously reported;
          └─ ros-noetic-ros-base =* *, which requires
             └─ ros-noetic-ros-core =* *, which requires
                └─ ros-noetic-class-loader =* *, which requires
                   └─ poco >=1.14.0,<1.14.1.0a0 *, which conflicts with any installable versions previously reported.
critical libmamba Could not solve for environment specs

**Method 2.2: Install `ros-base` versions of Noetic and Humble**

Since the desktop versions conflicted, I tried installing only the base versions:

```shell
# In a new environment
mamba install ros-noetic-ros-base ros-humble-ros-base colcon-common-extensions catkin_tools

This installation was successful! With both distributions in the same environment, I proceeded to build ros1_bridge. However, the build failed with a CMake error:

CMake Error at cmake/find_ros1_package.cmake:29 (message):
  find_ros1_package() failed to find 'action_msgs' using pkg_check_modules()
Call Stack (most recent call first):
  CMakeLists.txt:60 (find_ros1_package)

Following some guidance, I manually created .pc files (e.g., action_msgs.pc, builtin_interfaces.pc, tf2_msgs.pc, etc.) in the ${CONDA_PREFIX}/lib/pkgconfig directory. This seemed to resolve the initial package finding issues, allowing CMake to proceed further.

However, I am now stuck at a new, more complex linking error:

The link interface of target "rclcpp::rclcpp" contains:
  rosgraph_msgs::rosgraph_msgs__rosidl_generator_c
but the target was not found.

This is one of many similar errors. It seems like even within the unified environment, there are issues with how ROS 2 targets and libraries are being discovered and linked, especially on the aarch64 architecture.

---

Summary I've tried both separate and unified Conda environments via Robostack. The separate environment approach leads to a runtime symbol lookup error, while the unified environment approach (using ros-base) leads to a build-time linking error (target was not found).

Do you have any recommendations on the best path forward? Is there a known-good configuration for this setup (Robostack, Noetic + Humble, aarch64), or is there something I might be missing in my build or environment configuration?

Thank you again for your time and help.

[Tobias-Fischer]

Can you please try the attached pixi.toml (please rename .txt to .toml). See pixi.sh and https://robostack.github.io/GettingStarted.html#__tabbed_1_2 for more details about pixi.

Then mkdir -p ros2_ws/src; cd ros2_ws/src; git clone https://github.com/ros2/ros1_bridge.git

Then colcon build --symlink-install --cmake-args -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DPython_FIND_VIRTUALENV=ONLY -DPython3_FIND_VIRTUALENV=ONLY -DBUILD_TESTING=OFF

I don't have a Linux box so I can't test, but at least using pixi will make life a bit easier to collaborate.

Instead of creating .pc files manually, you should install the relevant packages via the pixi.toml. Then we need to get colcon to actually find them.

pixi.txt

[Tobias-Fischer]

Just tested it in an aarch64 VM - this is working fine. Just the BUILD_TESTING=ON doesn't work as it finds the same diagnostic_msgs from ROS1 and ROS2, but this is beyond RoboStack question I think.

[Tobias-Fischer]

Or it might be that we actually need to have two separate environments for noetic and humble and overlay them somehow?!? @wolfv / @traversaro might know more.

[traversaro]

Or it might be that we actually need to have two separate environments for noetic and humble and overlay them somehow?!? @wolfv / @traversaro might know more.

I think that any CMake-level package naming conflict would be present in both cases?