企业官网建设流程全解析

刚入坑无人机飞控的朋友，基本都会听到“PX4”这个名字。作为目前开源飞控里生态最完整、资料最丰富的一员，PX4几乎是每个想认真搞无人机开发的人绕不开的第一站。而这个系列我打算从零开始，带你一步步把 Ubuntu 24.04 上的 PX4 开发环境搭起来，从装系统、编译固件到跑起 Gazebo 仿真，把这套“飞控入门前期准备”的路全部走通。这篇就是第 01 篇，先把最基础、也最容易劝退新手的环境搭建讲清楚。

先说我为什么选 Ubuntu 24.04 而不是还在被大量教程使用的 20.04 / 22.04。原因很直接：24.04 是 2024 年 4 月发布的 LTS 长期支持版本，会一直支持到 2029 年，现在新出的不少硬件和软件包都在往它上面迁移。PX4 官方在 v1.14 之后对 Ubuntu 的适配也逐步向新版本靠拢，新 LTS 意味着后续几年你不用反复折腾系统升级。当然，版本新也带来一个问题：很多老教程里的命令在 24.04 上会踩坑，比如 Python 版本从 3.10 跳到 3.12、pip 安装方式的变化、Gazebo 版本差异等等。这也是我写这个系列的初衷——不是照搬官方文档，而是把真实踩过的坑和最终可用的路径记录下来。

这篇主要适合三类读者：一是刚接触无人机、想系统学习飞控开发的在校学生或转行开发者；二是已经在用别的飞控（比如 APM/ArduPilot）想迁移到 PX4 的人；三是只想先在电脑上跑仿真、不想急着买硬件的“仿真党”。无论你是哪一类，这篇文章都会尽量做到“照着做就能成”，同时对每一步背后的原理也做解释，让你以后遇到问题知道去哪查、怎么排查。

1. 整体设计与思路拆解：为什么是 Ubuntu 24.04 + PX4 + Gazebo

1.1 这套环境到底解决了什么问题

做飞控开发有个现实问题：固件不能直接在真机上反复测试，因为炸机成本太高、调试效率太低。所以行业通行做法是先在 PC 上做“软件在环仿真”，也就是把 PX4 固件编译成电脑上能跑的进程，再和 Gazebo 这个机器人仿真器连接，模拟出无人机在虚拟世界里的飞行状态。整个环境涉及的东西很多：操作系统、编译工具链、Python、ROS（可选）、Gazebo、PX4 固件源码、QGroundControl 地面站。任何一个环节出问题，都会导致“明明照着教程做却跑不起来”。

这一整套环境的价值就在于：它让你在花钱买飞控和机架之前，先用纯软件的方式学会 PX4 的基本操作、参数配置、飞行模式切换、日志分析。等你在仿真里把基本逻辑搞明白了，再去碰真实硬件，会从容很多。我见过太多人一上来就买 F405 飞控、电调、机架，结果固件都刷不进去，更别说调参了，最后整套设备吃灰。严格来说，如果你连 PX4 固件都没编译过、没在仿真里起飞过一次，真的不建议急着买硬件。

1.2 版本选型：Ubuntu 24.04 能跑 PX4 吗

先说结论：能跑，但要做一些针对性适配。PX4 官方文档对 Ubuntu 的支持早已覆盖最新 LTS，v1.15 和 main 分支都能在 24.04 上正常编译。不过要注意一个关键点：Ubuntu 24.04 默认的 GCC 是 13.x，CMake 是 3.28，Python 是 3.12，这些版本都比较新。PX4 的构建系统（基于 CMake + Ninja）对新版本的支持在近一年已经补得比较全，所以正常编译问题不大。真正容易出问题的是 Gazebo 的安装方式。

Ubuntu 24.04 的软件源里默认提供的是 Gazebo 11（也就是 Gazebo Classic），但 Ubuntu 24.04 的 Gazebo 11 包在 24.04 下存在一些 Qt 库兼容问题，容易出现仿真窗口白屏或者模型不加载的情况。所以我现在更推荐两条路：要么按 PX4 官方推荐的 Gazebo 版本走（官方脚本会帮你装合适的 Gazebo）；要么直接用 PX4 自带的新版 Gazebo（Garden/Harmonic）的方式。从兼容性和教程丰富度来看，先期用官方脚本装 Gazebo Classic 会更平滑，后面再慢慢过渡到新版 Gazebo。

