1. 障碍物生成这件事，先想清楚你要解决什么

在仿真环境里搭场景，最耗时间的往往不是建模本身，而是"场景里该有什么、该在哪、该不该动"。我最初做移动机器人避障验证时，花了两天才意识到一个很朴素的事实：如果障碍物全是静态的，那算法表现再好也说明不了什么，因为真实世界里的人和物是会动的。后来场景越搭越复杂，又开始反向踩坑——随机撒障碍物撒得满地都是，机器人在起点就被围死，跑一百次九十次失败，数据根本没法用。

这篇内容就聊这三件事：移动障碍物、随机障碍物、固定障碍物在Gazebo里怎么生成、怎么组织、怎么让它们服务你的验证目标。核心关键词是Gazebo障碍物生成，围绕它展开的是模型加载机制、随机分布策略、动态运动控制三条主线。

先说清楚适用人群。如果你只是想在Gazebo里摆几个箱子做个静态展示，本文的部分内容对你是过剩的，看固定障碍物那一节就够了；如果你在做路径规划、动态避障、多传感器融合、强化学习训练环境的搭建，那这三类障碍物的生成方式基本是你的刚需，尤其是随机障碍物和移动障碍物的参数设计，直接决定你的仿真数据有没有价值。如果你刚开始接触Gazebo，连world文件和model目录的关系都没理顺，也没关系，我会把基础机制拆开讲，因为后面所有的生成方式都建立在这套机制上。

需要提前对齐一个认知：Gazebo里的"生成障碍物"从来不是"画一个东西出来"这么简单，它本质是三件事的组合——几何体与物理属性的定义（SDF）、在世界中的位姿与组织方式（world/include/spawn）、以及运行时的时间维度变化（静态或动态）。把这三层分清楚，你会发现所谓"随机"和"移动"并不是什么特殊功能，只是在这三层上做了不同的处理。想通这一点，后面的操作就都是顺理成章的推导，而不是背命令。

还有一个容易被忽略的前提：不同Gazebo版本之间的差异会直接影响你的操作路径。经典版（Gazebo Classic，11及以前）和新的Gazebo（Ignition，Fortress/Garden及以后）在命令行工具、世界文件组织、服务调用接口上都有区别。本文以经典版的机制为主来展开，因为它的资料覆盖面最广、多数教学与工程环境仍在使用；涉及新版的差异我会单独标注，避免你照着敲命令结果报"找不到服务"。这一点我在实际项目里吃过亏，同一段脚本换个环境直接失效，排查了半天才发现是服务名变了。

2. 三层机制拆开看：SDF定义、世界组织、运行时生成

2.1 SDF是障碍物的"基因"，别急着写world

所有障碍物的本质都是一段SDF（Simulation Description Format）描述。哪怕你只是在GUI里拖一个立方体进去，Gazebo背后也是把它转成SDF再插入世界的。所以想让障碍物生成可控，第一步是把SDF的结构吃透。

一个最小可用的障碍物SDF包含三块：<collision>碰撞体、<visual>可视体、<inertial>惯性参数。新手最常犯的错误是只写visual，结果障碍物在仿真里"看得见摸不着"，机器人直接穿过去。我见过有人排查了半天传感器数据异常，最后发现是碰撞体尺寸和可视体尺寸不一致——视觉上箱子贴着墙，物理上早穿模了。

<model name="box_obstacle"> <static>false</static> <link name="link"> <collision name="collision"> <geometry> <box><size>0.5 0.5 1.0</size></box> </geometry> </collision> <visual name="visual"> <geometry> <box><size>0.5 0.5 1.0</size></box> </geometry> <material> <ambient>0.7 0.7 0.7 1</ambient> </material> </visual> <inertial> <mass>5.0</mass> <inertia> <ixx>0.52</ixx><iyy>0.52</iyy><izz>0.21</izz> <ixy>0</ixy><ixz>0</ixz><iyz>0</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，其实就是张量不对。这一段我建议你写个脚本算，别手拍。

<static>true</static>这个标签是区分固定与移动的第一道分水岭。设为true时，物体不参与动力学求解，不响应碰撞力，性能开销极低。典型的固定障碍物——墙体、立柱、货架——全部应该设为static。我在一个场景里放过两百多个静态箱子，帧率几乎没掉；后来误把一个本该静态的大物件设成动态，光这一个模型就让仿真实时率掉了三成，因为它的碰撞体在持续参与接触计算。

