ArduPilot 4.7：一套代码控制飞机、潜艇与平衡车的开源自驾仪
ArduPlane、ArduCopter、ArduRover、ArduSub 源。我们的自动驾驶仪软件能够控制几乎所有可以想象到的车辆系统，从传统飞机、四轴飞机、多旋翼和直升机到漫游车、船只、平衡机器人，甚至潜艇。
秒懂
- 它是什么？
- ArduPilot 是一个从 2010 年持续开发的开源自驾仪项目，覆盖多旋翼、固定翼、车辆、船只和潜艇。本文基于仓库文档分析其架构、五种飞行器变体、GPL-3.0 许可的影响，以及它为何不适合只想做简单飞控的用户。
- 适合谁用？
- ArduPilot 适合需要跨多种载具统一飞控代码的团队，特别是已有嵌入式开发经验、愿意阅读 wiki 和参与论坛讨论的工程师。它不适合只想快速起飞、不愿处理参数调优的业余用户，也不适合需要闭源商业授权的产品，因为 GPL-3.0 要求衍生作品开源。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个仓库，五种载具
ArduPilot 不是一个单一飞控，而是一套共享核心库的五个独立程序。仓库根目录下分列 ArduCopter、ArduPlane、Rover、ArduSub 和 AntennaTracker，各自对应多旋翼、固定翼、地面车辆、潜艇和天线跟踪器。这种结构意味着你可以在同一个代码库中维护不同载具的逻辑，而公共部分如导航滤波器、电池管理和 GPS 驱动被复用。对需要同时开发无人机和无人船的团队来说，这省去了维护两套代码的麻烦。但代价是代码量庞大，初学者很难快速定位问题。
从 2010 年积累的架构
项目自 2010 年持续开发，维护者列表中有 Andrew Tridgell（负责 Plane 和 AntennaTracker）、Randy Mackay（负责 Copter、Rover）等长期贡献者。从仓库布局看，每个载具目录包含独立的控制逻辑，而共享子系统（如 AP_NavEKF2 和 AP_NavEKF3 导航滤波器）以模块形式存在。这种分层设计让新载具可以复用已有的传感器融合和姿态控制代码。文档强调它支持从传统飞机到平衡车再到潜艇的广泛载具，这得益于其参数化配置系统。不过，这种灵活性也意味着默认参数往往不适合特定载具，用户必须根据 wiki 调整。
运行方式：编译、仿真与部署
根据 README 和仓库中的 CI 配置，ArduPilot 支持多种构建目标。开发者可以运行 SITL（软件在环）仿真，仓库中有 test_sitl_copter.yml、test_sitl_plane.yml 等 GitHub Actions 工作流，用于在无硬件情况下测试飞控逻辑。实际部署通常需要编译固件到 Pixhawk 等硬件板，维护者列表提到了 Pixhawk、Cube 系列和 BeagleBone Blue 等。具体编译命令在开发 wiki（ardupilot.org/dev）中有详细说明，但 README 本身未给出完整步骤。这意味着新用户必须依赖外部文档，上手门槛较高。
GPL-3.0 许可的硬约束
ArduPilot 采用 GPL-3.0 许可，这在开源硬件项目中常见，但对商业产品有直接影响。如果你的产品基于 ArduPilot 代码，你必须以相同许可开源你的衍生代码。README 提供了许可证概述和完整文本的链接，但没有豁免条款。对于想要闭源固件的公司，这是一个决定性限制。相比之下，BSD 或 MIT 许可的项目允许闭源使用，但 ArduPilot 没有这种选项。在评估时，法律团队应明确这一点。
测试与质量保障的可见证据
仓库的 CI 配置显示了多种测试工作流：除了 SITL 测试，还有 ChibiOS 构建测试、Linux SBC 测试、单元测试和覆盖率测试。这些工作流在每次推送时自动运行，覆盖了不同硬件平台和载具类型。Coverity 扫描和 bestpractices.dev 徽章表明项目有持续的质量检查。这些不是营销宣传，而是仓库中实际存在的配置文件。对于工程师来说，这比任何用户数量声明都更有说服力。
局限：学习曲线与支持范围
ArduPilot 的广度是双刃剑。文档明确列出多种载具，但没有提供开箱即用的体验。用户需要理解 PID 调参、传感器校准和飞行模式，这些都需要阅读 wiki。此外，虽然支持潜艇（ArduSub），但相关硬件和社区规模可能比多旋翼小。另一个潜在问题是代码库庞大，编译时间可能很长，对快速迭代不利。如果你只需要一个简单的四旋翼飞控，ArduPilot 可能是过度设计，更轻量的替代品如 Betaflight 或 iNav 可能更合适，尽管它们不支持潜艇或固定翼。
替代方案：与 PX4 的对比
与 ArduPilot 最常被比较的是 PX4。两者都是开源自驾仪，但架构不同。PX4 使用 NuttX 实时操作系统，而 ArduPilot 在多种 RTOS 上运行，包括 ChibiOS（从 CI 中的 test_chibios.yml 可见）。PX4 更强调模块化微服务架构，而 ArduPilot 采用更传统的整体式设计，但通过共享库实现复用。PX4 的许可为 BSD-3-Clause，比 GPL-3.0 更宽松，允许闭源商业使用。如果你的团队需要闭源，PX4 是更可行的选择。但 ArduPilot 的载具范围更广，特别是对潜艇和天线的支持是 PX4 所没有的。
维护成本与社区依赖
ArduPilot 的长期维护依赖活跃的贡献者社区。README 列出了维护者及其负责的子系统，例如 Paul Riseborough 负责 AP_NavEKF2/3，这显示了专业分工。但这也意味着，如果某个维护者离开，对应子系统可能缺乏维护。升级成本方面，每次版本更新（如从 4.6 到 4.7）可能引入参数变化或行为调整，用户需要关注发布说明。GPL-3.0 许可还要求你在分发固件时提供源代码访问，这增加了发布流程的复杂性。综合来看，采用 ArduPilot 意味着接受持续的学习和适配成本。
编辑结论
ArduPilot 适合需要跨多种载具统一飞控代码的团队，特别是已有嵌入式开发经验、愿意阅读 wiki 和参与论坛讨论的工程师。它不适合只想快速起飞、不愿处理参数调优的业余用户，也不适合需要闭源商业授权的产品，因为 GPL-3.0 要求衍生作品开源。在采用前，应先在 SITL 仿真中运行对应载具的测试流程（如 test_sitl_copter.yml），并核对目标硬件板是否在支持列表中。最终判断：ArduPilot 是功能广度最大的开源自驾仪，但代价是学习曲线陡峭和许可严格，适合愿意投入长期维护的团队。
社区笔记