2. ROS2基础回顾
在进入机器人AI验收测试之前，必须夯实ROS2（Robot Operating System 2）的基础。AI验收中的识别率、节点延迟和导航成功率，本质上都是对ROS2分布式通信系统中各节点协同工作的量化评估。如果对节点生命周期、话题通信的QoS策略、服务与动作的适用边界缺乏清晰认知，后续的测试指标将失去解释依据。本章将系统梳理ROS2的核心概念、通信机制，并给出从零搭建开发环境的完整路径。
上图展示了ROS2的核心概念框架。DDS（Data Distribution Service）作为实时通信中间件，是ROS2与ROS1最本质的区别。所有节点、话题、服务、动作都构建在DDS之上，而CLI、Launch、RQt等工具链则是我们进行AI验收测试时最常用的操作入口。理解这张图，就掌握了ROS2的骨架。
2.1 核心原理：节点、话题、服务与动作的职责边界
ROS2采用分布式架构，一个机器人系统由多个节点（Node）组成。每个节点是一个独立的可执行进程，负责特定的功能模块，例如摄像头驱动节点、YOLO目标检测节点、路径规划节点。节点之间不直接调用函数，而是通过话题（Topic）、服务（Service）和动作（Action）三种机制进行通信。
| 通信方式 | 通信模式 | 同步性 | 适用场景 | AI验收中的典型应用 |
|---|---|---|---|---|
| 话题 | 发布/订阅（Pub/Sub） | 异步 | 高频、单向、持续数据流 | 图像帧、激光扫描、速度指令 |
| 服务 | 请求/响应（Req/Rep） | 同步 | 低频、双向、有明确结果 | 触发拍照、查询模型版本、重置里程计 |
| 动作 | 目标/反馈/结果（Goal/Feedback/Result） | 异步+反馈 | 长耗时、可取消、需进度反馈 | 导航到目标点、机械臂抓取、自主充电 |
话题是ROS2中最常用的通信方式，采用发布/订阅模式，数据流向是单向的。发布者（Publisher）将消息放到指定话题上，订阅者（Subscriber）异步接收。这种设计天然支持多对多通信，非常适合传感器数据流。服务则用于需要即时响应的场景，客户端发送请求后阻塞等待服务器返回响应。动作机制是ROS2对ROS1动作库的升级，它基于话题和服务实现，但增加了反馈（Feedback）和取消（Cancel）能力，特别适合导航这类耗时任务。
关键理解：在AI验收测试中，识别率通常通过订阅视觉话题（如 /camera/image_raw）并统计检测框的置信度来计算；节点延迟则通过记录话题消息的时间戳差值来测量；导航成功率需要调用动作客户端（如 /navigate_to_pose）并监听结果状态。三种通信机制对应三种不同的测试方法。
2.2 通信机制深入：QoS策略与DDS发现协议
ROS2的通信质量由QoS（Quality of Service）策略控制。QoS决定了消息的可靠性、历史数据保留策略和时效性。在AI验收中，QoS配置不当是导致测试数据丢失或延迟异常的常见原因。
- 可靠性（Reliability）：RELIABLE（可靠传输，保证送达）或 BEST_EFFORT（尽力传输，允许丢包）。传感器数据通常用BEST_EFFORT，控制指令用RELIABLE。
- 历史记录（History）：KEEP_LAST（保留最近N条）或 KEEP_ALL（保留全部）。对于图像话题，KEEP_LAST(1)即可，避免内存膨胀。
- 时效性（Durability）：VOLATILE（不保留历史）或 TRANSIENT_LOCAL（为后加入的订阅者保留最近消息）。用于静态地图等场景。
DDS的发现协议（Discovery）是ROS2节点自动找到彼此的基础。节点启动时通过组播宣告自身存在，并交换订阅/发布信息。这个过程通常需要1-2秒，在测试中如果节点频繁重启，需要等待发现完成后再发送数据，否则会出现消息丢失。
# 查看当前所有话题及其QoS设置
ros2 topic info /camera/image_raw --verbose
# 输出示例：
# Type: sensor_msgs/msg/Image
# Publisher count: 1
# Subscriber count: 2
# Reliability: BEST_EFFORT
# History: KEEP_LAST
# Depth: 1风险提示：如果发布者使用BEST_EFFORT，而订阅者要求RELIABLE，通信将无法建立。在验收测试脚本中，务必使用 rclpy.qos.QoSProfile 显式设置QoS，避免使用默认值导致不匹配。
2.3 搭建ROS2开发环境：从安装到工作区配置
搭建一个稳定的ROS2开发环境是进行AI验收的前提。以下以Ubuntu 22.04 + ROS2 Humble为例，给出完整流程。
- 安装ROS2基础包：配置软件源并安装
ros-humble-desktop（包含可视化工具）或ros-humble-ros-base（精简版）。 - 设置环境变量：将
source /opt/ros/humble/setup.bash添加到~/.bashrc，确保每个终端自动加载。 - 创建工作区：使用
mkdir -p ~/ros2_ws/src创建目录结构，colcon build编译。 - 安装AI相关依赖：例如
ros-humble-cv-bridge（OpenCV与ROS图像转换）、ros-humble-nav2（导航栈）、ros-humble-tf2（坐标变换）。 - 验证环境：运行
ros2 run demo_nodes_cpp talker和ros2 run demo_nodes_py listener测试通信。
# 安装ROS2 Humble（Ubuntu 22.04）
sudo apt update
sudo apt install ros-humble-desktop python3-argcomplete
sudo apt install ros-humble-cv-bridge ros-humble-nav2 ros-humble-tf2
# 创建工作区
mkdir -p ~/ros2_ws/src
cd ~/ros2_ws
colcon build --symlink-install
echo "source ~/ros2_ws/install/setup.bash" >> ~/.bashrc
source ~/.bashrc经验建议：在AI验收中，建议使用Docker容器固定开发环境。将ROS2、CUDA、PyTorch和自定义算法打包成镜像，确保所有测试机器环境一致，避免因依赖版本差异导致识别率波动。
2.4 实战场景：用ROS2工具诊断节点延迟
假设我们正在验收一个视觉识别节点，该节点订阅摄像头话题 /camera/image_raw，发布检测结果话题 /detection/boxes。测试目标是测量该节点的端到端延迟。
初始现象：使用 ros2 topic hz /detection/boxes 查看发布频率，发现频率不稳定，从10Hz到30Hz波动，且偶发丢帧。
分析过程：首先检查话题QoS设置，发现摄像头驱动使用BEST_EFFORT，而识别节点订阅时未指定QoS，默认使用RELIABLE，导致通信不匹配，消息被丢弃。其次，使用 ros2 topic delay 测量延迟，发现平均延迟为120ms，远超预期的50ms。
实际操作步骤：
- 修改识别节点的订阅QoS为BEST_EFFORT，与发布端对齐。
- 使用
ros2 run rqt_graph查看节点连接图，确认没有多余的数据转发节点。 - 使用
ros2 topic echo /detection/boxes --once检查消息时间戳，发现时间戳是图像采集时间，而非处理完成时间，导致延迟计算偏差。 - 在识别节点内部增加处理完成时间戳字段，重新测量。
结果对比：调整QoS后，频率稳定在25Hz，延迟降至45ms。时间戳修正后，真实处理延迟为35ms，符合验收标准。
复盘经验：节点延迟测试必须同时关注QoS匹配、时间戳语义和系统负载。建议在测试脚本中统一使用 rclpy 的 TimeSource 获取系统时钟，避免不同节点时钟不同步。
2.5 常见误区与总结复盘
在ROS2基础学习和AI验收准备中，以下误区需要特别警惕：
- 误区一：认为话题通信是即时的。实际上，DDS的发现过程、QoS队列缓冲和网络传输都会引入延迟。
- 误区二：混淆服务与动作。服务适合短请求，动作适合长任务。如果导航调用使用服务，会阻塞节点导致其他功能卡死。
- 误区三：忽略命名空间。在多机器人测试中，话题可能被重映射为
/robot1/camera/image_raw，不检查命名空间会导致订阅不到数据。 - 误区四：使用
ros2 topic echo直接测量延迟。该命令本身有处理开销，应使用ros2 topic delay或自定义时间戳分析。