~johan's blog
返回专辑
ROS 2
·Johan·4 分钟阅读

Gazebo Bridge：映射是接口契约，不是「开了就有」

话题名、类型、QoS、时钟与 TF 职责一次对齐；桥配置进版本库，最小回显再叠算法。

#ROS2#仿真#回归
Gazebo Bridge：映射是接口契约，不是「开了就有」

1. 仿真里动、ROS 里静——根因常在桥

底盘在 Gazebo 里转圈，RViz 里 /odom 不动，Nav2 报「无里程计」。查半天算法，最后发现 ros_gz_bridge 把 /model/robot/odometry 映射成了 /odom，而导航栈订的是 /robot/odom——名字差一层 namespace，DDS 图里就是两个世界。Bridge 不是「把仿真打开」的开关，而是仿真侧与 ROS 侧之间的接口定义：话题名、消息类型、QoS、时钟域、TF 发布权，任一不一致都会表现为算法不稳。排查时先用 ros2 topic list 对照契约表逐项勾，而不是先改 Nav2 参数——否则会把桥的问题参数化进代价地图。

2. Bridge 配置即契约文件

ros_gz_bridge 用 YAML 或 launch 参数声明双向映射。每条映射至少写清：Gazebo 侧 topic、ROS 侧 topic、消息类型、方向（GZ→ROS / ROS→GZ）。

yaml
# bridge_config.yaml — 与 robot 型号绑定，进 git
- ros_topic_name: "/robot/scan"
  gz_topic_name: "/lidar"
  ros_type_name: "sensor_msgs/msg/LaserScan"
  gz_type_name: "gz.msgs.LaserScan"
  direction: GZ_TO_ROS

团队应维护「契约表」：传感器、cmd_vel、clock、TF 相关映射各一行，附期望频率与 QoS。禁止 README 写「参考我本地的 bridge」——那是把接口藏在个人磁盘上。Release 评审时 bridge yaml 与 URDF、Nav2 params 同级 diff，三者 namespace 不一致是最常见的一键回归失败原因。

3. 时钟：sim time 必须贯通

仿真未发布 /clock，或节点未设 use_sim_time:=true，stamp 会混用墙钟与 sim time，message_filters 与 costmap 的观测窗口全部错位。Launch 里统一：

python
SetParameter(name='use_sim_time', value=True)

验收：ros2 topic echo /clock --once 有输出；关键节点 ros2 param get /node use_sim_time 为 true。Gazebo Sim 与 Classic 的 clock 桥接方式不同，换仿真后端时 clock 映射是第一项回归。

4. QoS 与传感器语义

激光、深度、图像在 Gazebo 侧常以 sensor data 语义发布。Bridge 映射到 ROS 时若默认 Reliable + depth 10，而 Nav2 订 Best Effort + KeepLast(1)，可能看似连通实则无数据——ros2 topic info -v 会显示 QoS 不兼容。契约表里应写明每路 QoS；Bridge 支持在映射层指定，或与下游订阅者对齐。

图像经 image_transport 时，Bridge 只桥 raw topic 不够，还要确认 compressed/theora 是否与订阅侧一致。

5. TF：单一所有权

Gazebo 插件、robot_state_publisher、Bridge 若同时发布 base_link→odom，RViz 里 TF 跳变、AMCL 发散。契约应规定：谁发布哪段 TF。常见分工：Gazebo 插件发 world→base（或 odom→base），robot_state_publisher 发关节链；Bridge 只桥 /tf 或 /tf_static 之一，不重复。

bash
ros2 run tf2_tools view_frames   # 检查多父、断链
ros2 topic hz /robot/scan        # 确认桥后频率与 stamp 单调

6. 验收顺序：桥先于算法

最小验收链：仿真 + Bridge + 回显节点，不上 Nav2。

  1. 关键 topic 存在且 hz 接近预期
  2. stamp 单调、与 /clock 同域
  3. TF 树无多父、frame 名与 URDF 一致
  4. cmd_vel 桥回 Gazebo 后模型响应

通过后再叠定位与导航。CI 冒烟：解析 bridge yaml，断言必需映射存在；可选跑 30s 仿真 bag 对比关键 topic 计数。

7. 保真边界：桥不管物理

Bridge 只保证通道——摩擦系数、传感器噪声、通信延迟在 Gazebo 模型与插件里调，不能指望改 Bridge yaml「调出真机感」。契约验收停在名字/类型/QoS/时钟/TF；动力学保真另开实验矩阵。两者混谈会在桥配置里找本属于 SDF 的问题。

8. 案例：namespace 漂移拖死整队回归

某型号把 namespace 从 /robot1 改成 /r1，Bridge yaml 漏改一行 /robot1/scan。仿真 CI 仍绿——冒烟只查 topic 存在，未查前缀。Nav2 全栈测试红了一周，最后 diff bridge 配置才定位。此后契约表增加「namespace 前缀」列，CI 用正则校验 ROS 侧 topic 前缀与 launch 一致。

9. 与真机的关系

仿真 Bridge 契约通过，不代表真机驱动话题名相同；但结构应对齐（scan/odom/cmd_vel 相对位置、QoS 剖面、TF 树形状）。真机 overlay 只改驱动侧映射，不重写导航栈订阅名——否则仿真回归与现场部署永远是两套图。

10. cmd_vel 双向与插件延迟

底盘控制是 ROS→GZ 方向，常漏映射或符号反了（线速度正负与 URDF 前进轴不一致）。验收时发已知 Twist，在 Gazebo 里测模型位移方向与量纲。Bridge 引入的单向延迟通常远小于控制周期，但若叠多层（Bridge + 插件 + 物理步长），要在契约表记录期望最大延迟，控制侧勿再叠未经标定的前馈补偿。

← 全部文章

johan's blog