说实话多机器人系统的碰撞检测测试是我这几年见过的最容易被低估的一块。单独拿一台机器人出来测避障测试做得再好看都是常态可一旦两三台机器人在同一个仓库里跑起来各种稀奇古怪的相撞、卡死、互相礼让到死锁的状态就会冒出来。最讽刺的是很多团队把大量时间花在调参上却没有一套能回答到底测了哪些碰撞情况、通过标准是什么、跑完能得出什么结论的测试体系。这篇文章想聊的就是把多机器人碰撞检测测试这件事拆开来讲清楚它到底在测什么仿真层怎么做才可信场景怎么设计才不是随机碰运气判定标准怎么设定才不算自欺欺人以及从仿真搬到实机时那些最典型的翻车点。适合正在做多机调度、多机协同导航或者打算上多机项目的工程师和测试同学参考。你不需要先有完整的测试平台跟着这套思路从零搭起也完全可行。1. 先想明白多机器人碰撞检测测试到底在测什么1.1 单机避障测试的成熟套路为什么不通用单机导航的避障测试业内已经玩得很熟了把静态障碍物、动态行人、狭窄通道这些场景摆好看规划器能不能绕过去测一下最小间距和成功率基本就交差了。这套思路搬到多机器人系统上第一反应自然是把其他机器人当成会动的障碍物就行。但我敢说只要你在真实系统里试过一次就会立刻放弃这个想法——其他机器人不是被动的障碍物它们会对你做出反应而你的反应又会被它们感知到双方陷入一种互相猜步子的博弈。举个最简单的例子两台机器人正面相遇A向左避让B也检测到了A的动作出于同样的避让逻辑也向左避让结果两台车反而对上了。这种情况在单机测试里永远不会出现因为静态障碍物不会回应你的动作。单机测试的有效前提是环境状态独立于我的行为而多机系统里这个前提根本不成立。所以多机器人碰撞检测测试的本质是测交互不是测几何。1.2 把多机碰撞拆成三个层次来看我习惯把多机碰撞问题拆成三个层次每一层测的东西、暴露的症状都完全不同几何层机器人的外形表达、包围盒、膨胀半径、代价地图、碰撞形状是否准确。这个层出问题典型症状是明明有空隙却算成碰了或者反过来模型上没碰但实际车身刮了。比如车顶突出来的天线没算进碰撞模型仿真里永远碰不到实机上必挂。运动层双方未来的轨迹是否交叉、TTC碰撞时间是否够长、速度障碍判定对不对。这个层出问题典型症状是每个机器人都在避但预测轨迹还是相交。它考验的是对对方运动状态的预测能力预测用的数据老一秒钟结论就可能完全反过来。协商层谁有路权、谁先走、仲裁规则怎么定、两边的决策协议是否一致。这个层出问题典型症状就是相互礼让死锁、优先级冲突、谁也不肯先走。这三个层次是按决策链从上往下分的。很多团队测试只盯着几何层觉得碰撞检测就是距离够不够结果上了多机之后被协商层和运动层的问题打得措手不及。所以搭建测试体系之前先把你要测的系统涉及哪几个层列清楚再决定用例怎么设计。1.3 组件测试、双机测试与编队测试各管一段多机系统的测试不能只做系统级也不能只做组件级。我的经验是把它分成四档组件测试局部规划器避开静态障碍、通信模块的消息格式和时间戳正确、仲裁规则的单元逻辑正确。这档测的是每个零件没生锈。双机测试两台机器人之间的迎面、交叉、汇入等博弈行为。这一档性价比最高因为碰撞本质上是一个双人事件绝大多数碰撞逻辑问题在双机场景里就能暴露出来。小群组测试三四台甚至五六台机器人一起跑主要看级联效应和连锁避让。比如一台车为了避让A结果把B的路堵死了这种多米诺问题双机测不出来。全编队测试压满系统设计规模看调度压力下的阻塞传播、排队溢出、大面积死锁。建议的投入比例是金字塔形大量仿真双机用例打底小群组和编队场景只保留最核心的几十个实机再从中挑最温和的。很多团队反过来一上来就拉十台真机跑全场景既烧钱又很难定位问题属于费力不讨好。2. 仿真层怎么搭才足够可信环境、通信与感知的三座大山2.1 物理引擎失真碰撞响应比碰撞检测更容易骗人很多人在仿真环境里遇到为什么碰撞检测老是误报的困惑排查到最后发现不是检测算法的锅而是物理引擎的接触响应在捣乱。不同物理引擎对两个物体互相嵌入的处理方式差异很大有的会强行推开、有的会产生微小穿透、有的在特定步长下会让物体直接互相穿过去。如果你用接触响应来反推是否发生了碰撞很容易被引擎的数值行为骗住。我的做法是碰撞检测测试里机器人本体用干净的运动学模型碰撞判定用独立的几何检测模块不依赖物理引擎的回弹效果。这样测的是决策层有没有避免碰撞而不是物理引擎有没有正确反弹。但有一个细节必须较真——模型尺寸要和实机完全一致包括外伸的支架、货架底盘、安全触边这些隐性凸出部分。我参与的一个仓储项目就栽在这上面仿真里给机器人建模时偷懒只画了底盘矩形漏了货架两侧各伸出的五厘米护栏结果实机测试第一周就刮了两次货架而仿真里怎么蹓跶都是绿的。2.2 通信仿真别用共享内存假装无线网这是仿真环境里最大的甜蜜陷阱。很多团队在仿真里让所有机器人直接读写同一份全局状态等效于零延迟、不丢包、不乱序的神级网络。在这种条件下跑出来的多机协同参数调得再漂亮都是假的。等到实机上无线网络一抖动全队的协同立刻失效。正确做法是给仿真引入网络模型而且不能只加一个简单的固定延迟。至少要覆盖几类故障丢包可以按比例丢也可以定向对某台机器人单向丢包。延迟抖动延迟不是常数而是随时间波动模拟无线拥塞。消息乱序后发的消息先到先发的消息后到接收方按什么顺序处理。时钟偏移每台仿真机器人的时钟有微小偏差导致时间戳语义不一致。我后来在仿真里给每台机器人单独维护一个消息缓存每个消息都带时间戳接收方按数据年龄排序并且主动注入过期消息场景。这样一来拿到的数据到底新鲜不新鲜就变成了可以被测试的显式条件。很多在全局共享状态仿真里完全测不出来的问题在这一步原形毕露。2.3 感知仿真别只给激光数据加高斯噪声感知这块的常见误区是给测距数据加上高斯噪声就以为模拟了不确定性。但多机场景里真正致命的是目标级的不确定性也就是检测模块输出的目标列表本身出错而不是单个距离值带点抖动。典型的三种故障漏检另一台机器人明明在视野里检测模块这帧就是没输出它。误检墙上的反光斑被当成了一台机器人产生一个幽灵目标。目标ID跳变同一台机器人在前后两帧里被识别成两个不同的目标轨迹预测瞬间断裂。这些故障在原始传感器层面很难注入但如果你的系统里有一个目标列表接口就可以在接口层做故障注入模拟某台机器人漏检另一台两秒钟、模拟目标位置停留在一秒前、模拟一个虚假的机器人突然出现在走廊尽头。多机协调最怕的不是测距有误差而是那台车我压根没看见或者我看到的已经是它一秒前的位置了。感知仿真建议统一输出为带时间戳的目标列表故障注入层在这个列表层面动手既干净又可控。3. 场景设计从随机撒花到刻意刁难的结构化用例库3.1 先把冲突原型列全随机撒几千个场景跑一遍确实能发现不少意料之外的碰撞但它有两个硬伤一是复现难二是覆盖不完整——没撞上只能说明这次没撞上不能说明这类情况不会撞。所以我的第一原则是先建冲突原型库再谈随机。冲突原型典型场景核心控制参数对向相遇走廊里两台车迎面而行相对速度、避让方向选择交叉路口两条路径垂直交叉到达时间差、交叉角度同向汇入支路汇入主干道汇入角度、主干车速窄口通过单扇门或窄通道只能一车通过门宽、两队调度距离超车变道同向行驶中一侧要超越另一侧速度差、横向间距第三方阻塞两车避让时被第三台车堵住退路第三台车位置、自身状态每个原型都要有基础版和压力版两种基础版本就是标准的、容易通过的场景用来做回归基线压力版则把参数推向极限比如把走廊宽度收到刚好够一车通过、把交叉路口的到达时间差压到零附近逼系统露出破绽。3.2 多机专属的边界用例有些场景是单机测试里完全不存在、但多机系统里极其常见的我把它们单独拎出来重点测完全对称的迎面死锁两台机器人参数完全相同、速度相同、在走廊正中面对面。由于两边决策逻辑完全对称它们可能同时向左避、同时向右避、或者同时停下来等对方形成完美僵持。这个用例几乎是每个多机项目的必翻车项。环形互锁四台机器人首尾相接形成一个环每台都在等前一台让路。单看每一个局部决策都合理全局却卡死了。这是级联问题的入门级示例。感知不对称A能看到B但B被货架挡住看不到A。A以为B会避让自己B压根不知道A存在两台车直奔同一个目标点。通信单向故障B收得到A的消息但A收不到B的消息。两边的世界模型产生分歧仲裁规则可能因此失效。优先级冲突调度系统给两边下了矛盾的优先级指令两边都认为自己有路权互不相让。这些用例的共同点是两边的状态不对称而单机测试里根本没有双方状态这回事。设计场景库时我会专门留一个分区存放这类不对称用例优先级比普普通通的随机场景高得多。3.3 参数化矩阵与覆盖率场景库建好之后下一步是参数化。与其生成海量完全随机的场景不如定义几个关键维度做有控制的组合扫描速度比0.5x / 1x / 2x交角30°/ 60° / 90° / 150°通信延迟档位0ms / 100ms / 300ms / 丢包5%感知故障档位无故障 / 漏检1秒 / 位姿延迟1秒机器人数量2 / 3 / 4 / 6参数组合会爆炸所以要控制先固定一组默认参数单维扫描一遍再挑出最有价值的十到二十个组合做双维扫描最后加一批随机种子做压力翻腾。每次跑测试固定用同一批随机种子保证可复现。另外我强烈建议留一个未知集——一批随机生成的、从不入库的新场景专门用来检测测试库是否过拟合。如果你在未知集上的失败率明显高于入库场景说明你的系统已经把库里场景背下来了但还没学会处理新情况。4. 判定指标与通过口径别让全绿骗了你4.1 一套可用的指标组合碰撞检测测试的成绩单不能只有撞了没撞这一个二进制结果。我实际用的指标组合是这样指标计算口径主要回答的问题碰撞次数几何模型发生接触的次数最基本的及格线最小间距任意两台机器人之间的最小几何距离本次测试有多悬TTC最低值按当前速度和轨迹推算的碰撞时间最小值系统是否在危险的边缘试探协商避让触发次数因对方存在而改变原规划的次数避让行为是否过度或不足死锁/停滞累计时长系统无进展的总时间系统是否会安全地卡死任务完成率在规定时间内到达目标点的比例安全是否以效率为代价只看碰撞次数是最容易骗自己的。我见过一个项目测了三千个仿真场景零碰撞团队很高兴后来发现这个系统的策略是只要检测到任何其他机器人离老远就原地停下等人走。零碰撞是真的任务完成率接近零也是真的。一个场景跑了十分钟两台车隔着八米互相观望系统宣布安全通过——这种通过毫无意义。4.2 通过口径零碰撞只是及格线我推荐的通过口径分三档第一档硬指标全程无几何接触无危险接近最小间距大于安全阈值比如车身宽度的一半TTC最低值大于设定阈值比如0.5秒。第二档软指标发生危险接近或TTC过低时系统有合理响应比如主动减速、急停、重新规划且没有造成二次危险。这类事件不能算测试失败但必须人工审查确认当时的决策链路是合理的。第三档效率指标完成率、绕行率、死锁时长在可接受的范围内。另外要注意阈值不能一刀切。窄通道场景本来就要求低间距通过你给它设一个0.5米的最小间距指标等于逼着系统永远不敢进窄门。所以我的习惯是安全阈值按场景类型分档狭窄类场景多盯TTC和通过姿态开阔类场景多盯最小间距。4.3 回归基线与随机种子多机系统的代码一直在改调度策略在改、避让参数在改、通信协议也在改。没有回归基线你根本不知道这次改动是变好了还是变坏了。我建议把入库场景集做成回归基线每次改动后全量重跑然后对比指标分布而不是只对比通过了几个。随机种子管理也是硬功夫。仿真必须固定种子否则同一个场景每次跑出来的行为都不一样排查问题的时候你根本分不清这次失败是新问题还是老问题。我的工具里会给每次测试生成一个配置存档场景库版本、随机种子、代码版本、参数文件哈希全部打成一个标签。这样任何一次失败都能精确复现而不是靠再跑一次碰运气。5. 实机迁移仿真全绿、实机全红的典型翻车链5.1 定位漂移与坐标系误差仿真里的机器人位姿是直接从仿真器读的精确到毫米。实机完全不是这么回事——轮子打滑、里程计漂移、激光匹配误差随便就是几厘米到十几厘米的误差。一台宽度三十厘米的机器人定位漂移十厘米名义间距零点四米实际可能只剩零点二米安全余量直接腰斩。多机系统还会放大这个问题。如果A把B的位姿通过坐标变换放到自己的局部坐标再做决策每一次变换都会叠加误差如果两个机器人各自的坐标框架本身还有偏差那B在哪这件事在A看来就是一个带误差估计的模糊概念。我在实机上吃过这个亏之后强制定了两条规矩第一所有机器人上报的位姿统一转换到全局坐标系不在局部坐标里做跨机决策第二每个位姿消息必须带采样时间戳决策时按数据年龄动态扩大对对方的膨胀半径——数据越老膨胀越大。这相当于把不确定性和数据陈旧度直接换算成安全距离。5.2 通信的假同步陷阱实机上的无线通信不像仿真里那么听话。最隐蔽的问题是假同步——两边看起来都在跑同一套协同逻辑实际上由于时钟偏移A认为的现在和B认为的现在根本对不上导致两边对同一事件的先后顺序判断完全相反。举个具体场景A发送我已通过路口的消息B在两百毫秒后才收到但B的时钟比A慢了五十毫秒于是B认为这个消息是在它自己决定进入路口之后才发生的逻辑上产生了先后矛盾。解决办法分几步首先消息里必须携带数据采集时刻而不是发送时刻这能避免发送延迟被误判为感知延迟其次接收方要对消息做陈旧度检查超过一定年龄的数据直接丢弃或标记为过期决策模块必须明确处理没有新数据的情况最后在仿真里就必须把时钟偏移建模进去不要等到实机才第一次面对它。5.3 用少量真机做大量测试真机动辄上万块谁都不可能买三十台来做测试。更现实的方案是混合仿真场地里跑N台真机同时注入M台虚拟机器人虚拟机器人的位姿通过目标列表的形式喂给真机的感知模块真机的行为也通过仿真器的反馈回路影响虚拟机器人。这样用两到三台真机就能模拟出接近全编队的对抗压力。但混合仿真有它的顺序讲究。我的建议是从纯仿真出发逐步增加真机比例每一步都要确认前一步的结果稳定再往前走。真机数量不清零的情况下先在低速下验证安全兜底再把速度往上提。场地侧必须有围栏、急停按钮、限定活动区域至少一位安全员在场地内盯着所有可能出危险的参数先在仿真里摸清边界。从仿真已验证的场景里挑温和版先上实机千万别把压力版的极限场景直接搬到实机——那是拿设备当鞭炮放。6. 高频踩坑案例与一条可复用的排查链路6.1 死锁不是碰撞却是更贵的失败我在前面提过很多团队把零碰撞当作成功但多机系统里真正的隐形杀手是死锁和活锁。死锁是两台车面对面僵住谁都不动活锁是两边都在动但一直在绕圈永远到不了目的地。这些状态不触发任何碰撞告警看起来安全得很其实整个系统已经瘫痪了。这类问题的排查有一个很反直觉的点它经常不是避让策略的参数问题而是仲裁协议的逻辑问题。比如两台的优先级判断依赖对方上报的位姿而位姿在走廊里因为退化特征抖动了一下导致优先级反复翻转两边的决策也跟着反复翻转。建议在测试里加一个停滞检测模块任何机器人如果在规定时间内位姿变化小于阈值且视野里存在其他机器人就触发告警事件。这个事件要单独统计不混在碰撞指标里。6.2 误报与漏报的定位方法碰撞检测系统本身也是会出错的而且误报和漏报的排查路径完全不同。误报常出在几何层碰撞形状参数错、坐标系用错、把对方机器人当成静态障碍来算距离。漏报则常出在数据链路决策模块拿到的是过期位姿检查器判定安全通过的时候对方其实已经移动到了碰撞位置。定位这类问题靠眼神盯日志是盯不出来的。我的做法是把每个机器人的日志按时间线拆成三段感知输出、规划器状态、协商协议决策。每一条都带上统一的时钟戳。碰撞或者危险接近发生时回放决策那一刻三个模块各自的状态重点关注规划器做决策那一刻它看到的对方位姿是老多久以前的。我定位过的最典型的一类问题就是规划逻辑完全正确但它输入的是四百毫秒之前的旧数据这在共享内存仿真里永远测不出来因为那里的数据永远是新鲜的。6.3 排查链路五步法踩的坑多了以后我总结出五步排查法现在遇到什么诡异碰撞或者死锁都按这个顺序走复现同一个随机种子、同一个场景参数、同一个代码版本先把问题稳定复现出来。复现不了的问题先不修改成先补日志。最小化把场景缩到最简单的形式通常是两台机器人在直线走廊里对向或同向行驶去掉第三方干扰、去掉复杂地形直到能用最小场景稳定触发问题。分层排除按几何层、运动层、协商层、通信层、感知层的顺序逐个排除。每一层单测一遍确认是这一层的问题再深入千万不要跨层猜。根因定位定位到具体是哪个模块、哪个条件分支、哪条数据链路出了问题。修复并入库回归修完之后把最小化场景升级成一个正式入库的用例加进回归基线防止以后复发。这套链路看起来简单但贵在纪律性。我见过太多团队跳过了第1和第2步直接对着第3步的经验猜原因结果修了三天发现改的是没问题的模块回头才看见真正的原因是通信掉了一帧。6.4 日志与回放是我最不后悔的投入最后说一个听起来不性感但性价比极高的建议把日志系统和回放工具当一等公民来建设。每次跑测试都完整记录场景配置、随机种子、代码版本、所有机器人的位姿时间线、通信消息记录、感知目标列表。然后做一个即时回放小工具能够逐帧回放碰撞发生前或危险接近前最后十秒钟的现场。这个工具不需要多花哨能按时间轴拖动、能看到每台机器人的感知目标和规划轨迹就够了。真正排查的时候它比任何高级调试器都管用——因为多机问题本质上是时间和空间上的多方博弈静态看日志只能看到一行行单个模块的输入输出永远看不到双方在同一个时间点上的互动关系。就我个人实际操作的体会来说多机器人碰撞检测测试的核心资产不是那套测试代码也不是那几台机器而是你的场景库和日志回放能力。场景库决定了你能发现什么类型的问题日志回放决定了你发现问题之后能不能快速定位。我后来换了一个更大的项目机器人数量翻了三倍第一件事就是把场景库和回放工具原封不动搬过去后面的测试工作几乎没有重新摸石头过河。如果你正准备给多机系统搭测试环境我建议先把日志回放和种子管理这两件事做好再开始堆场景顺序别反了。