先把结论放在前面如果你要在ROS2生态里同时折腾无人机和地面机器人AirSim和Gazebo不是二选一的关系它们更像是两把不同用途的刀。Gazebo是“机器人实验室标配”传感器模型、物理碰撞、ROS2话题集成都是土生土长的好手AirSim则是“视觉与场景之王”光照、天气、城市地形做出来特别接近真实拍摄效果。这篇文章我就拿5个实战场景来对比它们分别是室内SLAM与导航、室外GPS/视觉导航、视觉目标识别与降落/跟随、三维八叉树地图避障、多机协同编队。每个场景我会直接给出“无人机用什么、地面机器人用什么、推荐哪个仿真器、为什么”顺便把环境搭建、版本选型、以及我踩过的一些坑一并交代清楚。适合刚入门ROS2、或者已经跑通过小乌龟但还没真正玩过仿真平台的人也适合准备用仿真做毕设或者预研项目、但还在犹豫到底该学AirSim还是Gazebo的读者。Gazebo和AirSim放在同一个工作区里不是不可能但要有章法。我最开始是老老实实先装了Gazebo后来为了做无人机视觉任务又去编译AirSim中间因为版本不对、环境变量冲突、重复依赖包直接把ROS2环境搞坏过一次。所以这篇文章也会把这些被虐出来的经验一起写上能帮你少走一些弯路。1. 先把底座概念理清无人机和地面机器人在仿真里差在哪1.1 动力学模型是完全不同的世界很多人以为仿真就是把模型文件换一下轮式机器人换成四旋翼继续跑原来的导航栈就行。这是最大的误区。地面机器人尤其是两轮差速或者四轮阿克曼车型在仿真里主要被当作一个非完整约束系统来处理。它的运动学方程可以简化成“线速度角速度”轮子与地面的接触力、打滑、颠簸这些物理细节Gazebo默认的ODE物理引擎已经能处理得很好。而且轮式机器人跑起来速度慢、惯性小控制频率通常10Hz到50Hz就够非常宽容。所以你经常看到TurtleBot3在Gazebo里用默认参数就能稳定导航。无人机就完全不是一回事。四旋翼是六自由度刚体三个方向平移、三个方向旋转底层是一个“推力力矩”系统。螺旋桨转速变化带来的升力变化、每个电机的响应延迟、机身角速度耦合、甚至桨尖气流对附近桨叶的影响都会影响飞行姿态。这类系统需要高频控制姿态内环一般要跑200Hz以上而Gazebo里如果物理引擎步长太大、传感器更新太慢飞起来就像喝醉了酒左右摆得根本没有办法收敛。AirSim对无人机动力学细节的建模明显更认真它模拟了转子转速与推力的非线性关系还带了一定程度的地面效应模拟。所以同一个PID控制器在Gazebo里调好的增益拿到AirSim里大概率需要重新调甚至稳定性都不一样。这不是代码写错了是两套物理模型的“脾气”本身就不同。1.2 AirSim与Gazebo的定位差异一个重场景一个重生态我自己的总结是Gazebo的强项在“和ROS2无缝衔接”AirSim的强项在“看起来像真的”。这直接决定了它们适合的任务完全不同。Gazebo背后是经典机器人仿真路线它天生就带着“传感器插件”“物理插件”“模型插件”这一套设计思路。你可以很方便地给机器人模型添加激光雷达、IMU、RGB相机、深度相机每个传感器通过gazebo_ros插件发布成ROS2话题。这意味着你在Gazebo里验证的代码拿到真实机器人上只需要改一改传感器话题名称和参数逻辑基本可以复用。AirSim则更像是“游戏引擎里跑机器人”。它建立在虚幻引擎Unreal Engine之上默认环境是城市街区、停车场、山地、海岸线这些高视觉保真度的场景。传感器是“仿真摄像头”图像质量、光影效果、天气变化、时间阳光角度各方面都远超Gazebo。但它和ROS2的衔接是需要桥接的通过airsim_ros_pkgs这类包把相机图像、IMU、GPS数据转发到ROS2话题并不像Gazebo那样在启动时就把一切铺好。从学习成本看Gazebo安装相对轻量跑一个TurtleBot3也就几分钟AirSim编译时间长、还要下载虚幻引擎的资源Windows和Linux都折腾很多人第一次编译就劝退了。但从视觉任务的角度看如果你要做的算法最终要部署到真实无人机上做目标检测、跟踪、降落AirSim生成的图像会让模型泛化好很多。1.3 ROS2在中间到底扮演什么角色AirSim和Gazebo都是“仿真器”但ROS2是中间的粘合层。你写的导航、规划、控制、感知代码不应该依赖某个仿真器而应该只依赖ROS2的话题、服务、动作、参数、TF树。以TF树为例在Gazebo里机器人模型每增加一个刚体URDF会自动生成对应的TF关系base_link到laser、base_link到camera清清楚楚。在AirSim里无人机和车辆的坐标系虽然也有约定但如果你要接进ros2通常得自己维护TF树。很多新手在AirSim里跑RTAB-Map或者octomap时长时间卡在“等待Transform”这一步就是这个原因。所以我的建议是不管用哪个仿真器先把ROS2的话题模型、TF模型、时钟同步机制弄清楚。仿真器只是信号源真正的主干是ROS2这棵“树”。你只有理解了这一点后面做多机协同、做仿真到实机迁移才会顺利。2. 环境搭建从零把AirSimGazeboROS2跑通2.1 版本选择锁定版本才能省心ROS2和Gazebo的版本关系是所有新手最容易翻车的地方。ROS2每个发行版对应的Gazebo版本并不完全相同而Gazebo现在又分成了两条线老的Gazebo Classic比如Gazebo 11和新的Ignition Gazebo现在叫GZ Sim版本名是Fortress、Harmonic这些。ROS2里常用的gazebo_ros_pkgs插件不同版本的适配方式还不一样。我目前用得最稳的组合是Ubuntu 22.04 ROS2 Humble Gazebo Fortress也兼容Gazebo 11。这套组合教程多、踩坑记录多遇到问题随手一搜基本都有答案特别适合刚入门的人。如果你用的是Ubuntu 24.04那就走ROS2 Jazzy Gazebo Harmonic这是现阶段比较新的组合功能新、性能好但中文资料相对少很多旧教程里的命令要自己改一改。我个人建议除非你有明确的原因必须用24.04否则第一套仿真环境从22.04起步更省心。安装ROS2 Humble本体之后再安装Gazebo相关的ROS2适配包sudo apt install ros-humble-gazebo-ros-pkgs ros-humble-gazebo-plugins如果要用Ignition Fortresssudo apt install ignition-fortress装完之后记得检查环境变量确保两个包都能被找到。最常用的验证方式which gz ros2 pkg list | grep gazebo2.2 把Gazebo“闪屏”问题压下去一个经典环境变量排查你说的“gazebo界面一直在闪”我太熟悉了。这个现象我在WSL2里遇到过在远程桌面里也遇到过甚至在独显机器上没配好驱动也遇到过。表现是窗口里的3D画面不停闪烁模型表面像在疯狂重绘严重的时候整个界面根本没法用还时不时伴随高CPU占用。绝大多数情况是OpenGL渲染和GPU驱动的问题Gazebo默认要调GPU加速但环境里要么显卡驱动没装好要么虚拟显示环境下没有硬件加速所以它就只能不断尝试重绘。排查顺序我建议这样来先看显卡环境glxinfo | grep renderer在WSL2或者远程桌面这种没有完整GPU的环境下大概率会显示software渲染。这时可以强制Gazebo走软件渲染export LIBGL_ALWAYS_SOFTWARE1如果你是在树莓派、云主机或者虚拟机里跑这个环境变量能直接解决闪烁问题。代价是渲染性能下降复杂场景会卡但至少界面是稳定的。另外还有一个容易忽略的点WSL2本身对OpenGL的原生支持有限如果直接在WSL2里跑Gazebo闪屏几乎是必现的。解决办法要么是用WSL2的WSLg较新版本Windows会自动启用要么干脆在Windows原生环境装Gazebo或者用Docker跑ROS2再接VNC。我个人是建议在WSL2里调试ROS2程序、用RVIZ2看数据把Gazebo跑在另一台纯Linux机器上虽然配置复杂一点但不会因为显示问题浪费一天时间。2.3 AirSim搭建要点别小看编译时间AirSim的搭建比Gazebo重得多尤其是编译这一步。它需要你先有虚幻引擎UE环境才能构建出可运行的仿真环境。如果你是纯Linux用户还要先确认系统满足UE的运行条件A卡基本别想了N卡是最省事的。大致流程是克隆AirSim仓库执行setup.sh拉取依赖和第三方库然后执行build.sh编译核心模块。这一步耗时取决于机器性能半小时到两小时都正常。如果只做基础开发不需要修改AirSim源码建议直接编译打包好的版本可以省掉很多折腾。AirSim运行时的环境行为由Settings.json控制。常见的配置是这样的{ SettingsVersion: 1.2, SimMode: Multirotor, ClockSpeed: 1, Camera: [ { Name: FrontCamera, ImageType: 0, FOV: 90 } ], Wind: { Enabled: false } }SimMode可以切换成Multirotor无人机或Car地面车。这意味着同一个AirSim环境你既能跑无人机也能跑地面机器人做对比实验非常方便。和ROS2对接时用AirSim官方仓库里的ros2包编译后会生成airsim_ros_pkgs。启动后无人机的里程计、IMU、图像、GPS就会以ROS2话题形式发布出来理论上用RVIZ2就可以直接看到飞机位置和相机画面。初次跑通之后记得把“物理仿真频率”和“ROS2话题发布频率”对齐否则会出现图像时间戳乱跳的问题。2.4 双仿真器共存的工作区组织既然要对比AirSim和Gazebo两个仿真器就应该放在同一个ROS2工作区里。我习惯这样组织~/sim_ws/src/ ├── airsim_ros_pkgs/ ├── gazebo_ros_pkgs/ ├── my_robot_description/ ├── my_mission_gazebo/ └── my_mission_airsim/把每个任务相关的launch文件、参数文件、配置文件单独放在一个包里命名区分清楚。避免把Gazebo和AirSim的配置混在一个包里否则后面你自己都会看晕。还有几个容易踩的坑默认端口冲突、坐标系命名的重复。AirSim默认的RPC端口是41451Gazebo的通信端口也有自己的默认值两者一般不冲突但如果你用Docker端口映射就一定要检查坐标系方面如果两个仿真器发布的frame_id都叫“map”那RVIZ2里数据会串。我的做法是在launch文件里通过参数重映射给AirSim的frame_id加上前缀比如airsim/map、airsim/base_link这样两个仿真数据同时播放也不会乱。3. 五个实战场景对比3.1 场景一室内2D SLAM与自主导航——Gazebo为什么是默认答案第一个场景非常经典一台轮式机器人从起点出发扫描环境构建二维栅格地图然后规划路径走到目标点。这也是很多人学习ROS2导航栈Nav2的第一个完整项目。地面机器人做这件事Gazebo是毫无疑问的默认选择。拿TurtleBot3为例启动仿真环境、激光雷达、Cartographer或者Gmapping几百行launch文件就能全部跑起来。Gazebo的激光雷达模型带有合理的噪声物理碰撞也稳定运行几十分钟不会飘。整个过程几乎就是“照着TurtleBot3官方教程敲一遍”唯一要改的是把话题名和你的模型对齐。换成无人机后问题立刻变麻烦。二维SLAM对无人机来说只是一个平面约束无人机在室内还需要高度估计、姿态稳定、视觉或激光三维感知。你可以用Gazebo跑PX4软件在环仿真也可以装一个带激光雷达的四旋翼模型但在Gazebo里调无人机的姿态控制器本身就是一件磨人的事。水平位置误差稍微大一点激光点云就“糊”了建出来的二维地图全是重影。AirSim在这个场景里更适合做什么它的强项是给无人机提供更真实的室内相机视角和物理传感如果你做的是基于视觉的无人机SLAMAirSim的图像质量会让特征提取稳定不少。但如果你只是要学Nav2和Cartographer完全没必要动用AirSim。这个场景的结论很明确地面机器人用Gazebo一小时跑通无人机室内SLAM先做好调半个月的心理准备工具上选Gazebo或AirSim都有理由但Gazebo的调试生态更成熟。3.2 场景二室外开阔区域的GPS/视觉导航——AirSim终于发力说到室外大场景导航Gazebo就开始吃力了。Gazebo不是不能建室外地形你可以导入测绘地图、用高度图生成地形甚至可以摆上建筑物模型但每添加一个高精度的网格模型物理引擎的负载就直线上升。我在Gazebo里试过放一个中等规模的园区模型Gazebo启动后CPU直接拉满实时性掉到0.3倍速跑个无人机飞一圈地图数据出来都是卡的。另外一个硬伤是Gazebo的光照和材质渲染真实感很弱你用视觉SLAM时特征点提取效果明显不如真实场景。AirSim在设计上就是为了解决这些问题而生。它自带的城市街区、广场、停车场场景渲染精度高光照阴影接近真实相机而且支持季节、天气、时间调节。你在AirSim里可以同时打开GPS模块、气压计、磁力计和相机让无人机从A点按规划路径飞到B点整个过程里视觉画面、GPS噪声、IMU漂移都很接近真实飞行。如果在这个场景里换地面机器人也没问题AirSim里的车模同样能跑GPS导航只是地形物理反馈没有Gazebo细腻。但你要做的是开阔园区、楼宇顶、山地这类视觉特征丰富的室外任务AirSim是最优选。Gazebo想模拟室外视觉任务至少我还没见过不费劲的方案。真要做一般得给Gazebo装一些自定义材质和环境光插件折腾成本远超收益。3.3 场景三视觉目标检测与降落/跟随——图像真实感的分水岭第三个场景我拿视觉目标检测和降落来举例。典型任务是无人机在空中识别地面上贴着的ArUco码或者AprilTag然后调整机头朝向下降到码正上方一定高度并完成降落。地面机器人则可以做视觉跟随看到目标物后跟着走保持一个安全距离。Gazebo里做这个实验完全可以给环境里添加一个贴二维码的立方体模型Ignition Gazebo加载二维码模型现在很方便然后通过Gazebo的相机插件把图像发布到ROS2用OpenCV或者ros2_aruco包识别。这套流程好处是流程简单、闭环调试方便坏处是Gazebo渲染出来的二维码在边缘、光照、反射上过于“干净”你把识别算法换到真实相机上往往要重新调参。AirSim做这个任务的优势非常明显。你可以在仿真里直接调整阳光角度、加雾、换季节让二维码图案和各种难缠的光照情况接触。同一套图像识别代码我在AirSim里测试时基本不用怎么改参数换到真实无人机上第一次跑就识别成功了。而在Gazebo里训练的模型放到室外真实环境经常是误检一片。所以结论是如果这个场景的目标是验证控制逻辑Gazebo足够了效率最高如果你的算法最终要部署到真实设备我建议至少在AirSim里做一遍图像层面的验证。AirSim的“仿真到现实”鸿沟比Gazebo小很多。3.4 场景四三维八叉树地图与体素导航——Gazebo生态更顺第四個场景比较进阶直接用上热词里说的“八叉树地图导航”。三维导航和二维一个重要区别是地图不是栅格像素而是八叉树体素OctoMap。无人机在三维空间里避障必须知道障碍物在垂直方向上也占据哪些格点这样才能规划出一条不会撞天花板、也不会擦着障碍物边飞过的路径。Gazebo做这件事有一条非常成熟的技术链路Gazebo发布激光点云或深度点云octomap_server接收点云生成OctoMap然后通过RVIZ2可视化再结合三维路径规划算法或者更上层的导航栈做避障。这条链路上的每一环ROS2社区都有很多现成包和教程遇到问题很容易对标。我自己在Gazebo里跑室内无人机的OctoMap建图从启动到RVIZ里看到完整体素地图整个过程不会超过半小时。AirSim能不能做八叉树地图理论上可以把AirSim的深度相机转成点云再推给octomap_server就行。但实际上AirSim的深度相机输出格式、话题频率、坐标定义都要额外适配而且八叉树建图算法对传感器噪声和帧率敏感AirSim的默认参数未必合适。我做过的测试里AirSim生成的深度图在边缘处噪声偏大不加滤波直接喂给octomap_server地图上会出现很多“雾状”噪点。这个场景的选型结论非常清晰Gazebo是绝对主选。地面机器人在这里反而不太需要上升到三维体素二维costmap足够解决地板上的避障问题只有无人机这种需要在xyz三个方向移动的机器人才真正用得上八叉树地图。所以建议是做无人机避障导航专心玩Gazebo和octomap_server就够了。3.5 场景五多机协同编队与搜索——AirSim的官方支持更省力第五个场景是无人机和地面机器人混编或者各自编队执行搜索任务。多机协同的难点不在单机算法而在“多个代理之间的同步、通信、状态广播和碰撞避免”。Gazebo里多机仿真可以做到。你可以在同一张地图里加载多台TurtleBot3每台机器人有独立的命名空间和TF前缀各个节点的名字也都加上前缀区分。这个方案跑三台没问题跑七八台的时候物理引擎和渲染模块的资源竞争就非常明显。Gazebo本质上是一个单体仿真器所有机器人共享同一个物理世界机器人数量的增加对CPU、内存和物理步长的压力是线性的甚至超线性。AirSim的多无人机支持是原生级的。官方API可以直接在一个环境里创建多架飞机各自独立设置起点和任务用Python/C API分别控制。它甚至支持实时画面回传、多无人机协同任务脚本还内置了竞速、搜救类场景模板。用起来比在Gazebo里手搓多机器人命名空间舒服太多了。如果你要做的是无人机编队、协同搜索、多机视觉接力AirSim能让你把精力集中到任务逻辑上而不是纠结仿真环境配置。地面机器人编队我更倾向Gazebo这是因为轮式机器人的协同逻辑相对简单而且Gazebo对多车的物理碰撞处理比AirSim成熟。AirSim的车辆模型虽然能开但多辆车的超声波、雷达等传感器模拟没有Gazebo丰富。这场景可以这样组合多无人机编队用AirSim多地面机器人编队用Gazebo两边的结果再通过同一个ROS2网络做融合。3.6 选型结论一页纸实战场景首选工具备选工具理由和注意点室内2D SLAM与导航GazeboAirSim激光雷达噪声、Nav2集成好无人机做室内SLAM要做好长期调参准备室外GPS/视觉导航AirSimGazeboAirSim城市地形、天气、光照真实Gazebo大场景物理负载过高视觉目标检测与降落/跟随AirSimGazeboAirSim图像更接近真实相机Gazebo适合先验证控制逻辑三维八叉树地图避障GazeboAirSimoctomap_server生态完整AirSim深度点云噪声需要额外处理多机协同编队与搜索AirSimGazeboAirSim多无人机API原生支持Gazebo多车物理资源消耗大这段表格不是“标准答案”而是我个人在项目实践里按“达到目标需要多少工作量”排的。如果你在某个场景里有不同的硬件条件、算法需求完全可能反过来选但最终判断标准一定是到底哪个能让我更快地验证控制逻辑、更快地看到有效效果、更快地迁移到实机。4. 常见问题与排查技巧实录4.1 仿真器本身的问题闪屏、卡顿、启动失败Gazebo闪屏前面已经详细说过了这里再补充一个我遇到过的偏门情况如果你在Gazebo里加载了特别复杂的模型比如带几十个link的机械臂或者大型室外场景界面也会出现类似闪烁的情况但不一定是显卡驱动问题而是物理引擎在跟“显示线程”抢资源。这时可以先降低GUI刷新频率或者把仿真速度调低一点看闪烁是否缓解。AirSim这边比较常见的坑是启动后黑屏。很多时候不是代码问题而是Settings.json写错了尤其是SimMode字段。写成了Car但环境里没有对应车辆模型或者无人机模型名称不对都会导致黑屏。另一个是AirSim加载地形时间特别长第一次启动可能要好几分钟你以为卡死了其实它在后台慢慢加载。耐心等是一方面更好的办法是先跑内置的“Blocks”基础环境确认AirSim本体没问题再切到复杂场景。仿真卡顿是所有仿真器共有的痛点。Gazebo的卡顿大多数来自物理步长过小、传感器发布频率过高、或者点云分辨率过大。AirSim的卡顿多和图像分辨率、反射缓冲、阴影质量有关。排查思路是一致的先降低图像分辨率关闭阴影和反射看是否变流畅如果还卡再降低传感器频率。4.2 ROS2接口与TF问题时间戳与坐标系是重灾区不管用哪个仿真器接入ROS2后有一类问题永远绕不过去时间戳不同步和TF树缺失。AirSim对接ROS2时时间戳是一个常见问题。AirSim内部有自己的仿真时钟ROS2使用系统时钟或/clock时钟两者如果不对齐你在RVIZ2里看到的点云和图像就会“互相追赶”看起来像数据在乱飘。解决方法是确保AirSim的发布频率稳定在launch文件里设置use_sim_time为true让所有节点使用同一个时钟源。TF树缺失的典型报错就是No transform from [base_link] to [map]。这个问题在Gazebo多机器人场景里尤其常见因为要把每台机器人的TF加上命名空间前缀。AirSim场景里则常见于相机坐标系没有正确发布。排查顺序是ros2 run tf2_tools view_frames ros2 topic echo /tf_static ros2 topic echo /tf看哪一层断了再回到URDF或者仿真器配置里去补。这个问题没有捷径只能一步一步看TF树。4.3 物理与传感器参数调节把默认参数当成起点不要当成真理Gazebo里每个传感器插件都有默认噪声和更新率AirSim也一样。问题在于默认值适合“演示”未必适合“验证你的算法”。比如八叉树建图时Gazebo激光雷达默认噪声水平很低导致你建出来的地图漂亮得不像话真实激光雷达噪声远高于此算法一旦迁移实机就性能下降。所以做仿真的时候我习惯手动给传感器加噪声模拟真实设备。AirSim里的IMU噪声参数也有讲究默认的随机游走值偏高如果你的姿态控制算法比较敏感可能会发现无人机悬停时角度一直在小幅度抖动。这是仿真器故意模拟的传感器误差不是bug。调参的时候记得先看传感器的原始输出再决定控制端的滤波策略。4.4 问题速查表症状可能原因排查思路与解决方向Gazebo界面一直闪显卡OpenGL渲染问题、WSL2/远程桌面检查glxinfo设置LIBGL_ALWAYS_SOFTWARE1Gazebo加载失败插件库版本与ROS2不匹配检查ros-humble-gazebo-ros-pkgs是否安装试运行turtlebot3示例AirSim黑屏或启动失败Settings.json配置错误、场景资源未加载先跑Blocks基础环境确认SimMode名称图像时间戳乱跳仿真实时率与系统时钟不同步launch设置use_sim_time降低传感器频率TF缺少base_link到mapURDF漏了坐标系、仿真器未发布静态TF用view_frames检查断点八叉树地图出现大量噪点传感器噪声过大、点云没有做滤波加体素滤波、降低点云分辨率多机仿真严重卡顿物理引擎和渲染负载过高降低模型精度、减少传感器频率或改用AirSim这张表我每次搭新环境都会看一眼。很多问题看起来各不相同本质上都是“仿真器、ROS2、物理引擎、显示环境”四者之间的版本和资源协调问题。5. 如果想少走弯路一点实操心得5.1 先单仿真通吃再上对比实验AirSim和Gazebo同时折腾对新手来说信息量太大了。正确路径是先用Gazebo跑通一个TurtleBot3的SLAM建立ROS2话题、TF树、launch文件的基本感觉再跑通AirSim的单机无人机飞行理解它和ROS2的桥接方式。两个平台各自熟悉后再开始设计“无人机在AirSim、多地面机器人在Gazebo”的对比实验。如果一上来就想两边同时跑通出了问题你根本分不清是哪个环节的锅。5.2 保真度取舍不是所有任务都需要“像真的”AirSim的图像真实感确实好但它重、慢、资源占用高。Gazebo的渲染假但它轻、灵活、和ROS2生态契合度极高。到底选哪个核心指标是“任务目标依赖的是什么”。如果任务核心是视觉比如目标检测、语义分割、视觉SLAM选AirSim因为它和真实相机的鸿沟更小。如果任务核心是控制与导航比如Nav2、OctoMap、多机通信选Gazebo因为它的传感器与物理插件生态让调试效率更高。这个“按任务核心选型”的思路比“哪个仿真器看起来更高级”靠谱得多。5.3 版本锁定和环境隔离最能救你最后一点实操心得也是我踩了多次坑后才彻底执行的把ROS2、Gazebo、AirSim的版本全部锁定并且做环境隔离。“版本锁定”就是在笔记里写明当前用的是Ubuntu哪个版本、ROS2哪个发行版、Gazebo是Classic还是Ignition、AirSim有没有升级过。不要觉得麻烦三个月后你再看自己的项目一定会感谢这行记录。“环境隔离”则是不要把所有依赖都装到系统全局。ROS2有覆盖机制AirSim又有自己的一套依赖不用虚拟环境的话很容易出现“升级一个库导致另一套环境崩掉”的情况。我现在习惯用Docker给不同的仿真任务建立独立环境一个容器跑Gazebo导航一个容器跑AirSim视觉任务两个容器间通过ROS2网络通信。这样即使某个环境坏了另一个也完全不受影响。我在实际项目里感受最深的一点是仿真平台之间的差别往往不在教程里而在你没有预料到的那一层。可能是渲染引擎可能是物理求解器可能是时钟同步。你只有把两个平台都用一段时间才会真的明白它们各自擅长什么。AirSim和Gazebo之间没有绝对的好坏只有“更适合某个任务”的工具。如果你现在还在纠结怎么选我的建议是从你最近要做的那个具体任务反推而不是从工具本身往前找应用。想清楚任务的核心依赖工具选择其实很快就有了答案。