14. 第一次功能验收与问题分层¶
14.1 学习目标¶
用最少的改动判断问题停在哪一层。验收顺序固定为供电、底盘控制板、独立遥控、主控通信、ROS 2 底层、传感器。前一层没有通过，就不在后一层反复改参数。
本章输出一份故障证据包，包括配置表、上电视频、OLED/指示灯、设备列表、ROS 2 节点和话题状态。后续排障可据此比较实际变化，不必依赖记忆判断故障何时出现。
14.2 适用范围¶
| 项目 | 适用情况 |
|---|---|
| ROS 2 机器人 | 主流程 |
| ROS 1 旧设备 | 分层方法相同，命令见附录 A |
| R680 | OLED、自检、遥控和电机反馈可提供更细的底盘证据 |
| 尚未完成接线检查的机器人 | 不适用，先完成第 11 章 |
14.3 操作前检查¶
先限制运动风险
底盘测试只使用低速、短时命令。清空运动区域，准备急停。轮子架空时确认支架稳定；阿克曼底盘还要给转向机构留出空间。
- 保存第 10 章配置表、第 12 章上电基线和第 13 章连接记录。
- 关闭导航、跟随、编队和智能交互等上层应用，只保留本次要验证的节点。
- 打开一个专门记录日志的主控终端，不在测试过程中清屏。
- 本章不修改车型、串口、雷达或相机参数。发现配置不符时先记录，修改放到对应章节。
14.4 工作原理¶
把机器人看成一条有方向的数据链：
电源
↓
底盘控制板自检与使能
↓
遥控器或 ROS 速度命令
↓
串口/CAN 通信
↓
电机驱动与机械运动
↓
编码器、IMU 等反馈
↓
ROS 2 节点与话题
↓
建图、导航、视觉等上层功能
这里的串口或串行端口和CAN都是主控与底盘控制板交换命令和状态的通道。编码器把车轮转动转换为脉冲，IMU测量加速度和角速度。控制板或 ROS 节点据此计算里程计，即机器人根据轮子运动推算出的位姿和速度；它会受轮径误差和打滑影响。
诊断从下往上进行。比如遥控器可以稳定控制四个轮子，说明电池、控制板、驱动器和主要机械结构基本可用。此时若 ROS 控制失败，先查主控通信和 ROS 配置；现有证据尚不支持更换电机。
14.5 操作步骤¶
1. 第零层：供电与启动¶
检查第 12 章的基线是否仍可重复：
- 电池电压在本机允许范围；
- 控制板和主控均能稳定启动；
- 没有异常发热、焦味和反复重启；
- 急停和使能状态可观察。
若这一层失败，停止后续测试。ROS 日志无法修复供电压降或接头烧蚀。
2. 第一层：底盘控制板和自检¶
记录 OLED 或指示灯。R680 可重点看：
TYPE是否与车型一致；- 使能是否为 ON；
- 电压显示是否稳定；
- 控制模式是否随遥控输入改变；
- 电机目标值和实际值是否有响应；
- 是否出现
TYPE X。
出现 TYPE X 时，底盘可能主动失能电机。这不是 ROS 层故障，先保存屏幕、接线和车型证据。
3. 第二层：不经过 ROS 验证底盘¶
选择随车支持的 APP、PS2 或航模遥控器，使用最低速度短按前、后、左、右或转向。测试内容取决于底盘形式：阿克曼不应按全向横移测试，差速底盘也没有横移能力。
记录每次输入、OLED 模式/目标值、轮子动作和实际方向。
| 输入 | OLED/控制板响应 | 轮子/转向响应 | 结论 |
|---|---|---|---|
| 前进 | |||
| 后退 | |||
| 左转 | |||
| 右转 | |||
| 停止 |
遥控无响应但 OLED 也没有模式或目标值时，先查遥控配对与操作；OLED 有目标值而电机不动时，查使能、驱动器、电机和编码器。
4. 第三层：主控是否识别底盘通信设备¶
在机器人主控终端中执行：
lsusb
ls -l /dev/ttyUSB* /dev/ttyACM* 2>/dev/null
dmesg --ctime | tail -n 80
先保存底盘控制板插入时的设备信息。不要仅依赖 /dev/ttyUSB0 这类编号，因为重新插拔或增加传感器后编号可能改变。稳定项目应使用 udev 规则或设备属性；相关配置在第 25 章处理。
5. 第四层：启动 ROS 2 底层¶
确认当前终端已加载正确 ROS 2 和工作空间，然后从当前功能包中选择与车型、主控和传感器匹配的启动文件。常见启动形式是：
ros2 launch turn_on_wheeltec_robot turn_on_wheeltec_robot.launch.py
包名和文件名随版本变化。若命令不存在，先执行：
ros2 pkg prefix turn_on_wheeltec_robot
ros2 pkg executables turn_on_wheeltec_robot
不要从其他资料版本复制启动文件覆盖当前系统。保留启动终端的完整错误信息。
6. 第五层：检查节点和基础话题¶
另开一个已经加载相同 ROS 2 环境的主控终端：
ros2 node list
ros2 topic list
找到底盘、里程计和 IMU 的实际话题名，再检查消息类型与频率：
ros2 topic info <话题名>
ros2 topic hz <话题名>
ros2 topic echo --once <话题名>
不同镜像使用的话题名可能不同。验收时依次确认：节点存在、话题类型正确、静止时数据稳定、轻推或短时运动后里程计/IMU 有合理变化。
7. 第六层：逐个启动传感器¶
底盘通过后，再分别启动雷达和相机。每次只增加一类设备，并保存启动日志。
常见出厂示例：
ros2 launch turn_on_wheeltec_robot wheeltec_lidar.launch.py
ros2 launch turn_on_wheeltec_robot wheeltec_camera.launch.py
实际文件名应以当前包为准。使用 ros2 topic list 和 ros2 topic hz 检查数据，不以“终端没有红字”作为通过标准。
8. 整理故障证据包¶
建议目录：
robot-baseline/
├── configuration.md
├── power-on.mp4
├── oled.jpg
├── wiring/
├── usb.txt
├── dmesg.txt
├── ros2-launch.log
├── nodes.txt
├── topics.txt
└── observations.md
日志中如含 Wi-Fi 密码、令牌或个人网络信息，分享前先脱敏。
14.6 验收标准¶
把结果归入下表，不使用含糊的“基本正常”：
| 层级 | 通过条件 | 实机结果 |
|---|---|---|
| 供电 | 稳定启动，无异常发热和重启 | |
| 控制板 | 自检通过，车型/使能状态明确 | |
| 独立底盘 | 遥控输入与底盘动作一致，停止可靠 | |
| 主控通信 | USB/串口设备稳定出现 | |
| ROS 2 底层 | 节点启动，里程计/IMU 话题持续发布 | |
| 雷达 | 设备和点云/扫描话题持续发布 | |
| 相机 | 设备和图像话题持续发布 |
本章至少要确定“最低失败层”。例如：供电、遥控底盘均通过，主控看不到串口设备，则最低失败层是主控通信；此时无需启动导航框架。
14.7 故障排查¶
| 现象 | 最低可能层 | 下一步 |
|---|---|---|
| 所有电气部件都不工作 | 供电 | 第 7–8 章检查电池、开关和主供电 |
| OLED 显示异常且遥控不能动 | 控制板/底盘 | 保存代码和接线证据；R680 见第 50 章 |
| 遥控能动，ROS 不能动 | 主控通信或 ROS 配置 | 查串口设备、权限、参数和底盘节点日志 |
| ROS 底盘节点在，但里程计不变 | 编码器、协议解析或车型参数 | 第 11、16、32 章 |
| 雷达节点启动但话题无数据 | 设备、端口、驱动或型号参数 | 第 25–26 章 |
相机能被 lsusb 识别但无图像 |
权限、带宽、驱动、分辨率或参数 | 第 20、25 章 |
| 节点很多且报错互相影响 | 同时启动了上层功能或旧进程残留 | 停止全部功能，按本章顺序单项启动 |