5.3 仿真与测试

5.3 仿真与测试

本节摘要：真机调试又贵又慢又危险，仿真先行是行业铁律——但"仿真通过"与"实机能用"之间隔着一张差距清单。本节讲仿真平台的能力边界、仿真测试金字塔怎么搭，以及把差距管理成流程的方法。

一次没有仿真的代价

某团队的新 AMR 跳过仿真直接上实机联调。第一周烧了两件事：避障参数没试错空间，机器人以 0.8 m/s 撞上货架，激光雷达支架变形，标定作废重来；测试进度全卡在"排队等场地"——真机测试必须占用真实仓库，晚上才排得上。第三周团队补建了仿真环境，参数调试、死锁复现、异常注入全部在虚拟仓库里过完，真机只做确认性测试，整体进度反而提前。这笔账背后的逻辑是：仿真的价值不在"像真"，而在"可重复、可加速、可失败"——仿真里撞一百次不要钱，真机撞一次就是一周。

平台能力与边界

Gazebo、Isaac Sim、Webots 是三个常被选用的平台，能力侧重不同：Gazebo 与 ROS 集成最深，社区资产丰富，适合常规导航与机械臂项目；Isaac Sim 的渲染与物理保真度高，适合视觉 AI 与大规模并行训练；Webots 轻量，教学友好。选型看三条：与自家中间件的耦合度、传感器仿真的保真需求、以及算力预算——渲染级真实感的代价是 GPU 账单。

传感器仿真各有真实的精度边界，写测试前要知道：

规律：几何与运动学仿真可靠，物理化学与制造偏差仿真不可靠。这个规律决定了仿真与实机的分工边界。

仿真测试金字塔

借鉴软件测试金字塔，机器人系统的验证分四级，越往下越多：

• 单元级（数千次/日，纯计算）：单个函数或模块在回放数据上跑。A* 在标准栅格集上的最优性检查、卡尔曼滤波在合成轨迹上的误差统计。没有机器人什么事，秒级反馈。
• 模块级（每日，仿真）：单个模块在仿真环境里跑。定位模块在虚拟仓库的固定脚本里运行，检查漂移指标；局部规划器对着注入的动态障碍跑一千种遇人脚本。
• 系统级（每周，仿真+少量实机）：整机在仿真里跑任务脚本，含异常注入——"SLAM 中途失明""雷达拔线""任务中途改目标"。实机只跑冒烟测试：启动、慢速走线、急停。
• 现场级（里程碑，实机）：真实场地真负载跑完整业务流。这一级是验收而非调试，进这一级前仿真里必须全绿。

def smoke_test_sequence(robot):
    """现场冒烟测试序列：宁可慢，不可跳"""
    robot.enable_safety()                    # 1. 安全链路最先验证
    assert robot.estop_fires_within(0.2)     # 急停响应 200 ms 内
    robot.set_speed_limit(0.2)               # 2. 首次运动限速
    robot.goto(marker_a, timeout=30)
    assert robot.pose_error_to(marker_a) < 0.10   # 到点精度 10 cm
    robot.block_path_with_box()              # 3. 注入静态障碍
    assert robot.avoids_and_replans(timeout=60)
    robot.restore_full_speed()
​

图：从单元到现场的验证金字塔

管理仿真与实机的差距

差距不是用来消除的，是用来管理的。四条实踐把差距变成流程的一部分：参数同源（仿真与实机共用同一套配置文件，防止"仿真里调好的参数忘了同步"）；差距清单（每次实机暴露的仿真没复现的问题，记录成因——玻璃反射、轮子打滑——评估该补进仿真还是该设为实机专属测试项）；保守降速惯例（仿真里验证过的行为，实机首跑按五折限速）；回放文化（实机传感器数据全程录制，任何现场问题先在回放里复现，再进仿真修复）。

⚠️ 常见坑：仿真过度调参。把参数在虚拟世界的物理里调到极限，实机上因为摩擦与延迟不同全线失效。参数整定以实机数据回放为准，仿真只负责范围与方向的探索。

本节要点

• 仿真的核心价值是可重复、可加速、可失败；几何运动学可靠、材料与制造偏差不可靠。
• 四级金字塔：单元回放、模块仿真、系统仿真加实机冒烟、现场验收，越往下越频繁。
• 传感器仿真的边界要背下来：玻璃、雾滴、振动、磨损是仿真盲区，留给实机专项。
• 差距管理四件套：参数同源、差距清单、保守降速、回放文化。

异常注入清单：把"万一"变成脚本

仿真的独特能力是注入现实里难以复现的异常。一份值得抄走的注入清单：感知类——雷达中途断流三秒后恢复、点云加高斯噪声、定位置信度阶梯下降；执行类——轮子打滑（里程计虚报）、电机单侧降功率、编码器卡死在旧值；系统类——网络丢包 20%、某节点重启、控制周期抖动两倍；环境类——动态障碍突然横穿、门被堵死、地面反光区。每个异常配一个预期行为断言（"雷达断流期间机器人应在三秒内减速停驻"），写进自动回归脚本。异常注入的哲学与单元测试相同：在问题便宜的时候暴露它——仿真里的一次断流测试，成本是真机事故的万分之一。

仿真进持续集成的门槛

把仿真测试挂进持续集成流水线，是团队工程化的分水岭。最低配置：每次代码合入，自动跑单元级回放测试与一个标准场景的仿真冒烟（建图、导航到三个点、避障各一遍），十分钟内出结果。进阶配置：夜间跑完整金字塔（单元加模块加系统级异常注入），早晨看报告。两条工程经验：一是仿真场景要带"金标准"断言（路径长度、耗时、最小离障距离的上下界），没有断言的仿真只是动画；二是仿真环境的 Docker 化——环境不一致造成的"我这里能跑"争论，在机器人团队里的发生率与纯软件团队一样高。

问题：仿真与现实的时间不一致怎么办

仿真可以加速（跑得比真实快十倍）也可以减速（逼真但慢），而机器人代码里若写死了"每秒一次"这类墙钟时间，加速仿真立刻失真。规范是从第一天起用仿真时钟：所有节点的定时、超时、日志时间戳统一取仿真时间源，物理时间只留给与外界的真实交互。切换成本在项目早期几乎为零，中期以后接近于重写——这也是"仿真先行"要在架构期就确立的原因之一。