1. 障碍物为什么要分三类来做在仿真环境里搭场景很多人第一步就卡在往世界里扔障碍物这件事上。扔几个箱子谁都会但真正跑算法的时候你会发现障碍物的行为模式直接决定了你的仿真结果有没有参考价值。我在做移动机器人路径规划和避障测试的过程中慢慢把一个看起来很随意的操作拆成了三类移动障碍物、随机障碍物、固定障碍物。这三类不是随便分的它们各自对应算法验证中完全不同的测试目标。固定障碍物解决的是地图结构问题。它相当于环境里的静态先验用来构建代价地图的基础层验证你的定位、建图、全局路径规划在已知静态环境下是否正常。移动障碍物解决的是动态响应问题考核的是局部规划器的实时重规划能力、预测模块的跟踪精度以及机器人在狭窄通道内面对对向来物时的决策鲁棒性。随机障碍物解决的是泛化能力问题用可控的随机性批量生成不同的场景布局避免你的算法过拟合在某一套手工摆出来的场景上。所以这篇内容想讲清楚的事情很具体在常见的机器人仿真环境里怎么用几种不同思路分别把这三类障碍物生成出来每种方式背后的实现逻辑是什么参数怎么调什么时候该用哪一种。适合已经能跑通基础仿真、开始正经做算法评测的读者如果你只是想摆个箱子看看模型能不能动前面的基础部分也能直接用。需要提前说明一点下面的方法都是我实际操作中反复用过、比较稳的路线涉及具体参数的地方会给出数值但这些数值是基于常见机器人尺寸和常见传感器范围的经验值换到你的场景需要按比例调整。这也是仿真工作最容易被忽略的地方参数不是抄来的是算出来的。1.1 三类障碍物的职责边界对比先把三类的差异摊在表里看清楚后面所有操作都是围绕这张表展开的。类型核心职责典型实现方式关键参数适用阶段固定障碍物构建静态地图结构、验证全局规划世界文件里直接定义模型位姿、尺寸、朝向建图、全局规划调试移动障碍物验证动态避障与重规划控制器插件驱动、外部脚本驱动速度、轨迹点、周期局部规划、预测模块随机障碍物批量生成场景、评估泛化性脚本按分布采样后注入数量、分布范围、间距阈值回归测试、参数寻优这张表最值得注意的一列是关键参数。固定障碍物的核心是位姿和尺寸因为它是地图的一部分移动障碍物的核心是速度和轨迹因为它是时间维度的东西随机障碍物的核心是分布范围和间距约束因为随机不等于随便两个障碍物叠在一起或者把机器人出生点堵死这个场景就废了。我见过不少人在随机生成这一列踩坑只写了随机采样没写最小间距和禁入区结果跑一百次场景里有三十次机器人一开始就被卡在障碍物里面仿真直接报碰撞白跑一轮。所以后面讲随机生成的时候间距检测和出生点保护这两个细节会重点展开。1.2 先确认你的仿真世界文件结构不管用哪种方式最后都落到世界文件的模型列表里。一个典型的世界文件包含物理引擎配置、光照、地面然后是若干个模型条目。固定障碍物就是在这里硬编码移动障碍物是模型条目加上控制器配置或者外部驱动的话题随机障碍物是脚本在启动前生成这个列表或者运行时动态插入。理解这个结构很关键因为它决定了你选哪条路。如果障碍物在仿真开始后完全不需要变化写进世界文件是最省事的加载快、可复现、不用额外进程。如果障碍物要动就必须挂控制器或者由外部节点持续发布状态。如果要随机就必须有一个生成器在仿真启动前介入因为世界文件一旦加载静态部分就固定了。这三条路的边界清楚之后就不会出现我想让固定障碍物随机出现但又想让它动这种自相矛盾的需求了。真需要动态随机那是移动障碍物加随机初始化位姿属于两条路的组合实现上分两步走。2. 固定障碍物世界文件里硬编码的正确姿势固定障碍物是最容易被低估的一类。很多人觉得不就是往文件里贴几段模型定义吗但实际上位姿写错一个符号、碰撞体尺寸和视觉模型不匹配后面调试会浪费大量时间。这一节把从零添加一个固定障碍物的完整过程拆开讲。2.1 模型条目的最小完整结构一个能正常参与碰撞计算的固定障碍物至少需要三部分视觉部分、碰撞部分、惯性部分。视觉部分决定你在界面里看到什么碰撞部分决定物理引擎怎么算惯性部分决定它被撞到时的反应。三者可以不一致但建议保持几何一致否则会出现看起来没碰到但物理上已经撞了的诡异现象。一个方块障碍物的典型结构如下这是最常见的写法用基本几何体而不是外部网格文件加载快、不用管路径问题model namefixed_box_01 statictrue/static pose3.0 1.5 0.25 0 0 0/pose link namelink collision namecollision geometry boxsize0.5 0.5 0.5/size/box /geometry /collision visual namevisual geometry boxsize0.5 0.5 0.5/size/box /geometry material ambient0.6 0.6 0.6 1/ambient diffuse0.6 0.6 0.6 1/diffuse /material /visual /link /model几个关键点值得单独说。statictrue/static这一行是固定障碍物的本质它告诉物理引擎这个物体不参与动力学积分位置永远不会变计算开销极低。如果你漏了这一行它会被当成动态物体虽然没受力不会动但每帧都要参与碰撞检测和积分场景里放几十个之后帧率会明显下降。pose里的六个数字是x y z roll pitch yaw。最容易错的是 z 值。一个边长 0.5 的立方体中心在 z0.25 时底面刚好贴地。如果你写 z0它会有一半埋在地面以下视觉上看起来矮了一截碰撞检测也可能出问题。这个高度等于尺寸一半的规则对所有贴地放置的几何体都成立圆柱是高度一半球体是半径。2.2 用循环批量生成固定障碍物的脚本思路手工写十个八个还行写几十个就容易出错而且改布局要一个个改效率极低。我的做法是用脚本生成世界文件里的模型片段再拼接到模板里。这样布局参数集中在一处改一个数就能整体平移或缩放。下面这段是生成一排墙式障碍物的脚本逻辑很简单给定起点、数量、间距、尺寸输出对应的模型 XML 片段。def gen_wall(start_x, start_y, count, spacing, size, axisx): pieces [] for i in range(count): if axis x: x start_x i * spacing y start_y else: x start_x y start_y i * spacing z size[2] / 2.0 pieces.append(f model namewall_{axis}_{i} statictrue/static pose{x:.3f} {y:.3f} {z:.3f} 0 0 0/pose link namelink collision namecollision geometryboxsize{size[0]} {size[1]} {size[2]}/size/box/geometry /collision visual namevisual geometryboxsize{size[0]} {size[1]} {size[2]}/size/box/geometry /visual /link /model) return .join(pieces)调这段代码的时候有个细节spacing必须大于size[0]沿 x 排列时否则相邻方块会重叠。重叠的静态物体在物理上不算错但视觉上会有一道缝而且如果你的算法按障碍物边界做膨胀重叠区域的膨胀会算重影响代价地图的准确性。我一般让间距等于尺寸加 0.02 到 0.05 的缝隙既保证是独立障碍物又不会留太宽的通道让机器人钻过去。还有一个经验给每个模型起名字的时候带上坐标或者序号比如wall_x_0、wall_x_1。仿真跑起来之后如果发现某个位置不对你从日志或者可视化标记里能直接定位到是哪个模型而不是对着一堆obstacle发懵。2.3 固定障碍物的碰撞体简化原则这是我想重点讲的一块因为它是性能和质量的分水岭。固定障碍物数量一多碰撞检测就是主要开销。原则是视觉可以精细碰撞必须简单。举例来说一个复杂的桌子模型视觉上用网格文件甚至带纹理都没问题但碰撞体用几个长方体拼出来就够了不需要跟视觉完全一样。更进一步如果是贴墙的装饰性物体碰撞体甚至可以简化成一面薄板。物理引擎算的是碰撞体的相交和视觉模型无关。具体操作上可以在同一个 link 里放多个 collision用不同几何体拼出近似形状视觉部分单独用网格。这样做的收益在场景规模上百个物体时非常明显。我做过对比一个包含约八十个固定障碍物的场景碰撞体用网格文件时仿真实时率大概在 0.6 左右全部换成简单几何体后能到 0.95 以上。这个差距直接决定你一次回归测试是跑半小时还是一小时。另外要注意静态物体的惯性部分其实可以省略因为不参与动力学。但如果你的工具链里有检查脚本会报缺失补一个也行不影响性能。3. 移动障碍物让障碍物按预期轨迹动起来移动障碍物是三类里最容易做错的一类。错的地方往往不是动不起来而是动得不符合预期速度忽快忽慢、转弯处瞬移、轨迹和机器人规划器的预测模型对不上。这一节从两种驱动方式讲起然后说清楚怎么让运动平滑可控。3.1 运动学驱动与插件驱动的选择移动障碍物有两条主流实现路线。第一条是运动学驱动直接把物体设为运动学状态由外部程序每帧写入新的位姿。第二条是插件驱动在模型上挂一个控制器插件插件内部按轨迹或者按速度指令更新位姿。两条路的差别在于控制权在哪。运动学驱动的好处是简单直接你在外部脚本里完全掌控位姿想走什么轨迹就走什么轨迹甚至可以从录制的真实数据回放。缺点是外部脚本的运行频率如果和仿真步长不匹配会出现抖动或者位姿跳变。比如仿真跑 1000Hz外部脚本只有 20Hz那两次更新之间物体会保持不动看起来就是一卡一卡的。插件驱动的好处是更新在仿真线程里时间同步天然准确运动平滑。缺点是要写插件或者配置现成插件灵活性稍差复杂轨迹需要事先定义好。我的建议是做算法评测、需要精确可复现的轨迹时用插件驱动做快速原型、轨迹来源是外部数据或者临时计算时用运动学驱动。两者不是互斥的同一个场景里可以混用比如主要干扰物用插件跑固定轨迹次要干扰物用脚本随机游走。3.2 运动学障碍物的位姿写入要点用外部节点写位姿的时候最常踩的坑是用了绝对位姿覆盖而不是增量更新或者更新频率和仿真对不上。下面这段示意代码用定时器按固定周期写入位姿位置沿直线往返import math class KinematicMover: def __init__(self, set_pose_fn, start, end, speed): self.set_pose set_pose_fn self.start start self.end end self.speed speed self.t 0.0 self.length math.dist(start, end) self.period 2.0 * self.length / speed def on_tick(self, dt): self.t (self.t dt) % self.period half self.period / 2.0 ratio self.t / half if self.t half else (self.period - self.t) / half x self.start[0] (self.end[0] - self.start[0]) * ratio y self.start[1] (self.end[1] - self.start[1]) * ratio self.set_pose(x, y, self.start[2], 0, 0, 0)这里的关键是用累计时间而不是每次加固定步长来算位置这样即使回调有抖动位置也不会漂移。另外速度参数要和机器人的最大速度匹配如果你的机器人巡航速度是 0.5m/s障碍物也跑 0.5m/s那两者的相对运动几乎为零测试不出避障能力。我一般把移动障碍物速度设在机器人速度的 0.3 到 0.8 倍之间正面对向时取低值横向穿越时取高值这样才能覆盖来得及躲和来不及躲两种边界。还有一点容易被忽略移动障碍物的更新必须走物理引擎认可的接口。直接改模型位姿在某些实现里会绕过碰撞检测的更新导致视觉上物体过去了但碰撞体还在原地。正确做法是确认你用的接口会触发碰撞体同步或者干脆用插件在物理步内更新。这个坑我踩过一次排查了两个多小时最后发现是接口用错了。3.3 用轨迹点串起复杂运动直线往返只能测最简单的场景。真正考验局部规划器的是突然从侧方插入在狭窄通道内掉头绕着一个固定障碍物转圈这类运动。这些用参数化轨迹写起来麻烦用轨迹点串最直观。轨迹点的方式是给定一串带时间戳的位姿运行时按时间插值。优点是轨迹形状完全可控可以录真实行人轨迹回放缺点是轨迹之间不连续时需要处理。我一般用线性插值加朝向单独计算位置插值保证平滑朝向按速度方向算避免朝向突变导致雷达点云分布跳变。轨迹设计上有几个实用套路。侧向插入让障碍物从机器人规划路径的侧方以垂直方向穿过时间点设在机器人预计到达该位置前后用来测试预测模块是否提前减速。对向接近在狭窄通道里从对面驶来速度取机器人速度的一半左右测试让行决策。环绕运动绕某个固定障碍物做圆周运动半径略大于机器人安全半径测试在动态障碍物附近的通过能力。每种轨迹都建议跑多组参数比如侧向插入的提前量设三个档位机器人到达前 0.5 秒、1 秒、2 秒。提前量太小时机器人来不及反应是正常的这组数据恰好能标定你算法的反应边界比单跑一组能过的场景有价值得多。4. 随机障碍物可控的随机才有评测价值随机生成这一块最容易出现的问题是把随机理解成乱来。真正有用的随机生成是带约束的采样数量在区间内、位置在可行区域内、相互之间保持最小间距、不侵占机器人出生点和目标点、不把通道完全堵死。约束设计得好一百次随机场景跑下来能覆盖到各种难度约束设计不好一半的场景是废的。4.1 采样区域的划分与禁入区设置第一步是把世界划分成区域。至少要划出三类可行采样区、禁入区、通道保留区。可行采样区是障碍物可以出现的地方禁入区是机器人出生点周围一圈、目标点周围一圈半径建议不小于机器人外接圆半径加安全距离我一般取 1.0 到 1.5 米通道保留区是连接出生点和目标点的走廊障碍物可以进入但不能完全封死实现上限制该区域内障碍物的密度或者保证至少有一条宽度大于机器人直径的通路。具体实现时用一个矩形列表描述可行区采样时先在整个包围盒里随机取点再判断是否落在可行区内、是否在禁入区内。这个先随机再过滤的方式比直接在多边形内采样好写效率也够用一般拒绝率不超过一半就不需要优化。import random def sample_position(region, forbidden, min_dist, placed, max_tries200): for _ in range(max_tries): x random.uniform(region[0], region[2]) y random.uniform(region[1], region[3]) if any(dist((x, y), f) f[2] for f in forbidden): continue if any(dist((x, y), p) min_dist for p in placed): continue return x, y return Nonemax_tries这个参数别设太大设成 200 左右返回 None 就说明这个区域在当前数量下已经放不下了应该考虑减少数量或者扩大区域而不是硬试。我见过有人设成 10000结果场景生成阶段卡死还以为是脚本有 bug。4.2 数量、尺寸与分布的参数化随机场景的价值在于批量覆盖所以参数必须外置成配置不能写死在代码里。我一般把这几项做成配置障碍物数量区间、尺寸区间、形状权重、分布偏好。参数建议范围说明数量8 到 30太少测不出拥挤太多大部分场景无解尺寸0.2 到 1.0 米覆盖小型杂物到大型箱体形状权重方块 0.6、圆柱 0.3、其他 0.1方块最常用圆柱测绕行最小间距机器人直径的 1.2 倍防止生成不可通行的窄缝最小间距这个参数特别值得说。它太小会生成机器人物理上过不去的窄缝算法表现差但不能说明算法有问题它太大场景过于宽松测不出拥挤环境下的表现。取机器人直径的 1.2 倍是个折中既允许存在接近极限的通道又保证理论上是可通过的。如果你的机器人带机械臂或者载货这个系数要往上调。数量上限也值得琢磨。三十个障碍物在十米见方的场地里已经很密了再往上加大部分随机布局会直接导致起点到终点无解这时候测试的就不是避障能力而是能不能找到路。真要做高密度测试更好的做法是固定一个走廊式的布局模板在走廊里随机撒点保证有解的同时提高难度。4.3 场景的可复现性与批量回归随机生成最大的副作用是不可复现。同一个脚本跑两次场景不一样出了问题没法复现。解决办法很简单记录随机种子。每次生成前设定种子并打印出来出问题的场景用这个种子一跑就能还原。更进一步我习惯把生成好的场景布局保存成一个清单文件包含每个障碍物的类型、位姿、尺寸。这样回归测试的时候直接读清单不依赖生成脚本环境完全确定。清单文件的另一个好处是可以做增量发现某个布局特别难就把它加入固定测试集长期保留。批量回归的组织方式也有讲究。不要一次性生成一百个场景连续跑而是分成几批每批二十个左右跑完统计成功率、平均耗时、最小安全距离这几个指标。指标异常的那批再去逐个看种子。这样既能看到整体趋势又不会淹没在日志里。我在实际使用中的体会是随机测试的价值八成来自认真分析失败场景而不是跑了多少次。5. 三类障碍物混用时的几个实际问题单独做每类都不难混在一起就会出现新问题。这一节讲三个我实际遇到过、文档里基本不会提的情况。5.1 动态障碍物与随机生成的时序冲突如果场景里有随机生成的固定障碍物又有移动障碍物那么移动障碍物的轨迹必须基于随机生成之后的地图来设计否则轨迹可能穿过随机障碍物。处理方式有两种一是先随机生成静态部分再根据生成结果计算动态轨迹比如让移动障碍物沿着空闲区域走二是把动态障碍物的轨迹也纳入约束生成静态障碍物时避开动态轨迹的扫掠区域。第二种更严谨但实现复杂需要计算轨迹的扫掠体。第一种简单适合轨迹本身是固定形状比如在一条预设走廊里往返的情况只要保证走廊不被随机障碍物堵住就行。我一般在走廊区域设置一个更低的最大密度从生成逻辑上保证动态轨迹可用。5.2 障碍物数量上升后的仿真步长调整障碍物一多碰撞检测的计算量上升如果仿真步长还是按空旷场景设的会出现物理不稳定或者实时率暴跌。经验做法是固定障碍物超过五十个、或者动态障碍物超过五个时把物理步长适当放宽同时减小每个步长的最大迭代次数。这两个参数要一起调只调一个容易出现穿透或者抖动。调完之后一定要验证让机器人以最高速度撞向一个障碍物看是否正常停下而不是穿过去。穿透是步长过大的典型症状。这个验证步骤别省我吃过亏场景调完帧率好看了结果测试结果全是机器人穿墙一晚上的数据全废。5.3 障碍物视觉与碰撞不一致导致的误判最后说一个隐蔽的问题。移动障碍物的视觉模型如果有偏移比如视觉几何在 link 坐标系里有个平移而碰撞体没有那么看起来快撞上的时候实际还有距离或者反之。这种问题在静态物体上不明显动态物体上因为一直在动很容易让人误判避障算法有问题。排查方法很直接打开碰撞体可视化对照视觉模型看位置是否重合。不重合就检查视觉和碰撞的 pose 偏移。我的习惯是所有障碍物的视觉和碰撞都用同一个几何定义不单独设偏移需要调整外观就用材质不动几何。这样牺牲一点视觉精细度换来的是排查问题时少一个变量。三类障碍物说到底服务于同一个目标让仿真环境能真实反映算法的能力边界。固定障碍物把地图立起来移动障碍物把时间维度加进去随机障碍物把覆盖面铺开。参数怎么定、脚本怎么写都是手段真正花时间的是想清楚我要测什么然后反过来设计场景。我自己在这件事上走过的最大的弯路就是一开始追求场景好看、复杂结果跑出来的数据根本没法归因。后来把场景拆小、每类单独验证、再逐步组合反而效率高得多。