Gazebo是ROS2生态中应用最广泛的仿真环境，但多数开发者只用到了它的基础功能。这篇文章不谈怎么添加传感器、怎么写URDF，而是聊一些在使用Gazebo过程中容易被忽略的技术细节——那些理解了能省下大量调试时间、不理解会反复踩坑的事情。
一、通信桥接：两种世界观的碰撞
Gazebo和ROS2的通信架构设计，反映了两种不同的工程哲学。
1.1 Gazebo Classic的通信协议
Gazebo Classic（版本11及以前）使用基于Boost ASIO的TCP/IP通信，消息序列化采用Google Protobuf。它的节点模型是“客户端-服务器”结构：一个gzserver进程负责物理计算和世界状态维护，一个gzclient进程负责图形界面。两者之间通过Gazebo Transport（一套基于Protobuf的自定义RPC机制）通信。
这个架构在ROS1时代很合理——因为ROS1本身也是基于TCPROS的。但Gazebo自己维护了一套完整的传输层，意味着你在Gazebo内部开发的插件，完全不需要依赖ROS就能运行。这是Gazebo的一个核心设计：它是一个独立于ROS的仿真框架，ROS只是它的一个“外围接口”。
1.2 新版Gazebo（Ignition/Gazebo）的架构变化
从Ignition（现称Gazebo，但社区常称“新Gazebo”）开始，通信层重构为gz-transport，同样基于Protobuf，但采用了更现代的设计。更重要的是，新Gazebo从“单一进程”拆分为多个独立组件：gz-server、gz-gui、gz-transport、gz-physics、gz-rendering等。每个组件可以独立运行，通过gz-transport通信。
这个变化的意义是：你可以不启动图形界面运行仿真（headless模式），也可以替换物理引擎而不影响其他组件。代价是：配置变复杂了。
1.3 ros_gz_bridge：两个世界的翻译器
Gazebo和ROS2采用完全不同的通信协议——Gazebo基于Protobuf/TCP，ROS2基于DDS。消息格式不兼容、通信协议差异、时间系统不同步，三者构成了桥接的核心难点。
ros_gz_bridge的核心功能就是在这两套协议之间做实时翻译。每个需要互通的话题都需要单独配置方向，例如：
或使用简写语法：/scan@sensor_msgs/msg/LaserScan@gz.msgs.LaserScan。
目前支持的话题类型约40种，但不支持ROS2的Service。如果需要控制Gazebo中的模型生成/删除，需要走另外的接口。
1.4 use_sim_time的隐性约束
这是新手最容易忽略的问题。在Gazebo+ROS2的环境中，use_sim_time必须设置为True，ROS2节点才会使用Gazebo的仿真时钟而非系统时钟。否则TF变换会出问题——具体表现为机器人有坐标但没有移动，或者定位持续漂移。
但有一个边界情况：如果在仿真过程中动态启动某个节点，且该节点没有正确继承use_sim_time参数，它的时间基准会和系统其他节点不同步，导致消息被丢。
解决方式：在launch文件中统一设置use_sim_time，并通过参数文件传递给所有节点。
二、性能瓶颈：为什么CPU总是跑不满
Gazebo的性能问题是一个老话题，但很多人的理解停留在“多给几个CPU核心就能快”这个层面。
2.1 ECM是核心瓶颈，不是CPU核心数
Gazebo Roadmap明确指出，性能瓶颈主要在Entity Component Manager、libsdformat、物理引擎和渲染系统四个部分。ECM负责管理仿真世界中的所有实体（模型、链接、传感器），每个仿真步长都需要遍历ECM进行状态更新。ECM的遍历是串行的，增加CPU核心并不能加速这个过程。
这意味着：当你添加100个相同的简单模型时，仿真速度下降不是因为CPU不够，而是ECM遍历所有实体需要的时间线性增加。实测数据：在单机配置下，100个带简单碰撞形状的机器人，实时系数通常降至0.4-0.6。多核CPU无法解决ECM串行遍历问题。
2.2 物理步长、实时系数与求解器类型
Gazebo的物理引擎支持ode、bullet、dart等后端。物理步长（max_step_size）默认0.001秒（1000Hz）。这在单机器人仿真中可行，但在多机器人场景下会严重拖慢性能。
一个被验证的优化方式：将步长改为0.002秒（500Hz），实时系数可提升约40%。但步长增加会导致碰撞检测精度下降，快速运动物体可能“穿模”。需要在精度和性能之间权衡。
求解器类型也有影响：dantzig求解器在接触较多的场景下速度较慢，quick求解器更快但精度较低。在URDF的<gazebo>标签中可指定：
2.3 多线程配置不生效的常见原因
一个常见场景：用户配置了<thread_count>8</thread_count>，但gz_sim_server仍然只用一个核心。根本原因：物理引擎的多线程支持有限。例如ODE的后端求解器本身不是完全并行化的。设置thread_position_correction=true可以启用位置校正的并行计算，但主循环仍然是串行的。
此外，设置环境变量GZ_SIM_SYSTEM_THREADS=8需要重启gz-server，并且某些系统版本下可能被覆盖。
2.4 渲染线程与物理线程的隔离
Gazebo新版的一个特性是：渲染和物理可以在独立线程中运行。但默认配置下两者仍有一定耦合。如果不需要可视化（例如批量仿真、强化学习训练），强烈建议关闭GUI或使用无头模式：
gz sim -r -s --headless-rendering world.sdf
这个模式下不加载渲染后端，物理计算可获额外性能。
三、传感器噪声与惯性参数：仿真是为真实准备的
Gazebo的传感器默认输出完美数据，但真实的传感器是有噪声的。如果不加噪声直接在仿真中调试感知算法，部署到真实机器人后必然出问题。
3.1 Ray传感器（激光雷达）的高斯噪声
Ray传感器支持为每个波束添加高斯噪声：
标准差0.02表示测量距离有约±4厘米的误差（2σ范围）。添加噪声后，测量值会被钳位在传感器的min/max范围之内。
3.2 IMU噪声的特殊性
Gazebo的IMU是个“异类”：它默认不是完美的。IMU的加速度和角速度测量需要配置<noise>参数，且IMU的积分漂移需要在后处理中模拟（Gazebo本身不会自动生成漂移）。
3.3 Camera传感器的高分辨率陷阱
当模拟高分辨率相机时（如1080P、4K），GPU显存和渲染带宽会成为瓶颈。一个实测案例：使用U3-3990CP相机（约1200万像素）在Gazebo Harmonic中，启动图像话题订阅后仿真性能急剧下降。
3.4 惯性参数的重要性
很多人从URDF导出时直接省略<inertial>标签，让Gazebo自动计算。但在多体动力学仿真中，惯性参数会显著影响接触力和运动响应。合理做法：使用Meshlab或SolidWorks等工具计算真实惯性矩阵，并在URDF中显式指定。自动计算往往低估转动惯量，导致旋转响应过快。
四、从Gazebo Classic到新Gazebo：隐性成本
Gazebo Classic已于2025年1月停止维护，新版本带来了架构升级，也带来了迁移成本。
4.1 SDF文件不兼容：相同文件，不同行为
新版SDF增加了对<include>标签中Fuel URI的原生支持（如https://fuel.gazebosim.org/...），可以直接从云端加载模型。但材质系统变化最大：旧版的<script>标签引用的gazebo.material脚本在新版中不再自动加载，需要改用直接的<ambient>/<diffuse>颜色定义。
实际迁移案例：某个含ground_plane、room、bookshelf模型的世界文件，在新版中所有模型渲染为黑色，原因正是材质引用路径不兼容。
4.2 插件接口彻底改变
Gazebo Classic的插件继承自ModelPlugin，新版改为实现System接口。这意味着所有自定义插件需要重写。
一个具体例子：Gazebo Classic的差速驱动插件libgazebo_ros_diff_drive.so，在新版中变为gz-sim-diff-drive-system，参数名也变了（例如wheelSeparation→wheel_separation）。直接复制旧URDF文件会导致插件加载失败。
4.3 包名映射关系
Gazebo Classic | 新版Gazebo |
|---|---|
gazebo_ros_pkgs | ros_gz |
gazebo_ros_control | gz_ros2_control |
libgazebo_ros_diff_drive.so | gz-sim-diff-drive-system |
新版包名遵循ros-<distro>-<package>格式，例如ros-jazzy-ros-gz。如果你在Ubuntu 24.04 + ROS2 Jazzy上试图安装ros-jazzy-gazebo-plugins，会发现不存在——因为包名已经变了。
五、多机器人仿真的实际问题
5.1 协商阶段的CPU峰值
在Open-RMF多机器人调度系统中，协商阶段（多机器人对交叉路口通行权的仲裁）CPU使用率会瞬间飙升至100%。这是rxcpp响应式编程框架的特征：它根据检测到的硬件线程数创建等量线程池，任务量大时所有线程满载。目前用户无法直接调节线程池大小，需要修改源码或接受协商期间的高CPU占用。
5.2 多线程不均衡的根本原因
gz_sim_server在典型配置下主线程负载可达100%，其他线程闲置。根本原因在于物理求解器本身不是为高度并行设计的。新版Gazebo引入了gz-physics插件系统，理论上可替换并行化物理引擎，但目前实际效果有限。
5.3 超实时仿真
Gazebo可以运行得比真实时间更快——通过设置<real_time_factor>0.0</real_time_factor>禁用实时限制。配合SIM_SPEEDUP参数可实现2-3倍速运行，但物理步长上限会限制加速效果。加速运行时的稳定性需要逐场景验证。
六、几个常见故障的具体排查
6.1 Gazebo启动成功但模型显示黑色
这是从Gazebo Classic迁移时最普遍的问题。原因：新版对材质引用方式要求更严格，旧版材质脚本不再自动加载。解决方法：将所有<material>中的<script>替换为直接的<ambient>/<diffuse>颜色定义。
6.2 Nav2规划出路径但机器人不动
Nav2发布/cmd_vel_nav，但Gazebo中机器人无响应。可能原因：插件接收的话题名不匹配。新版差速驱动插件默认订阅cmd_vel，但Nav2发布的是/cmd_vel_nav。解决方法：在插件的<topic>参数中明确指定话题名。
6.3 仿真运行一段时间后物理爆炸
通常发生在两个模型发生高速穿透时。物理步长过大或求解器精度不足是主因。降低<max_step_size>或启用<contact_surface_layer>参数可缓解。
结语
Gazebo是一个庞大的项目，从Classic到新版的架构变迁仍在进行中。理解通信桥接的底层逻辑、知道性能瓶颈的真正所在、掌握从旧版迁移的隐性成本，可以避免在实际项目中被这些问题卡住。
