2. ROS2通信架构基础
在ROS2的分布式计算模型中，节点（Node）是功能执行的最小单元，而话题（Topic）、服务（Service）、动作（Action）则是节点间交互的三种核心通信原语。理解这三者的底层数据路径、同步/异步语义以及各自的延迟构成，是进行模型部署优化、QoS配置和消息队列控制的前提。本章将逐一拆解四种通信模型的架构特征，并重点分析从发送方到接收方全链路中的延迟来源，为后续章节的调优实践奠定理论基础。
上图展示了ROS2中三种主要通信模型的基本数据路径。可以看到，话题通信是单向的发布-订阅模式，服务是双向的请求-响应模式，而动作则是在服务基础上增加了反馈通道。在实际工程中，延迟并非单一环节造成，而是多个阶段累积的结果。下面我们逐一深入分析。
2.1 节点与通信图：ROS2的执行单元
核心原理：节点是ROS2中可执行的计算单元，每个节点负责特定的功能（如传感器驱动、路径规划、电机控制）。节点之间通过DDS（Data Distribution Service）中间件进行通信，DDS负责消息的发现、序列化、传输和分发。与ROS1不同，ROS2的节点发现机制基于DDS的Discovery协议，节点启动时会通过组播或点对点方式广播自己的存在，并建立端到端的逻辑连接。
判断方法：在调优前，首先需要绘制系统的节点通信图（Node Graph）。使用 rqt_graph 或 ros2 node info 命令可以查看节点间的连接关系。重点关注：
- 节点数量与分布：节点是否分布在多台机器上？跨机通信会增加网络延迟。
- 话题连接数：一个话题被多个订阅者订阅时，发布者需要复制消息副本，增加CPU和带宽开销。
- 通信方向：是否存在环形依赖或冗余连接？
ros2 daemon stop 和 ros2 daemon start 可以刷新节点发现缓存，避免陈旧连接。
2.2 话题通信模型：异步发布-订阅
核心原理：话题是ROS2中最常用的通信方式，采用发布-订阅模式。发布者（Publisher）向话题写入消息，订阅者（Subscriber）从话题读取消息。通信是异步的，发布者不等待订阅者确认，订阅者也不阻塞发布者。DDS中间件负责消息的匹配和传输，支持多种QoS策略（如可靠性、历史记录、时效性）。
延迟来源分析：话题通信的端到端延迟由以下环节构成：
- 序列化延迟：将ROS2消息对象转换为字节流（使用CDR或TypeScript序列化）。消息越复杂，序列化时间越长。
- 网络传输延迟：包括网卡发送、物理链路传播、交换机转发、接收端网卡处理。对于千兆以太网，单次传输延迟通常在50-200微秒级别。
- 队列排队延迟：消息到达接收端后，进入DDS队列。如果订阅者处理速度慢于消息到达速率，队列会积压，导致延迟增加。
- 回调执行延迟：订阅者线程从队列取出消息并执行回调函数。回调中的计算量直接影响处理时间。
| 延迟环节 | 典型量级 | 影响因素 | 优化手段 |
|---|---|---|---|
| 序列化 | 1-50 µs | 消息大小、字段数量、序列化库 | 使用扁平消息、减少嵌套、启用零拷贝 |
| 网络传输 | 50-500 µs | 物理距离、网络负载、协议栈 | 使用共享内存传输、优化网卡中断合并 |
| 队列排队 | 0-100 ms | 队列深度、订阅者处理速率 | 调整队列深度、使用有界队列、背压控制 |
| 回调执行 | 10 µs - 10 ms | 回调复杂度、线程调度 | 拆分回调、使用多线程执行器、优先级调度 |
/scan，消息频率30Hz，消息大小约50KB。初始配置使用默认QoS（深度10），在CPU负载较高时，订阅端出现明显延迟抖动。通过 ros2 topic hz /scan 和 ros2 topic delay /scan 测量，发现平均延迟从5ms飙升至80ms。分析发现，订阅端回调中执行了耗时的点云滤波算法，导致回调执行时间超过33ms（即消息间隔），队列持续积压。优化措施：①将滤波算法移至独立节点，通过话题连接；②将订阅端QoS的队列深度从10调整为5，并设置 deadline 为100ms，强制丢弃过期消息；③使用多线程执行器，将回调绑定到独立线程。优化后，平均延迟稳定在8ms以内，抖动小于2ms。
2.3 服务通信模型：同步请求-响应
核心原理：服务采用客户端-服务器模式，客户端发送请求并阻塞等待响应。服务端处理请求并返回结果。通信是同步的，客户端在等待期间无法执行其他操作（除非使用异步客户端API）。服务适用于短事务型操作，如查询参数、触发一次性动作。
延迟来源分析：服务延迟 = 请求序列化 + 请求传输 + 服务端排队 + 服务端处理 + 响应序列化 + 响应传输 + 客户端反序列化。其中，服务端排队延迟是常见瓶颈，当多个客户端同时请求同一服务时，请求会进入服务端的等待队列。
判断方法：使用 ros2 service call 命令可以手动调用服务并测量响应时间。在代码中，可以使用 rclcpp::Client 的异步调用接口，避免阻塞主线程。
2.4 动作通信模型：异步长任务执行
核心原理：动作是ROS2为长耗时任务设计的通信原语，基于服务实现，但增加了反馈和取消机制。动作客户端发送目标（Goal），服务端执行任务并周期性地发送反馈（Feedback），任务完成后返回结果（Result）。动作通信是异步的，客户端在等待结果的同时可以处理其他事务。
延迟构成：动作延迟包括目标传输延迟、任务执行时间、反馈周期、结果传输延迟。与话题和服务不同，动作的延迟主要取决于任务本身的执行时间，而非网络传输。因此，优化动作延迟的关键在于：
- 任务分解：将长任务拆分为多个子步骤，通过反馈机制实时上报进度。
- 反馈频率控制：反馈消息不宜过于频繁，否则会占用带宽和CPU。通常反馈频率控制在10-20Hz即可。
- 取消响应：服务端应能快速响应取消请求，避免资源泄漏。
NavigateToPose 动作的延迟直接决定了机器人的响应速度。某案例中，机器人从接收目标到开始运动耗时1.2秒，其中动作目标传输仅占50ms，其余时间消耗在路径规划计算上。通过优化规划算法（改用增量式规划）并将反馈频率从5Hz提升到15Hz，操作员能更早感知到机器人的运动意图，主观体验明显改善。但注意，反馈频率提升增加了约3%的CPU占用，在低算力平台上需权衡。
2.5 延迟来源综合对比与排查清单
下表汇总了三种通信模型的延迟特征，便于在实际系统中快速定位瓶颈：
| 通信类型 | 同步性 | 典型延迟 | 主要延迟来源 | 适用场景 |
|---|---|---|---|---|
| 话题 | 异步 | 1ms - 100ms | 队列排队、回调执行 | 传感器数据流、状态发布 |
| 服务 | 同步 | 0.1ms - 10ms | 服务端处理、网络往返 | 参数查询、触发命令 |
| 动作 | 异步 | 100ms - 数秒 | 任务执行时间、反馈周期 | 导航、机械臂控制 |
排查流程：当系统出现延迟问题时，按以下步骤定位：
- 使用
ros2 topic delay或ros2 topic hz测量话题的端到端延迟和频率。 - 检查CPU占用率，确认是否存在回调执行过慢或线程饥饿。
- 使用
ros2 doctor检查DDS发现状态和网络健康度。 - 若跨机通信，使用
ping和iperf测试网络带宽和延迟基线。 - 检查QoS配置，确认队列深度、可靠性策略是否与消息频率匹配。