ROS1与ROS2无缝通信：用ros1_bridge打通Docker容器与主机

把 ROS2 容器和 ROS1 主机打通这件事，听起来像是要动大手术，实际上一套ros1_bridge就能搞定。你这边主机上跑着成熟的 ROS1 导航栈，那边容器里压着最新的 ROS2 算法包，两边各自为政确实浪费，让它们真正"对话"起来，才是项目推进的正路。这套方案我已经在几个实际项目里反复用过，今天直接把从零到通的完整路径写给你。

很多人一听到"ROS1 与 ROS2 通信"就觉得麻烦，其实只要理解了桥接原理，5 分钟跑通双向通信完全做得到。本文不会只丢给你几条命令，而是把为什么这么做、底层发生了什么、出了问题怎么查，一次讲透。

1. 先想清楚再动手：这套通信方案的顶层设计

1.1 为什么偏偏是 ros1_bridge

ROS1 和 ROS2 在底层架构上完全是两套东西。ROS1 靠 master 节点做中央调度，节点之间通过 XML-RPC 和 TCPROS 直接通信；ROS2 则去中心化，基于 DDS 进行服务发现和数据分发。这两者的消息定义、类型系统、通信模式都不兼容，想靠改配置就让它们互通，门都没有。

ros1_bridge是 ROS2 官方提供的核心工具包。它做的事情听上去很简单：在 ROS1 和 ROS2 两个运行时之间做消息翻译。但它的价值在于，翻译过程是动态而且类型感知的。它会同时监听两边的拓扑变化，一旦发现两端出现话题名相同、消息类型可映射的话题，就自动建立一个桥接通道，把一个生态里发布的消息原封不动地翻译成另一个生态里的数据。你在 ROS1 里发的sensor_msgs/LaserScan，容器里的 ROS2 节点可以像接收本地话题一样直接订阅。

之所以选 ros1_bridge 而不是自研网关，核心原因有两个。第一，它对消息类型的覆盖极其全面，ROS1 和 ROS2 所有标准消息接口都能自动映射，非标准接口通过编译期注册也能支持，省去了一行一行手写转换代码的痛苦。第二，它的 QoS 策略设计得足够聪明，能在不同通信模型之间做合理兜底，这一点在后面的实操里会体现出来。

1.2 网络拓扑怎么选：host 模式是最省事的选择

这套方案里的一个关键决策点，是 ROS2 容器到底用哪种网络模式。我见过不少人在这一步栽跟头，所以我直接把结论放在前面：优先使用 host 网络模式。

原因要从通信机制说起。ROS1 的节点发现依赖ROS_MASTER_URI，也就是告诉节点"去哪个 IP 找 master"，只要容器能访问到主机 IP 和 11311 端口，ROS1 通信就能打通。但 ROS2 的 DDS 发现机制完全不同，它默认依赖 UDP 多播，节点会在同一网段内通过多播广播自己的存在。如果容器用的是默认的 bridge 网络，容器和主机不在同一个多播域里，ROS2 节点就找不到对方，桥接自然无从谈起。

host 模式下，容器直接复用宿主机的网络栈，天然就在同一个多播域里，省去所有网络隔离带来的麻烦。实测下来，无论是在容器里跑ros2 topic list发现主机上的 ROS2 话题，还是反过来让主机看到容器里的话题，都像在同一台机器上操作一样顺畅。

如果你因为某些原因必须用 bridge 网络，也不是完全没戏，但需要额外处理 ROS1 的 IP 宣告和 ROS2 的多播跨域问题，复杂度会明显上升。对于绝大多数应用场景，host 模式就是最省心的解。

1.3 ros1_bridge 的桥接原理，几句话讲透

理解 ros1_bridge 的桥接原理，对排查问题非常有帮助。它本质上是一个运行在 ROS2 生态里的节点，内部同时维护着两套通信栈。一边以 ROS1 节点的身份连接到 ROS1 master，另一边以 ROS2 节点的身份加入 DDS 域。当它发现两端有匹配的话题时，就启动一个双向转发器。

这个"匹配"有两个条件：话题名完全一致，消息类型在 bridge 的映射表里能找到对应。比如 ROS1 的std_msgs/String对应 ROS2 的std_msgs/msg/String，ROS1 的sensor_msgs/LaserScan对应 ROS2 的sensor_msgs/msg/LaserScan。匹配成功后，ros1_bridge 就会显示类似created 2to1 bridge for topic /cmd_vel的日志，告诉你哪条话题的桥接通道已经建立。

了解这个原理后，你会明白几个常见问题的根源。比如容器启动后ros2 topic list能看到主机上的话题，但 ros1_bridge 没有打印创建桥接的日志，那大概率就是话题名或消息类型不匹配。再比如桥接建立后数据流不同步，那就要去检查 QoS 策略了。