还有一点，Ubuntu 24.04 的发行说明里明确提到默认不安装python3-pip，需要自己装，这与老版本不太一样。再加上 Python 3.12 默认启用PEP 668机制，直接用pip install到系统环境会被拒绝，必须用虚拟环境或者加--break-system-packages。这个问题几乎每个新手都会碰到，后面我在实操部分会专门讲。

1.3 安装方式选型：双系统、虚拟机还是 WSL

在动手装之前，先想清楚一个问题：PX4 开发环境你打算装在哪？三种常见方式我分别说下适用场景。

第一种，双系统。这是最推荐的正规军做法。PX4 编译涉及大量系统级依赖，对 USB 设备访问（接地面站、数传、飞控）也有要求，双系统性能损耗最小，不会出现虚拟机 USB 透传不稳定的问题。缺点是需要给 Ubuntu 划磁盘分区，操作有点门槛，切换系统还要重启。如果你打算长期搞飞控开发，别犹豫，选这个。

第二种，虚拟机（VirtualBox / VMware）。适合先体验一下、不想动磁盘分区的朋友。优势是安全，系统搞坏了删掉重来；缺点是性能打折，3D 加速在虚拟机里很别扭，Gazebo 仿真在虚拟机里帧率会非常低，地图加载也慢。如果你只是临时跑个固件编译，虚拟机够用；要是跑仿真，就有点吃力了。

第三种，WSL2。很多人想在 Windows 里直接跑 Linux 工具链，WSL2 确实很方便，而且现在 WSL2 对 GUI 应用的支持已经很好了。但 WSL2 和 USB 设备通信是比较麻烦的（需要 usbipd 之类的方案），这对以后接 PX4 硬件是硬伤。另外 Gazebo 在 WSL2 里的 OpenGL 渲染偶尔会出现黑色纹理的问题，需要手动处理。所以我的建议是：WSL2 适合“我在公司/学校电脑上临时改个代码”，不适合作为飞控开发主力环境。

这个系列后面的步骤都以双系统安装方式为主线来讲，因为绝大多数从入门到进阶的开发者最终都会走到这一步。

2. 第一步：Ubuntu 24.04 系统安装与初始化

2.1 系统镜像下载与启动盘制作

镜像下载尽量去官方渠道。打开 Ubuntu 官网的 Download 页面，选择 Ubuntu Desktop 24.04 LTS，会得到一个大约 6GB 的 ISO 文件。建议下载完成后核对一下 SHA256 校验值，官网每个镜像旁边都有对应校验值，这步虽然多花一分钟，但能避免拿到损坏或者被篡改的镜像。下载慢的话可以选离你比较近的国内镜像源，这个一般大家都有自己习惯用的，我就不展开说名字了。

启动盘制作我推荐用 Rufus（Windows 下）或者 balenaEtcher（跨平台）。两种工具都很成熟。需要注意的一点是，在 Rufus 里写入模式建议选 “DD 模式” 而不是 “ISO 模式”。原因在于 Ubuntu 24.04 的镜像使用了一种新的启动方式，DD 模式写入的启动盘兼容性更好、成功率更高。我最早用 ISO 模式做了几次都出现 “boot device not found”，换了 DD 模式一次就好。

如果是 UEFI 启动的电脑，进 BIOS 后要关闭 Secure Boot（安全启动），因为 Ubuntu 的第三方驱动（尤其是 NVIDIA 显卡驱动）在 Secure Boot 开启时加载会非常麻烦，后面装驱动很容易失败。不同品牌主板关闭路径不一样，无非是 BIOS 里找到 “Secure Boot” 或 “Security Boot” 选项，设为 Disabled。另外建议把 U 盘启动项调到第一位，方便直接从 U 盘引导。

2.2 双系统安装分区的实操思路

进入 Ubuntu 安装界面后，关键一步是分区。很多教程让你自定义分区，然后手动分/、/home、swap三个分区，其实对新手来说这有点过度设计。在 24.04 安装器里，如果你选择 “Install Ubuntu alongside Windows Boot Manager”，它会自动调整 Windows 分区大小，自动创建必要的分区，整个过程非常傻瓜化。这种方式对“前期准备”来说完全够用，以后再想精细调整也有的是办法。