2.2 world文件是舞台，include与spawn是两种入场方式

障碍物进入场景有两条路径，选择哪条取决于它是否"预定义"。

第一条是world文件内静态声明，通过<include>引用已有的模型文件，或者在world里直接内联<model>。这种做法适合场景主体结构，好处是随世界一起加载，确定性极强，每次启动都一模一样。

<include> <uri>model://box_obstacle</uri> <name>box_obstacle_1</name> <pose>2.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 运行时生成的三种调用方式怎么选

运行时插入模型，常见有三条路，各有适用场景：

小规模验证我基本用命令行，一条命令下去立刻能看到结果，反馈快。但只要涉及"生成二十个随机障碍物"，就切到服务调用，因为命令行会阻塞，而服务调用可以并发或循环批处理。世界插件是另一条思路——把布点逻辑写进插件，世界一加载就自动完成，适合需要反复启动同一场景的实验。它的代价是要写代码、编译、配置world引用，前期投入大，但如果你要做几百次重复实验，这个投入很快就能赚回来。

我个人的优先级是：调试期用命令行，实验期用服务调用脚本，固化场景用插件或直接写world。这个顺序不是绝对的，但按"先跑通再自动化"的思路走，踩的坑会少很多。

3. 固定障碍物：确定性场景的地基

3.1 什么该固定，什么不该固定

固定障碍物在验证中的作用是提供可复现的环境约束。做路径规划时，你需要一组稳定的墙体来界定可行区域；做定位精度测试时，你需要固定的特征物体来评估匹配效果。这类障碍物的第一原则是稳定，宁可丑一点、简单一点，也不要引入不确定因素。

我的判断标准很直接：这个物体在真实场景里会自己动吗？不会动的，全设为static。墙体、台阶、桌腿、货架、栏杆，全都归这一类。有人喜欢把桌腿做成动态，理由是"万一机器人撞上桌腿应该把它撞倒"，除非你的研究课题就是碰撞后的物体运动，否则这就是给自己找麻烦——一个被撞歪的桌腿会让后续所有实验的初始条件都变掉，数据没法复现。

还有一类介于两者之间的：可推动但平时不动的物体，比如纸箱、垃圾桶。我一般也设static，但会在论文或实验记录里明确标注"假设该物体在实验期间不发生位移"。如果确实需要研究推动行为，那就单独建一个实验组，别混在主场景里。

3.2 用include组织一组固定障碍物

实际场景里固定障碍物很少只有一个，通常是一组墙、一排柱子。最省事的方式是准备好单个模型，然后在world里用include逐个摆放。

<include> <uri>model://wall_segment</uri> <name>wall_north_01</name> <pose>0 5 1 0 0 0</pose> </include> <include> <uri>model://wall_segment</uri> <name>wall_north_02</name> <pose>2 5 1 0 0 0</pose> </include> <include> <uri>model://wall_segment</uri> <name>wall_east_01</name> <pose>4 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 随机布点的核心参数设计

写随机生成逻辑，绕不开几个参数，每个参数都影响样本质量：

参数之间是耦合的。数量多、尺寸大、间距大，这三个条件同时满足时，很可能在采样次数内找不到合法布局。这时候要么放宽某个条件，要么就接受"重采样整个场景"。我在一个狭窄走廊场景里就遇到过这个问题，最后把尺寸上限从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(count=None): 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是最优解，它支持循环行走动画，视觉上也像那么回事。但如果你的算法依赖真实的接触响应，比如安全距离的力反馈，那必须选动态模型配插件，因为actor是"无实体"的，机器人和它之间不会有物理接触。

我一般首选动态模型加速度插件。它虽然不如图省事，但行为可信。下面重点讲这条路线。

5.2 用速度控制让障碍物沿路径移动

核心思路是给障碍物一个速度指令，让它自己动起来，而不是每帧去设置它的位姿。区别在于：设置位姿是"瞬移"，物体的速度、加速度在物理意义上是不连续的，传感器计算出的相对速度会失真；设置速度则是让物理求解器自己积分出位置，动起来更自然。

最直接的方式是使用速度控制插件，配置在模型的SDF里：