2. 环境准备：镜像、依赖、版本匹配

2.1 版本组合与镜像选择

版本匹配是这套方案的生命线。ROS1 侧目前主流的发行版是 Noetic（Ubuntu 20.04），ROS2 侧我推荐使用 Humble（Ubuntu 22.04），这个组合是官方明确支持且社区验证最充分的。如果你主机上还是 Melodic 或者更早的 ROS1，我劝你先把升级列入计划，老版本和新工具链的兼容性会让你多踩很多坑。

容器镜像方面，我推荐直接使用 OSRF 官方发布的 ROS2 镜像，在 Docker Hub 上搜索osrf/ros就能找到。选择镜像时注意两点：第一，humble-desktop版本比humble-base多了很多调试工具和可视化库，虽然体积大一点，但省去了后续装工具的麻烦；第二，镜像标签要选带版本后缀的，不要选 latest，否则哪天镜像更新了你的构建脚本可能莫名其妙失效。

如果你已经在容器里装好了 ROS2 环境但没装 ros1_bridge，可以通过apt install ros-humble-ros1-bridge补齐。有的基础镜像没有预装这个包，这是正常的，按需补装即可。

2.2 容器里的 ros1_bridge 怎么装

装 ros1_bridge 看似只是apt install一条命令的事，但这里有个很多人忽视的前提：它必须同时感知 ROS1 和 ROS2 两套依赖环境。ros1_bridge 的源码包里有一层编译期的消息类型映射，虽然官方发布的二进制包已经预编译好了标准消息类型，但如果你的 ROS1 环境里自定义了一套消息接口，就需要从源码编译 ros1_bridge。

对于大多数场景，直接用二进制包就够了。安装方法分两种。如果容器镜像里已经有 ROS2 环境，进入容器后执行：

sudo apt update sudo apt install ros-humble-ros1-bridge

如果你的 ROS2 环境是通过社区一键安装脚本部署的，脚本一般已经帮你配置好了软件源，直接执行上面的安装命令即可。安装完成后，记得在~/.bashrc或启动脚本里 source 对应的环境文件：

source /opt/ros/humble/setup.bash

这里有个细节容易踩坑：ros1_bridge 运行时需要同时加载 ROS1 和 ROS2 的环境变量，但两者不能镜像切换式地 source。推荐的姿势是，在启动命令里显式指定两边的 setup 路径，或者使用一个包装脚本统一处理。后面我会给出具体的启动命令，确保两套环境都正确加载。

3. 五分钟实操：从零到双向通信跑通

3.1 第一步：ROS1 主机端启动 roscore

无论你是真的要跑机器人，还是只做连通性测试，ROS1 侧有一个标准起点，那就是先确保 roscore 在运行。在 ROS1 主机上执行：

roscore

如果你的 ROS1 环境没有配置过ROS_MASTER_URI，默认就是http://localhost:11311。这里额外提醒一句，如果 ROS1 主机上有多个网卡，或者你计划让容器通过局域网 IP 访问，最好在启动 roscore 前显式设置一下ROS_IP，避免 ROS1 广播出去的是错误的网卡 IP。比如主机的局域网 IP 是192.168.1.100，就执行：

export ROS_IP=192.168.1.100

这个环境变量会被 ROS1 节点用来告知其他节点"该连我的哪个 IP"，设置不对的话会出现节点能注册但数据传不过来的诡异问题。

roscore 启动后，可以先跑一个简单的 ROS1 话题发布或订阅，确认 ROS1 侧通信正常。比如在另一个终端里rostopic echo /chatter挂在那里，后面验证桥接时会用到。

3.2 第二步：启动 ROS2 容器并配置环境

启动容器的命令是整套方案里最关键的一步。我直接用 host 网络模式启动，命令如下：

docker run -it --rm \ --network host \ --name ros2_bridge_test \ osrf/ros:humble-desktop \ bash

参数说明一下：--network host让容器共享主机网络栈，-it保持交互式终端，--rm在退出时自动清理容器。启动后你会进入容器的 bash，一个干净的 ROS2 环境就在眼前了。

这里有一个很多新手会疑惑的点：容器启动后默认的 ROS2 domain ID 是 0，如果你主机上还有其他 ROS2 节点跑在别的 domain，或者容器里有多个 ROS2 环境，需要统一设置ROS_DOMAIN_ID确保在同一个域里。在容器里执行：

export ROS_DOMAIN_ID=0

这个值要和主机上 ROS2 节点的保持一致，0 是默认值，一般不用改。但如果你企业网络里有多个团队在跑 ROS2，为了避免跨团队干扰，强烈建议用不同的 domain ID 隔离。

进入容器后，先验证一下 ROS2 环境是否正常：

ros2 topic list

