在无人机圈子里PX4几乎成了开源自驾仪的代名词。不管你是折腾Pixhawk飞控板、做视觉避障算法验证还是纯粹想在仿真环境里把无人机飞起来第一道坎永远是开发环境的搭建。很多朋友第一次搭PX4环境时光是下载依赖、装交叉编译器就能耗掉大半天中间再碰上版本对不上的坑心态很容易崩。这篇文章分享一条我反复验证过的PX4开发环境搭建路径核心思路是把散落在各个源里的大体积依赖集中到百度云离线包中一次性下好再按照固定顺序解压配置实测下来整个命令执行过程可以控制在5分钟以内。适合刚入手PX4、想快速进入编译和仿真环节的开发者也适合实验室或培训机构批量复现环境省去每台机器各自折腾的时间。1. 为什么PX4开发环境总让人栽跟头1.1 PX4不是“一个软件”而是一整套工具链PX4本质上是开源的飞行控制软件栈包含飞控固件Firmware、地面站QGroundControl、仿真器Gazebo / jMAVSim以及大量的构建脚本。它主要用C和Python编写编译的时候还需要交叉编译器把源码编成ARM架构的固件才能烧录到Pixhawk等飞控硬件上运行。换句话说所谓“开发环境搭建”实际是把Ubuntu系统、Git、CMake、Python、交叉编译器、仿真器、PX4源码这七八样东西全部配到能协同工作的状态。很多人误以为把PX4源码下载下来就算搭好环境结果在make编译阶段才暴露出依赖缺失问题那时候再逐个排查特别费劲。我见过不少新手在第一次执行make px4_sitl_default时报错几十行翻来覆去就是-bash: cmake: command not found或者empy module missing这类基础依赖没装。把整套链路的构成提前搞清楚远比闷头敲命令重要。1.2 环境搭建慢到底慢在哪PX4的官方安装脚本ubuntu.sh非常强大一句命令就能装好大部分依赖但它的问题也很明显。依赖体积大脚本会安装几十个软件包包括gcc-arm-none-eabi交叉编译工具链、ninja-build、protobuf-compiler、python3-empy等全部下载安装完成后体积轻松超过2GB。版本兼容性敏感Ubuntu版本不同、PX4源码版本不同依赖的版本要求也不同。比如PX4 v1.13和v1.14对Python包empy和jinja2就有不同的版本锁定一旦装错版本编译时就会报各种奇怪错误。仿真器依赖更重Gazebo模拟器会拉取大量图形和传感器模型库首次启动还会自动下载模型文件这一步通常最折磨人。重试成本高在线安装过程中只要有一个包下载超时或中断再次运行脚本时往往还是从网络重新拉取同一个错误可能反复踩。这就是为什么很多人的PX4环境搭了三五天还没跑起来不是操作步骤不对而是大量时间花在了下载、解压、重试这些琐碎环节上。1.3 离线资源包的思路为什么更实用我被一台完全离线的开发机“教育”过一次之后彻底改变了搭环境的方式。当时手头只有U盘里的PX4源码和依赖包必须在不碰网络的情况下把环境从零配好。那次经历让我意识到如果提前把常用依赖、工具链、源码全部整理成离线包后面不管换多少台电脑环境都能快速复现。离线包的好处有三个一是下载环节可以集中完成一次下载、反复使用批量部署时效率极高二是版本完全锁定不会因为在线源更新导致某台机器装到了不同版本的依赖三是配置环节几乎不依赖网络出错的维度少了一大半。这也是这篇文章附带百度云资源的原因——把“下载”和“配置”拆开下载可以慢慢来但真正执行配置命令时完全可以做到5分钟内跑通。2. 动手前准备一张清单看懂所有依赖2.1 操作系统选型与磁盘规划PX4官方对Linux的支持最好我个人建议使用Ubuntu 20.04 LTS或22.04 LTS。20.04在PX4 v1.13、v1.14版本下兼容性最省心22.04同样可用但个别ROS/Gazebo相关的包名会有差异。磁盘方面至少预留30GB空闲空间。PX4源码本身不大但编译产生的中间文件、Gazebo模型缓存、CMake构建目录加起来非常占地方。内存建议8GB以上尤其是跑Gazebo仿真时内存不够很容易卡死。Windows用户可以考虑WSL2在WSL2里安装Ubuntu 22.04再跑PX4工具链也是可行的。不过要注意WSL2对USB设备直通支持有限如果后续要接Pixhawk硬件调试还是建议原生安装Ubuntu或使用单独的Linux物理机/虚拟机。虚拟机也可以但仿真性能会有损耗。2.2 离线资源包内容说明我在百度云上整理的资源包主要包含四块PX4 v1.14.3完整源码已初始化好所有子模块交叉编译工具链gcc-arm-none-eabi的离线安装包Python依赖包的本地缓存Gazebo和jMAVSim仿真器的依赖说明与配置脚本其中PX4源码是最关键的。GitHub上直接clone源码并不算慢真正慢的是初始化子模块的步骤官方仓库依赖了大量第三方库git submodule update --init --recursive可能需要下载几百MB甚至上GB的内容在线执行极其考验网络耐心。离线包把这一步省掉了解压即用。2.3 准备顺序先把下载任务排队我建议在开始搭建前先做两件事第一把百度云资源包下载好并校验压缩包完整性第二把Ubuntu的apt源替换为国内镜像源。这两件事做完后面的所有步骤都会顺畅很多。注意资源包版本和PX4源码版本必须对应。不要下了一个v1.14的源码包却用v1.12的依赖配置版本混搭是环境搭建失败的主要原因之一。3. 完整实操从零到编译通过3.1 第一步安装基础系统依赖打开终端先更新软件包索引再安装基础工具sudo apt update sudo apt install -y git zip qtcreator cmake build-essential genromfs ninja-build exiftool这些工具各自有各自的用途git用来拉取和管理源码cmake是PX4构建系统的核心ninja-build提供更快的构建后端genromfs用于生成固件镜像文件系统exiftool在编译过程中处理固件元数据。新手容易忽略exiftool但它缺失时编译会在最后阶段报错而且报错信息很隐蔽。3.2 第二步配置Python环境与pip依赖PX4编译脚本大量使用Python尤其是消息生成环节依赖empy、jinja2、numpy、toml等包。先安装pip再安装Python依赖sudo apt install -y python3-pip python3-venv python3 -m pip install --upgrade pip python3 -m pip install --user empy3.3.4 pyros-genmsg setuptools jinja2 numpy toml注意empy的版本。PX4 v1.14要求empy3.x如果系统里默认装了更高版本编译时会出现ModuleNotFoundError: No module named em这类问题。pyros-genmsg是消息生成依赖缺失时同样会直接中断编译。pip在国内环境下可能下载缓慢建议把pip源也切换为国内镜像。执行pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple这样后续安装Python包会快很多。3.3 第三步部署PX4源码和工具链这是整个流程中最关键的一步。如果你下载了百度云资源包解压后应该能看到一个PX4-Autopilot目录里面就是完整源码。把目录放到用户目录下例如~/PX4-Autopilot然后进入目录cd ~/PX4-Autopilot git submodule update --init --recursive资源包里已经初始化好了子模块这条命令主要用于确认子模块完整正常情况下几秒钟就会结束。如果你是自己clone的源码这一步会非常慢需要耐心等待。接下来安装交叉编译工具链。解压gcc-arm-none-eabi离线包后把工具链路径加到环境变量中echo export PATH$PATH:$HOME/gcc-arm-none-eabi-10.3-2021.10/bin ~/.bashrc source ~/.bashrc arm-none-eabi-gcc --version看到版本号输出就说明交叉编译器可用了。PX4 v1.14对GCC版本有最低要求建议使用10.3或更新的版本太老的编译器会在链接阶段报错。3.4 第四步编译固件与SITL仿真进入PX4源码目录先编译SITL仿真版本用于验证工具链是否完整cd ~/PX4-Autopilot make px4_sitl_default第一次编译时间比较长取决于CPU核心数十几分钟到半小时都有可能。编译完成后目录下会生成build/px4_sitl_default文件夹里面是可执行文件。如果这一步能顺利通过说明基础环境已经没问题了。接着可以尝试编译真实飞控固件。以Pixhawk 4为例命令是make px4_fmu-v5_default不同的飞控板对应不同的构建目标比如Pixhawk 6X对应px4_fmu-v6x_default可以选择自己手头板子的目标编译。编译完成后会生成可烧录的固件文件通常位于build/px4_fmu-v5_default/目录下后缀为.px4。3.5 第五步验证地面站连接环境搭建最终要落实到能飞或者能仿真。启动SITL仿真make px4_sitl_default jmavsim这个命令会同时启动PX4的SITL进程和jMAVSim仿真器看到3D无人机模型界面后再打开QGroundControl地面站地面站会自动连接到本机的仿真端口。如果连接成功地面站地图上会出现一架无人机并且能够看到实时姿态数据。如果想用更真实的物理仿真可以用Gazebomake px4_sitl_default gazeboGazebo启动后会加载无人机模型地面站同样可以连接。第一次启动Gazebo可能会卡在模型下载界面这是因为需要拉取场景模型耐心等待或者检查网络即可。4. 踩坑实录常见问题与排查方法4.1 编译阶段的高频报错我整理了一份PX4环境搭建过程中出现频率最高的报错速查表报错信息可能原因解决办法No module named emempy未安装或者版本不对重新安装empy3.3.4arm-none-eabi-gcc: command not found交叉编译器路径没加入PATH重新执行export PATH...并source ~/.bashrcCMake Error: The following variables are used in this project, but they are set to NOTFOUND缺少某个系统依赖库核对apt安装清单补装缺失包/usr/bin/env: python: No such file or directory系统缺少python软链接执行sudo ln -s /usr/bin/python3 /usr/bin/pythonException: Ctrl-C pressed, aborting编译空间不足或内存不足清理磁盘空间关闭多余应用其中python软链接问题最容易让人一头雾水。Ubuntu 20.04之后默认没有python命令只提供python3但PX4的部分脚本写死了python所以必须手动创建软链接。4.2 仿真启动失败的排查思路仿真器启动失败是另一个高频问题。主要表现为三种情况第一种是make px4_sitl_default gazebo执行后没有任何反应。先确认系统里是否已经安装Gazebo相关依赖。离线资源包里的配置脚本会自动安装但如果你手工操作可能需要额外执行sudo apt install -y gazebo11 libgazebo11-dev第二种是Gazebo启动后黑屏或者无人机模型不显示。这多半与显卡驱动或OpenGL渲染环境有关虚拟机环境尤其容易出现。可以尝试启动时加上软件渲染参数export LIBGL_ALWAYS_SOFTWARE1然后重新运行Gazebo。第三种是仿真启动后QGC地面站连不上检查一下PX4终端窗口是否还在运行以及QGC右下角的通信链路是否为UDP模式地址为127.0.0.1端口14550。4.3 几个提升效率的实操技巧环境能跑起来只是第一步实际开发中还有几个技巧非常管用。启用ccache编译缓存。PX4二次编译时如果改动很小完全没必要重新编译全部文件。安装ccache后把它设置成CMake的编译器包装器二次编译速度能提升好几倍sudo apt install -y ccache echo export CCACHE_DIR$HOME/.ccache ~/.bashrc echo export PATH/usr/lib/ccache:$PATH ~/.bashrc source ~/.bashrc使用多线程编译。编译时指定-j参数可以充分利用多核CPU比如make px4_sitl_default -j8如果CPU是8核16线程可以放心用-j16。需要留意内存容量线程开太多会导致内存耗尽系统直接卡死。版本冻结意识。PX4迭代速度快不同大版本之间的目录结构和构建系统差异很大。我建议在项目目录里用一个文件记录PX4版本、Ubuntu版本、Gazebo版本和工具链版本。环境一旦跑通就不要轻易升级任何组件。这个习惯能让你少踩很多坑。4.4 别忘了仿真模型的后续问题如果你是在做视觉SLAM或目标检测相关开发大概率会需要向Gazebo中加入自定义模型或传感器插件。这里提醒一句Gazebo的自定义模型路径是通过GAZEBO_MODEL_PATH环境变量加载的。如果在仿真中找不到模型先检查这个环境变量是否包含了模型目录而不是急着重装PX4。我个人在实际使用中还有一个体会每次给新手装环境我都会先用百度云离线资源包在虚拟机里完整跑一遍把版本号和关键路径记录下来再上实体开发机操作。这样做的原因不是程序化流程而是PX4的依赖确实敏感一个小版本的差异就可能导致编译失败。把环境“复现能力”放在第一位比临时抱佛脚去查错误日志靠谱得多。如果这篇分享能帮你节省一晚上的搭建时间那这个离线包的整理思路就值了。
PX4开发环境快速搭建：离线依赖包5分钟搞定编译与仿真
在无人机圈子里PX4几乎成了开源自驾仪的代名词。不管你是折腾Pixhawk飞控板、做视觉避障算法验证还是纯粹想在仿真环境里把无人机飞起来第一道坎永远是开发环境的搭建。很多朋友第一次搭PX4环境时光是下载依赖、装交叉编译器就能耗掉大半天中间再碰上版本对不上的坑心态很容易崩。这篇文章分享一条我反复验证过的PX4开发环境搭建路径核心思路是把散落在各个源里的大体积依赖集中到百度云离线包中一次性下好再按照固定顺序解压配置实测下来整个命令执行过程可以控制在5分钟以内。适合刚入手PX4、想快速进入编译和仿真环节的开发者也适合实验室或培训机构批量复现环境省去每台机器各自折腾的时间。1. 为什么PX4开发环境总让人栽跟头1.1 PX4不是“一个软件”而是一整套工具链PX4本质上是开源的飞行控制软件栈包含飞控固件Firmware、地面站QGroundControl、仿真器Gazebo / jMAVSim以及大量的构建脚本。它主要用C和Python编写编译的时候还需要交叉编译器把源码编成ARM架构的固件才能烧录到Pixhawk等飞控硬件上运行。换句话说所谓“开发环境搭建”实际是把Ubuntu系统、Git、CMake、Python、交叉编译器、仿真器、PX4源码这七八样东西全部配到能协同工作的状态。很多人误以为把PX4源码下载下来就算搭好环境结果在make编译阶段才暴露出依赖缺失问题那时候再逐个排查特别费劲。我见过不少新手在第一次执行make px4_sitl_default时报错几十行翻来覆去就是-bash: cmake: command not found或者empy module missing这类基础依赖没装。把整套链路的构成提前搞清楚远比闷头敲命令重要。1.2 环境搭建慢到底慢在哪PX4的官方安装脚本ubuntu.sh非常强大一句命令就能装好大部分依赖但它的问题也很明显。依赖体积大脚本会安装几十个软件包包括gcc-arm-none-eabi交叉编译工具链、ninja-build、protobuf-compiler、python3-empy等全部下载安装完成后体积轻松超过2GB。版本兼容性敏感Ubuntu版本不同、PX4源码版本不同依赖的版本要求也不同。比如PX4 v1.13和v1.14对Python包empy和jinja2就有不同的版本锁定一旦装错版本编译时就会报各种奇怪错误。仿真器依赖更重Gazebo模拟器会拉取大量图形和传感器模型库首次启动还会自动下载模型文件这一步通常最折磨人。重试成本高在线安装过程中只要有一个包下载超时或中断再次运行脚本时往往还是从网络重新拉取同一个错误可能反复踩。这就是为什么很多人的PX4环境搭了三五天还没跑起来不是操作步骤不对而是大量时间花在了下载、解压、重试这些琐碎环节上。1.3 离线资源包的思路为什么更实用我被一台完全离线的开发机“教育”过一次之后彻底改变了搭环境的方式。当时手头只有U盘里的PX4源码和依赖包必须在不碰网络的情况下把环境从零配好。那次经历让我意识到如果提前把常用依赖、工具链、源码全部整理成离线包后面不管换多少台电脑环境都能快速复现。离线包的好处有三个一是下载环节可以集中完成一次下载、反复使用批量部署时效率极高二是版本完全锁定不会因为在线源更新导致某台机器装到了不同版本的依赖三是配置环节几乎不依赖网络出错的维度少了一大半。这也是这篇文章附带百度云资源的原因——把“下载”和“配置”拆开下载可以慢慢来但真正执行配置命令时完全可以做到5分钟内跑通。2. 动手前准备一张清单看懂所有依赖2.1 操作系统选型与磁盘规划PX4官方对Linux的支持最好我个人建议使用Ubuntu 20.04 LTS或22.04 LTS。20.04在PX4 v1.13、v1.14版本下兼容性最省心22.04同样可用但个别ROS/Gazebo相关的包名会有差异。磁盘方面至少预留30GB空闲空间。PX4源码本身不大但编译产生的中间文件、Gazebo模型缓存、CMake构建目录加起来非常占地方。内存建议8GB以上尤其是跑Gazebo仿真时内存不够很容易卡死。Windows用户可以考虑WSL2在WSL2里安装Ubuntu 22.04再跑PX4工具链也是可行的。不过要注意WSL2对USB设备直通支持有限如果后续要接Pixhawk硬件调试还是建议原生安装Ubuntu或使用单独的Linux物理机/虚拟机。虚拟机也可以但仿真性能会有损耗。2.2 离线资源包内容说明我在百度云上整理的资源包主要包含四块PX4 v1.14.3完整源码已初始化好所有子模块交叉编译工具链gcc-arm-none-eabi的离线安装包Python依赖包的本地缓存Gazebo和jMAVSim仿真器的依赖说明与配置脚本其中PX4源码是最关键的。GitHub上直接clone源码并不算慢真正慢的是初始化子模块的步骤官方仓库依赖了大量第三方库git submodule update --init --recursive可能需要下载几百MB甚至上GB的内容在线执行极其考验网络耐心。离线包把这一步省掉了解压即用。2.3 准备顺序先把下载任务排队我建议在开始搭建前先做两件事第一把百度云资源包下载好并校验压缩包完整性第二把Ubuntu的apt源替换为国内镜像源。这两件事做完后面的所有步骤都会顺畅很多。注意资源包版本和PX4源码版本必须对应。不要下了一个v1.14的源码包却用v1.12的依赖配置版本混搭是环境搭建失败的主要原因之一。3. 完整实操从零到编译通过3.1 第一步安装基础系统依赖打开终端先更新软件包索引再安装基础工具sudo apt update sudo apt install -y git zip qtcreator cmake build-essential genromfs ninja-build exiftool这些工具各自有各自的用途git用来拉取和管理源码cmake是PX4构建系统的核心ninja-build提供更快的构建后端genromfs用于生成固件镜像文件系统exiftool在编译过程中处理固件元数据。新手容易忽略exiftool但它缺失时编译会在最后阶段报错而且报错信息很隐蔽。3.2 第二步配置Python环境与pip依赖PX4编译脚本大量使用Python尤其是消息生成环节依赖empy、jinja2、numpy、toml等包。先安装pip再安装Python依赖sudo apt install -y python3-pip python3-venv python3 -m pip install --upgrade pip python3 -m pip install --user empy3.3.4 pyros-genmsg setuptools jinja2 numpy toml注意empy的版本。PX4 v1.14要求empy3.x如果系统里默认装了更高版本编译时会出现ModuleNotFoundError: No module named em这类问题。pyros-genmsg是消息生成依赖缺失时同样会直接中断编译。pip在国内环境下可能下载缓慢建议把pip源也切换为国内镜像。执行pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple这样后续安装Python包会快很多。3.3 第三步部署PX4源码和工具链这是整个流程中最关键的一步。如果你下载了百度云资源包解压后应该能看到一个PX4-Autopilot目录里面就是完整源码。把目录放到用户目录下例如~/PX4-Autopilot然后进入目录cd ~/PX4-Autopilot git submodule update --init --recursive资源包里已经初始化好了子模块这条命令主要用于确认子模块完整正常情况下几秒钟就会结束。如果你是自己clone的源码这一步会非常慢需要耐心等待。接下来安装交叉编译工具链。解压gcc-arm-none-eabi离线包后把工具链路径加到环境变量中echo export PATH$PATH:$HOME/gcc-arm-none-eabi-10.3-2021.10/bin ~/.bashrc source ~/.bashrc arm-none-eabi-gcc --version看到版本号输出就说明交叉编译器可用了。PX4 v1.14对GCC版本有最低要求建议使用10.3或更新的版本太老的编译器会在链接阶段报错。3.4 第四步编译固件与SITL仿真进入PX4源码目录先编译SITL仿真版本用于验证工具链是否完整cd ~/PX4-Autopilot make px4_sitl_default第一次编译时间比较长取决于CPU核心数十几分钟到半小时都有可能。编译完成后目录下会生成build/px4_sitl_default文件夹里面是可执行文件。如果这一步能顺利通过说明基础环境已经没问题了。接着可以尝试编译真实飞控固件。以Pixhawk 4为例命令是make px4_fmu-v5_default不同的飞控板对应不同的构建目标比如Pixhawk 6X对应px4_fmu-v6x_default可以选择自己手头板子的目标编译。编译完成后会生成可烧录的固件文件通常位于build/px4_fmu-v5_default/目录下后缀为.px4。3.5 第五步验证地面站连接环境搭建最终要落实到能飞或者能仿真。启动SITL仿真make px4_sitl_default jmavsim这个命令会同时启动PX4的SITL进程和jMAVSim仿真器看到3D无人机模型界面后再打开QGroundControl地面站地面站会自动连接到本机的仿真端口。如果连接成功地面站地图上会出现一架无人机并且能够看到实时姿态数据。如果想用更真实的物理仿真可以用Gazebomake px4_sitl_default gazeboGazebo启动后会加载无人机模型地面站同样可以连接。第一次启动Gazebo可能会卡在模型下载界面这是因为需要拉取场景模型耐心等待或者检查网络即可。4. 踩坑实录常见问题与排查方法4.1 编译阶段的高频报错我整理了一份PX4环境搭建过程中出现频率最高的报错速查表报错信息可能原因解决办法No module named emempy未安装或者版本不对重新安装empy3.3.4arm-none-eabi-gcc: command not found交叉编译器路径没加入PATH重新执行export PATH...并source ~/.bashrcCMake Error: The following variables are used in this project, but they are set to NOTFOUND缺少某个系统依赖库核对apt安装清单补装缺失包/usr/bin/env: python: No such file or directory系统缺少python软链接执行sudo ln -s /usr/bin/python3 /usr/bin/pythonException: Ctrl-C pressed, aborting编译空间不足或内存不足清理磁盘空间关闭多余应用其中python软链接问题最容易让人一头雾水。Ubuntu 20.04之后默认没有python命令只提供python3但PX4的部分脚本写死了python所以必须手动创建软链接。4.2 仿真启动失败的排查思路仿真器启动失败是另一个高频问题。主要表现为三种情况第一种是make px4_sitl_default gazebo执行后没有任何反应。先确认系统里是否已经安装Gazebo相关依赖。离线资源包里的配置脚本会自动安装但如果你手工操作可能需要额外执行sudo apt install -y gazebo11 libgazebo11-dev第二种是Gazebo启动后黑屏或者无人机模型不显示。这多半与显卡驱动或OpenGL渲染环境有关虚拟机环境尤其容易出现。可以尝试启动时加上软件渲染参数export LIBGL_ALWAYS_SOFTWARE1然后重新运行Gazebo。第三种是仿真启动后QGC地面站连不上检查一下PX4终端窗口是否还在运行以及QGC右下角的通信链路是否为UDP模式地址为127.0.0.1端口14550。4.3 几个提升效率的实操技巧环境能跑起来只是第一步实际开发中还有几个技巧非常管用。启用ccache编译缓存。PX4二次编译时如果改动很小完全没必要重新编译全部文件。安装ccache后把它设置成CMake的编译器包装器二次编译速度能提升好几倍sudo apt install -y ccache echo export CCACHE_DIR$HOME/.ccache ~/.bashrc echo export PATH/usr/lib/ccache:$PATH ~/.bashrc source ~/.bashrc使用多线程编译。编译时指定-j参数可以充分利用多核CPU比如make px4_sitl_default -j8如果CPU是8核16线程可以放心用-j16。需要留意内存容量线程开太多会导致内存耗尽系统直接卡死。版本冻结意识。PX4迭代速度快不同大版本之间的目录结构和构建系统差异很大。我建议在项目目录里用一个文件记录PX4版本、Ubuntu版本、Gazebo版本和工具链版本。环境一旦跑通就不要轻易升级任何组件。这个习惯能让你少踩很多坑。4.4 别忘了仿真模型的后续问题如果你是在做视觉SLAM或目标检测相关开发大概率会需要向Gazebo中加入自定义模型或传感器插件。这里提醒一句Gazebo的自定义模型路径是通过GAZEBO_MODEL_PATH环境变量加载的。如果在仿真中找不到模型先检查这个环境变量是否包含了模型目录而不是急着重装PX4。我个人在实际使用中还有一个体会每次给新手装环境我都会先用百度云离线资源包在虚拟机里完整跑一遍把版本号和关键路径记录下来再上实体开发机操作。这样做的原因不是程序化流程而是PX4的依赖确实敏感一个小版本的差异就可能导致编译失败。把环境“复现能力”放在第一位比临时抱佛脚去查错误日志靠谱得多。如果这篇分享能帮你节省一晚上的搭建时间那这个离线包的整理思路就值了。
