1. 环境规划与配置思路
1.1 先搞明白这套环境到底能干嘛
搞无人机开发的人，尤其是第一次碰PX4的，往往不是被算法难倒，而是被环境折腾得没脾气。今天要讲的这套组合——Ubuntu 18.04 + QGC + Qt Creator，是一个既能干活又能教学的经典搭建方案。装好之后，你可以在电脑上编译PX4固件，用软件在环仿真跑起一个“虚拟无人机”，然后用QGC地面站看它的姿态、位置、日志，最后再用Qt Creator来翻代码、改代码、下断点。换句话说，这套环境就是一套完整的“PX4桌面模拟开发舱”，不需要买任何硬件就能把飞控的核心逻辑跑起来。
这套环境适合谁？如果你是想入门PX4二次开发的新手，或者正在评估PX4的算法工程师，又或者只是想把调参、显示、代码编辑这三件事拧到一个工作台里的老手，都可以参考这套方案。我经常跟朋友说，PX4学习曲线陡，很大一部分原因是“前置条件”太多：编译器、Python包、仿真器、地面站、IDE，哪个没对上都会卡你一下。这篇博客就是把我从头到尾搭环境的完整路径记录下来，包括我踩过的坑和最后的解决手段，希望能让你少绕几圈。
1.2 版本选型：为什么是Ubuntu 18.04、QGC、Qt Creator
很多人会问：“现在都Ubuntu 22.04了，为什么还要用18.04？” 我的回答很实际：如果你是冲着PX4的稳定开发体验去的，18.04至今依然是兼容性最好的版本之一。PX4从v1.10到v1.13，官方CI长期在18.04上跑，Gazebo 9、jMAVSim、ROS Melodic都和18.04搭配得最顺。如果你做ROS无人机开发，Melodic版本更是只官方支持18.04。虽然20.04甚至22.04也能装，但你在网上搜到的大部分PX4教程、别人分享的依赖清单、出错帖子，还是围绕18.04写的。用18.04可以帮你在“配置环境”这件事上少踩很多坑。
QGC是PX4最常用的地面站，支持Windows/macOS/Linux，但我推荐直接在Ubuntu里跑AppImage版本——它和PX4配合最紧密，不需要额外配置端口就能自动发现SITL仿真的数据流。Qt Creator则是代码工具，PX4源码本身就是一套大型CMake工程，Qt Creator对CMake的支持相当成熟，代码跳转、变量重命名、符号搜索都很顺手。它不像VS Code那样需要装一堆插件，开箱就能干活，是“懒人 + 专业”折中的好选择。
1.3 准备工作与系统清单
在开始之前，先确认你的电脑至少满足这些条件：内存8GB以上（16GB更稳），硬盘剩余空间40GB左右，CPU建议i5或同级以上。如果你用的是虚拟机，建议分配4核CPU、8GB内存，并开启3D加速，否则后面跑Gazebo会明显吃力。网络环境也要稳定，因为整个搭建过程要下载源代码、依赖包、仿真器，动辄几个GB。
这里先给你一个整体步骤预览，后面每个部分再细说：
- 安装Ubuntu 18.04系统级依赖和Python环境；
- 克隆PX4源码，编译SITL仿真目标；
- 下载QGC地面站，连接仿真；
- 安装Qt Creator，导入PX4作为CMake工程；
- 排错与踩坑记录。
这一套下来，快的半天，慢的最多两天也能搞定。如果哪一步卡住了，别急着重装系统，先看报错信息，90%的问题都能通过安装缺失依赖或换软件源解决。
2. 搭建PX4编译环境：从依赖到固件编译
2.1 安装基础依赖，我建议手动装而不是一把梭
PX4官方给了一个自动化脚本Tools/setup/ubuntu.sh，理论上运行完它环境就齐了。但我个人不建议新手上来就跑这个脚本，原因有三：第一，脚本会安装大量相关包，包括很多你当前用不到的，装错了也不好定位；第二，脚本中间如果网络超时，它可能中断，残留一堆半成品状态反而更难收拾；第三，手动装能让你清楚知道每个依赖是干什么的，后面出问题好判断。
我针对Ubuntu 18.04整理了一份精简但够用的依赖清单。先跑一遍系统更新：
sudo apt update && sudo apt upgrade -y然后安装构建PX4固件所需的基础工具链：
sudo apt install -y \ git \ zip \ cmake \ build-essential \ ninja-build \ genromfs \ exiftool \ astyle \ bc \ curl \ gcc \ g++ \ gdb \ make \ ncurses-dev \ libxml2-dev \ libssl-dev \ libudev-dev \ libgstreamer1.0-dev \ libgstreamer-plugins-base1.0-dev \ protobuf-compiler \ python3 \ python3-pip \ python3-jinja2 \ python3-numpy \ python3-empy \ python3-pyparsing \ python3-setuptools \ python3-catkin-pkg \ python3-defusedxml \ python3-packaging \ python3-netifaces \ python3-toml \ qml-module-qtquick-controls2Python工具链还需要一些编译期脚本依赖，CMake的模块生成时会调用。最好用pip补装用户级包：
pip3 install --user \ empy \ pyros-genmsg \ setuptools \ pyparsing \ catkin_pkg \ defusedxml \ packaging \ numpy \ jinja2 \ kconfiglib \ jsonschema \ future \ pkgconfig注意：如果你之前装过ROS，不要重复安装上面的包。ROS自带很多依赖，重复安装可能造成版本覆盖，出现“找不到模块”之类的诡异错误。遇到这类情况，先
which python3看当前默认Python路径，再确认pip安装目录是否在PYTHONPATH里。
2.2 获取PX4源码的完整姿势
源码存放路径我建议放~/src，避免和系统目录混在一起。执行：
mkdir -p ~/src cd ~/src git clone --recursive https://github.com/PX4/PX4-Autopilot.git这个--recursive参数非常重要。PX4不是单一仓库，它带了一堆子模块，比如src/lib/DriverFramework、mavlink等，漏掉任何一个都会导致编译到一半报“文件找不到”。如果不小心不带参数克隆了，也不要慌，在仓库根目录补一下：
git submodule update --init --recursive克隆完成后，强烈建议切到某个稳定版本，而不是直接用main分支。main分支每天都有大量提交，编译依赖和要求会随时变化，在18.04上很容易遇到“官方已经放弃对老系统支持”的编译错误。我一般用v1.13系列：
cd PX4-Autopilot git checkout v1.13.2 git submodule update --init --recursive拿到代码后，先看一眼顶层目录下的CMakeLists.txt和Tools/setup文件夹，这样你能对PX4的构建机制有个大概认识。PX4使用CMake + Ninja/Make生成构建系统，硬件目标由make命令后面的“目标名”决定。例如px4_fmu-v5是Pixhawk 4的固件目标，px4_sitl是软件在环仿真目标。
2.3 首次编译，从make px4_sitl jmavsim说起
环境就绪后，第一步不是急着编译硬件固件，而是先跑软件在环仿真。原因是SITL目标不需要连接硬件，出问题好排查，还能立刻看到无人机在仿真器里动起来，正反馈来得快。
在PX4源码根目录执行：
make px4_sitl jmavsim这条命令会做两件事：先编译PX4固件SITL版本，再启动jMAVSim仿真器。首次编译时间比较长，快则十几分钟，慢则半个多小时，取决于机器性能和网络。如果只想编译固件，不启动仿真器，可以执行：
make px4_sitl_default编译产物会输出在build/px4_sitl_default目录下，里面有个bin/px4可执行文件，这就是SITL版飞控程序。后续如果你要手动启动仿真，可以先运行make px4_sitl，再单独打开终端运行./Tools/simulation/jmavsim/jmavsim_run.sh或其他仿真器脚本。
如果编译过程中报错，先别乱改成“下面这个包装了重启就没了”，要重点看提示缺失的是头文件还是Python模块。头文件缺失就补对应的-dev包，Python模块缺失就pip3 install。我遇到最多的两个坑，一是No module named em，这是缺少empy；二是ninja: error: loading 'build.ninja'，这是CMake生成阶段出错，通常是某个依赖没装全。
编译成功后会弹出jMAVSim黑色窗口，上面有一架小无人机模型，终端里会滚动显示pxh>命令行提示符。在这个提示符下可以输入commander takeoff等指令控制飞机，虽然QGC也能做到，但这个命令行是排障利器。
3. QGC地面站安装与SITL仿真联调
3.1 安装QGC地面站并处理权限
QGC（QGroundControl）是PX4生态里的“驾驶舱”，可以显示飞行状态、传感器数据、地图、飞行日志，还能上传参数和固件。在Ubuntu 18.04上，官方提供AppImage格式，好处是不需要安装一堆运行库，下载就能跑，缺点是对fuse依赖比较挑。
先去QGC官网下载最新的稳定版AppImage，比如QGroundControl.AppImage，放到你的目录，比如~/bin。然后：
chmod +x QGroundControl.AppImage sudo usermod -a -G dialout $USER把当前用户加入dialout组这步非常重要，虽然纯仿真不涉及串口，但后面真机调试时，没有这步权限就无法打开/dev/ttyACM0。执行完需要注销并重新登录，或者重启系统，组权限才会生效。
如果在Ubuntu 18.04上双击AppImage没反应，多半是fuse的问题。安装fuse就可以：
sudo apt install -y libfuse2还不行的话，试试这种提取方式运行：
./QGroundControl.AppImage --appimage-extract-and-run3.2 启动SITL仿真并和QGC连接
QGC安装好之后，先不要开。我们先启动PX4仿真，再开QGC，这样QGC能自动发现仿真设备。
新开一个终端，进入PX4源码目录：
make px4_sitl jmavsim等待仿真窗口出现、终端出现pxh>提示符后，再新开一个终端启动QGC：
cd ~/bin ./QGroundControl.AppImage正常情况下，几秒内QGC左上角会显示“连接中”或者直接显示一个UDP连接，地图上出现一架无人机，左上角姿态仪表开始跳动。如果没自动发现，手动添加连接：点右上角的“齿轮”图标 -> Comm Links -> Add -> Type选UDP -> Listening Port填14550 -> 确定并连接。PX4 SITL默认就是向UDP 14550广播MAVLink数据，改端口反而连不上。
连上后你可以把右上角的飞行模式改成“Offboard”试试？先别急，SITL仿真下最好先在QGC里设置“Takeoff”或用手柄控制。没有手柄的话，可以在终端pxh>输入：
commander takeoff然后切到QGC的地图页面，飞机会离地，高度大概2.5米左右，姿态仪上能看到真实的倾角变化。
3.3 用Gazebo或jMAVSim，选哪个
仿真器我前面一直用jMAVSim，但PX4还支持Gazebo。二者区别在于：jMAVSim轻量、启动快，适合快速验证飞控逻辑和命令行操作；Gazebo重量级，有基于物理引擎的真实摩擦、风、多传感器模型，适合做视觉SLAM、激光雷达、室外环境测试。Ubuntu 18.04下Gazebo安装比较重，官方推荐版本是Gazebo 9，通过PX4脚本可以自动装，但手动的话需要：
sudo apt install -y gazebo9 libgazebo9-dev启动Gazebo版本：
make px4_sitl gazebo第一次启动Gazebo会下载大量模型文件，是正常现象，慢慢等就行。如果虚拟机跑Gazebo特别卡，优先加内存和显存，或者改用jMAVSim。我的原则是：如果你只是学习PX4任务逻辑，jMAVSim足够；如果你想做传感器融合或避障实验，还得上Gazebo。
4. 用Qt Creator把PX4当常规项目来开发
4.1 安装Qt Creator并导入PX4源码
写代码和读代码这件事，光靠Vim是真的熬人。Qt Creator作为PX4社区用的比较多的IDE之一，最大的好处是原生CMake支持，打开一个CMakeLists.txt就能把整个工程吃进去。Ubuntu 18.04可以直接从软件源安装：
sudo apt install -y qtcreator系统源里的Qt Creator版本是4.9左右，对PX4的CMake工程识别已经够用。如果你需要更新版本，也可以去Qt官网下载社区版在线安装器，只为Qt Creator的话安装体积会小很多，但需要注册Qt账号，看个人接受度。
安装完成后打开Qt Creator，选择“文件 -> 打开文件或项目”，定位到~/src/PX4-Autopilot/CMakeLists.txt。第一次导入，向导会要求选择一个Kit（工具链），选中Desktop下默认的GCC x86_64即可。构建目录我习惯设为源码目录外的build-qtcreator，避免和PX4自带的build/混在一起，造成旧构建产物干扰。
点击“配置项目”后，Qt Creator会对整个源码做索引，这个过程会消耗一些CPU和内存，耐心等它跑完。索引完成后，你就能用Ctrl+鼠标点击跳转函数定义、查看所有符号引用、批量重命名等，读PX4源码的体验接近商业IDE。
4.2 自定义构建步骤，避开一键编译的坑
这里必须提醒你：Qt Creator默认的“构建”按钮往往不能直接一键编译PX4。原因在于PX4的构建系统对CMake参数和目标名有特殊要求，比如固件目标px4_sitl_default是通过PX4自带脚本来配置的，Qt Creator的默认CMake参数不一定能正确生成。
我的做法是绕开默认构建，给它配置一个自定义构建步骤。在项目页面左侧选中“Build”，找到“Build Steps”，把原来的构建步骤删掉，添加一个“Custom Process Step”。命令填：
make参数填：
px4_sitl_default工作目录填：
%{sourceDir}这样点击左下角的锤子图标时，Qt Creator就会执行make px4_sitl_default，和你在终端敲命令效果一致。启动仿真的话，可以再配置一个“Run”步骤，命令填make，参数填px4_sitl jmavsim，这样F5就能直接跑仿真，非常顺手。
需要说明的是，PX4的CMake配置复杂，有时候Qt Creator的“问题”面板显示一堆红色错误，但那些错误可能只是CMake缓存导致的。遇到这种情况不要慌，在菜单栏选择“构建 -> 重新构建项目”，或者直接删除构建目录后重新配置。
4.3 日常编辑、跳转与排错技巧
说几个在Qt Creator里实际用起来很顺手的技巧。
第一，调出“定位器”用快捷键Ctrl+K，可以直接打开文件、搜索符号，比在左侧文件树一层层点快得多。PX4源码很大，学会用定位器找文件是节省时间的第一步。
第二，配置代码风格。PX4官方代码风格比较统一，在Qt Creator里可以设置“工具 -> 选项 -> C++ -> Code Style”，引入.astylerc或.clang-format文件，不过18.04自带的旧版Qt Creator可能不支持clang-format，问题不大，手动对齐也能接受。
第三，在调试仿真进程时，Qt Creator的调试器经常“跟不上”。因为PX4系统是多线程实时控制，直接给px4进程上GDB断点，断点命中后整个仿真会瞬间卡死，反而不如看日志直观。所以日常开发我推荐在关键代码段加PX4_INFO打印，通过日志观察流程，只在确实需要查线程死锁等疑难问题时才上调试器。
5. 我踩过的坑：常见问题排查实录
5.1 依赖安装与编译报错
这一节是我最想输送给你的部分，因为环境搭建的每一条报错我都碰过至少一次。
报错ModuleNotFoundError: No module named 'em'：这基本是empy没装好。18.04系统Python有2和3两个版本，你需要注意默认的python3和pip3对应关系。执行pip3 install --user empy后，要确认~/.local/lib/python3.6/site-packages里能搜到em这个包。
报错Can't find cmake：检查cmake版本，PX4需要CMake 3.10以上，18.04自带的3.10.2满足要求。如果是通过其他方式装了新版本导致PATH混乱，可以用cmake --version确认。不要用snap版的cmake，它经常被沙盒限制访问build目录。
报错ninja: error: loading 'build.ninja': No such file or directory：这个问题出现在CMake生成阶段失败之后。多半是缺少某个Python模块或系统库，重新执行一次make px4_sitl_default看清楚前面的报错，而不是盯着ninja最后那句看。
报错cc1plus: fatal error: Killed signal terminated program cc1plus：这是内存不足，编译PX4时内存峰值很夸张，尤其是Gazebo模型和MAVLink代码生成阶段。解决办法是关掉浏览器等大内存应用，或者增大swap空间。虚拟机用户尤其注意，最少给到8G内存。
5.2 QGC启动不了或连不上仿真
QGC启动时如果提示缺少库，优先安装AppImage要求的基础包：
sudo apt install -y libgl1-mesa-glx libglu1-mesa libxv1 libxcb-xinerama0如果打开后一片黑或闪退，试着降低图形特效，或者用QT_QUICK_BACKEND=software ./QGroundControl.AppImage强制软件渲染，虽然卡一点但至少能跑。
连不上仿真的情况，首先要确认PX4仿真进程是否活着，终端里能不能看到pxh>提示符。接着在QGC的Comm Links里手动添加UDP连接，端口必须和PX4 SITL默认一致（14550）。有的版本QGC会自动尝试连接多个端口，如果之前有残留连接，先全部断开重连一次。
另外，如果你在虚拟机的Ubuntu里跑QGC，虚拟机网络如果用的是NAT模式，UDP广播可能无法正常桥接。建议改成桥接模式，或者就老老实实把QGC跑在宿主机上，PX4仿真留在虚拟机里，然后通过宿主机和虚拟机之间的IP直连。
5.3 虚拟机和双系统用户的额外提醒
如果你跟我一样，最初是拿虚拟机来装的，我给你几个实在建议。
虚拟机的“3D加速”一定要开，否则Qt Creator和QGC都会很卡，Gazebo基本跑不动。VMware里在虚拟机设置 -> 显示器 -> 勾选“加速3D图形”；VirtualBox则在设置 -> 显示 -> 显存拉到128MB并启用3D加速。
USB设备透传也是个老问题。如果后面你想连Pixhawk真机，VirtualBox对USB device的透传经常抽风，VMware会稳定一些。不过用SITL仿真阶段不涉及USB，可以暂时不管。
双系统用户倒是没有性能问题，但要小心磁盘分区格式。PX4源码放在NTFS分区里会导致权限错乱、符号链接失败，编译会莫名其妙报错。一定把源码放在ext4分区，也就是你的Ubuntu主目录底下，别图省事放到Windows的盘符上。
5.4 干净卸载重来：环境复原步骤
很多问题你费了半天劲去修，往往不如彻底重来。如果你已经乱装了一大堆依赖、改坏了系统Python，而又不想重装Ubuntu，最干脆的做法是移除PX4源码和相关构建目录，再重新走一遍：
rm -rf ~/src/PX4-Autopilot rm -rf ~/.local/lib/python3.6/site-packages/* # 谨慎，这会清空当前用户的pip包也可以直接删除用户级pip目录里的PX4相关包，保留其他包。然后从2.1节重新开始。如果系统Python环境已经坏了，不要在家里瞎折腾，在虚拟机上重新安装Ubuntu 18.04也就是20分钟的事，比排查环境冲突快得多。
最后再分享一个小习惯：每次搭建完一套成功的环境，我会立刻用虚拟机快照或者tar备份一下源码目录和QGC配置。比如VMware的快照功能，装好一套干净环境打个快照，之后写飞控代码写崩了，直接回滚，几秒钟就恢复。这个习惯帮我省下的时间，至少值回所有折腾环境的时间。