不过有一个小技巧：如果你打算以后做大型仿真、跑 SLAM 或者建图，建议在自动分区之后，手动将/home单独分出来，并给足空间，比如至少 100GB。为什么？因为 PX4 源码、Gazebo 模型库、QGroundControl 的缓存、日志文件都会写在/home下，时间久了这些数据非常占空间。我自己的习惯是根分区给 80GB、/home给剩余全部空间。swap 方面，如果内存大于 16GB，可以不用单独分 swap，让系统用 swapfile 按需创建；内存只有 8GB 的话建议在安装器里指定一个 8GB 的 swap 分区，否则后面编译固件时内存会被吃满。

安装过程中会让你创建用户名和密码，这个用户名会出现在终端路径前缀里，比如/home/username。注意尽量不要用中文用户名，因为后面很多编译工具链对非 ASCII 路径支持不好，会导致各种莫名其妙的问题。我当年用中文用户名，结果 CMake 报了一堆编码错误，后来重装系统才彻底解决。

2.3 装完系统后的四件套：换源、更新、驱动、输入法

装好系统进桌面后，先别急着装 PX4，先把系统基础打好。我的固定顺序是：

第一步换软件源。Ubuntu 默认源的服务器在国外，下载速度不行。打开 “Software & Updates”，在 “Ubuntu Software” 选项卡里找到 “Download from”，选择国内镜像源。一般镜像源列表里就能直接选到，或者手动填阿里云、清华 TUNA 等镜像地址。换完源之后执行：

sudo apt update sudo apt upgrade -y

如果内核有更新，建议重启一次，让系统运行在新内核上。这一步顺便把build-essential、curl、git等基础工具装好：

sudo apt install -y build-essential curl git cmake ninja-build

第二步装显卡驱动。如果你的电脑有 NVIDIA 独显，在 “Software & Updates” 的 “Additional Drivers” 选项卡里，选择一个 NVIDIA 的专有驱动版本，点 Apply Changes，装完重启。有读者会问，我不装专有驱动，用开源 nouveau 行不行？行，但 Gazebo 渲染时会明显卡顿，而且一些小模型的纹理加载不正常。这个阶段还是装上省心。

第三步配置中文输入法。Ubuntu 24.04 默认桌面环境是 GNOME，输入法框架默认是 IBus。在 “Settings → Keyboard → Input Sources” 里点 “+” 添加 “Chinese (Intelligent Pinyin)”。如果添加后无法正常弹出中文输入，可以在终端执行：

im-config -n ibus

然后注销重进一下。这样做是为了确保 GTK 应用和 Qt 应用（比如 QGroundControl 是 Qt 写的）都能正常调起输入法。

第四步装一些开发常用工具。比如vim、htop、net-tools、ssh、gnome-tweaks等，按需装就好。这一步不是必须的，但能让后面的开发过程顺手很多。

3. 第二步：PX4 固件源码获取与依赖环境搭建

3.1 前置依赖：Python 环境要单独处理

前面提到，Ubuntu 24.04 默认自带 Python 3.12，但没装pip。PX4 的构建过程会用到一些 Python 工具包，比如empy、toml、numpy、jinja2、kconfiglib，这些依赖必须准备好。

先安装 pip：

sudo apt install -y python3-pip python3-venv

接着处理 PEP 668 问题。我的建议是给 PX4 相关工具单独建一个虚拟环境，但这个方案在 PX4 自动安装脚本里不太好用，因为脚本会直接调用系统 Python 环境去装依赖。所以更现实的做法是加--break-system-packages让 pip 写入系统环境。虽然这种做法有争议，但在这个场景下最省事。执行：

pip3 install --break-system-packages empy==3.3.4 toml numpy jinja2 pyyaml kconfiglib

注意empy一定要指定 3.3.4 这个版本。PX4 的构建脚本对 empy 的接口有要求，新版本 4.x 去掉了旧接口，会导致编译报错ModuleNotFoundError: No module named 'em'。这个坑我用了 4.x 版本踩过，后来降回来才编译通过。

另外确认 CMake 版本是否满足 PX4 要求。Ubuntu 24.04 默认自带 cmake 3.28.3，PX4 官方要求最低 3.10.2，所以默认版本就够了。但需要单独确认 Ninja 是否安装，构建系统默认是 Ninja，比 Make 快很多。如果ninja --version提示找不到命令，执行sudo apt install -y ninja-build。

3.2 获取 PX4 源码

PX4 源码托管在 GitHub 上的PX4/PX4-Autopilot仓库。直接git clone的话速度可能不太稳定，可以先用--depth 1只拉最新版本，减少下载量：

cd ~ git clone --depth 1 https://github.com/PX4/PX4-Autopilot.git --branch v1.15.4

