第一组：感知输入（橙色，3 条）

/speech_text 语言感知

• 消息类型：一般是 std_msgs/String 或自定义消息（含识别文本、置信度、时间戳）
• 链路：语音识别节点发布 → 任务规划节点订阅
• 测试关注：识别准确率（安静/嘈杂两种环境）、从说话到出文本的响应时延、空输入和超长输入的处理、方言与背景音干扰

/camera/color/image_raw 视觉感知

• 消息类型：sensor_msgs/Image，标准消息里含 header（时间戳 + 坐标系）、分辨率、编码格式（rgb8 / bgr8）、原始数据
• 这是全系统数据量最大的话题——1080p 一帧约 6MB
• 测试关注：实际帧率是否达标、丢帧率、时间戳连续性、编码格式是否与下游一致、带宽与 CPU 占用
• 补充知识点：图像话题必须配 /camera_info（相机内参）才有意义，标定不准会直接导致后续所有视觉结果偏移

/imu 惯性测量

• 消息类型：sensor_msgs/Imu，包含四元数姿态、角速度、线加速度，以及三个协方差矩阵
• 测试关注：零偏测试（机器人静置时角速度应接近 0）、噪声水平、输出频率、静止时姿态漂移速度
• 面试常问：为什么 IMU 不能单独用于定位？→ 因为积分会累积误差，必须和轮式里程计或激光融合

第二组：理解与定位（绿色，3 条）

/detection_results 目标检测

• 消息类型：自定义消息，通常含边界框坐标、类别标签、置信度、时间戳
• 测试关注：检测准确率与漏检率（算法指标）、消息字段是否完整、检测结果用的坐标系和机器人坐标系是否统一、从图像到检测结果的延迟
• 这一条是"算法测试岗"和"功能测试岗"的分界线，投算法测试时会被重点问

/tf 坐标变换

• 消息类型：tf2_msgs/TFMessage
• 作用：维护机器人全身的坐标变换树——从地图 map 到里程计 odom，到机器人本体 base_link，再到每个关节、每个传感器，全靠它计算相对位置
• 测试关注：TF 树是否完整（用 ros2 run tf2_tools view_frames 生成树状图）、是否存在一个子节点挂两个父节点（TF 必须是"树"不能是"网"）、时间戳是否更新、静态变换与动态变换是否分开
• 现象级判断：RViz 里机器人闪烁、飘走或者突然消失，第一反应就是查 TF

/nav/point 方向位置

• 消息类型：一般是 geometry_msgs/PoseStamped（带时间戳和目标坐标系的位置 + 朝向四元数）
• 测试关注：目标点坐标是否被正确解析、朝向角是否生效、无效目标点（超出地图范围）如何报错

第三组：规划、执行与反馈（蓝 / 黄 / 粉，3 条）

navigate_to_pose 任务执行

• 注意这个细节：它没有 / 前缀。ROS 2 里话题、服务通常以 / 开头，动作（Action）则习惯不带——这正是原图列标题写"话题/服务/动作名称"的原因
• 消息类型：nav2_msgs/action/NavigateToPose，是 Nav2 导航栈的标准动作
• 为什么用动作不用话题：导航是长任务，需要中间的进度反馈、能中途取消、能返回最终结果，这是话题做不到的
• 测试关注：目标点不可达时是否正确返回失败（不能卡死）、中途取消是否真的停下、超时与重试机制、路径规划失败的降级处理

/arm_trajectory 机械臂规划

• 消息类型：trajectory_msgs/JointTrajectory，是一串带时间戳的关节点位序列，控制器按时间插值执行
• 测试关注：轨迹点数量与时间间隔是否合理、关节是否超出限位、逆解是否可达、实际执行时间与规划时间是否一致
• 这类测试的核心指标是轨迹跟随误差，属于精度测试

/cmd_vel 底盘控制

• 消息类型：geometry_msgs/Twist，含线速度和角速度各三个分量，实际常用的只有 linear.x（前进）和 angular.z（转向）
• 这是底盘唯一的运动入口，安全性要求最高，测试优先级排第一
• 必须测四项：限幅（发的速度超过最大值时是否被截断）、急停（发零速度后是否立即停止，响应时间多少）、频率稳定性（一般 10–50Hz，掉频会导致底盘一顿一顿）、异常值（发 NaN 或 Inf 会不会失控）

/joint_states 底层状态

• 消息类型：sensor_msgs/JointState，含关节名称数组、位置数组、速度数组、力矩数组
• 测试关注：关节数量与名称是否和真机一致、数值是否在合理范围、时间戳是否连续、更新频率（一般 100–1000Hz）、单个关节数据异常是否影响整机