系列：机器人巡检仿真——从方法到可验收实现（00/10）
定位：以真实电厂机器狗巡检项目为贯穿案例，提炼可迁移的机器人巡检仿真开发方法。
适合读者：机器人、自动化、计算机、电子信息等专业学生，以及准备进入 ROS 2、机器人软件、仿真、导航或测试方向的求职者。

为什么会有这个系列

这个系列源于一个真实的工程问题：如何搭建一套可重复、可量化、可扩展的机器人巡检仿真平台，用于验证机器人在电厂场景中的定位、导航、避障、任务执行和安全能力。

电厂内通常分布着仪表、设备、管线、墙体和狭窄通道。机器人巡检并不只是“让一个模型在三维场景里走起来”，它至少需要形成下面这条闭环：

用户创建巡检路线
→ 仿真器生成 RTK、IMU、LiDAR 等传感器数据
→ 定位和导航算法计算运动指令
→ 机器人绕开障碍并依次到达巡检点
→ 到点后执行巡检动作
→ 系统处理碰撞、超时和传感器故障
→ 保存轨迹、事件、真值和评测指标

如果其中任何一个环节只是“看起来存在”，没有真正参与前后因果关系，那么系统即使能够演示，也不一定能够证明算法可靠。

贯穿系列的项目是什么

案例项目第一阶段采用以下技术组合：

Gazebo Harmonic
+ ROS 2 Jazzy
+ Nav2
+ robot_localization
+ RViz

它们分别承担：

• Gazebo：电厂场景、机器人运动、物理碰撞和传感器生成；
• ROS 2：节点、消息、服务、动作和坐标变换的通信骨架；
• Nav2：地图导航、路径规划、局部避障和速度指令计算；
• robot_localization：RTK、IMU 和里程计等定位数据的融合；
• RViz：地图、机器人、点云、TF、航点和路径的可视化调试。

项目没有在第一阶段同时实现完整四足步态，而是使用具有机器狗外形和碰撞尺寸的简化运动代理，优先验证上层巡检导航闭环。

这项选择不代表四足动力学不重要，也不代表简化模型能够证明足端接触和步态可靠。它代表一种工程顺序：先明确当前要验证的结论，再决定哪些组件必须真实、哪些可以代理、哪些暂时不属于能力声明。

这个项目实际遇到了什么

如果只是运行官方示例，很多系统级问题不会出现。进入真实集成后，我们陆续遇到了：

• 仿真时间与 TF 数据不同步；
• 点云把机器人自身识别成障碍物；
• 轮轴方向错误连锁影响位姿、GPS 和导航；
• RTK、IMU 与里程计如何分工和融合；
• 地图、odom 与 base_link 坐标责任不清；
• 控制器退出后如何保证机器人停止；
• 任务取消后如何处理迟到的导航结果；
• 一次成功怎样转化为可重复的验收结论；
• 如何通过故障注入验证真正的安全行为。

这些问题横跨模型、通信、时间、坐标、定位、导航、安全和测试基础设施。它们也让我们意识到：机器人巡检仿真真正困难的部分，往往不是某一个算法，而是多个模块能否在同一套时空、接口和失败规则下形成闭环。

这个项目已经证明了什么

核心巡检导航 POC 最终完成了 137 项单元测试，以及一组覆盖正常、边界、故障和稳定性的系统测试，包括：

• 单点导航；
• 五航点连续巡检；
• 静态障碍绕行；
• 狭窄通道通过；
• RTK、IMU 和里程计融合定位；
• 点云中断与 TF 超时处理；
• 控制器退出后的安全停车；
• 导航取消与任务重置；
• 多次重复运行稳定性；
• 真实障碍物碰撞停止。

这些证据能够证明定义范围内的导航巡检闭环已经形成，但不能证明：

• 完整四足步态稳定；
• 关节和足端控制可靠；
• 机器人能够通过楼梯和复杂非平整地形；
• 所有真实电厂环境都已经被覆盖；
• 仿真结果可以不经实机验证直接用于生产。

明确“证明了什么”和“没有证明什么”，也是这个系列反复强调的工程习惯。

为什么不把它写成项目开发日志

这个系列不会按照 Git 提交顺序记录“某天增加了什么文件、修复了什么参数”。开发流水账只能复述一个项目，很难帮助读者迁移到自己的场景。

我们更关心的问题是：

从这个具体项目中，可以提炼出哪些适用于其他机器人巡检仿真的开发方法？

因此，电厂机器狗巡检承担三个角色：

1. 实现案例：展示方法怎样落到真实代码、配置和系统接口；
2. 问题来源：提供真实故障，而不是凭空设计的教学问题；
3. 验证证据：用测试结果证明方法是否真正有效。

系列真正讨论的是一套能够迁移到园区、仓库、变电站、矿井、管廊等场景的方法：如何定义验证目标、选择仿真精度、设计系统闭环、隔离非目标复杂度、定位跨模块故障，并最终形成可重复验收的证据。

文章的路线图

章节	核心问题	读者将获得什么
01	机器人仿真到底要证明什么	验证主张、真实性契约与 POC 范围
02	巡检任务如何形成完整闭环	任务、感知、定位、导航、控制和评测架构
03	怎样构建场景、地图和机器人	Gazebo 场景、SDF/URDF、碰撞体与运动代理
04	为什么时间和坐标系经常导致系统失效	/clock、TF、map、odom 和传感器时间戳
05	怎样完成多航点自主巡检	Nav2、路线编辑、Action 和任务状态机
06	机器人怎样知道自己在哪里	RTK、IMU、里程计、定位融合与真值隔离
07	传感器或控制器失效时怎么办	安全监控、超时检测、碰撞停止与故障注入
08	如何定位跨模块的复杂故障	最小复现、根因分析、轮轴错误案例与回归测试
09	怎样证明系统不是偶然成功	MCAP、指标、测试矩阵、重复运行与最终验收
10	怎样完成整个项目的总结与复盘	架构回顾、验收证据、能力边界与后续演进

每一篇都会采用相同的组织方式：

提出一个通用工程问题
→ 给出可迁移的方法
→ 用本案例落地
→ 展示真实故障或测试证据
→ 说明如何迁移到其他巡检项目

怎样阅读这个系列

如果你刚开始接触机器人仿真，建议按照 01～10 的顺序阅读。前几篇会建立系统闭环、时间、坐标和导航等基础概念，后几篇进入安全、故障排查和验收。

如果你已经使用过 ROS 2、Gazebo 或 Nav2，也可以直接从感兴趣的问题进入：

• 想理解项目范围与仿真真实性：从第 01 篇开始；
• 经常被 TF 和时间问题困扰：阅读第 04 篇；
• 正在做多航点任务：阅读第 05 篇；
• 关注定位融合：阅读第 06 篇；
• 关注安全与故障注入：阅读第 07 篇；
• 想学习复杂问题排查：阅读第 08 篇；
• 想建立测试和验收体系：阅读第 09 篇。

这个系列不会要求读者一开始就掌握所有术语。RTK、IMU、TF、/cmd_vel、Nav2、robot_localization、RViz 等概念，会在第一次承担关键作用时进行解释。

系列的基本原则

贯穿十篇文章的核心原则可以概括为：

先定义验证主张
→ 再选择需要的真实性
→ 先建立因果闭环
→ 再决定哪些组件可以代理
→ 最后用验收证据约束能力声明

第一篇将从其中最重要的问题开始：

面对一个复杂的机器人仿真项目，我们应该优先追求“更逼真”，还是先明确“需要证明什么”？

点击开始第一篇学习：《机器人仿真的第一原则：先决定你要证明什么》