1. 项目缘起与整体设计思路1.1 为什么要在仿真里搭室内环境做机器人开发的人都有一个共识真机调试的成本太高了。一台带机械臂或者移动底盘的机器人少则几千多则几万撞一次墙可能就要换零件更别提传感器标定、电池续航、场地限制这些琐碎问题。所以但凡涉及导航、避障、路径规划这类算法验证我都会先在仿真环境里跑通再考虑上真机。Gazebo 就是干这件事的。它本质上是一个物理仿真引擎能模拟重力、碰撞、摩擦、传感器噪声还能加载 URDF 或 SDF 描述的机器人模型。而室内环境搭建是所有移动机器人仿真的第一步——你得先有个“房子”机器人才能在里面跑起来。这个项目要解决的核心问题就是在 Ubuntu 16.04 上用 ROS 配合 Gazebo从零搭出一个可用的室内场景让机器人能在里面做后续的导航和建图实验。适合谁来参考如果你刚接触 ROS已经装好了 Kinetic 版本想跑通第一个仿真场景或者你已经会加载现成的 world 文件但想自己动手改布局、加家具、调光照那这篇内容都能给你一套可直接复现的流程。我下面讲的所有操作都是基于 Kinetic Gazebo 7 这个经典组合实测稳定。1.2 整体方案选型与目录规划搭建室内环境有两条路一是直接用 Gazebo 自带的模型库拼装二是自己写 SDF 或 URDF 文件从零定义。我的建议是混合使用——墙体、地板这种规则结构自己写桌椅、柜子这类复杂模型直接从 Gazebo 模型库拖拽省时省力。目录结构上我习惯在 ROS 工作空间的src下建一个独立的仿真包比如叫indoor_sim里面分几个子目录worlds放世界文件models放自定义模型launch放启动脚本maps留给后续建图用。这样做的理由是仿真资源和算法代码解耦换场景时不用动核心逻辑也方便用 git 管理。提示Ubuntu 16.04 对应的 ROS 版本是 KineticGazebo 版本是 7.x。如果你用的是其他版本组合部分 API 会有差异但整体思路通用。2. 环境准备与核心细节解析2.1 系统依赖与 Gazebo 安装确认Ubuntu 16.04 装 ROS Kinetic 时如果选的是ros-kinetic-desktop-fullGazebo 7 会作为依赖自动装上。但很多人装的是desktop版本那就没有 Gazebo需要手动补。先确认一下gazebo --version如果输出版本号是 7.x说明已经就绪。如果没有执行sudo apt-get install ros-kinetic-gazebo-ros-pkgs ros-kinetic-gazebo-ros-control这两个包一个是 Gazebo 和 ROS 的桥接一个是控制器接口后面加载机器人模型时都会用到。装完后建议跑一下官方示例验证roslaunch gazebo_ros empty_world.launch能弹出一个空场景窗口说明环境没问题。这一步看似简单但我见过不少人卡在这里——要么是显卡驱动问题导致 Gazebo 黑屏要么是模型库下载超时。显卡问题一般更新驱动能解决模型库问题后面会讲离线方案。2.2 世界文件的基本结构Gazebo 的世界文件是 SDF 格式后缀.world。它的骨架大概长这样最外层是sdf标签里面一个worldworld 里包含include引用外部模型、model自定义模型、light光源、physics物理参数这几类元素。我一般不会从空白文件手写而是复制 Gazebo 自带的某个 world 作为模板删掉不需要的部分再改。自带 world 文件在/usr/share/gazebo-7/worlds/目录下比如empty.world就是最干净的起点。复制过来后第一件事是改physics里的实时更新率默认 1000Hz 对室内场景偏高调到 250Hz 能明显降低 CPU 占用而仿真精度几乎不受影响。physics typeode max_step_size0.004/max_step_size real_time_update_rate250/real_time_update_rate /physicsmax_step_size和real_time_update_rate的乘积决定了仿真步长0.004 乘 250 等于 1也就是每步仿真 1 毫秒的物理时间这个配比在室内场景里很稳。2.3 模型库的离线配置Gazebo 启动时会去在线模型库拉取模型网络不好的话会卡很久甚至失败。解决办法是提前把常用模型下载到本地。模型库默认缓存在~/.gazebo/models/你可以手动往里面放模型文件夹每个文件夹包含model.config和model.sdf。如果在线拉取一直超时可以找一台网络通畅的机器把~/.gazebo/models/整个目录打包拷过来。我常用的室内模型包括table、chair、bookshelf、door、cube这些基本够搭一个办公室或客厅。放好之后在 world 文件里用include引用时Gazebo 会优先查本地缓存速度飞快。注意模型文件夹的命名要和model.config里的name一致否则 include 时会报找不到模型。这个坑我踩过排查了半天才发现是文件夹名大小写对不上。3. 实操过程与核心环节实现3.1 搭建房间墙体与地板先从最基础的房间轮廓开始。我习惯用一个大的立方体做地板四个薄立方体做墙。在 world 文件的world标签内添加如下结构model namefloor statictrue/static link namelink collision namecollision geometry boxsize10 8 0.1/size/box /geometry /collision visual namevisual geometry boxsize10 8 0.1/size/box /geometry material script urifile://media/materials/scripts/gazebo.material/uri nameGazebo/Grey/name /script /material /visual /link /model这里10 8 0.1表示房间长 10 米、宽 8 米、地板厚 0.1 米。statictrue/static很关键它让地板固定不动不受物理引擎影响。墙体同理只是尺寸换成10 0.1 3这种长条位置通过pose标签调整。四面墙的 pose 分别是(0, 4, 1.5)、(0, -4, 1.5)、(5, 0, 1.5)、(-5, 0, 1.5)对应前后左右。为什么墙高设 3 米因为室内场景一般层高 2.8 到 3 米太矮会显得压抑太高则浪费渲染资源。地板厚度 0.1 米是经验值太薄容易在碰撞检测时出现穿透太厚则视觉上不自然。3.2 添加家具与障碍物墙体搭好后房间是空的需要加家具来模拟真实环境。直接用 include 引用本地模型include urimodel://table/uri pose2 1 0 0 0 0/pose /include include urimodel://chair/uri pose2 2 0 0 0 0/pose /includepose的六个参数依次是 x、y、z 位置和 roll、pitch、yaw 姿态。桌子放在 (2, 1)椅子放在 (2, 2)朝向默认。这里有个细节家具的 z 坐标要设成 0因为模型原点通常在底部Gazebo 会自动把它放在地板上。如果你发现家具陷进地板或者悬空多半是模型原点定义的问题可以微调 z 值。我一般会在房间里放三到五件家具再加几个立方体当随机障碍物。障碍物不要太多否则后续跑导航算法时路径规划会很难看也不利于观察算法效果。布局上留出一条主通道宽度至少 1 米方便机器人通行。3.3 光照与视觉参数调整默认的 Gazebo 场景光照偏暗室内看起来灰蒙蒙的。在 world 里加一个方向光和一个点光源light typedirectional namesun cast_shadowstrue/cast_shadows pose0 0 10 0 0 0/pose diffuse0.8 0.8 0.8 1/diffuse specular0.2 0.2 0.2 1/specular direction-0.5 0.1 -0.9/direction /lightdiffuse控制漫反射强度0.8 已经比较亮了。direction是光的方向向量朝下偏一点模拟顶光。如果想让场景更真实可以再加一个点光源放在房间中央模拟吸顶灯。阴影建议开启虽然会稍微增加计算量但视觉上立体感强很多调试时也更容易判断机器人和障碍物的相对位置。3.4 启动文件编写与场景加载world 文件写好后需要一个 launch 文件来启动。在launch目录下新建indoor.launchlaunch arg nameworld_file default$(find indoor_sim)/worlds/indoor.world/ include file$(find gazebo_ros)/launch/empty_world.launch arg nameworld_name value$(arg world_file)/ arg namepaused valuefalse/ arg nameuse_sim_time valuetrue/ arg namegui valuetrue/ /include /launchuse_sim_time设为 true 很重要它让 ROS 的时间系统跟随 Gazebo 的仿真时钟否则后面跑导航时时间戳会对不上。paused设为 false 让场景启动后直接运行。启动命令roslaunch indoor_sim indoor.launch如果一切正常你会看到 Gazebo 窗口里出现一个带家具的房间。第一次加载可能稍慢因为要解析模型之后就快了。3.5 验证场景可用性场景搭好后不能只看得验证它是否真的可用。我通常做两件事一是用 Gazebo 自带的模型插入功能拖一个简单机器人进去看它会不会掉穿地板或者卡在墙里二是用rostopic list检查/clock、/gazebo/model_states这些话题是否正常发布。如果机器人掉穿地板说明地板的 collision 没生效检查collision标签是否写全。如果机器人卡在墙里多半是初始位置和墙体重叠了调整 spawn 的坐标即可。这一步是后续所有实验的基础务必确认无误再往下走。4. 常见问题与排查技巧实录4.1 Gazebo 启动黑屏或崩溃这是 Ubuntu 16.04 上最常见的问题九成是显卡驱动或 OpenGL 渲染的问题。先试软件渲染export LIBGL_ALWAYS_SOFTWARE1 gazebo如果软件渲染能起来说明是显卡驱动的事更新驱动或者换用兼容的 OpenGL 版本。另一个可能是 Gazebo 的在线模型库拉取卡死可以在启动时加--verbose看日志确认卡在哪一步。我遇到过一次是 DNS 解析慢把模型库地址在 hosts 里固定后就好了。4.2 模型加载失败或显示为灰色方块灰色方块意味着 Gazebo 找到了模型文件但没找到材质贴图。检查模型文件夹里是否有materials子目录以及model.sdf里material的路径是否正确。如果是 include 的官方模型确认~/.gazebo/models/下该模型完整。有时候是模型库版本和 Gazebo 版本不匹配换一个相近版本的模型即可。4.3 仿真运行卡顿、实时率低室内场景家具多、光照复杂时实时率可能掉到 0.5 以下。优化手段有几个降低real_time_update_rate到 150 或 100关闭不必要的阴影把家具模型的 collision 简化成包围盒。我实测过把实时率从 1000 降到 250CPU 占用能降一半而仿真结果的差异在导航任务里几乎看不出来。4.4 机器人模型加载后原地抖动这是物理引擎参数不匹配的典型症状。检查机器人的质量、惯量矩阵是否合理尤其是 link 的inertial标签。如果惯量设得太小求解器会不稳定。另一个原因是max_step_size太大调小到 0.001 试试。我一般会在机器人 URDF 里把 base_link 的质量设成 5 到 10 千克惯量按实际尺寸估算抖动基本就消失了。4.5 常见问题速查表问题现象可能原因解决方向启动黑屏显卡驱动/OpenGL软件渲染测试更新驱动模型灰色方块材质路径错误检查 materials 目录和 sdf 路径仿真卡顿更新率过高/阴影过多降更新率关阴影简化碰撞机器人抖动惯量参数不合理调整 inertial减小步长掉穿地板collision 缺失补全 collision 标签时间戳对不上use_sim_time 未设launch 里设为 true提示排查问题时养成看终端日志的习惯Gazebo 和 ROS 的报错信息通常很具体比盲目试错高效得多。5. 场景扩展与后续衔接5.1 从单房间到多房间布局单房间跑通后很自然想扩展成多房间模拟走廊加办公室的结构。做法是把墙体复制几份通过 pose 平移拼出隔断留出门洞。门洞宽度建议 0.8 到 1 米太窄机器人过不去太宽就失去走廊的意义。多房间场景对后续的全局路径规划更有挑战性也更接近真实办公环境。5.2 与建图导航的衔接这个室内环境搭好后下一步通常是加载机器人模型跑 SLAM 建图或者导航。需要确保 world 里的物理参数和机器人 URDF 兼容尤其是摩擦系数。地板摩擦系数设 0.8 左右比较合适太低机器人会打滑太高则转向困难。建图时建议先用 teleop 手动控制机器人走一圈确认激光雷达数据正常再启动 SLAM 节点。5.3 场景文件的版本管理world 文件和模型文件夹建议一起纳入 git 管理但~/.gazebo/models/里的官方模型不用管那是公共资源。自定义模型放在仿真包的models目录下world 文件里用相对路径引用这样换机器时整个包拷过去就能用。我习惯在 world 文件头部加注释记录修改日期和改动内容时间久了回头看能省很多事。5.4 性能与精度的平衡经验仿真永远是在性能和精度之间找平衡。室内场景不需要毫米级精度所以物理步长可以放宽光照可以简化模型可以降面。我的经验是只要机器人能稳定运行、传感器数据合理、导航算法能收敛这个场景就是合格的。追求极致逼真反而会拖慢开发节奏得不偿失。最后分享一个我常用的技巧把常用的 world 配置和机器人 spawn 写成一个组合 launch 文件一条命令启动整个实验环境。这样每次调试不用重复敲命令也避免了手动操作带来的不一致。时间长了你会发现这种自动化的小习惯比任何高深算法都更能提升日常开发效率。