PX4源码获取与编译：从Git仓库到飞控固件
这一章，我们来聊聊PX4源码的获取和编译。说白了，就是怎么把一堆代码变成能跑在飞控板上的固件。我见过不少新手，拿着源码不知道怎么下手，或者编译出来飞不起来——嗯，多半是编译命令选错了。
Git仓库结构：别被文件夹吓到
先说说PX4的Git仓库。你从GitHub上clone下来，第一眼看到的就是根目录下那一堆文件夹。我刚开始接触时也觉得眼花，但其实核心就几个。
核心目录一览：
- src/ —— 源码主目录。所有模块代码都在这里，包括飞行控制、导航、传感器驱动等。
- boards/ —— 板级支持包。每种飞控板（Pixhawk、CUAV、Holybro等）的配置和引脚定义。
- ROMFS/ —— 文件系统镜像。启动脚本、参数默认值、mixer文件都在这里。
- msg/ —— uORB消息定义。模块间通信的数据结构。
- mavlink/include/mavlink/v2.0/ —— MAVLink协议定义。
- Tools/ —— 辅助工具链。仿真、调试、测试脚本。
- cmake/ —— CMake构建配置。编译系统的核心。
我个人习惯把 src/ 和 boards/ 当作两个入口。改代码去 src/，换板子去 boards/。其他目录平时很少动。
Firmware目录解析：编译产物的归宿
你编译完成后，所有生成的文件都会放在 build/ 目录下。这个目录是按机型命名的，比如 build/px4_fmu-v5_default/。
| 文件/目录 | 说明 |
|---|---|
px4_fmu-v5_default.px4 |
最终固件文件，直接烧录到飞控板 |
px4_fmu-v5_default.bin |
二进制格式固件，部分烧录工具需要 |
px4_fmu-v5_default.elf |
带调试信息的可执行文件，GDB调试用 |
src/ |
编译过程中生成的中间文件 |
build.log |
编译日志，排查错误的好帮手 |
小技巧： 如果你编译报错，先看 build.log 的最后几行。我曾经花了一下午找bug，结果发现是工具链版本不对——日志里其实已经写了。
make编译系统：别怕，它没那么复杂
PX4用的是CMake + make这套组合。你只需要记住一个命令：
make [目标]这个「目标」决定了你编译什么机型、什么配置。比如：
make px4_fmu-v5_default这条命令会编译Pixhawk 4（FMUv5）的默认固件。为什么是这个名字？因为 boards/ 目录下有个 px4/fmu-v5/default.cmake 文件，定义了所有配置。
编译系统的工作流程是这样的：
- CMake读取
boards/下的配置文件，生成Makefile - make根据Makefile，按依赖关系编译每个模块
- 链接器把所有目标文件链接成固件
- 生成
.px4、.bin、.elf文件
注意： 第一次编译会很慢，因为要编译所有模块。之后只编译修改过的文件，速度会快很多。我建议第一次编译时去喝杯咖啡。
针对不同机型的编译命令
不同飞控板、不同机型，编译命令都不一样。下面是我常用的几个：
| 目标 | 适用板子 | 说明 |
|---|---|---|
px4_fmu-v2_default |
Pixhawk 1 (FMUv2) | 老款板子，资源有限 |
px4_fmu-v5_default |
Pixhawk 4 (FMUv5) | 主流板子，性能足够 |
px4_fmu-v6x_default |
Pixhawk 6X (FMUv6x) | 新款板子，支持更多外设 |
sitl_default |
PC仿真 | 在电脑上跑，不需要硬件 |
nuttx_pixhawk4 |
Pixhawk 4 | 另一种命名方式，效果一样 |
怎么知道自己的板子用哪个目标？去 boards/ 目录下找。每个子目录名就是目标名的一部分。比如 boards/px4/fmu-v5/ 对应 px4_fmu-v5。
避坑指南： 我曾经帮一个朋友调试，他编译了 px4_fmu-v2_default 烧到Pixhawk 4上，结果飞控死活不启动。后来发现是固件和板子不匹配。记住：固件版本必须和飞控板硬件版本对应。
固件烧录方法：把代码变成飞行
编译完成后，最后一步就是烧录。常用的方法有三种：
1. QGroundControl（推荐）
最简单的方法。打开QGC，进入「固件」页面，选择你编译好的 .px4 文件，点击烧录就行。QGC会自动识别飞控板并完成烧录。
2. 命令行烧录
如果你喜欢命令行，可以用 make 直接烧录：
make px4_fmu-v5_default upload这条命令会编译并烧录。前提是你的飞控板已经通过USB连接，并且驱动安装正确。
3. 使用J-Link/SWD调试器
这是最底层的方法。适合开发调试，或者飞控板变砖时救砖。你需要：
- J-Link或ST-Link调试器
- 连接SWD接口（SWDIO、SWCLK、GND）
- 使用
JLinkExe或openocd烧录.elf文件
警告： 用调试器烧录时，一定要确认接线正确。我曾经接反了SWDIO和SWCLK，结果飞控板直接冒烟了——嗯，那次之后我每次接线都会用万用表量一遍。
知识体系总览
下面这张图，把本章的核心逻辑串起来了。从源码到固件，再到飞控板，每一步都离不开。
从Git仓库拉下源码，理解目录结构，选对编译命令，生成固件，最后烧录到飞控板——这就是整个流程。每一步都有坑，但走一遍之后，你会发现其实没那么难。
我的建议： 第一次玩，先用 make sitl_default 在电脑上跑仿真。这样不用硬件也能验证你的编译环境是否正常。等仿真跑通了，再烧到真机上。我当年就是这么过来的，省了不少炸机的钱。