第二章 PX4源码获取与编译：从零搭建你的开发环境
好，咱们正式开始动手了。这一章我带你走一遍PX4源码的获取和编译流程。说实话，很多新手在这一步就被劝退了——环境配不好，编译报错一堆，连代码都跑不起来。别急，我踩过的坑，今天一次性帮你填平。
2.1 下载PX4源码：选对分支很重要
先说说源码怎么拿。PX4托管在GitHub上，地址是 https://github.com/PX4/PX4-Autopilot。我个人习惯用 git clone 直接拉取，但这里有个细节——分支选择。
v1.14.3 或 v1.15.0-beta1。你在项目里用稳定版，出问题了也好查文档。
# 克隆主仓库
git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot
# 切换到稳定版分支
git checkout v1.14.3
# 更新子模块（这一步容易忘）
git submodule update --init --recursive
嗯，这里要特别提一下 --recursive 参数。PX4依赖很多子模块，比如uORB、drivers、mavlink等等。如果不加这个参数，你编译时会发现一堆头文件找不到。我在项目中遇到过好几次，同事拉完代码直接编译，报错后一脸懵地来找我——其实就是子模块没拉全。
2.2 配置编译环境：Ubuntu 20.04 是最稳的选择
环境配置这块，我推荐用Ubuntu 20.04 LTS。为什么？因为PX4官方对这个版本的测试最充分。你非要用22.04也行，但有些依赖包版本会变，得自己折腾。
说白了，环境配置就三步：装依赖、装工具链、装仿真器。
2.2.1 安装系统依赖
PX4官方提供了一个自动化脚本，但我建议你手动装，这样出了问题你知道哪里挂了。
# 更新包列表
sudo apt update
# 安装基础依赖
sudo apt install -y \
git \
cmake \
ninja-build \
python3-pip \
python3-venv \
gcc-arm-none-eabi \
gdb-multiarch \
libxml2-dev \
libxslt1-dev \
libssl-dev \
libffi-dev \
libncurses5-dev \
libncursesw5-dev \
libudev-dev \
libusb-1.0-0-dev \
zlib1g-dev \
pkg-config \
protobuf-compiler \
clang-tidy \
doxygen \
graphviz
这里有个坑：gcc-arm-none-eabi 的版本。Ubuntu 20.04 默认装的是 9.x 版本，够用。但如果你用 Ubuntu 22.04，默认装的是 10.x，编译某些老版本固件会报错。我曾经因为这个折腾了一下午，最后老老实实降级了。
2.2.2 安装Python依赖
PX4的编译脚本和测试工具依赖Python包。我建议用虚拟环境，别污染系统Python。
# 创建虚拟环境
python3 -m venv px4_venv
source px4_venv/bin/activate
# 安装PX4 Python工具
pip install --upgrade pip
pip install --user -r PX4-Autopilot/Tools/setup/requirements.txt
source px4_venv/bin/activate。我习惯把这个命令加到 .bashrc 里，省得每次手动敲。
2.2.3 安装仿真环境（可选但推荐）
如果你没有真机，或者想先调试逻辑，Gazebo仿真是个好选择。安装命令如下：
# 安装Gazebo 11（Ubuntu 20.04默认）
sudo apt install -y gazebo11 libgazebo11-dev
# 安装PX4的Gazebo插件
cd PX4-Autopilot
make gazebo
你想想看，没有真机的时候，仿真环境就是你的救命稻草。我刚开始做驱动开发时，先在Gazebo里跑通了逻辑，才敢上真机。不然炸一次机，成本够买好几块开发板了。
2.3 编译目标固件：从make命令开始
环境配好了，咱们来编译固件。PX4用 make 命令管理编译，格式是 make [board]_[target]。
常用的目标有：
| 目标 | 说明 | 典型用途 |
|---|---|---|
px4_fmu-v5_default |
Pixhawk 4 (FMUv5) 固件 | 最常见的硬件平台 |
px4_fmu-v6x_default |
Pixhawk 6X (FMUv6X) 固件 | 新一代高性能飞控 |
sitl_default |
软件在环仿真 | 无硬件调试 |
gazebo |
Gazebo仿真 | 配合Gazebo做HITL/SITL |
举个例子，编译Pixhawk 4的固件：
cd PX4-Autopilot
make px4_fmu-v5_default
第一次编译会比较慢，因为要下载工具链、编译所有模块。我建议用 -j 参数指定并行编译核心数，比如 make -j4 px4_fmu-v5_default，能快不少。
build/ 目录下看到中间产物，比如 px4_fmu-v5_default.px4 就是最终固件。
2.4 常见编译错误解决：我踩过的坑都在这了
编译报错是家常便饭。别慌，大部分问题都有固定解法。我整理了几个高频错误，你遇到了直接对号入座。
2.4.1 错误1：找不到 arm-none-eabi-gcc
现象：
/bin/sh: 1: arm-none-eabi-gcc: not found原因： 工具链没装或者没加到PATH里。
解决：
# 检查是否安装
which arm-none-eabi-gcc
# 如果没装，重新安装
sudo apt install --reinstall gcc-arm-none-eabi
# 如果装了但找不到，手动加PATH
export PATH=$PATH:/usr/bin
我曾经犯过一个低级错误：装了工具链但忘了source环境变量，结果折腾了半小时才发现。
2.4.2 错误2：子模块缺失
现象：
fatal: Not a git repository: /path/to/PX4-Autopilot/src/modules/uORB原因： 克隆时没加 --recursive，或者子模块没更新。
解决：
git submodule update --init --recursive
嗯，这个错误我见得太多了。尤其是团队协作时，有人拉代码忘了加参数，编译直接挂。我的建议是：每次拉完代码，先跑一遍 git submodule status 检查一下。
2.4.3 错误3：Python依赖版本冲突
现象：
ModuleNotFoundError: No module named 'numpy'原因： 虚拟环境没激活，或者依赖没装全。
解决：
# 激活虚拟环境
source px4_venv/bin/activate
# 重新安装依赖
pip install --user -r PX4-Autopilot/Tools/setup/requirements.txt
sudo pip install！这会把包装到系统Python里，容易搞乱环境。我建议始终用虚拟环境。
2.4.4 错误4：内存不足导致编译崩溃
现象： 编译到一半，终端卡死或者报 Killed。
原因： 并行编译太猛，内存爆了。尤其是虚拟机用户，默认只给2GB内存。
解决：
# 减少并行数
make -j2 px4_fmu-v5_default
# 或者用ninja（更省内存）
make px4_fmu-v5_default NINJA=1
你想想看，编译PX4这种大型项目，内存少于4GB真的会卡。我自己的开发机是16GB内存，开8个并行编译都没问题。如果你用虚拟机，建议至少给4GB。
2.5 知识体系总览：一张图看懂本章
说了这么多，我画了一张流程图，帮你把整个流程串起来。从源码获取到固件生成，每一步都清晰可见。
2.6 避坑指南：我踩过的那些坑
最后，分享几个我亲身经历的教训，希望能帮你少走弯路。
- 不要用root用户编译。 我曾经图省事，用sudo make编译，结果生成的固件权限混乱，烧录时死活识别不到。后来查了半天才发现是权限问题。
- 编译前先清理。 如果你切换了分支或者改了配置，记得先
make clean或make distclean。不然残留的中间文件会导致奇怪的问题。 - 注意磁盘空间。 PX4编译一次大概占用2-3GB空间。如果你频繁编译，build目录会越来越大。我习惯定期
rm -rf build/清理一下。 - 网络问题。 国内访问GitHub有时很慢。我建议用代理，或者把
git://换成https://。子模块下载失败时，多试几次git submodule update。
好了，这一章的内容就到这。环境搭好了，下一章咱们就可以开始写真正的驱动代码了。记住，编译环境是基础，基础不牢，地动山摇。花点时间把这一步走稳，后面会顺利很多。