Gazebo Sim 与 ROS2 架构异同 + Gazebo‑Bridge 深度解析

重点区分：

• 旧版：Gazebo Classic + gazebo_ros_pkgs
• 新版：Gazebo Sim (Ignition) + ros_gz（ros_gz_bridge）

核心事实：Gazebo 本身是一套完整独立分布式仿真系统，不是 ROS2 的一个组件。两者通信协议、消息格式完全不一样，必须靠 Bridge 做翻译转发。

一、内部架构分别是什么

1）ROS2 内部架构

• 底层通信：DDS
• 单元：Node（节点，独立进程）
• 通信范式：发布‑订阅、服务、Action
• 消息定义：.msg/.srv IDL，DDS 序列化
• 话题发现：DDS 自动发现，局域网多机可通信
• 定位：机器人中间件，负责机器人业务数据流，不做物理仿真

2）Gazebo Sim（新版，原 Ignition）内部架构

Gazebo Sim 自己拥有一套完整的分布式通信栈：gz‑transport

• 底层通信：ZeroMQ + Protobuf
• 单元：Gazebo 系统组件 / Plugin 插件，可以多进程分布式仿真
• 通信范式：同样是发布‑订阅、服务，概念上和 ROS2 很像
• 消息定义：Protobuf（.proto），和 ROS2 的 msg 完全不互通
• 话题发现：gz‑transport 自有发现机制
• 定位：物理仿真引擎，做 3D 世界、动力学、传感器仿真

⚠️关键点： Gazebo 的话题 ≠ ROS2 的话题。 即使名字都叫 /scan，一个是 protobuf，一个是 DDS IDL，原生不能互相识别，必须桥梁。

二、Gazebo Sim 与 ROS2 架构异同对比表

表格

对比项	ROS2	Gazebo Sim(gz‑transport)
底层传输	DDS	ZeroMQ(gz‑transport)
消息描述语言	.msg/.srv IDL	.proto Protobuf
进程单元	ROS2 Node（独立进程）	Gazebo Plugin /gz 组件，可以内嵌或独立进程
通信模型	发布订阅 / Service / Action	发布订阅 / Service（没有 Action）
设备发现	DDS 域内自动发现	gz‑transport 自己的组播发现
跨机器	支持 DDS 多机分布式	支持 gz‑transport 分布式仿真
核心职责	机器人业务中间件，感知规划控制	物理动力学仿真、传感器渲染、3D 世界
时间源	ROS2 时间（系统时间 / 仿真时间）	Gazebo 仿真时钟，物理步进驱动
原生互通	两者协议完全不兼容	两者协议完全不兼容

✅相同点

1. 都采用发布‑订阅松耦合分布式架构；
2. 都有话题、服务的概念，组件之间解耦；
3. 都支持跨进程、跨机器运行；
4. 都支持仿真时间模式。

❌本质不同：

两套完全独立的中间件，只是设计思想类似，报文格式、传输协议互不识别，不能直接对话。

三、Bridge 桥梁的作用：翻译官

形象比喻： Gazebo 讲 Protobuf+ZeroMQ 语言；ROS2 讲 IDL+DDS 语言。 ros_gz_bridge 就是翻译，一边听懂 Gazebo，一边听懂 ROS2，双向转译消息内容。

版本区分（非常重要，Humble 环境）

1. Gazebo Classic（老 Gazebo11） 桥接包：gazebo_ros_pkgs 实现方式：Bridge 是 Gazebo 内部的一个 Plugin 插件，运行在 Gazebo 主进程内部。

缺点：插件崩溃会把整个 Gazebo 一起搞崩。

1. Gazebo Sim（新版 Ignition，Humble/Jazzy 推荐） 桥接包：ros_gz，核心组件：ros_gz_bridge 实现方式：Bridge 是一个独立的 ROS2 Node 进程！

• 它既是 gz‑transport 的客户端（订阅 / 发布 Gazebo 话题）
• 同时又是标准 ROS2 节点（订阅 / 发布 ROS2 话题）
• 不在 Gazebo 进程里面，解耦；bridge 挂掉不会导致 Gazebo 崩溃。

四、ros_gz_bridge 工作流程（双向桥接）

方向 1：Gazebo → ROS2（传感器数据方向）

1. Gazebo 仿真运行，激光插件产生 Gazebo 内部 protobuf 激光消息，发布到 gz‑transport 话题，例如：/world/default/model/robot/lidar
2. ros_gz_bridge（独立 ROS2 节点）作为 gz 客户端订阅该 Gazebo 话题
3. bridge 把 Protobuf 消息内容解析，转换成 ROS2 对应的sensor_msgs/msg/LaserScan消息
4. bridge 以 ROS2 节点身份，通过 DDS 发布 ROS2 话题，如/scan
5. ROS2 控制算法、RViz2 就可以订阅/scan

方向 2：ROS2 → Gazebo（控制指令方向）

1. ROS2 控制算法输出速度指令：/cmd_vel（geometry_msgs/msg/Twist）
2. ros_gz_bridge 订阅 ROS2 的/cmd_vel
3. bridge 把 ROS2 Twist 消息翻译成 Gazebo 的 protobuf 运动命令
4. 通过 gz‑transport 发布给 Gazebo 仿真器
5. Gazebo 接收指令，驱动虚拟机器人底盘运动

plaintext

控制算法Node ---DDS---> ros_gz_bridge ---gz‑transport---> Gazebo Sim
Gazebo Sim ---gz‑transport---> ros_gz_bridge ---DDS---> RViz2 / 控制算法Node

ros_gz_bridge 本身不做物理仿真，不做业务逻辑，只做：消息协议转换 + 话题转发。

五、Bridge 配置方式（实操）

可以在 launch 文件配置需要双向映射的话题对。 伪示例：

python

运行

Node(
    package='ros_gz_bridge',
    executable='parameter_bridge',
    parameters=[{
        # 格式：["Gazebo话题@Gazebo消息类型@ROS2话题@ROS2消息类型"]
        'config': [
            '/world/default/model/robot/lidar@gz.msgs.LaserScan@sensor_msgs/msg/LaserScan@/scan',
            '/cmd_vel@geometry_msgs/msg/Twist@gz.msgs.Twist@/model/robot/cmd_vel'
        ]
    }]
)

六、常见踩坑理解

1. ❌误区：Gazebo 是 ROS2 的一个节点 ✅真相：Gazebo 是独立仿真程序；ros_gz_bridge 才是 ROS2 节点。Gazebo 可以完全脱离 ROS2 单独运行。

2. ❌误区：话题名字一样就可以互通 ✅真相：名字相同没用，底层协议不同，必须经过 bridge 映射。

3. bridge 是独立进程的好处： bridge 出错、崩溃，Gazebo 仿真还可以继续跑，便于调试；旧版 Classic 桥接是 Gazebo 插件，插件异常直接让仿真器退出。

4. 仿真时间同步： ros_gz 还会把 Gazebo 的仿真时钟桥接到 ROS2 的/clock话题，ROS2 各个节点使用仿真时间，保证仿真步调一致。

七、整套数字化系统链路回顾（Gazebo Sim + ros_gz_bridge + ROS2 算法 + RViz2）

plaintext

Gazebo Sim(gz‑transport protobuf)
        ↓↑
ros_gz_bridge（独立ROS2 Node，协议翻译）
        ↓↑  DDS/ROS2消息
┌──────────┬──────────┐
控制算法Node   RViz2监控面板