<model name="moving_box"> <static>false</static> <link name="link"> <collision name="collision"> <geometry><box><size>0.4 0.4 0.8</size></box></geometry> </collision> <visual name="visual"> <geometry><box><size>0.4 0.4 0.8</size></box></geometry> </visual> <inertial> <mass>3.0</mass> <inertia> <ixx>0.32</ixx><iyy>0.32</iyy><izz>0.08</izz> <ixy>0</ixy><ixz>0</ixz><iyz>0</iyz> </inertia> </inertial> </link> <plugin name="vel_ctrl" filename="libgazebo_ros_planar_move.so"> <commandTopic>cmd_vel</commandTopic> <odometryTopic>odom</odometryTopic> <odometryFrame>odom</odometryFrame> <robotBaseFrame>moving_box_link</robotBaseFrame> <updateRate>50</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的情况——如果模型的原点不在几何中心，z=0会让一半的模型埋在地面以下。

6.2 动态障碍物"抖"或者原地打转

抖动通常来自三个方向。一是惯性参数错误，尤其张量和对角轴不匹配时，物体会在受力后异常旋转。二是速度指令的频率和物理步长不匹配，指令下发过快过密，求解器来不及积分。三是障碍物的碰撞体和地面或其他物体存在初始重叠，求解器在拼命把它们推开，表现为持续抖动。

原地打转多数是坐标系方向搞错了。平面移动插件的速度定义在模型自身的坐标系下，如果你的模型朝向和预期差了90度，直行的指令就会变成斜行甚至旋转。排查办法是先下发一个纯x方向的速度，观察它实际往哪走，对一下就清楚了。

6.3 随机生成的成功率太低

成功率低表现为大量采样被拒绝，或者生成的场景彼此都很像。原因和对策我整理成了速查表：

倒数第二条值得单独说。有些随机库在初始化时如果不显式给种子，会用一个默认值，导致你跑十次拿到的"随机"场景完全一样。我第一次做场景集时就是这个坑，生成了一百个场景，回头一看只有前几个不同，后面全是重复。记录种子这个习惯，一半是为了复现，另一半就是为了确认随机真的生效了。

6.4 性能与实时率下滑的定位思路

障碍物一多，实时率下降几乎是必然的，关键是分清是渲染慢还是物理慢。我的判断方法是关掉GUI再跑一次，如果实时率明显回升，瓶颈在渲染；如果几乎没变，瓶颈在物理计算，通常是碰撞体太多太复杂。

针对物理瓶颈，优先简化碰撞体，其次减少动态物体数量。动态物体的开销远大于静态，因为每个都要参与动力学积分。我在一个场景里把三十个动态障碍物降到十五个，实时率立刻回到了可用水平。如果确实需要大量动态物体，考虑用actor替代——它们不参与物理，开销小得多，代价是失去真实碰撞。

还有一个容易忽略的点：障碍物被远远丢在场景外也会消耗性能，因为它们在场景图里依然存在。定期清理不再需要的障碍物，或者把它们移到不影响计算的位置，是个好习惯。

7. 我在实际搭建中的几点体会

三类障碍物的分工，说到底是在回答一个问题：你要测的算法，面对的是"已知的静态世界"还是"有不确定性的世界"。固定障碍物对应前者，随机和移动对应后者，而真实部署面对的一定是后者。所以我现在的场景搭建习惯是，先用固定障碍物把基本功能跑通，确认机器人在理想环境下能稳定工作，然后加随机障碍物测泛化，最后加移动障碍物测动态响应。这个渐进顺序很重要，一步到位搭复杂场景，出了问题根本不知道该怀疑哪一层。

另一个体会是，参数记录比参数调优更重要。我花在调障碍物数量、速度、间距上的时间不少，但真正让实验变得可信的，是每一次生成都留下了种子、坐标和运动参数。没有这些记录，跑出来的失败案例就是一次性的，没法复现、没法分析、没法分享给别人验证。

最后分享一个后期才意识到的小技巧：场景集不要只保存"通过的"，失败的样本更要存。算法在某类布局下失败，这类布局往往才是最有价值的测试用例。我的场景集里现在专门有一档是"高失败率布局"，每次改算法都先跑这一组，能最快看到改进是否真的有效。