如果输出为空是正常的，因为 ROS1 侧的话题还没被桥接过来。但至少能看到系统默认的一些话题，比如/parameter_events和/rosout，说明 DDS 已经在正常工作了。

3.3 第三步：拉起 ros1_bridge

这一步是整个方案的临门一脚。在容器里执行 ros1_bridge，但有个细节必须处理：ros1_bridge 同时需要 ROS1 和 ROS2 的环境变量，不能只 source 一个。正确的启动方式是：

source /opt/ros/noetic/setup.bash source /opt/ros/humble/setup.bash ros2 run ros1_bridge dynamic_bridge

如果容器里没有安装 Noetic 的 ROS1 环境（这种情况很常见，因为容器里只装了 ROS2），那么 ros1_bridge 默认怎么找到 ROS1 master？答案是它靠的是ROS_MASTER_URI环境变量。所以即使容器里没有完整的 ROS1 软件栈，只要设置了正确的ROS_MASTER_URI指向主机上的 roscore 即可：

export ROS_MASTER_URI=http://192.168.1.100:11311

如果容器里没有源码安装 ROS1 环境，那么上述 source 就不要写，只用 ROS2 的 source。运行ros2 run ros1_bridge dynamic_bridge，它会自动通过ROS_MASTER_URI连接主机的 ROS1 master。

启动后，你会看到 ros1_bridge 打印大量日志，包括Found 1 deactivated bridge for topic /chatter之类的信息。别慌，这说明 bridge 已经发现两端有匹配的话题，但还没真正激活通道。一旦 ROS1 侧的话题开始有发布流量，它就会自动激活对应桥接通道，日志里变成created 2to1 bridge for topic /chatter。

这里有一个经验之谈：dynamic_bridge 是"懒汉"，只有当它看到某条话题上真的有数据在流动时，才会创建桥接通道。所以如果启动后发现没有任何桥接日志，不用焦虑，先去 ROS1 侧发布数据，桥接通道自然会出现。

3.4 第四步：双向收发验证

到了验证环节，我习惯分两个方向分别测，避免混淆。在 ROS1 主机上开一个终端，发布一条文本消息：

rostopic pub -r 1 /chatter std_msgs/String "data: 'hello from ros1'"

然后回到容器里，订阅这条话题：

ros2 topic echo /chatter std_msgs/String

如果一切正常，你应该能在容器里看到 ROS1 发来的消息内容。这说明 ROS1 到 ROS2 的方向已经打通。同样的，在容器里发布消息回传给 ROS1 主机，流程完全对称：

ros2 topic pub -r 1 /chatter_ros2 std_msgs/String "data: 'hello from ros2'"

然后在 ROS1 主机上rostopic echo /chatter_ros2，确认收到。

测试时建议同时开着ros2 topic list观察，你会发现原本在 ROS1 侧注册的话题，桥接建立后也会出现在 ROS2 的话题列表里，前缀保持不变。这一点很重要，因为 ROS2 侧的话题命名规则和 ROS1 是兼容的，你不需要在代码里做任何前缀替换。

常见的验证场景还包括自定义消息类型。如果你的 ROS1 系统里跑着/odom（nav_msgs/Odometry）或者/scan（sensor_msgs/LaserScan），这些话题只要一流动，bridge 就会自动建桥。我在实际项目里就是这么干的：ROS1 主机负责传感器数据采集和底盘控制，ROS2 容器里跑导航规划算法，数据流全靠 ros1_bridge 中转，一点额外开发量都没有。

3.5 进阶：静态桥接与一键启动脚本

dynamic_bridge 的自动发现能力对调试来说很方便，但生产环境里我强烈建议换成静态桥接。静态桥接需要你显式声明要桥接哪些话题、用哪种消息类型，虽然配置起来多了一步，但好处是对系统运行行为有精确控制，不会被意料之外的话题拖累性能。

静态桥接的配置文件是一个 YAML 文件，里面指定了桥接方向、话题名和消息类型。例如：

topics: - name: /chatter type: std_msgs/String queue_size: 10 qos: reliability: reliable durability: volatile

保存为bridge_config.yaml后，用参数加载它启动静态桥：

ros2 run ros1_bridge static_bridge --ros-args --params-file /path/to/bridge_config.yaml

静态桥接比动态桥接多了一种模式：纯 1to2 或纯 2to1。动态桥接默认是双向的，静态桥接可以通过配置实现单向桥接，这在一些安全敏感的工业场景中非常有用，比如只允许传感器数据从 ROS1 流入 ROS2，不允许 ROS2 直接向 ROS1 底盘控制下发指令，防止误操作影响真实设备。

对于一套需要反复启停的开发环境，我习惯把启动逻辑写成一个脚本。一个最小化的启动脚本可能是这样的：

