Gazebo固定、随机与移动障碍物生成实践

1. 障碍物生成这件事先想清楚你要解决什么在仿真环境里搭场景最耗时间的往往不是建模本身而是场景里该有什么、该在哪、该不该动。我最初做移动机器人避障验证时花了两天才意识到一个很朴素的事实如果障碍物全是静态的那算法表现再好也说明不了什么因为真实世界里的人和物是会动的。后来场景越搭越复杂又开始反向踩坑——随机撒障碍物撒得满地都是机器人在起点就被围死跑一百次九十次失败数据根本没法用。这篇内容就聊这三件事移动障碍物、随机障碍物、固定障碍物在Gazebo里怎么生成、怎么组织、怎么让它们服务你的验证目标。核心关键词是Gazebo障碍物生成围绕它展开的是模型加载机制、随机分布策略、动态运动控制三条主线。先说清楚适用人群。如果你只是想在Gazebo里摆几个箱子做个静态展示本文的部分内容对你是过剩的看固定障碍物那一节就够了如果你在做路径规划、动态避障、多传感器融合、强化学习训练环境的搭建那这三类障碍物的生成方式基本是你的刚需尤其是随机障碍物和移动障碍物的参数设计直接决定你的仿真数据有没有价值。如果你刚开始接触Gazebo连world文件和model目录的关系都没理顺也没关系我会把基础机制拆开讲因为后面所有的生成方式都建立在这套机制上。需要提前对齐一个认知Gazebo里的生成障碍物从来不是画一个东西出来这么简单它本质是三件事的组合——几何体与物理属性的定义SDF、在世界中的位姿与组织方式world/include/spawn、以及运行时的时间维度变化静态或动态。把这三层分清楚你会发现所谓随机和移动并不是什么特殊功能只是在这三层上做了不同的处理。想通这一点后面的操作就都是顺理成章的推导而不是背命令。还有一个容易被忽略的前提不同Gazebo版本之间的差异会直接影响你的操作路径。经典版Gazebo Classic11及以前和新的GazeboIgnitionFortress/Garden及以后在命令行工具、世界文件组织、服务调用接口上都有区别。本文以经典版的机制为主来展开因为它的资料覆盖面最广、多数教学与工程环境仍在使用涉及新版的差异我会单独标注避免你照着敲命令结果报找不到服务。这一点我在实际项目里吃过亏同一段脚本换个环境直接失效排查了半天才发现是服务名变了。2. 三层机制拆开看SDF定义、世界组织、运行时生成2.1 SDF是障碍物的基因别急着写world所有障碍物的本质都是一段SDFSimulation Description Format描述。哪怕你只是在GUI里拖一个立方体进去Gazebo背后也是把它转成SDF再插入世界的。所以想让障碍物生成可控第一步是把SDF的结构吃透。一个最小可用的障碍物SDF包含三块collision碰撞体、visual可视体、inertial惯性参数。新手最常犯的错误是只写visual结果障碍物在仿真里看得见摸不着机器人直接穿过去。我见过有人排查了半天传感器数据异常最后发现是碰撞体尺寸和可视体尺寸不一致——视觉上箱子贴着墙物理上早穿模了。model namebox_obstacle staticfalse/static link namelink collision namecollision geometry boxsize0.5 0.5 1.0/size/box /geometry /collision visual namevisual geometry boxsize0.5 0.5 1.0/size/box /geometry material ambient0.7 0.7 0.7 1/ambient /material /visual inertial mass5.0/mass inertia ixx0.52/ixxiyy0.52/iyyizz0.21/izz ixy0/ixyixz0/ixziyz0/iyz /inertia /inertial /link /model惯性张量的数值不是随便填的。均匀实心长方体的公式是I m/12 * (a² b²)这样的形式这里质量5kg、边长0.5m的立方体绕竖直轴z的转动惯量是5/12 × (0.5² 0.5²) ≈ 0.21绕水平轴是5/12 × (0.5² 1.0²) ≈ 0.52。填错不会立刻报错但一旦障碍物被机器人撞到它的翻滚姿态会变得非常诡异看着像物理引擎出了bug其实就是张量不对。这一段我建议你写个脚本算别手拍。statictrue/static这个标签是区分固定与移动的第一道分水岭。设为true时物体不参与动力学求解不响应碰撞力性能开销极低。典型的固定障碍物——墙体、立柱、货架——全部应该设为static。我在一个场景里放过两百多个静态箱子帧率几乎没掉后来误把一个本该静态的大物件设成动态光这一个模型就让仿真实时率掉了三成因为它的碰撞体在持续参与接触计算。2.2 world文件是舞台include与spawn是两种入场方式障碍物进入场景有两条路径选择哪条取决于它是否预定义。第一条是world文件内静态声明通过include引用已有的模型文件或者在world里直接内联model。这种做法适合场景主体结构好处是随世界一起加载确定性极强每次启动都一模一样。include urimodel://box_obstacle/uri namebox_obstacle_1/name pose2.0 0 0.5 0 0 0/pose /include注意name必须唯一否则后面的同名模型会被静默覆盖或者干脆加载失败。这个坑很隐蔽你复制粘贴十行include忘了改name启动后场景里少了一半障碍物控制台却只有一行不显眼的warning。第二条是运行时生成用gz model命令行或rosrun gazebo_ros spawn_model也可以直接调Gazebo的/gazebo/spawn_sdf_model服务。这条路径适合随机障碍物——因为你需要在启动后动态计算位姿再插入而不是写死在文件里。两条路径的性能差异在障碍物数量大时很明显。我做过对比同样是三百个静态箱子world内声明的加载时间明显短于在启动后逐个spawn因为后者每个模型都要走一遍服务调用和场景图插入的流程。所以我的习惯是固定障碍物写进world随机和移动障碍物运行时生成。这个分工不是死规则但它把确定性和灵活性的边界划得很清楚调试时也容易定位问题出在哪一层。2.3 运行时生成的三种调用方式怎么选运行时插入模型常见有三条路各有适用场景调用方式典型命令/接口适用场景主要限制命令行 spawnrosrun gazebo_ros spawn_model手动调试、脚本化少量插入每次都要拼参数批量时繁琐Gazebo服务/gazebo/spawn_sdf_model程序内批量生成、与算法联动需处理服务等待与超时世界插件ModelPlugin / WorldPlugin场景自管理、随仿真启动自动布点开发成本高需编译小规模验证我基本用命令行一条命令下去立刻能看到结果反馈快。但只要涉及生成二十个随机障碍物就切到服务调用因为命令行会阻塞而服务调用可以并发或循环批处理。世界插件是另一条思路——把布点逻辑写进插件世界一加载就自动完成适合需要反复启动同一场景的实验。它的代价是要写代码、编译、配置world引用前期投入大但如果你要做几百次重复实验这个投入很快就能赚回来。我个人的优先级是调试期用命令行实验期用服务调用脚本固化场景用插件或直接写world。这个顺序不是绝对的但按先跑通再自动化的思路走踩的坑会少很多。3. 固定障碍物确定性场景的地基3.1 什么该固定什么不该固定固定障碍物在验证中的作用是提供可复现的环境约束。做路径规划时你需要一组稳定的墙体来界定可行区域做定位精度测试时你需要固定的特征物体来评估匹配效果。这类障碍物的第一原则是稳定宁可丑一点、简单一点也不要引入不确定因素。我的判断标准很直接这个物体在真实场景里会自己动吗不会动的全设为static。墙体、台阶、桌腿、货架、栏杆全都归这一类。有人喜欢把桌腿做成动态理由是万一机器人撞上桌腿应该把它撞倒除非你的研究课题就是碰撞后的物体运动否则这就是给自己找麻烦——一个被撞歪的桌腿会让后续所有实验的初始条件都变掉数据没法复现。还有一类介于两者之间的可推动但平时不动的物体比如纸箱、垃圾桶。我一般也设static但会在论文或实验记录里明确标注假设该物体在实验期间不发生位移。如果确实需要研究推动行为那就单独建一个实验组别混在主场景里。3.2 用include组织一组固定障碍物实际场景里固定障碍物很少只有一个通常是一组墙、一排柱子。最省事的方式是准备好单个模型然后在world里用include逐个摆放。include urimodel://wall_segment/uri namewall_north_01/name pose0 5 1 0 0 0/pose /include include urimodel://wall_segment/uri namewall_north_02/name pose2 5 1 0 0 0/pose /include include urimodel://wall_segment/uri namewall_east_01/name pose4 3 1 0 0 1.5708/pose /include注意最后那个1.5708是绕z轴转90度把墙段从南北向转成东西向。位姿的六个数是x y z roll pitch yaw单位分别是米和弧度这个顺序不能错。我早年写过一个场景把yaw写在了roll的位置结果一整面墙立起来了排查了半小时才发现是位姿顺序问题。墙段拼接时的对齐是个细节活。如果墙段长2米那相邻两段的x或y间隔就得精确是2米差一点点就会有缝或者重叠。重叠在视觉上不明显但碰撞体交叠会让物理求解器产生额外的接触点轻微影响性能有缝更麻烦机器人可能会从缝里挤过去让你误以为避障算法失效。我的做法是先定一个基准点然后所有坐标都用基准点加偏移量算出来而不是手写绝对值。3.3 大场景的性能控制障碍物数量上去以后性能会成为实际瓶颈。几百个静态模型在视觉上没问题但每个模型的碰撞体都要参与空间划分计算。控制手段我常用的有三个第一简化碰撞体。复杂的视觉模型配一个简单的box碰撞体性能差异非常明显。一个带曲面的货架视觉模型碰撞体用几个box拼出来就够了精度损失几乎可以忽略。第二合并同质模型。如果有一百个一模一样的小箱子考虑把它们合并成少数几个模型或者用实例化机制减少重复加载。第三视觉细节分级。远处的障碍物不需要精细纹理把material换成纯色即可。这个对渲染帧率有帮助对物理计算没影响但整体流畅度会好很多。注意静态障碍物不参与动力学但它的碰撞体仍然参与接触检测。所以设成static就不用管性能了是错误认知碰撞体的复杂度依然是成本。我在一个仓储场景里做过实测把两百个货架的碰撞体从网格模型换成box组合后仿真实时率从0.6提升到0.9左右。这个提升不算夸张但对于需要跑几小时的长时间实验来说省下来的时间相当可观。4. 随机障碍物让场景具备统计意义4.1 随机的边界先定规则再写代码随机障碍物最大的价值是避免算法对固定场景过拟合。如果你的避障算法只在一种布局下测试那它很可能只是学会了绕开那几个特定位置。随机化能逼出算法的真实能力。但随机不等于乱来。我踩过的最大的坑就是第一版随机布点时完全无约束结果大量样本里机器人在起点就被围死或者通行区域被彻底堵死这些样本对算法评估毫无价值反而拉低了整体统计的可信度。后来我总结了三条必须遵守的约束可通行性约束必须保证起点到终点至少存在一条通路否则这个样本是无效的。最小间距约束任意两个障碍物之间、障碍物与机器人之间保持最小距离避免初始状态就发生碰撞。边界约束障碍物不能超出场景边界也不能压住关键区域如充电桩、地图边界的传感器可视范围。这三条约束的实现成本不高但如果不做你的数据集里会有大量垃圾样本。用生活化的类比随机撒障碍物像往一个房间里丢椅子你可以让位置随机但不能把门口堵死否则这个随机房间根本没法测人怎么走。4.2 随机布点的核心参数设计写随机生成逻辑绕不开几个参数每个参数都影响样本质量参数含义取值建议踩坑经验数量范围每次生成的障碍物个数5~20太少没难度太多通行性骤降尺寸范围障碍物边长/半径区间0.2~1.0m与通道宽度挂钩别超过通道1/3最小间距障碍物间中心距下限≥ 两半径之和 0.1m太小会重叠导致物理抖动采样区域允许布点的空间范围略小于场景边界留出安全边距避免贴墙卡住采样次数上限单次生成的最大尝试次数50~100防死循环超限则重采样或降级参数之间是耦合的。数量多、尺寸大、间距大这三个条件同时满足时很可能在采样次数内找不到合法布局。这时候要么放宽某个条件要么就接受重采样整个场景。我在一个狭窄走廊场景里就遇到过这个问题最后把尺寸上限从1.0降到0.6才让采样收敛率变得可接受。采样算法本身最直接的是拒绝采样随机生成一个位姿检查是否满足所有约束不满足就重来。实现简单对稀疏场景效率很高。场景变密以后拒绝采样的失败率会急剧上升这时候可以换成基于网格的采样——把空间划分成格子每次在空格子里取能显著提高成功率。这个改动不复杂但能让生成效率提升数倍尤其是在障碍物数量偏多的时候。4.3 用Python脚本实现批量随机生成下面这套流程是我现在常用的做法核心是在场景管理器里预定义布点区域用脚本循环调用生成服务。先说预定义。在world里留出布点区域的办法是定义一个不可见的边界实际做法是直接用场景坐标范围做约束不需要额外建模import random import math # 场景与障碍物的约束参数 SCENE_X (-4.0, 4.0) SCENE_Y (-4.0, 4.0) OBSTACLE_SIZE (0.2, 1.0) COUNT_RANGE (5, 20) MIN_GAP 0.35 # 障碍物之间的最小中心距 EDGE_MARGIN 0.6 # 距场景边界的安全边距 MAX_TRIES 100 def sample_pose(existing, size_range): for _ in range(MAX_TRIES): s random.uniform(*size_range) x random.uniform(SCENE_X[0] EDGE_MARGIN s/2, SCENE_X[1] - EDGE_MARGIN - s/2) y random.uniform(SCENE_Y[0] EDGE_MARGIN s/2, SCENE_Y[1] - EDGE_MARGIN - s/2) yaw random.uniform(0, 2 * math.pi) ok True for (ox, oy, os) in existing: if math.hypot(x - ox, y - oy) s/2 os/2 MIN_GAP: ok False break if ok: return x, y, s, yaw return None def generate_layout(countNone): count count or random.randint(*COUNT_RANGE) placed [] for _ in range(count): pose sample_pose(placed, OBSTACLE_SIZE) if pose is None: break placed.append(pose) return placed这段代码里有两处值得展开。第一处是边界处理我用了EDGE_MARGIN s/2先留安全边距再收半个尺寸保证障碍物整个体积都在采样区域内而不是中心点在区域内、身体却探出去。第二处是间距判断用了半径之和再加MIN_GAP而不是简单的中心距阈值因为障碍物尺寸随机固定阈值对不同尺寸的物体意义不同。生成结果拿到后调用生成服务python3 spawn_random.py --world warehouse --count 12 --seed 42脚本内部用服务调用插入模型关键点有三个每次插入后等待服务返回避免并发下场景图状态不一致给每个模型唯一的命名通常拼上序号把本次生成的种子和位姿列表落盘。种子必须记录否则这次生成的布局无法复现后期分析算法在某些场景失败时就没有回放依据。这个记录习惯我建议从第一天就养成成本几乎为零价值极大。4.4 种子与场景集的工程化组织做算法评估你需要的不是一个随机场景而是一组可复现的随机场景。我现在的做法是固定一个场景集比如50个布局每个布局对应一个种子跑实验时遍历这50个。这样不同算法之间的对比才有意义因为大家面对的是同一组难度样本。场景集的组织方式很简单一个JSON文件就够了{ scene_set: corridor_obstacles_v2, count_per_scene: [8, 12, 16], scenes: [ {seed: 1, obstacles: [[1.2, 0.5, 0.4, 0.0], [2.4, -0.8, 0.6, 1.57]]}, {seed: 2, obstacles: [[0.9, 1.1, 0.3, 0.8], [3.0, 0.2, 0.5, 2.10]]} ] }每个障碍物的四个数是x y size yaw。加载时按种子或直接按坐标列表重建即可。这里有个小技巧按障碍物数量分层。如果全用8个障碍物的场景算法在中等密度下的表现就被忽略了。我通常设2~3个密度档每档若干种子这样统计出来的成功率曲线更能反映算法的鲁棒性边界。还有一点值得强调随机化不要只随机位置。如果有余力把尺寸、朝向、甚至部分障碍物的形态box还是cylinder也纳入随机范围。单一的随机维度容易让算法记住某种特定形状泛化性上不去。当然随机维度越多场景集规模越大这里需要在覆盖面和实验成本之间取平衡。5. 移动障碍物引入时间维度的难点5.1 移动障碍物的三种实现路线固定和随机解决的是空间分布移动障碍物解决的是时间维度。这一步的复杂度明显上升因为你要同时处理运动轨迹、运动学模型、以及与物理引擎的交互。实现路线我见过三种适用场景差别很大路线做法优点代价actor轨迹用SDF的actor配合script动画支持骨骼动画适合行人无物理碰撞不参与避障真实交互动态模型插件动态模型配速度控制插件有真实碰撞可被撞动需要写或配置控制器外部程序驱动用脚本持续设置模型位姿轨迹完全可控绕过物理碰撞行为不真实如果你的目的是测试导航算法能否躲开行人且不关心碰撞后的物理效果actor是最优解它支持循环行走动画视觉上也像那么回事。但如果你的算法依赖真实的接触响应比如安全距离的力反馈那必须选动态模型配插件因为actor是无实体的机器人和它之间不会有物理接触。我一般首选动态模型加速度插件。它虽然不如图省事但行为可信。下面重点讲这条路线。5.2 用速度控制让障碍物沿路径移动核心思路是给障碍物一个速度指令让它自己动起来而不是每帧去设置它的位姿。区别在于设置位姿是瞬移物体的速度、加速度在物理意义上是不连续的传感器计算出的相对速度会失真设置速度则是让物理求解器自己积分出位置动起来更自然。最直接的方式是使用速度控制插件配置在模型的SDF里model namemoving_box staticfalse/static link namelink collision namecollision geometryboxsize0.4 0.4 0.8/size/box/geometry /collision visual namevisual geometryboxsize0.4 0.4 0.8/size/box/geometry /visual inertial mass3.0/mass inertia ixx0.32/ixxiyy0.32/iyyizz0.08/izz ixy0/ixyixz0/ixziyz0/iyz /inertia /inertial /link plugin namevel_ctrl filenamelibgazebo_ros_planar_move.so commandTopiccmd_vel/commandTopic odometryTopicodom/odometryTopic odometryFrameodom/odometryFrame robotBaseFramemoving_box_link/robotBaseFrame updateRate50/updateRate /plugin /model这里需要说明插件的选型逻辑。平面移动类插件只处理x、y的平移和绕z的旋转不考虑俯仰和滚转正好匹配地面移动障碍物——行人、AGV、移动机器人都是这个约束。用全向的六自由度控制反而是多余的还会引入模型倾斜的风险。updateRate设50意思是每秒下发50次速度指令太低会导致运动一顿一顿太高对物理求解没有额外收益。50这个值是在平滑度和计算开销之间的常用折中我实测过20会明显抖动100带来的提升则感受不到。有个细节容易出问题robotBaseFrame必须和模型里实际的link名对应。上面模型的主link叫link但插件里写的是moving_box_link如果不一致插件会找不到基准坐标系。正确的做法是显式给link设名字并两边对齐。这种不一致不会在加载时报错而是表现为模型不动或者里程计数据全是零排查起来很费时间。5.3 轨迹设计直线、往复与随机游走障碍物动起来之后动成什么样是关键。我常用的轨迹有三类对应不同的测试目的直线穿越是最基础的一种。让障碍物垂直于机器人行进方向穿过通道测试算法在突发横向障碍下的反应。这种轨迹效果好因为干扰出现在最意想不到的时刻。实现上只需要持续下发固定方向的线速度。往复运动适合测试长时运行下的稳定性。一个在通道里来回走动的障碍物会反复制造通行窗口和阻碍逼迫规划器不断重规划。这条轨迹用正弦或三角波函数更新速度方向即可注意在转向点速度要归零否则模型会因为瞬间反向出现物理抖动。随机游走最接近真实场景的不确定性。每隔随机时间间隔给障碍物更换一个随机方向和速度模拟行人的无规则移动。这种模式下最难评估算法的最优性但最能测出鲁棒性。我的建议是验证阶段用直线和往复因为结果容易解释批量实验阶段再加入随机游走看整体表现是否明显劣化。提示所有轨迹设计都要考虑障碍物的实际尺寸和转弯半径。一个0.4米宽的箱子以恒定速度直角转角在物理上看起来会像瞬间转向很不自然也容易和相邻障碍物发生卡顿。给转角加一点平滑插值效果会好很多。5.4 移动障碍物与随机生成的组合真正有意思的是把移动和随机组合起来位置随机初始化 运动模式随机选择。这样每一条实验轨迹都是新的但底层参数受控、可复现。组合的做法是先按第4节的方式随机采样初始位姿再为每个障碍物随机分配一条轨迹模板直线/往复/随机游走和一组速度参数把这些信息一并记进场景集文件。加载时按记录的顺序初始化保证复现。def make_moving_obstacle(rng, bounds): x, y rng.uniform(*bounds[x]), rng.uniform(*bounds[y]) mode rng.choice([line, pingpong, walk]) speed rng.uniform(0.2, 0.8) heading rng.uniform(0, 6.283) return {x: x, y: y, mode: mode, speed: speed, heading: heading}这段逻辑的关键在于随机的是模式参数而不是每帧的位姿。把随机性压缩在初始化阶段运行阶段的运动就由确定性规则驱动这样既有新鲜感又可复现。如果每帧都随机你就失去了重现问题的能力——出了问题都不知道怎么再跑一遍。速度范围为什么定在0.2到0.8米每秒这个区间大致对应慢走和快走。低于0.2米每秒障碍物几乎构不成干扰高于0.8米每秒很多规划器的重规划周期跟不上会表现为必然碰撞测的就不是算法能力而是响应带宽了。这个区间不是标准答案但要与你的机器人运动能力匹配——障碍物速度如果远超机器人的最大速度测试就失去了意义。6. 常见问题与排查清单实录6.1 生成后看不见模型或者模型穿模这是最高频的问题排查顺序我总结成三步。第一步看模型是否真的插入了。在Gazebo里打开模型列表或者直接调世界服务查当前模型名。有时候insert命令返回成功但实际没进场景原因是服务等待没做够——Gazebo服务在刚启动时还没就绪你抢先调用就会失败而且某些接口的返回值并不能可靠反映失败。第二步看碰撞体与可视体是否一致。能看见但穿模八成是collision和visual的几何不一致或者碰撞体压根没写。这个在上面SDF那节已经强调过但它的表现形式很容易误导人。第三步看位姿是否在可视范围外。生成的坐标超出了相机视野或者落在地下视觉上就是没出现。检查z值尤其是随机生成时只随机了xy却把z写死为0的情况——如果模型的原点不在几何中心z0会让一半的模型埋在地面以下。6.2 动态障碍物抖或者原地打转抖动通常来自三个方向。一是惯性参数错误尤其张量和对角轴不匹配时物体会在受力后异常旋转。二是速度指令的频率和物理步长不匹配指令下发过快过密求解器来不及积分。三是障碍物的碰撞体和地面或其他物体存在初始重叠求解器在拼命把它们推开表现为持续抖动。原地打转多数是坐标系方向搞错了。平面移动插件的速度定义在模型自身的坐标系下如果你的模型朝向和预期差了90度直行的指令就会变成斜行甚至旋转。排查办法是先下发一个纯x方向的速度观察它实际往哪走对一下就清楚了。6.3 随机生成的成功率太低成功率低表现为大量采样被拒绝或者生成的场景彼此都很像。原因和对策我整理成了速查表现象可能原因处理办法采样循环迟迟不结束约束过紧空间装不下放宽尺寸上限或减少数量生成的场景都挤在角落采样范围与安全边距冲突检查边距是否过大导致可用区被压缩大部分障碍物互相重叠间距判断用了中心距而非半径和按各自尺寸做间距计算不同种子生成的布局高度相似随机数生成器未正确设置种子显式设置种子避免默认种子固定部分场景完全不连通未做可通行性检查加入通路检测失败则重采样倒数第二条值得单独说。有些随机库在初始化时如果不显式给种子会用一个默认值导致你跑十次拿到的随机场景完全一样。我第一次做场景集时就是这个坑生成了一百个场景回头一看只有前几个不同后面全是重复。记录种子这个习惯一半是为了复现另一半就是为了确认随机真的生效了。6.4 性能与实时率下滑的定位思路障碍物一多实时率下降几乎是必然的关键是分清是渲染慢还是物理慢。我的判断方法是关掉GUI再跑一次如果实时率明显回升瓶颈在渲染如果几乎没变瓶颈在物理计算通常是碰撞体太多太复杂。针对物理瓶颈优先简化碰撞体其次减少动态物体数量。动态物体的开销远大于静态因为每个都要参与动力学积分。我在一个场景里把三十个动态障碍物降到十五个实时率立刻回到了可用水平。如果确实需要大量动态物体考虑用actor替代——它们不参与物理开销小得多代价是失去真实碰撞。还有一个容易忽略的点障碍物被远远丢在场景外也会消耗性能因为它们在场景图里依然存在。定期清理不再需要的障碍物或者把它们移到不影响计算的位置是个好习惯。7. 我在实际搭建中的几点体会三类障碍物的分工说到底是在回答一个问题你要测的算法面对的是已知的静态世界还是有不确定性的世界。固定障碍物对应前者随机和移动对应后者而真实部署面对的一定是后者。所以我现在的场景搭建习惯是先用固定障碍物把基本功能跑通确认机器人在理想环境下能稳定工作然后加随机障碍物测泛化最后加移动障碍物测动态响应。这个渐进顺序很重要一步到位搭复杂场景出了问题根本不知道该怀疑哪一层。另一个体会是参数记录比参数调优更重要。我花在调障碍物数量、速度、间距上的时间不少但真正让实验变得可信的是每一次生成都留下了种子、坐标和运动参数。没有这些记录跑出来的失败案例就是一次性的没法复现、没法分析、没法分享给别人验证。最后分享一个后期才意识到的小技巧场景集不要只保存通过的失败的样本更要存。算法在某类布局下失败这类布局往往才是最有价值的测试用例。我的场景集里现在专门有一档是高失败率布局每次改算法都先跑这一组能最快看到改进是否真的有效。