关于分支版本，我建议固定到某个 release 版本而不是用 main 分支。原因很简单：main 分支是持续开发的，今天能编译明天可能就不行，对入门阶段非常不利。v1.15.x 是当前较稳的版本线，等后续熟悉了再尝试 main 分支不迟。如果 clone 过程中因为网络问题失败，可以重试几次，或者用git clone时加--depth 1，单次拉取的数据量会小很多。

clone 完成后，把路径简化一下，做软链接或者直接改目录名都行。我喜欢统一命名为~/px4：

mv ~/PX4-Autopilot ~/px4 cd ~/px4

这一步不是必须的，但路径短一点，后面敲命令会省很多事，尤其是在脚本里引用时不容易写错。

3.3 运行自动安装脚本

PX4 官方提供了一套非常方便的环境安装脚本，路径在Tools/setup/ubuntu.sh。它会把编译固件和仿真所需的几乎所有东西装好，包括gcc-arm-none-eabi交叉编译工具链、Gazebo、ROS 相关依赖等。执行方式：

cd ~/px4 bash ./Tools/setup/ubuntu.sh

这个脚本会运行很长时间，取决于你的网速，可能需要 20 分钟到 1 小时不等。脚本中途会询问是否安装一些可选组件，比如 ROS 2，如果你暂时不需要 ROS，可以直接 N。以后需要时再单独装也行。脚本执行到最后会提示你重新登录系统，让用户组变更生效。

有几个注意点：第一，脚本执行过程会多次调用sudo，期间需要输入密码，人别走开太远，我这个脚本跑了一半因为没输密码卡了十分钟。第二，如果脚本在某个 apt 安装环节报错，先看是不是网络问题，把源换成国内镜像后大概率能过。第三，脚本会安装自己版本的 Gazebo，如果你之前手动装过别的版本，可能在依赖冲突上卡住，建议在执行脚本前先卸载干净原有的 Gazebo。

3.4 编译固件，验证工具链是否可用

依赖装完，接下来这一步是整个环境搭建的核心验证：编译 SITL 仿真固件。SITL 全称 Software In The Loop，也就是把 PX4 固件编译成一个可以在 Linux 上直接运行的本地进程，它不需要真实飞控硬件。执行：

cd ~/px4 make px4_sitl gazebo-classic

第一次编译会比较久，通常 10 到 30 分钟，取决于 CPU 性能。如果这个过程没有任何报错，最后出现类似[100%] Built target px4的输出，并且自动弹出 Gazebo 窗口，那就说明环境已经搭建成功了。Gazebo 窗口里会停着一架默认的无人机模型iris，终端里同时会运行 PX4 shell，你可以在这里输入命令。

如果你只用make px4_sitl而不带 gazebo 参数，则只编译固件不启动仿真器，适合只验证编译环境的情况。后续我更推荐用带机型的命令，比如make px4_sitl gazebo-classic_iris，指定具体机型启动仿真，避免默认机型加载了多余的传感器插件。

4. 第三步：Gazebo 仿真环境与地面站连接

4.1 启动仿真与常见机型选择

环境搭建成功之后，就是学习怎么用仿真环境。每次启动仿真，终端里都会输出一堆 MAVLink 相关的日志，其中最关键的一行是：

NuttShell (NSH) nsh>

这说明 PX4 SITL 已经跑起来了。PX4 内部有一个类似命令行的 NSH shell，可以执行顶层命令，比如查看系统状态、校准传感器、切换飞行模式等。由于 SITL 模式没有真实硬件，传感器数据默认是正常且已校准的，这让我们可以直接跳过真机必须的校准步骤。

在跑仿真的过程中，gazebo-classic和gazebo这两个关键词要分清。make px4_sitl gazebo-classic启动的是 Gazebo 11，对应经典仿真模型库；make px4_sitl gazebo启动的是新版 Gazebo（Ignition / Garden 系列）。不同版本对应的启动命令不一样，PX4 官方文档目前对gazebo-classic的教程更充分，新手期建议先用它。等后面想试室内视觉仿真、多机仿真时，再切到新版不迟。

仿真启动时默认加载的 iris 四旋翼模型非常适合入门。如果你想要快速起飞测试，可以在仿真里用commander takeoff指令起飞，也可以在地面站里手动解锁起飞。我个人更推荐直接在 QGroundControl 里操作，因为真机飞行时你大概率也是这么操作的，从仿真开始就习惯地面站的交互方式，后面上真机不至于手忙脚乱。

4.2 QGroundControl 连接仿真与基础飞行流程

