刚入坑无人机飞控的朋友基本都会听到“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 Gazebo1.1 这套环境到底解决了什么问题做飞控开发有个现实问题固件不能直接在真机上反复测试因为炸机成本太高、调试效率太低。所以行业通行做法是先在 PC 上做“软件在环仿真”也就是把 PX4 固件编译成电脑上能跑的进程再和 Gazebo 这个机器人仿真器连接模拟出无人机在虚拟世界里的飞行状态。整个环境涉及的东西很多操作系统、编译工具链、Python、ROS可选、Gazebo、PX4 固件源码、QGroundControl 地面站。任何一个环节出问题都会导致“明明照着教程做却跑不起来”。这一整套环境的价值就在于它让你在花钱买飞控和机架之前先用纯软件的方式学会 PX4 的基本操作、参数配置、飞行模式切换、日志分析。等你在仿真里把基本逻辑搞明白了再去碰真实硬件会从容很多。我见过太多人一上来就买 F405 飞控、电调、机架结果固件都刷不进去更别说调参了最后整套设备吃灰。严格来说如果你连 PX4 固件都没编译过、没在仿真里起飞过一次真的不建议急着买硬件。1.2 版本选型Ubuntu 24.04 能跑 PX4 吗先说结论能跑但要做一些针对性适配。PX4 官方文档对 Ubuntu 的支持早已覆盖最新 LTSv1.15 和 main 分支都能在 24.04 上正常编译。不过要注意一个关键点Ubuntu 24.04 默认的 GCC 是 13.xCMake 是 3.28Python 是 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 自带的新版 GazeboGarden/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 校验值官网每个镜像旁边都有对应校验值这步虽然多花一分钟但能避免拿到损坏或者被篡改的镜像。下载慢的话可以选离你比较近的国内镜像源这个一般大家都有自己习惯用的我就不展开说名字了。启动盘制作我推荐用 RufusWindows 下或者 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这些依赖必须准备好。先安装 pipsudo apt install -y python3-pip python3-venv接着处理 PEP 668 问题。我的建议是给 PX4 相关工具单独建一个虚拟环境但这个方案在 PX4 自动安装脚本里不太好用因为脚本会直接调用系统 Python 环境去装依赖。所以更现实的做法是加--break-system-packages让 pip 写入系统环境。虽然这种做法有争议但在这个场景下最省事。执行pip3 install --break-system-packages empy3.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.3PX4 官方要求最低 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 完成后把路径简化一下做软链接或者直接改目录名都行。我喜欢统一命名为~/px4mv ~/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启动的是新版 GazeboIgnition / Garden 系列。不同版本对应的启动命令不一样PX4 官方文档目前对gazebo-classic的教程更充分新手期建议先用它。等后面想试室内视觉仿真、多机仿真时再切到新版不迟。仿真启动时默认加载的 iris 四旋翼模型非常适合入门。如果你想要快速起飞测试可以在仿真里用commander takeoff指令起飞也可以在地面站里手动解锁起飞。我个人更推荐直接在 QGroundControl 里操作因为真机飞行时你大概率也是这么操作的从仿真开始就习惯地面站的交互方式后面上真机不至于手忙脚乱。4.2 QGroundControl 连接仿真与基础飞行流程QGroundControl以下简称 QGC是 PX4 最常用的地面站软件负责显示飞行状态、实时地图、参数调整、任务规划等。在 Linux 上安装 QGC最省事的方式是去官网下载 AppImage 文件chmod x QGroundControl.AppImage ./QGroundControl.AppImageQGC 启动后会自动检测本地 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时不要按CtrlC强行退出尽量在 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 高频问题排查速查表我把这段时间遇到的典型问题整理成了一张表方便你逐项对照排查。现象可能原因排查与解决git clone卡住或报错网络问题换国内镜像源或重新 clone 并指定--depth 1python3 -m pip不存在未安装 pipsudo apt install -y python3-pippip 安装报 externally-managedPEP 668 限制加--break-system-packages参数编译报错No module named emempy 版本不对pip3 install --break-system-packages empy3.3.4Gazebo 启动后白屏显卡驱动或模型库问题检查 NVIDIA 驱动、清理~/.gazebo缓存仿真启动后 QGC 未连接端口或进程残留确认 UDP 14550、pkill -f px4后重启编译过程中内存被杀并行任务过多或内存不足减小-j并行度或增加 swapapt update 报仓库错误24.04 源配置格式不同修改/etc/apt/sources.list.d/ubuntu.sources这张表基于我自己从 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 里成功起飞的时候前面所有的折腾都会觉得值得。