2. ROS2基础回顾
在自动驾驶系统中，ROS2 并不是一个“单机消息总线”，而是一套围绕分布式实时通信构建的软件中间件。理解节点、话题、服务、动作、参数、执行器与 DDS 之间的关系，是后续做生命周期管理、确定性调度和故障隔离的前提。本节从通信原语出发，串联到自动驾驶的典型数据流。
一、核心通信原语：五种交互方式
ROS2 提供五种基本交互机制，它们分别对应不同的数据流向与实时性要求：
- 话题（Topic）：发布/订阅模型，单向、多对多、异步。适合高频传感器流，如激光雷达点云、摄像头图像、IMU 数据。
- 服务（Service）：请求/响应模型，双向、一对一、同步阻塞。适合短时、确定性的查询或配置操作，如查询车辆状态、切换地图。
- 动作（Action）：基于话题和服务的组合，支持长时间任务、进度反馈与取消。适合导航到目标点、泊车入位等耗时任务。
- 参数（Parameter）：节点级键值配置，支持运行时动态修改。适合阈值、增益、模式开关等可调参数。
- 执行器（Executor）：负责调度回调的线程模型，决定节点内回调如何并发执行，直接影响实时性与确定性。
节点是 ROS2 的计算单元，通信原语是节点之间的“接口契约”。在自动驾驶中，一个节点往往同时使用话题、服务、动作和参数，因此必须明确每种接口的语义与实时边界。
二、DDS 通信模型：ROS2 的底层骨架
ROS2 默认使用 DDS（Data Distribution Service）作为通信中间件。DDS 采用以数据为中心的发布/订阅模型，通过全局数据空间实现去中心化通信。每个节点在 DDS 中声明自己的发布者和订阅者，DDS 负责发现、匹配、序列化和传输。
关键概念包括：
- Domain ID：逻辑隔离域，同一域内节点才能互相发现。自动驾驶中常用不同 Domain 隔离仿真、测试与实车。
- QoS：服务质量策略，决定可靠性、历史深度、持久性、截止时间等。QoS 不匹配是“话题存在但收不到数据”的最常见原因。
- 发现机制：节点启动后通过 DDS 发现协议自动寻找匹配的发布者/订阅者，无需中心节点。
下面这张图展示了自动驾驶场景中从传感器到控制器的典型数据流，以及 DDS 在其中的位置：
三、执行器：回调调度的关键
执行器决定节点内回调函数的执行方式。ROS2 提供两种主要执行器：
- 单线程执行器（SingleThreadedExecutor）：所有回调串行执行，逻辑简单，但一个耗时回调会阻塞其他回调。
- 多线程执行器（MultiThreadedExecutor）：回调可并发执行，适合高吞吐场景，但需要处理线程安全与回调组（CallbackGroup）配置。
在自动驾驶中，感知节点通常使用多线程执行器并配合互斥回调组，避免点云处理阻塞目标跟踪；而控制节点更倾向单线程执行器，保证控制周期的确定性。
# 查看节点使用的执行器与回调组
ros2 node info /perception_node
# 查看话题 QoS 配置
ros2 topic info /points --verbose
# 查看参数
ros2 param list /controller_node
ros2 param get /controller_node max_speed四、自动驾驶典型数据流与 QoS 匹配
下表总结了自动驾驶中常见话题的推荐 QoS 配置与实时性要求：
| 话题 | 方向 | 推荐 QoS | 实时性要求 |
|---|---|---|---|
| /lidar/points | 传感器 → 感知 | Best Effort, Depth 5 | 高吞吐，允许丢帧 |
| /camera/image | 传感器 → 感知 | Best Effort, Depth 3 | 高带宽，允许丢帧 |
| /perception/objects | 感知 → 规划 | Reliable, Depth 10 | 关键数据，不可丢 |
| /localization/pose | 定位 → 规划控制 | Reliable, Depth 5 | 高频且必须可靠 |
| /control/cmd | 控制 → 底盘 | Reliable, Depth 1 | 低延迟，最新值优先 |
QoS 不匹配是 ROS2 调试中最常见的问题之一。如果发布者使用 Best Effort，而订阅者要求 Reliable，DDS 将无法建立连接，表现为“话题存在但收不到数据”。使用
ros2 topic info --verbose 可以快速对比两端 QoS。
五、常见误区与复盘
误区一：把话题当服务用。话题是异步流，不适合请求/响应语义。若用话题模拟服务，容易造成状态不一致和超时难以处理。
误区二：忽略执行器线程模型。多线程执行器下，多个回调可能同时访问共享数据，必须使用回调组或锁保护。
误区三：QoS 配置随意。传感器数据用 Reliable 会带来重传延迟，控制指令用 Best Effort 可能丢失关键命令。
误区四：参数当全局变量。参数是节点级配置，跨节点共享应通过话题或服务，而不是直接读写其他节点参数。
误区二：忽略执行器线程模型。多线程执行器下，多个回调可能同时访问共享数据，必须使用回调组或锁保护。
误区三：QoS 配置随意。传感器数据用 Reliable 会带来重传延迟，控制指令用 Best Effort 可能丢失关键命令。
误区四：参数当全局变量。参数是节点级配置，跨节点共享应通过话题或服务，而不是直接读写其他节点参数。
复盘时建议按以下顺序排查：先确认节点是否发现（ros2 node list），再确认话题是否匹配（ros2 topic info --verbose），然后检查 QoS 与执行器配置，最后用 ros2 topic hz 和 ros2 topic echo 验证数据流是否正常。掌握这些基础原语与 DDS 模型，才能在后续生命周期管理中做到可控、可观测、可恢复。