QGroundControl（以下简称 QGC）是 PX4 最常用的地面站软件，负责显示飞行状态、实时地图、参数调整、任务规划等。在 Linux 上安装 QGC，最省事的方式是去官网下载 AppImage 文件：

chmod +x QGroundControl.AppImage ./QGroundControl.AppImage

QGC 启动后会自动检测本地 14550 端口的 MAVLink 连接。PX4 SITL 启动时默认会在 UDP 14550 端口发送 MAVLink 数据，所以只要 QGC 开着，它就会自动连接到仿真环境，无需额外设置。连接成功后，QGC 地图上会看到虚拟无人机的位置，姿态仪表、高度、空速等也会实时刷新。

接下来讲一套最基础的飞行操作流程。第一步，在 QGC 右上角找到 “Q” 图标进入应用设置，在 “General” 里确认 “Mavlink” 和 “Units” 是你熟悉的显示方式。第二步，回到主界面，在左侧工具条中点击 “Arm” 解锁电机。SITL 模式下不需要像真机那样检查 GPS 星数；但如果 QGC 提示 “Vehicle is not ready to arm”，还可以去 “Safety” 页面检查一下是否是遥控器信号或地理围栏的设置问题。第三步，提升油门到 50% 以上，让无人机起飞。第四步，切换到 “Position” 模式，让飞控自己稳定悬停。第五步，用鼠标在地图上规划一个稍远的点，点击 “Fly” 按钮，观察无人机自主飞过去。

这些流程每一步背后都对应真实的 PX4 状态机和飞行模式切换逻辑，在仿真里练熟了，后面接触真机时很多概念都是通的。我在学习阶段就是这样反复起飞、降落、切模式，慢慢理解了 MC（多旋翼）控制模式里Manual、Altitude、Position、Mission的区别。

4.3 仿真日常使用的一些心得

用了一段时间仿真之后，有几个小体会值得分享。

第一，仿真的模型并没有风、地面效应等真实物理因素，飞起来会比真机“乖巧”很多，所以在仿真里练出来的手感需要用真机重新适应。但从学习飞控设计、代码逻辑的角度看，仿真已经足够。

第二，每次重新启动仿真，PX4 的参数都会恢复默认。这对测试来说其实是好事，不会因为上一次乱改参数导致这次起飞异常。但如果你确实想保存一组参数，可以在 QGC 里点击 “Parameters → Save to file”，把当前参数保存下来，下次启动后再加载。

第三，如果仿真过程中 Gazebo 模型加载很慢，或者部分模型显示成黑色，常见原因是显卡驱动没装好或 Gazebo 资源文件缓存损坏。可以清理一下~/.gazebo目录下的模型缓存再试。

第四，终端运行make px4_sitl gazebo-classic时不要按Ctrl+C强行退出，尽量在 QGC 里先降落、解锁、退出仿真，再关终端。遇到 Gazebo 卡死的情况除外，直接kill进程也是一种策略，但容易残留端口占用导致下次启动失败，此时可执行：

pkill -f px4 pkill -f gazebo

清理掉残留进程再重新启动。

5. 踩坑实录：安装与编译过程中的常见问题

5.1 网络下载慢和依赖安装失败

这个问题出现的频率最高，而且会以各种形态出现，比如git clone卡住、apt install超时、下载 Gazebo 模型失败等。先说 git clone 的问题。GitHub 直连速度在不同网络环境下差异很大，最常见的解决思路有两个：一是换成国内镜像仓库，一般别人已经同步了 PX4 仓库；二是把 git 的 http 缓冲区调大，减少超时概率。注意这里只建议用公开的开源镜像，不要折腾任何不安全的第三方渠道。

然后是 apt 源问题。Ubuntu 24.04 的软件源配置文件已经是新的/etc/apt/sources.list.d/ubuntu.sources格式，如果你在网上找到的老教程让你直接改/etc/apt/sources.list，在 24.04 上是不生效的。正确做法是编辑ubuntu.sources文件，把URIs那一行换成镜像地址，然后执行sudo apt update。

Gazebo 模型库下载则是另一个隐形坑。第一次启动 Gazebo 仿真时，软件会从模型库在线下载部分模型文件，下载速度慢的话仿真窗口会长时间只有一个空场景。解决方式是把常用的模型文件先手动放到~/.gazebo/models目录下。网上有现成的模型库压缩包可下载，解压后放进目录即可，这样 Gazebo 启动时就不再等待网络下载。

