第1章：ROS/ROS2通信机制：话题与服务、消息定义、QoS配置、通信延迟排查
1.1 话题与服务——选对工具干对活
做感知模块联调，第一件事就是搞清楚通信方式。ROS里最常用的就是话题（Topic）和服务（Service）。
我个人习惯这么区分：话题是“广播”，服务是“问答”。你想想看，激光雷达发点云数据，一个发多个收，这不就是广播吗？而你要查询某个传感器的状态，一问一答，那就是服务。
我在项目中遇到过一个问题：有人用服务来传高频的感知数据，结果系统直接卡死。为什么？因为服务是同步阻塞的，你发一个请求，得等响应回来才能干别的事。高频数据流用服务，那就是给自己挖坑。
核心原则：
- 持续、高频的数据流 → 用话题（Topic）
- 偶尔、一次性的请求/响应 → 用服务（Service）
- 需要确认执行结果 → 用服务（Service）
ROS2里还多了个动作（Action），适合那种执行时间长的任务，比如导航到某个点。不过感知模块里用得不多，这里就不展开了。
1.2 消息定义——别让类型成为联调的绊脚石
消息定义看着简单，但坑不少。我记得有一次联调，两个团队各自定义了几乎一样的消息，就差了字段名的大小写，结果对接时折腾了一整天。
消息定义有几个要点：
- 字段类型要精确：float32够用就别用float64，uint8能表示就别用int32。省带宽，省内存。
- 命名要规范：我建议团队内部统一命名风格，比如都用snake_case，别混用camelCase。
- 版本管理：消息定义变了，所有依赖的节点都得重新编译。ROS2在这方面比ROS1好一些，但也不是完全兼容。
小技巧：定义消息时，尽量用嵌套结构。比如把“时间戳”单独做成一个字段，而不是散落在各个地方。这样后期改起来方便。
举个实际例子，感知模块里常见的消息定义：
# 感知目标消息
uint32 id # 目标ID
float32 x # x坐标（米）
float32 y # y坐标（米）
float32 velocity # 速度（m/s）
uint8 type # 目标类型：0=行人，1=车辆，2=自行车
builtin_interfaces/Time timestamp # 时间戳嗯，这里要注意：时间戳一定要带。没有时间戳的感知数据，在融合模块里基本就是废的。
1.3 QoS配置——ROS2的杀手锏也是坑王
ROS2的QoS（Quality of Service）配置，说白了就是让你控制消息怎么发、怎么收、丢了怎么办。ROS1里没有这个，所以ROS2的灵活性高了很多，但也复杂了不少。
我刚开始用ROS2时，就踩过一个坑：两个节点明明在同一个网络里，就是收不到对方的消息。查了半天，发现是QoS配置不匹配。一个设的是RELIABLE，另一个设的是BEST_EFFORT，结果订阅方收不到发布方的消息。
警告：ROS2中，发布方和订阅方的QoS配置必须兼容，否则通信会失败。最常见的坑就是RELIABLE vs BEST_EFFORT不匹配。
QoS的几个关键参数：
| 参数 | 说明 | 推荐场景 |
|---|---|---|
| Reliability | RELIABLE（可靠）或 BEST_EFFORT（尽力） | 控制指令用RELIABLE，传感器数据用BEST_EFFORT |
| Durability | VOLATILE（不保留）或 TRANSIENT_LOCAL（保留最后一条） | 地图数据用TRANSIENT_LOCAL，实时数据用VOLATILE |
| Depth | 消息队列深度 | 高频数据设大一点（如100），低频数据设小一点（如10） |
我个人习惯：感知数据用BEST_EFFORT + 大Depth。为什么？因为感知数据丢了就丢了，下一帧马上就来。但如果是控制指令，必须用RELIABLE，丢了可就出事故了。
1.4 通信延迟排查——找到那个“慢”在哪
通信延迟是感知模块联调里最头疼的问题之一。你想想看，摄像头30fps的数据，经过预处理、检测、跟踪、发布，再到融合模块，中间每一步都可能引入延迟。
我曾经排查过一个延迟问题，从传感器到决策模块，延迟高达200ms。一步步查下来，发现是消息序列化/反序列化占了大部分时间。说白了，就是消息定义太复杂，字段太多，序列化时CPU吃不住。
排查通信延迟的几个步骤：
- 打时间戳：每个关键节点都打上时间戳，从发布到接收，每一步都记录下来。
- 用ros2 topic hz：看看话题的实际频率，是不是和预期一致。
- 检查QoS：RELIABLE模式在网络不好时会重传，导致延迟飙升。
- 看CPU占用：序列化/反序列化是不是成了瓶颈。
实战经验：我遇到过最离谱的一次，延迟是因为某个节点的回调函数里做了大量计算，导致消息队列积压。解决方案很简单：把计算放到单独的线程里，回调只负责收数据。
ROS2里有个好用的工具——ros2 topic delay，可以直接看话题的端到端延迟。不过要注意，这个延迟是发布到接收的时间差，不包括处理时间。
嗯，最后说一句：延迟排查没有银弹。每个系统的瓶颈都不一样，关键是要有系统性的排查思路，而不是瞎猜。
本章小结：ROS/ROS2通信机制的核心就四个字——选、定、配、查。选对通信方式，定好消息格式，配好QoS参数，查清延迟来源。把这四步走扎实了，感知模块联调就成功了一半。
可可精品资料库