#!/bin/bash # 设置 ROS1 master 地址 export ROS_MASTER_URI=http://192.168.1.100:11311 # 启动 roscore（如果还没启动） docker exec -d ros2_bridge_test bash -c "source /opt/ros/humble/setup.bash && ros2 run ros1_bridge dynamic_bridge"

这不是一个标准的启动脚本，但足够看出思路。合格的启动脚本应该把主机 IP、domain ID、镜像标签、需要挂载的数据目录都写成变量，方便不同项目之间复用。我会把这一步留给你根据实际项目微调。

4. 常见问题与排查技巧实录

4.1 高频问题速查表

这套方案在实际运行中遇到的问题，重复率极高。我把常见的几类问题整理成了一张速查表，方便你遇到问题时快速定位。

4.2 几个我踩过的坑

第一个坑是关于 ROS1 的 IP 宣告。我的主机上同时插着以太网和 Wi-Fi，系统的默认路由走的是 Wi-Fi，但 ROS1 master 只监听以太网 IP。结果容器通过ROS_MASTER_URI连接 master 没问题，但 ROS1 节点之间握手时广播了错误的ROS_IP，导致数据一直不通。绕了很大一圈才定位到问题，后来只要涉及多网卡环境，我都会在启动脚本里固定设置ROS_IP。

第二个坑是关于 QoS 策略。我刚开始用动态桥接跑激光雷达数据时，时不时丢帧，看起来像网络问题。后来用ros2 topic info --verbose /scan查看了实际协商后的 QoS，发现问题出在桥接默认用了 reliable 策略，但发送端是 best_effort，两端无法协商统一。解决办法是改用静态桥接，在配置里显式指定reliability: best_effort。这个坑几乎每个从 ROS1 切到 ROS2 的人都会遇到，因为 ROS1 没有 QoS 这个概念，默认都是尽力而为，而 ROS2 的默认策略却是 reliable。

第三个坑比较隐蔽。我在容器里用tail -f /dev/null保持容器前台运行，结果容器启动脚本里 source 的顺序写反了，先 source 了 ROS2 环境，后 source 了 ROS1 环境。表面上看没有报错，但 ros1_bridge 启动后找不到 ROS1 master，日志里全是超时重试。后来才想到，ROS_DISTRO、CMAKE_PREFIX_PATH这些环境变量会被第二次 source 覆盖，顺序反了会导致 bridge 的 CMake 配置缓存指错路径。我把 source 顺序调整之后就恢复正常了。

第四个坑是关于时间不同步。如果你在桥接话题里传递header.stamp，两边的时钟偏差会影响下游算法。容器默认用的是宿主机内核时间，一般偏差不大，但如果你在用虚拟化环境或容器运行时启用了额外的时钟隔离，就需要确认容器和主机的时钟是否一致。我在一个虚拟化平台上跑的时候，容器时钟比主机慢了将近 1 秒，导致导航算法里的时间戳比对全部错乱。解决办法是在容器启动时使用--device=/dev/ptp0挂载硬件时钟设备，或者部署 chrony 做时间同步。实测中，clock_gettime的误差和设备挂载情况关系很大，不能想当然认为容器和宿主机必然同步。

4.3 关于鱼香ROS和社区方案的一点建议

在网上搜索这套方案时，你大概率会看到鱼香ROS一键安装之类的社区脚本。客观地说，这类脚本对新手确实友好，省去了配置软件源和依赖的繁琐过程。但我的建议是，学习阶段可以用脚本快速搭起环境，生产部署时还是要把每一步依赖的来历搞清楚。等你理解了环境变量、软件源、依赖关系这些底层逻辑后，再决定是否在自动化的基础上做精简。毕竟 ros1_bridge 的坑大多数不在安装环节，而在网络和 QoS 配置上。

5. 写在最后的经验分享

这套方案在多个项目里跑下来，我最大的体会是：ros1_bridge 本身非常稳定，真正的问题几乎都出在容器网络和环境变量这两件事上。只要你记住 host 网络模式、ROS_MASTER_URI指向正确、ROS_DOMAIN_ID保持一致这三个核心原则，绝大多数坑都能避开。

另外，如果你正在规划全新项目，我建议认真考虑是否真的要跨生态通信。ros1_bridge 的价值主要体现在过渡期——比如老的 ROS1 硬件驱动无法迁移到 ROS2，或者团队里还有大量 ROS1 代码需要复用。如果你的项目从零开始，最好直接上 ROS2 Humble 及之后的版本，不要为了兼容而增加一层桥接的复杂度。但如果确实需要同时保留两套生态，ros1_bridge 就是你的最佳伙伴。它在 ROS1 和 ROS2 之间做的那些翻译工作，比你自己写任何一套网关协议都靠谱得多。