5.2 Python 版本和 pip 权限问题

Ubuntu 24.04 的 Python 是 3.12，很多人按着 Ubuntu 20.04 时代的教程执行pip install empy，会直接遇到：

error: externally-managed-environment

这就是前面提到的 PEP 668 机制。处理方法很简单，按提示加--break-system-packages参数，或者干脆创建虚拟环境。但注意，如果创建虚拟环境，后续make px4_sitl时系统可能找不到虚拟环境里的 Python 包，因为 PX4 的构建工具默认调用/usr/bin/python3。所以在这个阶段，直接--break-system-packages更省心。

另一个相关报错是编译时提示缺少numpy或者jinja2，但你已经用 pip 装过了。这种情况通常是 pip 装了但系统 CMake 调用的是另一个 Python 环境。可以在终端先执行：

python3 -c "import numpy; print(numpy.__version__)"

确认包能正常导入。如果导入失败，就说明你用的 python3 与 pip3 指向的不是同一个解释器，需要重新安装 pip 或者在 PATH 里指定。

5.3 编译过程卡死、内存不足怎么办

编译 PX4 SITL 固件本身不需要特别高的配置，8GB 内存以上基本够用，但一个容易忽略的问题是并行编译任务数。make和ninja默认并行度会参考 CPU 核心数，如果你的机器核心很多但内存较小，比如 16 核 + 8GB 内存，并行编译时内存很容易被打满，轻则编译变慢，重则直接 OOM 被杀。

解决方式是指定并行度。使用make时可以通过-j参数控制：

make px4_sitl gazebo-classic -j4

表示同时最多 4 个编译任务，内存压力会小很多。如果是 ninja 构建，可以在 CMake 配置阶段指定：

cmake -B build/px4_sitl_default -DNINJA_STATUS="[%p/%f]"

不过对新手来说，直接加-j4是最简单的控制方式。另外如果你的内存确实很小，建议开一个 swap 文件。Ubuntu 24.04 默认只在内存不足时按需创建 swapfile，大小不一定够用，可以手动扩展：

sudo fallocate -l 8G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile

这个操作虽然提升不了编译速度，但能避免编译到一半被系统强制杀掉。

5.4 高频问题排查速查表

我把这段时间遇到的典型问题整理成了一张表，方便你逐项对照排查。

这张表基于我自己从 22.04 迁移到 24.04 期间遇到的实际问题整理。环境问题就是这样，每个人机器情况不同，遇到的问题可能千奇百怪，但排查思路基本一致：先看日志，再确认网络，再查版本，最后考虑缓存。

6. 实操总结：我建议的最终路径与下一步规划

从零开始搭一套可用的 PX4 开发环境，我推荐你按这个顺序走：先在 Windows 上用 Rufus 做 Ubuntu 24.04 启动盘，安装双系统，装完确认显卡驱动和软件源没问题，然后安装基础开发工具，再 clone PX4 源码、运行官方依赖脚本，最后用make px4_sitl gazebo-classic验证编译与仿真。整个过程听起来不复杂，但因为我踩过版本不对、依赖冲突、Python 权限等各种坑，所以每一步都写得很啰嗦。如果你能顺着这个顺序一次成功，那确实可以省不少时间。

在环境准备好之后，建议你强迫自己完成三个小练习：用 QGC 连接仿真并手动起飞降落一次；在 QGC 里改一个参数（比如最大倾斜角）并观察仿真中效果；用commander指令在 NSH 里完成一次自主起飞。这三个练习做完，你基本就掌握了 PX4 开发环境的使用逻辑，也为后续学习 PX4 的代码结构、模块设计和传感器融合打下了基础。

这个系列后续我会继续写 PX4 源码结构导读、第一个自定义模块编写、Gazebo 多机仿真、以及如何把真实飞控接到电脑上做 HITL 硬件在环仿真。环境搭好只是万里长征第一步，后面真正有趣的部分在于理解飞控系统是如何在姿态控制、位置控制、任务规划之间层层协作的。如果这篇文章帮你顺利跑起来了，或者你在搭建过程中遇到了别的坑，欢迎在评论区留言，我会根据实际反馈继续调整后续教程的侧重点。

最后分享一个自己的感受：环境搭建是最无聊但也是最关键的一步，很多人都在这一步放弃了。耐心点，一行一行看日志，遇到问题就搜索关键报错信息。等看到那架虚拟飞机在 Gazebo 里成功起飞的时候，前面所有的折腾都会觉得值得。