1. 通信基础回顾：ROS2通信模型概述
各位好，我是这次课程的主讲。咱们直接切入正题——ROS2的通信模型。说实话，我从ROS1时代就开始折腾机器人通信，那时候最头疼的就是节点一多，系统就变得不稳定。ROS2换了底层架构后，情况好了很多，但前提是你得理解它到底怎么工作的。
这一章，我们先打好基础。后面所有的优化技巧，都建立在你对通信模型、DDS选型和QoS策略的理解之上。
1.1 三大通信模型：话题、服务、动作
ROS2提供了三种通信方式，各有各的适用场景。我个人的习惯是：能用话题就别用服务，能用服务就别用动作。为什么？往下看。
话题（Topic）
话题是ROS2里最常用的通信方式。它是异步、一对多的发布-订阅模型。发布者往话题上发数据，订阅者接收数据，双方不需要知道对方的存在。
- 适用场景：传感器数据流、状态信息广播、周期性日志。
- 特点：实时性高，但数据可能丢失（取决于QoS）。
- 我踩过的坑：曾经有个项目，激光雷达数据总是丢帧。查了半天，发现是发布端的队列深度设得太小，订阅端处理不过来就直接丢了。嗯，这里要注意，话题的可靠性完全靠QoS撑着。
服务（Service）
服务是同步、一对一的请求-响应模型。客户端发请求，服务端处理完返回结果，期间客户端会阻塞等待。
- 适用场景：查询参数、触发一次性动作（如拍照）、远程过程调用。
- 特点：可靠，但延迟高，不适合高频通信。
- 避坑指南：我曾经在控制循环里调用了服务，结果每次请求都要等几十毫秒，整个控制周期直接崩了。服务真的不适合高频场景，别硬用。
动作（Action）
动作是异步、长时间运行的通信模型。它基于话题和服务实现，但增加了反馈和可取消的能力。
- 适用场景：导航、机械臂运动、复杂任务执行。
- 特点：支持进度反馈，可中途取消，但实现复杂度高。
- 个人经验：做AGV调度时，动作通信帮了大忙。任务执行到一半，调度系统可以随时取消或重新规划，这在纯话题模型里很难优雅实现。
核心对比：话题是“发完不管”，服务是“问了再答”，动作是“边做边报”。选型时先问自己：我需要反馈吗？我能容忍阻塞吗？数据丢了会出事故吗？
1.2 底层DDS选型与配置
ROS2的通信底层不再是自研的协议，而是直接跑在DDS（数据分发服务）之上。DDS是一个去中心化的实时数据总线标准。说白了，它就是一个超级强大的消息中间件，专门为分布式实时系统设计的。
ROS2官方默认集成了两种DDS实现：Fast DDS（原Fast RTPS）和Cyclone DDS。另外还有RTI Connext DDS（商业版）和GurumDDS（国产）。
| DDS实现 | 特点 | 推荐场景 |
|---|---|---|
| Fast DDS | 开源、性能均衡、社区活跃 | 大多数通用机器人项目 |
| Cyclone DDS | 轻量、低延迟、资源占用少 | 嵌入式、资源受限设备 |
| RTI Connext | 企业级、高可靠、技术支持好 | 工业、医疗、航天等关键系统 |
| GurumDDS | 国产自主、兼容性好 | 信创项目、国内合规需求 |
你可能会问：我该选哪个？我的建议是：默认用Fast DDS，除非你有特殊需求。我在一个移动机器人项目里，默认Fast DDS跑得挺好，但换到树莓派上，内存吃紧，换成Cyclone DDS后，内存占用直接降了30%。
配置DDS也很简单。你可以通过环境变量来切换实现：
# 切换到Cyclone DDS
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
# 切换到Fast DDS（默认）
export RMW_IMPLEMENTATION=rmw_fastrtps_cpp小技巧：如果你在同一个网络里混用了不同DDS实现的节点，它们之间是无法通信的。所有节点必须使用同一个RMW实现。我曾经因为这个排查了半天，最后发现是开发机上用的Fast DDS，而测试机上默认是Cyclone DDS。
1.3 QoS策略全景图
QoS（服务质量）是ROS2通信的灵魂。它决定了数据怎么发、怎么收、丢了怎么办。说白了，QoS就是你和DDS之间签的一份通信契约。
ROS2的QoS策略包含以下几个核心维度：
- 可靠性（Reliability）：
RELIABLE（保证送达） vsBEST_EFFORT（尽力而为）。 - 持久性（Durability）：
VOLATILE（只发新数据） vsTRANSIENT_LOCAL（保留最后一份数据给晚来的订阅者）。 - 历史记录（History）：
KEEP_LAST（保留最近N条） vsKEEP_ALL（保留所有）。 - 深度（Depth）：队列大小，配合
KEEP_LAST使用。 - 截止时间（Deadline）：数据发布的最大间隔。
- 生命周期（Lifespan）：数据有效时间，超时自动丢弃。
我画了一张图，帮你快速理解这些策略之间的关系：
QoS的配置直接影响通信性能。举个例子，如果你发布的是激光雷达数据，用BEST_EFFORT + KEEP_LAST(1)就够了。因为雷达数据更新很快，丢一帧无所谓，重要的是延迟要低。但如果你发布的是控制指令，那就必须用RELIABLE，指令丢了机器人可能就撞墙了。
重要警告：发布端和订阅端的QoS策略必须兼容。比如发布端设了RELIABLE，订阅端设了BEST_EFFORT，通信会降级为BEST_EFFORT。如果完全不兼容（比如一个要求TRANSIENT_LOCAL，另一个是VOLATILE），通信会直接失败。我曾经在调试时遇到过这种问题，日志里只报了个“incompatible QoS”，排查了半天才发现是两端策略没对齐。
好了，这一章的基础内容就到这里。通信模型、DDS选型、QoS策略，这三块是ROS2通信的基石。后面的章节，我们会深入每个细节，讲怎么调优、怎么避坑。你先把这些概念消化掉，后面才能跟上节奏。