2. ROS2基础回顾
在自动驾驶系统中，ROS2 并不是一个“可有可无的中间件”，而是承载感知、定位、预测、规划、控制等模块协同运行的通信骨架。理解 ROS2 的基础概念，关键不在于记住术语定义，而在于看清每个通信原语在自动驾驶软件架构中对应哪一类交互需求。节点、话题、服务、动作、参数、执行器与 DDS，共同构成了一套从“谁在运行”到“如何交换数据”再到“如何调度任务”的完整体系。
一、核心原理：七类原语的职责边界
节点（Node）是 ROS2 中的最小计算单元，通常对应一个功能模块，例如激光雷达驱动节点、目标检测节点、轨迹规划节点。节点之间不直接持有彼此指针，而是通过 DDS 发现机制建立通信关系，这使系统具备分布式部署能力。
话题（Topic）采用发布/订阅模型，适合高频、单向、持续的数据流。自动驾驶中的点云、图像、车辆底盘状态、里程计等，几乎都以话题形式传输。话题的关键参数包括消息类型、QoS 可靠性、历史深度和发布频率。
服务（Service）采用请求/响应模型，适合低频、需要明确返回结果的同步操作，例如“查询当前地图版本”“请求一次标定参数写入”。服务不应承载高频数据流，否则会阻塞调用方。
动作（Action）是服务与话题的组合，支持长时间运行任务、周期反馈和取消操作。自动驾驶中的“变道”“靠边停车”“重新规划到目标点”等行为，天然适合用动作描述。
参数（Parameter）用于节点运行时配置，例如检测阈值、控制增益、传感器外参。参数可动态更新，但不应被当作高频数据通道使用。
执行器（Executor）负责调度节点中的回调。单线程执行器简单但容易阻塞；多线程执行器可提升并发，但需要关注回调组与线程安全。自动驾驶中，感知与控制的实时性差异很大，执行器配置直接影响时延抖动。
DDS是 ROS2 的底层通信中间件，提供发现、序列化、QoS 和传输能力。ROS2 的 QoS 策略，如 Reliability、Durability、History、Deadline，最终由 DDS 实现。理解 DDS，才能理解为什么同一个话题在不同 QoS 下表现完全不同。
二、方法流程：从需求到通信原语的选择
在自动驾驶软件架构设计中，选择通信原语应遵循一条清晰流程：先判断交互是“持续流”还是“一次性请求”，再判断是否需要反馈与取消，最后确定 QoS 与执行器策略。
- 持续高频数据：优先使用话题，并配置合适的 QoS。例如点云使用 Best Effort 可降低丢包重传带来的时延，控制指令使用 Reliable 保证关键命令不丢失。
- 低频同步查询：使用服务。例如查询地图版本、请求传感器标定状态。
- 长时任务：使用动作。例如“变道到左侧车道”，需要周期反馈进度，并允许在危险时取消。
- 运行时配置：使用参数。例如动态调整规划器最大速度、检测置信度阈值。
- 调度与并发：根据回调实时性要求配置执行器与回调组。感知回调可放入多线程执行器，控制回调应放入独立线程或高优先级回调组。
关键原则：话题负责“流”，服务负责“问”，动作负责“做”，参数负责“调”，执行器负责“排”，DDS 负责“通”。六者职责不能混用，否则会出现时延抖动、回调阻塞或 QoS 不匹配等典型问题。
三、案例场景：自动驾驶数据链路映射
以城市道路自动驾驶为例，激光雷达驱动节点以 10 Hz 发布 /lidar/points，QoS 设置为 Best Effort、Keep Last 5。感知节点订阅该话题，输出 /perception/objects，包含障碍物类别、位置、速度。预测节点订阅感知结果，发布 /prediction/trajectories。规划节点综合预测、定位与地图信息，发布 /planning/trajectory。控制节点订阅轨迹，输出 /vehicle/control_cmd 给底盘。
当乘客按下“靠边停车”按钮时，系统不会通过话题持续发送按钮状态，而是调用一个动作 /pull_over，规划模块接收目标，周期反馈“正在寻找停车点”“已减速”“已停车”，并允许在异常时取消。地图版本查询则通过服务 /map/get_version 完成。车辆最高速度、跟车距离等通过参数服务器动态配置。
# 查看话题与 QoS
ros2 topic list -t
ros2 topic info /lidar/points --verbose
# 查看动作
ros2 action list
ros2 action info /pull_over
# 查看参数
ros2 param list /planning_node
ros2 param get /planning_node max_speed
# 查看节点与执行器相关日志
ros2 node info /perception_node四、误区与复盘：常见通信设计问题
| 误区 | 现象 | 修正方式 |
|---|---|---|
| 用服务传输高频点云 | 调用方阻塞，时延剧烈抖动 | 改为话题，配置 Best Effort 与合适深度 |
| 话题 QoS 不匹配 | 发布者与订阅者无法建立连接 | 统一 Reliability、Durability、History 策略 |
| 单线程执行器承载所有回调 | 控制回调被感知回调阻塞 | 使用多线程执行器并划分回调组 |
| 用参数传递实时数据 | 参数更新频率低，数据滞后 | 实时数据走话题，参数只做配置 |
| 忽略 DDS 发现开销 | 节点数量多时启动慢、网络流量大 | 合理划分域、使用发现服务器或限制发现范围 |
复盘建议：在自动驾驶项目中，建议为每个话题建立“通信契约”，明确消息类型、频率、QoS、最大时延和丢包容忍度。这样在集成测试和排障时，可以快速判断问题出在算法、通信还是调度层。
注意：ROS2 的 QoS 不是“越可靠越好”。对于高频传感器数据，Reliable 可能因重传导致时延累积；对于控制指令，Best Effort 又可能丢失关键刹车命令。必须按数据语义选择，而不是按习惯选择。
将 ROS2 基础原语与自动驾驶架构对齐后，后续讨论性能与可靠性时就有了共同语言：时延问题可能来自 DDS 传输、执行器调度或 QoS 配置；可靠性问题可能来自节点崩溃、发现失败或回调阻塞。只有先看清通信骨架，才能进一步做性能剖析与可靠性加固。