无人机VS地面机器人：AirSim与Gazebo在ROS2仿真中的实战对比

无人机VS地面机器人用AirSim和Gazebo玩转ROS2仿真的5个实战场景对比做机器人仿真这些年我前后折腾过不下七八套仿真方案从最早的Stage到后来的Webots、CoppeliaSim再到老牌的Gazebo和微软开源的AirSim每套都踩过不少坑。最近半年因为项目需要我把两套主流的机器人仿真平台——AirSim和Gazebo——分别接进ROS2 Humble里用无人机和地面机器人各跑了一遍常见任务今天就把这段实战经历整理一下。先说结论AirSim和Gazebo并不是简单的“二选一”关系它们俩擅长的东西完全不一样。AirSim出身游戏引擎画面真实感、传感器噪点仿真、物理碰撞细节做得极其出色尤其适合无人机这类视觉感知密集的任务Gazebo则是ROS生态里的老大哥插件丰富、社区量大、和ROS2的集成几乎是无缝的地面机器人、机械臂、多智能体调度这类“以控制逻辑为核心”的仿真它依然是首选。这篇文章适合已经把ROS2基础跑通、正准备给项目选仿真平台的开发者也适合刚入坑机器人、想搞清楚“我到底该学哪个仿真器”的新手朋友。我会把5个实战场景从环境搭建到最终结果一次讲透包括版本选型、通信桥接、传感器参数配置这些绕不开的细节最后附上我在实际调试中踩过的一些坑。1. 为什么同时折腾两套仿真平台1.1 两个平台的定位差异在开始实战之前先搞清楚一件事AirSim和Gazebo的设计初衷就不一样搞清楚这一点后面选型就轻松很多。Gazebo的核心定位是“机器人算法验证的物理引擎”。它和ROS深度绑定整个架构围绕传感器插件、模型插件、控制器插件来设计。你在Gazebo里仿真的重点不是“画面多精致”而是在规定好的物理规则下你的算法能不能跑通。地面机器人、机械臂、移动底盘这类低速、强逻辑、多传感器融合的场景Gazebo几乎是无脑首选。代价就是它的渲染能力很弱光照、纹理、真实感都比不上游戏引擎级别如果做视觉SLAM或者视觉目标检测这类强依赖图像的任务Gazebo默认的合成图像和真实图像差异偏大算法在仿真里能跑通上真机容易翻车。AirSim正好补上这个短板。它是基于虚幻引擎Unreal Engine开发的光照模型、材质反射、物体纹理都是游戏级渲染图像仿真度非常高。同时AirSim对无人机的旋翼动力学做了专门建模尾桨效应、地面效应、叶尖涡这些都有近似模拟飞控的响应曲线和真实物理世界非常接近。代价是它对地面机器人的支持比较弱虽然可以通过Car模式改造但整体生态还是以空中平台为主自定义机器人模型也不太方便。1.2 这套方案的组合逻辑我在项目里为什么两套都用了因为实际任务需求横跨了空地两个维度单平台根本吃不下。做无人机自主巡检时需要高度逼真的视觉画面让视觉SLAM和物体检测算法在仿真里先得到足够接近真机的验证这个需求AirSim最合适。做地面机器人的路径规划与避障调度时需要频繁调参、快速迭代同时要无缝对接ROS2的导航栈Nav2、代价地图、TF树这些这个需求Gazebo加ROS2是绝对的主场。所以我的整套方案实际是组合拳AirSim负责视觉算法验证和无人机动力学仿真Gazebo负责地面机器人的控制与导航仿真两者通过ROS2的话题通信各干各的。下面5个实战场景就是在这套双平台架构下跑的我尽量把每个场景从需求分析、配置方法到结果对比讲清楚。2. 环境搭建与工具链选型2.1 版本匹配是最大的坑先说环境版本这个坑我替你们踩过了。ROS2目前主流的发行版是Humble适配Ubuntu 22.04和Jazzy适配Ubuntu 24.04。我建议绝大多数人直接用Ubuntu 22.04 ROS2 Humble因为Humble是LTS版本社区资料最全遇到问题搜得到答案。Jazzy虽然更晚、支持时间更长但目前很多第三方包还没完全跟上来新手容易卡在环境问题上。Gazebo这边要特别注意ROS2 Humble默认搭配的是Gazebo Fortressubuntu 22.04而老教程里大量出现的Gazebo 11Gazebo Classic是ROS1时代的东西不能和ROS2直接集成。如果你在Ubuntu 22.04上装了ROS2 Humble又想用ros_gz这种官方桥接包那就必须安Fortress。Ubuntu 24.04 ROS2 Jazzy对应的则是Gazebo Harmonic。不同版本之间的SDF格式、插件API都有差异教程一定要对着版本看不然照着复制粘贴就会在启动的时候爆一堆找不到lib的错。AirSim的环境就相对独立它跑在Windows或Linux的Unreal引擎之上只需要按照官方文档编译AirSim插件即可。Ubuntu下编译AirSim需要先装好Unreal Engine源码版这个过程比较大大概要下载几十个G而且需要注册Epic账号。如果只是做算法验证不追求极致画质用AirSim CityEnvironments这种预设的城市场景包就够了不必自己新建场景。我的建议是如果你是从零开始先按Ubuntu 22.04 ROS2 Humble Gazebo Fortress搭建这套组合最稳。等基础跑通了再去折腾AirSim因为AirSim那块对硬件和编译环境的要求明显更高。2.2 ROS2与仿真器的桥接方式Gazebo与ROS2之间的通信走的是“微服务式”的桥接包叫ros_gz。它不像ROS1里gazebo_ros那样是单一的插件体系而是用ros2 run ros_gz_bridge parameter_bridge命令来把Gazebo的话题转发成ROS2话题。比如把Gazebo里IMU数据转发成ROS2的/sensor_msgs/msg/Imu命令大概长这样ros2 run ros_gz_bridge parameter_bridge /imusensor_msgs/msg/Imugz.msgs.IMU每条桥接命令都要指定话题名、消息类型两边对应关系。写一个launch文件把这些桥接规则统一管理起来是必须的不然手动敲命令能敲到怀疑人生。AirSim的ROS2连接走的是airsim_ros_pkgs包。它会开启一个ROS2节点把AirSim里的相机图像、里程计、IMU数据发布成ROS2话题同时订阅ROS2的速度指令话题来控制无人机。图像话题支持压缩图像和原始图像两种格式我强烈建议先用压缩图像做调试因为几路摄像头同时传原始数据带宽占用非常恐怖。版本这块还有很多细节比如ROS2和Python版本要匹配装colcon扩展要用pip安装对应版本这些我后面碰到具体问题了再展开说。总之一句话环境版本的组合错了一位后面全是无用功。3. 5个实战场景逐一对决现在进入正题。这5个场景是我根据自己项目里最典型的仿真需求挑出来的覆盖了感知、规划、控制、协同四类核心功能。每个场景我都用两套平台分别跑了一遍这里给出完整的过程和对比结论。3.1 场景一二维栅格地图构建与SLAM场景描述让机器人在地图未知的环境里自主移动通过雷达和里程计数据构建环境地图。这是机器人最基础的“定位与建图”需求。地面机器人我用的是差速底盘模型搭载二维激光雷达跑的是ROS2里最常用的slam_toolbox。Gazebo侧配置一台2D激光雷达扫描线数设为720扫描范围270度更新频率设为10Hz。这些参数基本对标真实二代雷达的量级。Gazebo自带一个好处模型库里有现成的差速底盘加一个gpu_ray插件就能直接广播出/scan话题不需要额外写传感器插件。桥接和启动一切正常slam_toolbox直接订阅话题构建地图默认分辨率每格5厘米效果非常稳定。整套跑下来地图轮廓清晰回环修正也能正常工作——比如我让小车绕了一个大圈回到原点地图没有出现明显的重影或断层。AirSim侧没有现成的地面机器人我用它提供的Car模型改造了一个简化底盘加了一个二维雷达传感器。AirSim的激光雷达输出的是点云数据PointCloud2和Gazebo直接输出二维scan不同需要自己把点云投影成二维栅格数据。我在ROS2里写了一个转换节点把垂直方向一定高度范围内的点云压缩成二维scan再用slam_toolbox建图。因为这个插件扫描范围和频率都不好自由调节对比下来地图效果明显比Gazebo要粗糙一些偶尔还有一些飞点。结论很明确纯做二维SLAM建图Gazebo对地面机器人是绝对的主场。AirSim在这块优势发挥不出来还要额外做数据转换性价比不高。3.2 场景二三维感知与障碍物规避场景描述机器人在三维环境中感知周围的障碍物并通过局部规划进行避障。这个场景我重点测试深度相机和点云数据的质量。Gazebo这边用RGB-D相机插件模拟深度相机输出深度图、彩色图、点云三类数据。我让地面机器人穿越一个摆放了不同高度障碍物的走廊用Nav2自带的局部规划器做避障。Gazebo的深度相机有个特点物体表面材质对深度值影响很大。有些半透明的物体深度图会出现空洞。但真机上的RGB-D相机也会有这个问题所以反而说明Gazebo的模拟有一定物理真实性。AirSim这块就体现出它的画质优势了。同样的走廊场景AirSim里深度图边缘干净利落物体轮廓清晰点云密度高且噪声模式接近真实传感器。我跑了一个基于深度相机的VFH避障算法反应速度很快基本没有因为图像质量问题产生误判。不过需要注意一个关键问题AirSim的深度图像值范围是可以调的。默认情况下深度值以米为单位的浮点存储但也可以改成厘米或毫米整数型方便直接转成点云。这个参数如果不对点云会整体错位或缩放我第一次用默认设置时点云坐标全是乱的后来才发现是深度值单位的问题。结论如果是做视觉驱动的避障或者依赖深度图的感知任务AirSim的仿真质量明显更高尤其是涉及到光照变化和物体纹理的场景AirSim的表现更接近真实世界。Gazebo胜在快但图像的“真实感”和“信息保真度”确实不如AirSim。3.3 场景三视觉目标识别与跟踪这个场景是无人机最典型的一个任务——从俯视视角识别地面上的目标物体然后持续跟踪目标移动。Gazebo里我加载了一个城市场景模型在场景中放置几个不同颜色的小车作为跟踪目标无人机模型上挂载一个前置摄像头。因为Gazebo的图像渲染比较简单目标车的纹理识别主要靠颜色特征。我用OpenCV写了一个基于颜色阈值的目标识别节点识别效果还算稳定但稍有光线变化比如场景里光源角度变化颜色阈值就要重新调试。如果云端纹理稍微复杂一点识别率降得非常厉害。AirSim的画面真实感就完胜了。我在AirSim的CityEnvironments预设场景中放置了几辆颜色不同的车辆。无人机的摄像头视角经过游戏引擎渲染画面里远处的地面建筑、路面标线、车体反光都清清楚楚。还是用同样的OpenCV颜色识别节点在AirSim里识别率明显更高画面干扰对颜色提取的影响更小。后续我还试着换成了基于YOLOv5的目标检测用仿真画面做预训练测试集训练出来的模型放在AirSim的仿真场景里测试mAP能达到真实场景的八成左右。这是一个非常关键的对比结论——如果你的算法最终要部署到真机上做视觉识别AirSim的仿真画面作为训练和验证集的价值远比Gazebo高。但AirSim也有个问题摄像头内参标定比较麻烦不同虚拟相机的视场角、分辨率、水平偏移参数需要手动设置如果跟实际使用的相机规格不匹配算法迁移到真机上会出现尺度错误。结论视觉任务无脑倾向AirSim尤其是涉及深度学习目标检测、语义分割这类对图像质量敏感的任务。Gazebo更适合验证“识别到目标之后”的控制逻辑而不是识别算法本身。3.4 场景四多智能体协同任务场景描述多台机器人可以是无人机编队也可以是地面机器人车队协同完成一个任务比如多车共同覆盖一个区域、多机编队飞行。Gazebo对多智能体的支持非常成熟。我用一个launch文件一次拉起3台地面机器人每台机器人都有独立的命名空间robot1、robot2、robot3各自的话题通过命名空间隔离TF树完全独立。Nav2自带多机器人支持通过不同命名空间就能各自导航不会产生话题冲突。我测试了3台机器人同时向不同目标点导航Gazebo跑得很稳CPU占用率也不高。这得益于Gazebo多年的多智能体调试积累几乎所有环节都替你考虑到了。AirSim的多无人机支持也还可以它本身支持加载多个无人机实例airSim_ros_pkgs也提供了多机支持模式。但问题在于每加一台无人机就需要一个独立的Unreal渲染进程对GPU和内存的消耗成倍增加。我测试了2台无人机同场景飞行帧率掉了近40%。如果做编队飞行这种需要高刷新率的控制实验AirSim的多机性能确实扛不住。性能对比我用了一个简单的指标同样是2台机器人或无人机在Gazebo里控制频率能跑到100Hz以上在AirSim里勉强稳定在30Hz。如果你要做高动态的编队算法、集群避碰实验Gazebo是更合理的选择AirSim更适合在精细画质下同时跑2到3台机器人的小规模协同任务。3.5 场景五模型在环与算法功能测试最后一个场景比较实际——把仿真当成“测试平台”验证算法能不能跑通也就是MIL模型在环测试。很多团队在把算法部署到真机前都会先在仿真里做一轮完整的回归测试。Gazebo在这里的优势是启动速度快、无头模式无UI界面支持优秀。我写了一个自动化测试脚本每天凌晨批量跑200个随机场景的导航测试Gazebo可以完全在无UI模式下运行只保留HEADLESStrue的启动参数CPU占用稳定一晚上能跑完所有用例自动生成通过率报表。这种批量化、自动化测试的需求Gazebo的效率和稳定性都远超AirSim。AirSim因为依赖Unreal引擎基本上必须渲染画面才能运行无头模式支持不佳。跑批量测试就要一直开着GPU功耗和硬件成本都上去了。但AirSim有一个独特优势支持场景编程和动态环境生成。我可以在飞行过程中实时改变光照条件比如从晴天切换到黄昏、动态生成障碍物、插入雷雨天特效这种“极端环境注入”能力是Gazebo不具备的。在做视觉算法的鲁棒性测试时这种动态环境变化非常有用Gazebo要改环境得先改SDF文件重新加载做不到实时切换。结论功能回归测试、CI集成测试选Gazebo需要模拟复杂视觉环境的鲁棒性测试选AirSim。4. 两套平台的综合对比与选型建议4.1 核心指标对比表为了让你对照方便我把5个场景里表现差异最大的几个维度整理成了一张表对比维度GazeboFortress ROS2 HumbleAirSimUE4 ROS2 Humble图像仿真真实度一般合成感重极高接近真实相机物理引擎可靠度高适合控制逻辑验证高旋翼动力学出色地面机器人支持极好模型库丰富较弱需改造Car模型多机并发性能非常强CPU优化好较差吃GPU显存无头模式支持极好适合批量测试很差必须渲染搭建难度低ROS生态一体高需编译UE工程与ROS2集成原生级桥接简单较复杂需自定义桥接社区资料丰富度极高中等4.2 我的选型逻辑经过这5个场景的实测我总结了一套自己的选型口诀控制算法用Gazebo视觉算法用AirSim地面平台用Gazebo空中平台看需求批量测试用Gazebo画质验证用AirSim。具体来说如果你做的是路径规划、导航调度、多机协同、底盘控制这类“逻辑密集型”任务Gazebo能帮你省下大量折腾环境的时间而且跑得快、跑得稳。如果你做的是无人机视觉巡检、目标识别、视觉避障这类“感知密集型”任务AirSim的画面质量能让你的视觉算法在仿真阶段就得到较充分验证大幅降低上真机后“仿真能跑、真机翻车”的概率。当然最好的情况是两套平台都掌握在自己的项目里搭配使用。比如我就经常把Gazebo和AirSim接在同一个ROS2系统里Gazebo管理地面导航AirSim管理空中视觉巡航两套仿真数据统一汇聚到一套ROS2调度框架里整体开发效率确实高了不少。5. 常见问题与排查技巧实录5.1 Gazebo界面一直在闪很多人在Ubuntu 22.04下启动Gazebo Fortress时遇到过界面疯狂闪烁的情况这个问题我排查了很久。原因主要是GPU驱动问题或OpenGL版本不匹配。先检查一下显卡驱动的OpenGL支持glxinfo | grep OpenGL version如果返回的是OpenGL 2.1之类的老版本说明你已经进到LLVMpipe软件渲染模式了需要重装显卡驱动。如果驱动没问题但界面仍然闪烁试试设置环境变量export LIBGL_ALWAYS_SOFTWARE1但注意这样会强制软渲染可以用但是性能会大打折扣。还有一种可能是Gazebo Fortress默认启用Vulkan渲染而旧显卡不支持可以在启动时禁用硬件加速。如果你用的是虚拟机我建议直接放弃在虚拟机里跑Gazebo界面用无头模式加可视化工具是更务实的办法。5.2 AirSim点云坐标混乱我在场景二中提到过AirSim的深度相机输出数值单位影响点云坐标。AirSim的深度值有三种输出模式DistanceToPlane平面距离、DistanceToCenter中心距离、Disparity视差数值可以是float米或int厘米。我用的ROS包默认按“米”解析但AirSim的UE4插件侧如果设成了厘米两边一对接点云就乱了。排查方法是先放置一个已知距离的物体用Rviz里的点云测量工具量一下距离如果偏差一个固定倍数基本上就是单位问题。5.3 ROS2桥接后话题不出现Gazebo里明明有传感器话题但ROS2里就是找不到。八成是忘了启动ros_gz_bridge。Gazebo与ROS2的消息不是天然打通的必须通过参数桥接。我建议AMCL、Nav2这类核心节点的输入话题第一批就要桥接到位不然后面排查起来根本分不清是节点没启动还是话题没桥接。写一个集中管理的launch文件把所有传感器的桥接规则写进去启动省心非常多。5.4 无人机在AirSim里起飞后飘移AirSim默认开了非常完整的风场和空气动力学模型很多人第一次用无人机模式时发现飞机悬停不住一直飘。这不一定是你控制算法的问题可能是环境中风场初始化太强了。在AirSim的settings.json里可以关掉或调小风场参数{ Wind: { Enabled: false } }如果你是想做控制算法验证先把风场关掉跑通基础逻辑再加风扰测试。另外飞行模式建议先选API模式而不是遥控模式否则ROS2的速度控制指令不会被正确接收。5.5 环境版本不匹配问题汇总这里我把常见的版本坑汇总一下症状原因解决办法找不到ros_gz_bridge包Gazebo版本与ROS2不匹配Humble装FortressJazzy装Harmonic启动时找不到libgz-transportGazebo依赖库不完整用官方安装脚本重新安装gazeboAirSim编译报UE4宏错误UE4版本与AirSim分支对应关系错误严格按照AirSim官方文档选择UE4版本ROS2话题延迟极高仿真器发布频率与传感器参数不匹配统一时间步长和发布频率关闭不必要的可视化5.6 关于GPU性能的几个建议最后聊一下仿真性能。如果你有RTX系列显卡Gazebo可以利用CUDA加速物理运算AirSim的渲染更是吃GPU的大户。有两个小技巧一是把渲染分辨率调低到720P甚至更低的百分比视觉效果对于算法验证来说已经够了二是把所有不必要的后期处理特效关掉例如动态模糊、景深、体积光这些对仿真实验没有任何帮助白费GPU性能。GPU显存不够时不要开多无人机并行老老实实一台一台跑。关于Gazebo的GPU加速不少人也问过。其实在Gazebo Classic时代gpu_ray支持硬件加速到Fortress之后渲染后端变成OGRE 2.x对显卡要求反而变高了但用法上基本透明无需主动配置。6. 最后几点经验这套双平台仿真方案跑了大半年积累了几条真实经验分享给准备入坑的朋友。第一不要迷信任何单一仿真平台的“完美”宣传。每个仿真器都只是真实世界某个面向的近似Gazebo近似得好的是物理交互AirSim近似得好的是视觉感知和空气动力学。知道自己要验证什么才知道该选哪个。第二仿真里能过不代表真机上能用。仿真永远不可能完全复现真机的未知因素但仿真里过不了真机上大概率更过不了。我把仿真当作“保守过滤器”先用Gazebo验证控制算法逻辑再用AirSim模拟接近真机的视觉约束两轮仿真都过了上真机的成功率会大很多。第三做仿真一定要控制好软件版本依赖关系。ROS2、Gazebo、UE4这类大型软件叠在一起最长的一个环境我搭了三天才跑通。我的建议是每完成一步就做一次备份尤其装完基础环境后一定打一个快照或做一个镜像后面环境坏了恢复起来非常快。第四最终要形成自己的“仿真配置模板”。当你把一套Gazebo多机器人配置、AirSim无人机配置跑通一次之后把它固化成模板后面所有新项目都从模板起步不要每次都从零开始配。我现在的模板里已经写好了全套的launch文件、传感器参数、桥接规则、Rviz配置新项目半天就能跑起来第一个Demo。这套“AirSimGazeboROS2”的组合基本能覆盖我目前能想象到的绝大多数机器人仿真场景。后续我打算在这个基础上尝试接入更多的开源生态比如把PX4固件接到AirSim去做更精细的飞控在环仿真再把Nav2做更深度的参数调优测试。仿真这条路没有终点每一个新的需求都是对平台认知的一次刷新。