简介PX4 固件 v1.11.0 完整工程包面向无人机开发者、机器人研究者和开源飞控爱好者提供可直接下载解压的预集成源码树免去逐个子模块拉取与网络配置的繁琐步骤。包体包含 21946 个文件以 C/C 源码c、h、cpp、hpp为核心涵盖飞行控制、导航、传感器融合、MAVLink 通信协议等模块同时含 makefile、Kconfig、defconfig 等构建配置以及 msg、uavcan、sdf 等接口与仿真描述文件整体约 897MB适合本地离线编译、代码阅读与二次开发。已有 1623 人学习下载。从内容预览可看到固件内置多种机型配置如 3DR Iris、TBS Discovery 等。版本还包含 PID 控制优化、GPS/IMU 融合增强、地理围栏与紧急停机等安全特性方便使用者深入分析 PX4 架构或在配套硬件上刷写实验也可用于课程设计与毕设源码讲解。 你还在用 PX4 最新主分支上的固件吗我前段时间被迫把项目回退到了 firmware 1.11.0原因很现实机载电脑和飞控之间跑的那套 MAVLink 消息在新版本里变了接口以前调好的外设驱动和参数全部作废而论文和现成代码都是基于老接口写的。折腾了整整两天从下载、编译到烧录踩了不少坑才把 1.11.0 完整跑通。这篇文章就当作给同样需要回退老版本的同学一份避坑记录覆盖 PX4 老固件的获取方式、Ubuntu 环境搭建、编译烧录全流程以及最容易让人崩溃的几个问题。不管你是做科研复现、老机架维护还是单纯想对比新旧固件差异这篇应该都能帮你省下不少时间。1. 为什么都这个时间点了还要碰 1.11.0 这个老固件1.1 老版本并非落后很多场景必须用它先说个反直觉的事PX4 新版本年年更新但很多老项目反而卡在旧版本上不敢动。最典型的就是科研场景跑目标检测、路径规划、集群编队的人代码仓库里往往写着on PX4 v1.11.0这类说明。下游的机载电脑、ROS 节点、MAVROS 桥接层都是基于 1.11.0 的消息格式和 uORB 主题开发调通的一旦升级固件消息结构可能更名字段可能调整整个上层系统全得跟着改。另一个常见需求是外设兼容性。老飞控板上的某些传感器驱动、PX4IO 固件版本、甚至同一颗 IMU 的滤波参数在新固件里可能换了算法路径。比如早期 Pixhawk 系列搭配某些第三方 RTK 模块在 1.11.0 里的驱动稳定到了 1.13 以后行为就变了。做产品的人不会平白无故去升级一个跑得好好的飞控固件。还有一类人必须碰老版本复现论文。很多学术公开代码用的是 Gazebo PX4 1.11.0 组合你如果直接拉最新的主分支仿真环境里飞机根本起不来。这类项目对版本的要求是写死的不是你换个新版本就能适配的。1.2 1.11.0 与新版的核心差异1.11.0 属于 PX4 一个比较特殊的过渡版本它在内部架构上开始向分层模块化推进但很多新版本引入的机制还没完全落地。和现在的新版相比主要差异集中在几个维度编译系统1.11.0 使用基于 CMake 的目标板组织方式目标名长这样px4_fmu-v5_default新版虽然也是 CMake但很多内部库和构建选项已经挪了位置。MAVLink 行为1.11.0 的很多自定义消息、参数标识和新版不一致特别是MAV_CMD、MAV_TYPE这类枚举跨版本通信容易出兼容性问题。子模块策略PX4 源码仓库依赖大量 git submodule1.11.0 的子模块版本和老接口绑定更紧不能随便git pull子模块到最新版。所以如果你需要在老版本基础上二次开发老老实实把固件版本锁死在 1.11.0才是正确策略而不是试图在最新主分支上做向后兼容。2. 下载 firmware 1.11.0zip 包与 git checkout 两条路2.1 直接下载 zip 压缩包看似简单但有个大坑看到px4 firmware1.11.0.zip这个文件名大多数人第一反应是直接去 GitHub 上打包下载 zip。这条路能走通但有个非常隐蔽的坑PX4 源码仓库不是单体仓库它依赖一堆 git submodule。你从网页上点 Download ZIP 拿到的压缩包只包含主仓库的代码不包含子模块的代码。直接拿这个 zip 包去编译你会遇到这种报错CMake Error: The source directory Tools/... does not exist mavlink headers not found原因就是Tools/mavlink、src/lib/...这些子模块目录是空的。那 zip 包能不能用能但要先把解压后的目录变成一个完整的 git 仓库然后手动初始化子模块cd PX4-Autopilot git init git remote add origin https://github.com/PX4/PX4-Autopilot.git git fetch --depth 1 origin v1.11.0 git checkout FETCH_HEAD git submodule update --init --recursive实际操作下来这一套流程又绕又容易失败因为--depth 1浅克隆会导致部分 tag 引用缺失。我的建议是除非你已经把 zip 包下载到了本地、网络环境又特别差否则别走 zip 这条路。2.2 git clone 指定 tag这才是老版本最稳的姿势最靠谱的获取方式是用git clone完整拉取仓库再切到v1.11.0这个 tag。具体命令git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot git checkout v1.11.0 -b my-v1.11.0 git submodule update --init --recursivegit checkout v1.11.0 -b my-v1.11.0的意思是从 tagv1.11.0创建一个名为my-v1.11.0的新分支。为什么要建分支而不是直接处于 detached HEAD因为后续如果你想改代码需要一个分支来承载提交记录否则直接在 tag 上改代码很容易丢。这里有个小教训第一步的--recursive必须带。如果你在 clone 时忘了后面编译时会出现一堆 fuchsia 的、mavlink 的、googletest 的目录缺失那时候再去补子模块虽然也能补救但网络压力会大很多而且有些子模块版本需要和主仓库配合分开拉非常容易搞混。2.3 如何确认下载的代码是完整的git 的好处是自带完整性校验。切换完 tag 后可以先用这几条命令自查git log --oneline -1 git status git submodule statusgit log --oneline -1应该能看到HEAD指向v1.11.0对应提交git submodule status显示的每个子模块前面不应有-号。如果某个子模块前面有个负号说明该子模块没初始化需要回到第 2.2 节补命令。这一步花不了十秒钟但能避免你编译到一半才发现源码不全然后整个人都不好了。另外注意一点PX4 1.11.0 的官方仓库路径是PX4/PX4-Autopilot某些第三方或者培训机构维护的镜像仓库可能在 tag 命名上有差异如果你git checkout v1.11.0报错说 tag 不存在先git tag | grep 1.11看看仓库里实际有哪些 tag。3. Ubuntu 搭建 1.11.0 编译环境版本匹配是关键3.1 推荐系统版本与工具链PX4 1.11.0 官方支持的编译环境明确写着 Ubuntu 18.04。这不是开发商偷懒而是工具链版本和系统库版本深度绑定。1.11.0 时期的交叉编译器、Python 依赖、CMake 版本都是按 18.04 的环境验证过的。如果你跟我一样手头的机器装了 Ubuntu 20.04 甚至 22.04当然也能编但会多出不少适配工作。我在 20.04 上编译的教训是尽量优先使用官方工具链安装脚本而不是自己拿 apt 一个个装依赖。进入源码目录后运行官方脚本bash Tools/setup/ubuntu.sh这个脚本会安装 CMake、Python 依赖、GCC 交叉编译器等一系列环境。脚本执行时间比较长过程中会有一段提示让你按回车确认安装某些工具包别走开等它跑完。如果你用 Ubuntu 20.04/22.04脚本有可能会因为软件源版本差异报错。一个可用的兜底方案是手动安装gcc-arm-none-eabi并检查版本arm-none-eabi-gcc --version对于 1.11.0交叉编译器版本大致对应 ARM 官方的 9-2020-q2 系列。版本太新可能导致链接时出现不兼容的段错误太老则可能不支持某些编译选项。这个经验不是官方文档里的是实际踩过的。3.2 编译目标板的选择PX4 编译前需要知道目标飞控板类型。主流的 1.11.0 目标名有px4_fmu-v5_default对应 Pixhawk 4 / FMUv5px4_fmu-v3_default对应 Pixhawk 1 的 2MB Flash 版本、Pixhawk 2.1Cube Blackpx4_fmu-v4_default对应 Pixhawk 3 / FMUv4不确定自己的板子该选哪个目标时直接跑make list_config_targets命令会列出当前源码支持的所有目标板。找到和你硬件对应的那一行复制目标名去编译。以 Pixhawk 4 为例编译命令是make px4_fmu-v5_default首次编译会花比较长时间因为要编译整个固件和部分宿主工具我的机器大概跑了 20 多分钟期间 CPU 会全程满载这很正常。编译成功后产物目录在build/px4_fmu-v5_default/里面有一个px4_fmu-v5_default.px4文件这就是后面要烧录到飞控的固件。目录下还有一个.bin文件供某些 bootloader 升级场景使用平时用不上。3.3 SITL 仿真环境的编译很多人拿老版本是为了跑 Gazebo 仿真这个在 1.11.0 里也支持。编译 SITL 的目标名不是px4_fmu-v5_default而是make px4_sitl_default gazebo编完 SITL 后要启用环境变量才能让 Gazebo 找到模型和 3D 插件source Tools/setup_gazebo.bash $(pwd) $(pwd)/build/px4_sitl_default export ROS_PACKAGE_PATH$ROS_PACKAGE_PATH:$(pwd):$(pwd)/Tools/sitl_gazebo这两行环境变量如果你忘了 sourceGazebo 里通常会报模型找不到或者飞机不出现的错。老版本的仿真流程网上资料很多但这两行是跑通 SITL 的隐藏前提我专门提一下。4. 编译踩坑实录从报错到解决的全过程4.1 网络类报错不仅仅是重试一下老版本协议和 GitHub 的连接问题几乎是每个人都会遇到的。常见的报错长这样fatal: 无法访问 https://github.com/px4/px4-autopilot.git/:failed to connect这个报错一出现很多人第一反应是网络不行重试。但根据我的排查经验问题可能出在三个不同层面DNS 解析失败现象是访问github.com超时但访问别的网站正常。先在终端里执行ping github.com确认域名能否解析。子模块对应的仓库从不同域名拉取PX4 的子模块有部分托管在独立的 repo 地址而不是同一个 GitHub 仓库下某些网络环境下主仓库能拉子模块却超时。这时候要重点看报错信息里 URL 是哪个。公司或校园网出口做了限制导致 HTTPS 连接被重置。排查时先不要反复重试否则容易拉出半截子模块状态更糟。正确做法是先检查网络连通性再决定是否用 zip 包方式代替 git clone。我个人的备选方案是找一个网络波动小的时间段重新完整 clone 一遍不要试图在一个已损坏的仓库上 patch那会浪费更多时间。需要注意的是https://github.com/px4/px4-autopilot.git/这个地址虽然 GitHub 会自动跳转到PX4/PX4-Autopilot但如果你看报错信息时发现 URL 里是小写px4说明可能是某些文档或第三方脚本里的旧地址。把git remote -v里的 URL 改成完整正确的仓库地址可以避免部分访问问题。4.2 编译环境类报错CMake 与 Python 版本是重灾区在 Ubuntu 20.04 上编译 1.11.0我最先遇到的是 CMake 配置时报错CMake Error: The current CMake version is higher than 3.16...老版本的某些 CMakeLists 对新版本 CMake 的兼容性并没有持续测试。遇到这种情况最简单的处理是安装低版本 CMake而不是去改构建脚本。我用的是将 CMake 源码编译到/usr/local/cmake-3.13之后通过PATH切版本的方式这样不影响系统里其他软件依赖的高版本 CMake。另一个问题是 Python 环境。1.11.0 的构建脚本针对 Python 3.6/3.7 验证过Ubuntu 20.04 自带的 Python 3.8 有时候会在安装依赖阶段报cannot import name ...这类导入错误。我的处理方案是用virtualenv建一个 Python 3.7 的虚拟环境然后在里面跑pip install --user -r requirements.txt。4.3 子模块不完整造成的编译错乱这是最容易误判的一类错误。现象是编译中途突然报某个头文件找不到看起来像是代码有问题排查半天才发现是子模块缺失。比如fatal error: mavlink/v2.0/...: No such file or directory这不是 PX4 源码的问题而是mavlink子模块没有正确导出。修复方式还是那句老话git submodule update --init --recursive但要注意如果主仓库的HEAD不在分支上或者你在错误的分支上执行这条命令它会把子模块切到另一个状态。执行前确认当前git status是干净的最好git log看一下当前提交确实是 v1.11.0 对应的。5. 烧录到飞控板与地面站配置5.1 命令行 USB 烧录编译通过后把飞控通过 USB 连到电脑执行make px4_fmu-v5_default upload这条命令会先重新编译一次然后进入烧录流程。烧录前飞控需要处于 bootloader 模式有些板子需要按住飞控板上的 BOOT 键再上电QGroundControl 刷固件时则通常不需要手动按。如果终端提示Permission denied: /dev/ttyACM0说明当前用户没有串口权限。执行sudo usermod -a -G dialout $USER然后注销重新登录或者重启系统让用户组生效。之后重新插拔 USB再执行 upload 命令。5.2 用 QGroundControl 刷自定义固件命令行烧录用得比较多但如果你对命令行不熟推荐用 QGroundControl 地面站。打开 QGroundControl进入设置里的固件页面选择自定义固件文件然后选中编译目录下的px4_fmu-v5_default.px4文件地面站会自动完成擦除和写入。这里有个值得注意的细节如果你手里的 QGroundControl 版本太新打开 1.11.0 时期生成的参数文件时个别界面控件可能不兼容。为了减少干扰可以考虑使用和 1.11.0 同期发布的稳定版 QGroundControl。这不是硬性要求但如果你发现自己某些参数显示异常先别急着怀疑固件换一个旧版地面站试试多半就正常了。5.3 刷完老固件之后的必做校准从新版固件刷回 1.11.0或从未刷过 1.11.0刷完第一次上电时一定不要直接解锁起飞。至少完成以下几件事机架选择在 QGroundControl 中设置正确的机架类型多旋翼选多旋翼固定翼选固定翼。机架选错会导致混控器输出完全错误。加速度计和陀螺仪校准按照地面站提示把飞机依次摆放到多个姿态位置等待数值稳定。遥控器校准拨动所有摇杆通道确保行程范围映射正确。参数检查如果之前有备份参数通过地面站恢复参数文件如果没有备份重点检查MAV_开头的参数是否真的是恢复默认而不是继承了其他固件版本的残留参数。对于回退到 1.11.0 的人来说最怕的是参数残留。老版本固件和新版本固件的参数 ID 并不完全一致直接恢复新版固件的参数文件到老固件可能会把某些参数写到错误的 ID 上导致飞机行为诡异。所以我的习惯是刷完老固件后先重置所有参数为默认值再进行手动校准最后才恢复关键参数。这个过程更像是在重新初始化一架飞机而不是升级更新但这是能稳定起飞的最短路径。如果你只是临时评估老固件建议刷回老版本前先用 QGroundControl 导出当前参数和固件版本信息备份好。万一新功能还得用随时能恢复到原本状态。这套流程走下来1.11.0 在你手里就是一个稳定、可控、可复现的飞行平台而不是一个让人头疼的老古董。本文还有配套的精品资源点击获取 PX4固件回退1.11.0全流程：编译、MAVLink兼容与烧录避坑指南
简介PX4 固件 v1.11.0 完整工程包面向无人机开发者、机器人研究者和开源飞控爱好者提供可直接下载解压的预集成源码树免去逐个子模块拉取与网络配置的繁琐步骤。包体包含 21946 个文件以 C/C 源码c、h、cpp、hpp为核心涵盖飞行控制、导航、传感器融合、MAVLink 通信协议等模块同时含 makefile、Kconfig、defconfig 等构建配置以及 msg、uavcan、sdf 等接口与仿真描述文件整体约 897MB适合本地离线编译、代码阅读与二次开发。已有 1623 人学习下载。从内容预览可看到固件内置多种机型配置如 3DR Iris、TBS Discovery 等。版本还包含 PID 控制优化、GPS/IMU 融合增强、地理围栏与紧急停机等安全特性方便使用者深入分析 PX4 架构或在配套硬件上刷写实验也可用于课程设计与毕设源码讲解。 你还在用 PX4 最新主分支上的固件吗我前段时间被迫把项目回退到了 firmware 1.11.0原因很现实机载电脑和飞控之间跑的那套 MAVLink 消息在新版本里变了接口以前调好的外设驱动和参数全部作废而论文和现成代码都是基于老接口写的。折腾了整整两天从下载、编译到烧录踩了不少坑才把 1.11.0 完整跑通。这篇文章就当作给同样需要回退老版本的同学一份避坑记录覆盖 PX4 老固件的获取方式、Ubuntu 环境搭建、编译烧录全流程以及最容易让人崩溃的几个问题。不管你是做科研复现、老机架维护还是单纯想对比新旧固件差异这篇应该都能帮你省下不少时间。1. 为什么都这个时间点了还要碰 1.11.0 这个老固件1.1 老版本并非落后很多场景必须用它先说个反直觉的事PX4 新版本年年更新但很多老项目反而卡在旧版本上不敢动。最典型的就是科研场景跑目标检测、路径规划、集群编队的人代码仓库里往往写着on PX4 v1.11.0这类说明。下游的机载电脑、ROS 节点、MAVROS 桥接层都是基于 1.11.0 的消息格式和 uORB 主题开发调通的一旦升级固件消息结构可能更名字段可能调整整个上层系统全得跟着改。另一个常见需求是外设兼容性。老飞控板上的某些传感器驱动、PX4IO 固件版本、甚至同一颗 IMU 的滤波参数在新固件里可能换了算法路径。比如早期 Pixhawk 系列搭配某些第三方 RTK 模块在 1.11.0 里的驱动稳定到了 1.13 以后行为就变了。做产品的人不会平白无故去升级一个跑得好好的飞控固件。还有一类人必须碰老版本复现论文。很多学术公开代码用的是 Gazebo PX4 1.11.0 组合你如果直接拉最新的主分支仿真环境里飞机根本起不来。这类项目对版本的要求是写死的不是你换个新版本就能适配的。1.2 1.11.0 与新版的核心差异1.11.0 属于 PX4 一个比较特殊的过渡版本它在内部架构上开始向分层模块化推进但很多新版本引入的机制还没完全落地。和现在的新版相比主要差异集中在几个维度编译系统1.11.0 使用基于 CMake 的目标板组织方式目标名长这样px4_fmu-v5_default新版虽然也是 CMake但很多内部库和构建选项已经挪了位置。MAVLink 行为1.11.0 的很多自定义消息、参数标识和新版不一致特别是MAV_CMD、MAV_TYPE这类枚举跨版本通信容易出兼容性问题。子模块策略PX4 源码仓库依赖大量 git submodule1.11.0 的子模块版本和老接口绑定更紧不能随便git pull子模块到最新版。所以如果你需要在老版本基础上二次开发老老实实把固件版本锁死在 1.11.0才是正确策略而不是试图在最新主分支上做向后兼容。2. 下载 firmware 1.11.0zip 包与 git checkout 两条路2.1 直接下载 zip 压缩包看似简单但有个大坑看到px4 firmware1.11.0.zip这个文件名大多数人第一反应是直接去 GitHub 上打包下载 zip。这条路能走通但有个非常隐蔽的坑PX4 源码仓库不是单体仓库它依赖一堆 git submodule。你从网页上点 Download ZIP 拿到的压缩包只包含主仓库的代码不包含子模块的代码。直接拿这个 zip 包去编译你会遇到这种报错CMake Error: The source directory Tools/... does not exist mavlink headers not found原因就是Tools/mavlink、src/lib/...这些子模块目录是空的。那 zip 包能不能用能但要先把解压后的目录变成一个完整的 git 仓库然后手动初始化子模块cd PX4-Autopilot git init git remote add origin https://github.com/PX4/PX4-Autopilot.git git fetch --depth 1 origin v1.11.0 git checkout FETCH_HEAD git submodule update --init --recursive实际操作下来这一套流程又绕又容易失败因为--depth 1浅克隆会导致部分 tag 引用缺失。我的建议是除非你已经把 zip 包下载到了本地、网络环境又特别差否则别走 zip 这条路。2.2 git clone 指定 tag这才是老版本最稳的姿势最靠谱的获取方式是用git clone完整拉取仓库再切到v1.11.0这个 tag。具体命令git clone --recursive https://github.com/PX4/PX4-Autopilot.git cd PX4-Autopilot git checkout v1.11.0 -b my-v1.11.0 git submodule update --init --recursivegit checkout v1.11.0 -b my-v1.11.0的意思是从 tagv1.11.0创建一个名为my-v1.11.0的新分支。为什么要建分支而不是直接处于 detached HEAD因为后续如果你想改代码需要一个分支来承载提交记录否则直接在 tag 上改代码很容易丢。这里有个小教训第一步的--recursive必须带。如果你在 clone 时忘了后面编译时会出现一堆 fuchsia 的、mavlink 的、googletest 的目录缺失那时候再去补子模块虽然也能补救但网络压力会大很多而且有些子模块版本需要和主仓库配合分开拉非常容易搞混。2.3 如何确认下载的代码是完整的git 的好处是自带完整性校验。切换完 tag 后可以先用这几条命令自查git log --oneline -1 git status git submodule statusgit log --oneline -1应该能看到HEAD指向v1.11.0对应提交git submodule status显示的每个子模块前面不应有-号。如果某个子模块前面有个负号说明该子模块没初始化需要回到第 2.2 节补命令。这一步花不了十秒钟但能避免你编译到一半才发现源码不全然后整个人都不好了。另外注意一点PX4 1.11.0 的官方仓库路径是PX4/PX4-Autopilot某些第三方或者培训机构维护的镜像仓库可能在 tag 命名上有差异如果你git checkout v1.11.0报错说 tag 不存在先git tag | grep 1.11看看仓库里实际有哪些 tag。3. Ubuntu 搭建 1.11.0 编译环境版本匹配是关键3.1 推荐系统版本与工具链PX4 1.11.0 官方支持的编译环境明确写着 Ubuntu 18.04。这不是开发商偷懒而是工具链版本和系统库版本深度绑定。1.11.0 时期的交叉编译器、Python 依赖、CMake 版本都是按 18.04 的环境验证过的。如果你跟我一样手头的机器装了 Ubuntu 20.04 甚至 22.04当然也能编但会多出不少适配工作。我在 20.04 上编译的教训是尽量优先使用官方工具链安装脚本而不是自己拿 apt 一个个装依赖。进入源码目录后运行官方脚本bash Tools/setup/ubuntu.sh这个脚本会安装 CMake、Python 依赖、GCC 交叉编译器等一系列环境。脚本执行时间比较长过程中会有一段提示让你按回车确认安装某些工具包别走开等它跑完。如果你用 Ubuntu 20.04/22.04脚本有可能会因为软件源版本差异报错。一个可用的兜底方案是手动安装gcc-arm-none-eabi并检查版本arm-none-eabi-gcc --version对于 1.11.0交叉编译器版本大致对应 ARM 官方的 9-2020-q2 系列。版本太新可能导致链接时出现不兼容的段错误太老则可能不支持某些编译选项。这个经验不是官方文档里的是实际踩过的。3.2 编译目标板的选择PX4 编译前需要知道目标飞控板类型。主流的 1.11.0 目标名有px4_fmu-v5_default对应 Pixhawk 4 / FMUv5px4_fmu-v3_default对应 Pixhawk 1 的 2MB Flash 版本、Pixhawk 2.1Cube Blackpx4_fmu-v4_default对应 Pixhawk 3 / FMUv4不确定自己的板子该选哪个目标时直接跑make list_config_targets命令会列出当前源码支持的所有目标板。找到和你硬件对应的那一行复制目标名去编译。以 Pixhawk 4 为例编译命令是make px4_fmu-v5_default首次编译会花比较长时间因为要编译整个固件和部分宿主工具我的机器大概跑了 20 多分钟期间 CPU 会全程满载这很正常。编译成功后产物目录在build/px4_fmu-v5_default/里面有一个px4_fmu-v5_default.px4文件这就是后面要烧录到飞控的固件。目录下还有一个.bin文件供某些 bootloader 升级场景使用平时用不上。3.3 SITL 仿真环境的编译很多人拿老版本是为了跑 Gazebo 仿真这个在 1.11.0 里也支持。编译 SITL 的目标名不是px4_fmu-v5_default而是make px4_sitl_default gazebo编完 SITL 后要启用环境变量才能让 Gazebo 找到模型和 3D 插件source Tools/setup_gazebo.bash $(pwd) $(pwd)/build/px4_sitl_default export ROS_PACKAGE_PATH$ROS_PACKAGE_PATH:$(pwd):$(pwd)/Tools/sitl_gazebo这两行环境变量如果你忘了 sourceGazebo 里通常会报模型找不到或者飞机不出现的错。老版本的仿真流程网上资料很多但这两行是跑通 SITL 的隐藏前提我专门提一下。4. 编译踩坑实录从报错到解决的全过程4.1 网络类报错不仅仅是重试一下老版本协议和 GitHub 的连接问题几乎是每个人都会遇到的。常见的报错长这样fatal: 无法访问 https://github.com/px4/px4-autopilot.git/:failed to connect这个报错一出现很多人第一反应是网络不行重试。但根据我的排查经验问题可能出在三个不同层面DNS 解析失败现象是访问github.com超时但访问别的网站正常。先在终端里执行ping github.com确认域名能否解析。子模块对应的仓库从不同域名拉取PX4 的子模块有部分托管在独立的 repo 地址而不是同一个 GitHub 仓库下某些网络环境下主仓库能拉子模块却超时。这时候要重点看报错信息里 URL 是哪个。公司或校园网出口做了限制导致 HTTPS 连接被重置。排查时先不要反复重试否则容易拉出半截子模块状态更糟。正确做法是先检查网络连通性再决定是否用 zip 包方式代替 git clone。我个人的备选方案是找一个网络波动小的时间段重新完整 clone 一遍不要试图在一个已损坏的仓库上 patch那会浪费更多时间。需要注意的是https://github.com/px4/px4-autopilot.git/这个地址虽然 GitHub 会自动跳转到PX4/PX4-Autopilot但如果你看报错信息时发现 URL 里是小写px4说明可能是某些文档或第三方脚本里的旧地址。把git remote -v里的 URL 改成完整正确的仓库地址可以避免部分访问问题。4.2 编译环境类报错CMake 与 Python 版本是重灾区在 Ubuntu 20.04 上编译 1.11.0我最先遇到的是 CMake 配置时报错CMake Error: The current CMake version is higher than 3.16...老版本的某些 CMakeLists 对新版本 CMake 的兼容性并没有持续测试。遇到这种情况最简单的处理是安装低版本 CMake而不是去改构建脚本。我用的是将 CMake 源码编译到/usr/local/cmake-3.13之后通过PATH切版本的方式这样不影响系统里其他软件依赖的高版本 CMake。另一个问题是 Python 环境。1.11.0 的构建脚本针对 Python 3.6/3.7 验证过Ubuntu 20.04 自带的 Python 3.8 有时候会在安装依赖阶段报cannot import name ...这类导入错误。我的处理方案是用virtualenv建一个 Python 3.7 的虚拟环境然后在里面跑pip install --user -r requirements.txt。4.3 子模块不完整造成的编译错乱这是最容易误判的一类错误。现象是编译中途突然报某个头文件找不到看起来像是代码有问题排查半天才发现是子模块缺失。比如fatal error: mavlink/v2.0/...: No such file or directory这不是 PX4 源码的问题而是mavlink子模块没有正确导出。修复方式还是那句老话git submodule update --init --recursive但要注意如果主仓库的HEAD不在分支上或者你在错误的分支上执行这条命令它会把子模块切到另一个状态。执行前确认当前git status是干净的最好git log看一下当前提交确实是 v1.11.0 对应的。5. 烧录到飞控板与地面站配置5.1 命令行 USB 烧录编译通过后把飞控通过 USB 连到电脑执行make px4_fmu-v5_default upload这条命令会先重新编译一次然后进入烧录流程。烧录前飞控需要处于 bootloader 模式有些板子需要按住飞控板上的 BOOT 键再上电QGroundControl 刷固件时则通常不需要手动按。如果终端提示Permission denied: /dev/ttyACM0说明当前用户没有串口权限。执行sudo usermod -a -G dialout $USER然后注销重新登录或者重启系统让用户组生效。之后重新插拔 USB再执行 upload 命令。5.2 用 QGroundControl 刷自定义固件命令行烧录用得比较多但如果你对命令行不熟推荐用 QGroundControl 地面站。打开 QGroundControl进入设置里的固件页面选择自定义固件文件然后选中编译目录下的px4_fmu-v5_default.px4文件地面站会自动完成擦除和写入。这里有个值得注意的细节如果你手里的 QGroundControl 版本太新打开 1.11.0 时期生成的参数文件时个别界面控件可能不兼容。为了减少干扰可以考虑使用和 1.11.0 同期发布的稳定版 QGroundControl。这不是硬性要求但如果你发现自己某些参数显示异常先别急着怀疑固件换一个旧版地面站试试多半就正常了。5.3 刷完老固件之后的必做校准从新版固件刷回 1.11.0或从未刷过 1.11.0刷完第一次上电时一定不要直接解锁起飞。至少完成以下几件事机架选择在 QGroundControl 中设置正确的机架类型多旋翼选多旋翼固定翼选固定翼。机架选错会导致混控器输出完全错误。加速度计和陀螺仪校准按照地面站提示把飞机依次摆放到多个姿态位置等待数值稳定。遥控器校准拨动所有摇杆通道确保行程范围映射正确。参数检查如果之前有备份参数通过地面站恢复参数文件如果没有备份重点检查MAV_开头的参数是否真的是恢复默认而不是继承了其他固件版本的残留参数。对于回退到 1.11.0 的人来说最怕的是参数残留。老版本固件和新版本固件的参数 ID 并不完全一致直接恢复新版固件的参数文件到老固件可能会把某些参数写到错误的 ID 上导致飞机行为诡异。所以我的习惯是刷完老固件后先重置所有参数为默认值再进行手动校准最后才恢复关键参数。这个过程更像是在重新初始化一架飞机而不是升级更新但这是能稳定起飞的最短路径。如果你只是临时评估老固件建议刷回老版本前先用 QGroundControl 导出当前参数和固件版本信息备份好。万一新功能还得用随时能恢复到原本状态。这套流程走下来1.11.0 在你手里就是一个稳定、可控、可复现的飞行平台而不是一个让人头疼的老古董。本文还有配套的精品资源点击获取