做无人机开发绕不开仿真。不管是调飞控参数、验证视觉识别还是跑一条巡检航线先在仿真开发平台里跑通比直接上真机省太多时间、精力和炸机成本。这个圈子里的无人机仿真开发平台有不少但真正在工程和科研里被反复提起的基本就那么六七款。这篇文章就把我这些年用过的、带项目踩过坑的平台拉出来做一次横向对比重点说说每家的特点、功能和适用场景结尾再给一套从零跑通PX4 SITL加Gazebo的环境搭建实录。想快速上手无人机算法、飞控或视觉感知的新手以及正在评估项目技术路线的开发团队都能拿它当一份选型参考。1. 先搞清楚无人机仿真开发平台到底在仿什么仿真不是把一架3D模型飞机丢进游戏引擎里飞两圈那么简单。真正能用的无人机仿真平台至少要同时在几层上面做文章。选平台之前先把这件事看清后面才不会南辕北辙。1.1 一个完整仿真平台的四层结构第一层是飞行器动力学模型。多旋翼、固定翼、倾转旋翼的气动特性完全不一样旋翼机的拉力、力矩、升力系数、阻力、螺旋桨滑流固定翼的升力线斜率、失速特性、舵面效率都会直接影响控制律能不能收敛。仿真平台必须把这一层当成核心来建模而不是简单地把运动学方程套进去。第二层是传感器模型。GPS、IMU、磁罗盘、气压计、视觉摄像头、激光雷达、毫米波雷达真机上每个传感器都有自己的噪声、延迟、故障模式。仿真如果只给一个“真值”而没有噪声那飞控的姿态估计和滤波器会在仿真里看着很漂亮一上真机立刻原形毕露。不少新手第一次把PX4仿真和真机对比最大的感触就是“仿真里稳如老狗真机里抖成筛子”多半是传感器噪声没仿真到位。第三层是飞控固件和算法。这一层最关键你到底是只验证上层算法还是连底层飞控固件一起跑。如果连固件都跑那仿真软件需要能编译和运行真实的飞控源码也就是常说的SITLSoftware In the Loop软件在环。跑SITL的好处是仿真里调过的参数、改过的控制分配可以直接迁移到真机上因为固件本质是同一份代码只是底层硬件被模拟出来了。第四层是环境场景。包括地形、建筑、天气、光照、GPS信号遮挡、磁干扰区域等。对于视觉算法、航拍路径规划、集群避障来说环境保真度甚至比飞行动力学还重要。AirSim能吃香很大程度上就是因为它把这一层做成了能出论文级别图像的渲染场景。把这四层想明白选平台就很清楚了你要做视觉感知核心矛盾在环境保真度和传感器模型你要做控制律验证核心矛盾在动力学精度和实时性你要做飞控固件二次开发那么能不能跑SITL就是硬指标。1.2 从“单元仿真”到“硬件在环”是怎么回事很多刚接触无人机仿真的朋友看到一堆缩写会晕SITL、HITL/HIL、RITL其实它们描述的是同一件事被测对象和仿真环境之间接口到底插在哪一层。单元仿真只测一个子模块。比如你写了一个路径规划算法输入是一组坐标输出是一条航线那只需要写个脚本喂数据进去就够了不需要飞控参与。SITL是把飞控固件编译成普通进程跑在电脑上通过MAVLink等协议和仿真器交互固件完全不知道自己没有运行在STM32上。硬件在环HIL则是把固件烧进真实飞控板里通过串口连到仿真计算机仿真计算机把传感器数据喂给飞控板飞控板再把PWM指令输出回仿真器。做HIL的价值在于验证硬件时序、总线通信和外设故障但成本高、搭建周期长。绝大多数研发场景SITL已经够用而且可以随时改代码、打断点、加日志。如果你所在团队还处在算法迭代阶段先别急着上HIL先用SITL把流程跑通性价比高得多。1.3 选型前先问自己四个问题我每次帮人搭建仿真环境都会先问四个问题你要验证的核心是控制、视觉还是集群协同控制验证优先考虑动力学精度和飞控固件对接视觉验证优先考虑渲染保真度集群协同优先考虑多实例并发能力。飞控用PX4还是ArduPilot或者压根不用现成飞控如果基于PX4二次开发那仿真平台最好直接支持PX4 SITL省去一大堆自研接口如果只是用MATLAB写控制率那Simulink直接生成代码可能更顺。团队的技术栈是什么熟悉ROS的团队用Gazebo会很顺手熟悉Python和强化学习的团队用AirSim更合适习惯基于模型设计的那就老实选Simulink。对渲染精度和实时性的要求有多高要出高质量视觉数据集需要AirSim这类游戏引擎级渲染要跑实时控制回路则要考虑仿真负载会不会把CPU占满。这四个问题没有标准答案但答案会直接决定你在第2章看到哪款平台时应该眼睛一亮。2. 六款主流无人机仿真开发平台逐一拆解下面进入正题。这六款平台我按照“工程界最常被拿出来对比”的标准筛选AirSim、Gazebo加ROS家族、PX4 SITL、ArduPilot SITL、Simulink无人机工具箱、FlightGear加JSBSim。每一节我会写清楚它的架构、核心能力、适合场景以及我实际使用中的感受。2.1 AirSim视觉感知和AI算法的高保真选项AirSim是微软开源的仿真平台底层基于Unreal Engine后来也支持Unity。我第一次用AirSim是跑视觉避障当时最大的感受是光线、纹理、反射这些细节做得太像真了用AirSim生成的图像训练出来的分割模型放到真机数据上效果很能打。它的核心优势在“把仿真当游戏引擎做”。场景中可以动态加光照、调天气、加物体纹理还可以用UE的资源商店导入更复杂的城市场景、农田地形。传感器层面支持RGB相机、深度相机、语义分割、实例分割、激光雷达、GPS和IMU噪声模型虽然不如专门做飞控验证的仿真器精细但对于视觉算法训练来说完全够用。它还自带一套强化学习接口可以很方便地用Python控制无人机和车辆这也是为什么学术界做深度强化学习很爱用它。AirSim的另一大卖点是跨语言支持。C、Python、C#都有API可以脱离Unreal Editor单独运行。也就是说你可以在普通Python脚本里调用AirSim的API让飞机在仿真世界里起飞、悬停、拍照、返回非常适合pipeline式研发。但AirSim也有明显短板动力学模型相对简化多旋翼参数需要自己花时间标定直接改飞控固件链路非常麻烦。它更适合“上层应用开发者”而不是“飞控固件开发者”。如果你要验证的是PX4的整个起飞姿态过程AirSim不是最好的选择。2.2 Gazebo加ROS/ROS 2开源机器人生态里的万能中转站Gazebo原本是机器人仿真领域的老牌玩家并不是为无人机专门设计但因为它插件机制太成熟加上ROS生态的加持成了无人机仿真界绕不开的选项。Gazebo最核心的能力是场景和传感器插件。它支持加载高精度URDF/SDF模型模拟接触、摩擦、惯性和力传感器插件可以从零写自定义噪声模型、故障模型自由度极高。配合ROS的robot_state_publisher、sensor_msgs等标准消息你写的感知算法、路径规划节点、状态估计节点可以原封不动在真机上跑。这种“接口一致性”是Gazebo最值钱的地方。无人机方向最常见的组合是PX4 SITL加Gazebo。PX4官方已经把Gazebo的机型、传感器模型都维护好了通过make px4_sitl gazebo就能一键拉起一架四旋翼通过MAVROS或者MAVSDK从外部接管飞行控制。而且Gazebo支持一机多实例集群仿真是它的强项之一很多多无人机编队、避障研究都在这个组合上做。Gazebo的问题是上手曲线陡。它本身不提供无人机模型需要你对SDF/URDF、插件、坐标系关系有理解。如果你不是搞ROS出身第一次看到.world文件里一段段XML插件的节点名很容易劝退。我建议先照着PX4官方教程跑通一个demo等看到飞机在Gazebo里动了再回头琢磨内部结构会轻松很多。2.3 PX4 SITL跑真固件的低成本方案PX4 SITL并不是一款独立软件而是一套把PX4飞行栈跑在桌面系统上的方案通常和Gazebo、JMAVSim搭配使用。它和Gazebo搭配的效果最全面和JMAVSim搭配则更轻量。PX4 SITL的原理是把PX4固件编译成主机进程通过共享内存或UDP和仿真器通信。仿真器把传感器的仿真数据发给PX4PX4的导航、控制、任务逻辑照常执行输出电机转速仿真器再根据转速更新力学模型。这样你改的都是真实PX4代码从仿真切真机时参数和行为一致性很高。我团队在PX4开发初期的标准动作是make px4_sitl gazebo启动仿真用QGroundControl连接先在地面上校准传感器切到Position模式推油门起飞然后规划一条航线让它自己跑。整个过程和真机的QGC操作几乎一样。如果做二次开发可以在src/modules里改代码加上自己的日志输出在VSCode里单步调试比拿真机日志复盘效率高太多。它对应的成本是动力学和传感器模型依赖于Gazebo本身而这些模型的质量远不如专业流体仿真软件。如果你做的是非常细的旋翼流体研究或者需要毫米级IMU噪声分析SITL给不了那么多细节。但作为飞控开发、任务规划开发、故障注入测试的平台PX4 SITL完全够用而且免费开源社区资料极其丰富。2.4 ArduPilot SITL另一大飞控生态的成熟选项ArduPilot和PX4是开源飞控领域的两座大山它的SITL方案同样成熟。ArduPilot的SITL更像一个独立的仿真进程确定性很好配合MAVProxy命令行工具做自动化测试很顺手。ArduPilot SITL支持多旋翼、固定翼、直升机、地面车、船只等载具类型每个类型都内置了独立的数学模型。它可以直接通过SIM_参数配置传感器噪声、故障概率并且内置了一些故障注入场景比如GPS丢失、空速管堵塞、电压跌落等非常适合做应急处置测试。和PX4 SITL相比ArduPilot的SITL对硬件在环切换同样无缝而且MAVProxy外壳对自动化和脚本化特别友好。你可以写一段脚本自动起飞、自动执行航线、自动检查飞行模式切换做回归测试很舒服。ArduPilot SITL的短板是可视化默认较弱MAVProxy只有文本界面想看到3D画面得接FlightGear或者Gazebo这又多了一层配置成本。如果你不需要高度可视化的场景只想快速验证逻辑它其实比Gazebo那套组合更轻。团队里做传统休闲航模、长航时固定翼项目的话ArduPilot生态会更亲切。2.5 Simulink加UAV Toolbox基于模型设计的工程利器Matlab/Simulink在汽车ECU和航空航天领域扎根多年。UAV Toolbox专门为无人机设计了一套从建模、仿真到自动代码生成的工具链。和前面所有开源平台相比它最大的优势是把建模仿真和控制器代码生成焊在了一起。用Simulink做无人机控制你可以拖拽出飞行器模型在同一个模型里设计姿态控制、位置控制和任务逻辑然后通过Embedded Coder自动生成C/C代码直接部署到真实MCU上。这个过程在做样机迭代时极其高效改一个控制增益仿真里跑一条曲线确认没问题后点一下生成按钮代码就出来了。它另一个强项是HIL仿真。通过Simulink Real-Time、Speedgoat等硬件可以把真实飞控板连接到控制模型里让飞控板读取仿真传感器信号并输出真实PWM信号闭环测试整个软硬件链路。这在需要通过适航认证、符合DO-178C等流程的项目里几乎是标配。代价也很实在正版授权不便宜UAV Toolbox和配套组件加起来费用可观。而且它的无人机模型是“标准模型”很多非对称、非线性细节需要自己建模。Simulink适合有系统工程思维、习惯模型管理、需要文档化设计的团队不适合只想随便玩玩、拿Python跑个demo的学生个人项目。2.6 FlightGear与JSBSim固定翼动力学研究的经典组合FlightGear是一个开源飞行模拟器用户界面、地形、天气、雷达系统做得非常完整本身就可以当“简化版模拟飞行游戏”用。JSBSim是一个独立的飞行动力学模型库不依赖图形界面以纯数学方式计算气动力和力矩。两者组合以后JSBSim负责动力学解算FlightGear负责可视化中间通过指定协议通信。这个组合有一个特色对固定翼气动模型的支持非常细腻。JSBSim允许你把飞机的翼型、舵面、襟翼、起落架、发动机推力逐项建模而且通过配置文件可以随时替换气动数据做参数研究特别方便。相比之下Gazebo里默认的固定翼模型往往简化得有点过分AirSim干脆就不太适合固定翼控制细节研究。当然它也有明显的“古典感”配置全靠写XML社区资料偏老ROS集成需要自己写桥接。做多旋翼的朋友基本不用看它但如果你在搞固定翼飞控、失速保护、自动着陆等研究这套组合值得花时间啃下来。3. 横向对比与选型建议少走弯路的干货六款平台各有侧重真到了选型时很多人会纠结“我该用哪个”。我先把核心参数放在一张表里再按应用场景给结论。3.1 六款平台关键参数横向对比对比项AirSimGazebo ROS/ROS 2PX4 SITLArduPilot SITLSimulink UAV ToolboxFlightGear JSBSim开源/授权开源开源开源开源商业授权开源核心场景视觉感知、AI训练机器人算法全栈飞控固件开发飞控固件开发控制设计、HIL固定翼气动研究支持飞控不直接支持支持PX4/ArduPilot只支持PX4只支持ArduPilot自家代码生成不直接支持动力学精度中等中等中等中等偏高高自定义模型高固定翼传感器仿真丰富视觉细节强丰富插件灵活依赖配套仿真器内置多种传感器模型可通过模型自建基础不丰富环境渲染极高中等中等低低中等接口语言Python/C/C#ROS/ROS 2/C/PythonMAVLink/MAVSDKMAVLink/MAVProxyMATLAB/Simulink自定义XML/协议上手难度中高中中中高高适合人群AI算法工程师机器人全栈团队飞控开发者飞控开发者/硬件极客控制算法团队固定翼研究者典型限制和真实飞控链路较远配置复杂模型需要自己调依赖模型保真度CLI为主可视化弱授权费用高多旋翼支持弱3.2 按应用场景直接给出选型结论如果你做的是多旋翼飞控二次开发首选PX4 SITL加Gazebo。这是官方支持最好、资料最多、上手最快的组合。团队如果习惯用Qt地面站和自动化测试再加一层MAVSDK基本可以覆盖公司级研发流程。如果你做的是视觉识别、目标跟踪、语义分割首选AirSim。它的渲染保真度远高于其他平台能直接生成带标注数据配合Python的深度学习环境无缝衔接。别指望它给你真实飞控的全链路细节那本来就不是它的业务。如果你做的是多无人机协同、集群避障、编队控制首选Gazebo加ROS/ROS 2。多实例管理方便通信中间件天然支持分布式MAVROS可以同时接管多台SITL飞控很适合做任务级的集群算法验证。如果你做的是控制律设计和自动代码生成Simulink加UAV Toolbox是最稳妥的。它能让你在同一个模型里完成从仿真到部署的全链路尤其适合团队里要过评审、要留文档、要追代码版本的情况。预算要提前确认别等项目中期才突然发现需要买一堆工具箱。如果你做的是固定翼、长航时、滑翔之类的气动研究老老实实研究FlightGear加JSBSim。Gazebo虽然也支持固定翼但气动建模深度不够容易让你得出“这个机翼升力很奇怪”的结论。3.3 几个选型上的常见认知误区第一个误区是“仿真越逼真越好”。实际上仿真逼真度和可调试性是互斥的。AirSim渲染再高级你要在它里面调飞控PID增益时反而难受而Gazebo看起来糙但是你可以随时给传感器加高斯噪声把故障注入字段打开针对特定场景做一轮压力测试。选平台不是你想象中那种“买顶配”的逻辑。第二个误区是“支持ROS就是万能”。ROS确实能把整个系统串起来但ROS版本、Gazebo版本、PX4版本之间的匹配才是噩梦。很多新人在ROS 2 Humble配上老版本Gazebo编译一下午全在修依赖。选型时要问的是我的算法和飞控之间真需要用ROS吗如果只是简单SITL验证MAVSDK已经够了何必再多套一层中间件。第三个误区是“这个平台代码是全的能看所以能改成我要的”。代码全和高保真是两码事。Gazebo的传感器插件全是开源的但你要把其中某个噪声模型改成特定型号IMU工作是实打实的。开源只给了你改的资格没给你改完的时间。选平台前把团队工时算进去比看GitHub星星数更重要。4. 实操实录从零跑通PX4 SITL加Gazebo仿真开发环境前面说了那么多对比总得有一篇能直接照做的。下面这套流程是我多次搭建后固定的版本组合和操作顺序照着走可以少踩很多坑。本文以Ubuntu 22.04、PX4 v1.14.3、Gazebo Classic 11的组合为例原因是官方维护力度足、社区反馈多比较稳定。4.1 环境准备与版本搭配原则很多新手直接拉PX4主分支然后发现Gazebo启动后飞机在地上抽搐。问题多半出在版本错配PX4主分支可能已经把接口切换到Gazebo新版而你电脑上装的是旧版Gazebo Classic或者ROS节点用了最新版MAVROS和旧PX4之间的MAVLink消息字段兼容异常。我自己踩过几次坑之后总结出一条经验不要用主分支用官方release版本并且固定版本组合。在我的实测环境中这套组合是稳定可复现的Ubuntu 22.04 LTSPX4-Autopilot v1.14.3tag方式拉取Gazebo Classic 11通过PX4官网setup脚本自动安装QGroundControl 4.4.x或更新版本Python 3.10和pip工具链如果后面接入ROS 2我用的是ROS 2 Humble如果只是想先跑通SITL第一步可以完全不装ROS避免引入过多依赖。两个人同时尝试搭建时先不加ROS会让问题排查范围小很多。4.2 拉源码、装依赖、启动一次仿真先做基础工具安装。系统刚装完时建议执行一遍sudo apt update sudo apt install -y git zip qtcreator cmake build-essential ninja-build然后克隆PX4仓库。注意加--recursivePX4有大量子模块漏一个后面编译都会报错。git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot git fetch --tags git checkout v1.14.3 git submodule update --recursivePX4官方提供了一套环境安装脚本会自动装Gazebo、MAVROS、依赖库等。建议执行前先看一遍脚本内容了解它装了哪些东西避免盲目运行。bash ./Tools/setup/ubuntu.sh脚本跑完重开终端。编译并启动SITLmake px4_sitl gazebo-classic第一次编译会很久取决于机器性能可能十几分钟到几十分钟。编译完会自动拉起一个Gazebo窗口里面是一架标准的四旋翼模型终端里会滚出PX4的日志看到[info] Starting Gazebo...之类的输出就说明启动成功。这时PX4的MAVLink通道默认跑在UDP 14550端口QGroundControl会自动发现并连接。QGroundControl可以到官网下载AppImage下载后赋权chmod x QGroundControl.AppImage ./QGroundControl.AppImage连接成功后地面站里能看到飞机位置、姿态角、电池电量甚至可以看到Gazebo里仿真电机的转速。第一次看到这些联动时你就明白“SITL跑的是真固件”是什么意思了。4.3 在地面站里完成一次完整的起降任务起飞前先检查QGC右上角的模式显示。在SITL里因为没有磁罗盘干扰通常校准很快但姿态估计需要几秒钟收敛。我习惯的步骤是把飞行模式切到Position模式然后推油门。SITL和真机一样如果油门杆太低不会解锁解锁后推到中间以上才会主动起飞。起飞到半米后放开摇杆飞机会自动悬停。这时你能在QGC的3D地图里看到飞机的实时位置还能旋转视角观察飞机姿态。接着规划一个简单的矩形航线在地图界面上右键添加航点输入航点高度然后点击上传、起飞执行。PX4会自动按航线飞行完成所有航点后待机。学会这一步之后后续验证自主巡检、返航逻辑本质上就是把航线本身换掉而已。如果想试验失效保护直接在Gazebo里把发动机仿真组件停掉飞控会识别到电机异常尝试切换模式或触发降落保护。这个在真机上危险性极高的测试在仿真里可以反复做也是SITL最有价值的地方之一。4.4 用MAVSDK写一个最简单的起飞脚本很多场景下你不想在QGC里手动操作而是要用代码控制飞机。MAVSDK是PX4官方推荐的SDK之一支持Python和C。先安装Python版pip3 install mavsdk写一个极简脚本控制飞机起飞到2米高度并悬停import asyncio from mavsdk import System async def run(): drone System() await drone.connect(system_addressudp://:14540) print(等待飞控连接...) async for state in drone.core.connection_state(): if state.is_connected: print(已连接) break print(等待飞控就绪) async for telemetry in drone.telemetry.health(): if telemetry.is_ready_to_arm: print(飞控就绪) break print(解锁并起飞) await drone.action.arm() await drone.action.set_takeoff_altitude(2.0) await drone.action.takeoff() await asyncio.sleep(8) print(任务完成降落) await drone.action.land() if __name__ __main__: asyncio.run(run())注意连接地址里的udp://:14540是给外部开发者使用的端口和QGC使用的14550不同。SITL启动后会监听多个端口14540用来接收外部MAVLink请求。这个脚本跑起来后终端日志会告诉你起飞指令、位置变化和降落状态逻辑验证效率比在地面站里手动操作高很多。5. 常见问题与排查技巧实录再稳定的环境新来的同学也总会遇到几个典型问题。我把团队里确实遇到过的、社区里反复出现的几类问题整理成速查表给读者直接抄作业。5.1 仿真起不来、画面空白、QGC连接失败最常遇到的是Gazebo窗口打开了但里面没有飞机模型或者飞机模型一阵厚一阵透明。这类问题八成是模型路径没有找到。PX4启动时会读取PX4_SIM_SPEED_FACTOR、GAZEBO_MODEL_PATH等环境变量很多子模块没有正确初始化时就会出现模型加载失败。排查命令是先看终端日志里有没有红色的Model not found或者Path not set提示。如果模型路径有问题手动指定source /usr/share/gazebo/setup.sh export GAZEBO_MODEL_PATH${GAZEBO_MODEL_PATH}:$HOME/PX4-Autopilot/Tools/sitl_gazebo/models如果QGC始终连不上检查端口。默认MAVLink输出是UDP 14550QGC自动监听这个端口。如果被其他程序占用了可以关掉占用程序或者在make px4_sitl gazebo-classic前设置PX4_HOME_LAT等环境变量来改变仿真全球定位坐标避免局部信号干扰。5.2 飞机起飞后位置飘得离谱或者位置估计崩溃SITL里的GPS默认是理想传感器但如果Gazebo的传感器插件参数没调好位置估计可能会一会东一会西。先确认你在地面站里等GPS lock全部完成再解锁其次是不要在飞机还没有跳到Current Position模式时就手动猛推油门。在PX4 1.14版本中可以通过EKF2_*参数检查估计器状态。QGC的MAVLink Inspector里订阅vehicle_attitude和vehicle_gps_position如果两者差异很大多半是Gazebo的GPS插件位置时延设置和PX4默认参数不匹配。把SENS_GPS_NSATS等参数调到合理范围再重启SITL。5.3 仿真帧率巨卡CPU占用拉满画面完全跟不上控制Gazebo的物理引擎步长越小越精确但CPU开销也越大。如果不关心接触细节可以把物理步长从0.001调到0.002或0.004在我的机器上帧率能提升一倍以上。如果是跑集群多架无人机共用一个Gazebo世界可以为每架飞机降低传感器更新频率或者干脆使用无头模式不渲染画面只保留物理计算。无头模式跑起来之后通过QGC的3D地图和MAVLink日志照样能判断算法行为。5.4 AirSim里图像过暗、风扇声听不到、传感器数据奇怪AirSim的很多问题不是代码问题而是游戏引擎内部光照、材质和物理材质没配对。起飞后图像过暗先检查settings.json里的CameraDefaults配置把FOV_Degrees和DepthNoise调到合适值效果仍然不对时检查场景中的点光源、天光和反射探头。AirSim的物理参数里还藏着旋翼转速对应的推力和转动力矩建议按官方文档先跑通默认四旋翼模型再模仿它的参数结构去改自己的机型不要从零乱填。5.5 版本升级后旧模型用不了升级PX4版本后旧的Gazebo world、传感器插件甚至MAVLink消息格式都可能不再兼容。这时最忌讳的是“硬改编译错误”。我的经验是先把所有第三方扩展摘掉只跑原版模型确认环境本身健康再一个一个接回自己的插件。否则你会陷入“改了一万行代码也找不到根因”的泥潭。仿真环境也建议用conda这类环境管理工具分成多个虚拟环境不同项目固定不同版本组合省得互相污染。6. 长期用下来的个人体会仿真开发平台这个领域更新速度不慢新出的渲染引擎、开源项目时不时冒出来但底层逻辑这么多年没变过先想清楚要验证什么再选工具工具只是把“假设-实验-结论”循环转得更快的放大器。我在实际使用中最大的体会是千万不要迷信单一平台。一个正经的无人机团队至少会同时保有两套仿真环境——一套Gazebo加PX4 SITL负责飞控、任务和失效保护逻辑一套AirSim负责视觉感知和端到端策略训练。两套环境各有分工前者保控制链路真实后者保感知场景真实缺一不可。最后再分享一个对新人很实用的小技巧在仿真里养成“先看日志、再猜原因”的习惯。打开QGC的MAVLink控制台或VSCode的调试器先看vehicle_status、estimator_status、local_position这几个核心话题再动手改参数。仿真最大的优势就是可以反复试错这个试错过程如果配合完整的日志分析收获会比直接在真机上炸机大得多。等你在仿真里把一套流程跑得滚瓜烂熟再上真机才会真正体会到“今天没炸机是仿真帮我挡了一刀”。
