1. MAVLink协议概述：协议起源、设计哲学、在无人机生态中的地位
1.1 协议起源：从一场“遥控器不够用”的困境说起
MAVLink 的故事，得从 2009 年讲起。
那时候我还在折腾早期的开源飞控，说白了就是一堆传感器、一个单片机、再加一个简陋的遥控器。你想想看，遥控器只有几个通道，油门、副翼、升降、方向就占满了。想传个 GPS 坐标？没门。想看看电池电压？得自己焊个显示屏。
当时有个叫 Lorenz Meier 的瑞士小伙子，在苏黎世联邦理工做无人机研究。他遇到一个很现实的问题：地面站和飞控之间怎么高效地传数据？用串口发原始字节？太乱。自己定义协议？每个项目一套，没法复用。
于是 MAVLink 诞生了。全称是 Micro Air Vehicle Link，微小型飞行器通信链路。注意这个“Micro”，它从一开始就瞄准了嵌入式设备——资源有限、带宽有限、实时性要求高。
核心事实：MAVLink 是当今最广泛使用的无人机通信协议，没有之一。PX4、ArduPilot、QGroundControl、Mission Planner 全部基于它。
我记得第一次在项目中用 MAVLink 时，最大的感受是：终于不用自己造轮子了。之前我做过一个四旋翼，光通信协议就写了三版，每一版都有 bug。后来直接移植了 MAVLink 的 C 库，一周搞定。
1.2 设计哲学：轻量、可靠、可扩展
MAVLink 的设计哲学，说白了就三个词：轻量、可靠、可扩展。咱们一个一个说。
轻量
MAVLink 的报文头只有 6 个字节。你想想看，一个典型的 GPS 坐标报文，加上头也就 28 个字节。在 115200 bps 的串口上，传输时间不到 3 毫秒。
为什么会这么小？因为 MAVLink 用了单字节的消息 ID 和单字节的载荷长度。早期的 MAVLink 1.0 版本，消息 ID 只有 0-255，载荷最大 255 字节。对于飞控这种资源受限的设备，刚刚好。
| 版本 | 报文头大小 | 消息 ID 范围 | 最大载荷 | 校验方式 |
|---|---|---|---|---|
| MAVLink 1.0 | 6 字节 | 0-255 | 255 字节 | CRC-16-CCITT |
| MAVLink 2.0 | 10 字节 | 0-16777215 | 255 字节 | CRC-16-CCITT + 签名 |
我的经验：在 115200 bps 的串口上，MAVLink 1.0 的报文传输延迟可以控制在 1-5 毫秒。如果你用 921600 bps，延迟能降到 0.5 毫秒以下。对于大多数飞控应用，这个延迟完全够用。
可靠
MAVLink 的可靠性靠两样东西：CRC 校验和消息确认机制。
每个报文末尾都带一个 16 位 CRC 校验。接收方收到后先算 CRC，对不上就直接丢弃。我曾经在项目中遇到过电磁干扰严重的环境，串口数据经常被干扰。MAVLink 的 CRC 帮我过滤掉了至少 99% 的错误包。
消息确认机制呢？MAVLink 支持命令确认（COMMAND_ACK），你发一个起飞指令，飞控必须回一个“收到并执行”的确认。如果超时没收到，地面站可以重发。
注意：MAVLink 本身不保证消息的可靠传输。它只提供 CRC 校验和确认机制，但重传逻辑需要应用层自己实现。别指望协议帮你搞定一切。
可扩展
MAVLink 2.0 引入了消息 ID 扩展（24 位）和兼容性标志。这意味着你可以定义自己的消息类型，只要不跟官方冲突就行。
我有个朋友做农业无人机，需要传农药流量数据。官方没有这个消息，他就自己定义了一个 CUSTOM_FLOW_RATE，ID 选了个 0x10000 以上的值，完美避开官方范围。
1.3 在无人机生态中的地位：事实上的“通用语言”
MAVLink 在无人机生态中的地位，相当于 HTTP 在 Web 中的地位。它不是唯一的协议，但它是事实上的标准。
咱们看看它覆盖了哪些东西：
- 飞控固件：PX4、ArduPilot 全部原生支持 MAVLink
- 地面站：QGroundControl、Mission Planner、MAVProxy 全部基于 MAVLink
- 机载计算机：ROS 的 MAVROS 包、DroneKit、MAVSDK 全部封装了 MAVLink
- 数传模块：Holybro、CUAV、SiK Radio 全部默认走 MAVLink
你想想看，一个协议能同时被飞控、地面站、机载计算机、数传模块支持，这生态得多强？
关键数据：截至 2024 年，MAVLink 定义了超过 200 种标准消息类型，覆盖心跳、姿态、GPS、电池、遥控器、任务、日志、参数等所有核心功能。
我个人习惯把 MAVLink 比作“无人机界的 USB”。USB 定义了设备怎么连接、怎么传数据、怎么供电。MAVLink 定义了飞控怎么跟地面站说话、怎么传传感器数据、怎么执行命令。没有它，每个厂商都得自己搞一套，生态就碎了。
下面这张图展示了 MAVLink 在典型无人机系统中的位置：
从这张图你能看到，MAVLink 处在中间层，向上对接飞控、机载计算机、地面站，向下兼容串口、UDP、TCP、蓝牙等各种物理层。这就是它的核心价值——解耦。
飞控开发者不用关心地面站是用什么语言写的，地面站开发者也不用关心飞控跑在什么芯片上。只要大家都遵守 MAVLink 的规范，就能互相通信。
1.4 版本演进：从 1.0 到 2.0
MAVLink 1.0 在 2009 年发布，一直用到 2017 年。说实话，1.0 版本已经很够用了。但后来无人机越来越复杂，消息类型越来越多，1.0 的 256 个消息 ID 不够用了。
2017 年，MAVLink 2.0 发布。主要改进有：
- 24 位消息 ID：支持最多 16777216 种消息类型，基本用不完
- 消息签名：防止伪造和篡改，安全性大幅提升
- 兼容性标志：允许接收方跳过不认识的字段，向前兼容
- 可变长度数组：支持动态大小的数组，更灵活
我的建议：新项目直接用 MAVLink 2.0。1.0 虽然还能用，但 2.0 的签名功能在商业项目中几乎是必须的。你总不希望别人伪造一个“降落”指令让你的飞机掉下来吧？
我曾经帮一个客户排查过问题，他们的无人机在飞行中突然失控。后来发现是有人在附近用了一个不加密的数传模块，发送了伪造的 MAVLink 指令。启用 2.0 的签名功能后，问题再没出现过。
1.5 为什么选择 MAVLink？
你可能要问：市面上有那么多通信协议，为什么偏偏选 MAVLink？
我的回答是：生态。
你选一个协议，不只是选技术，更是选生态。MAVLink 背后有 PX4 和 ArduPilot 两个最大的开源飞控项目，有 QGroundControl 和 Mission Planner 两个最成熟的地面站，有数以万计的开发者在使用它、改进它。
你遇到一个问题，去 GitHub 上搜一下，大概率有人已经遇到过并解决了。你需要的功能，大概率已经有现成的消息类型。你想集成一个新的传感器，大概率已经有对应的 MAVLink 消息。
这就是生态的力量。
一句话总结：MAVLink 不是最完美的协议，但它是无人机领域生态最完善、社区最活跃、工具链最成熟的协议。没有之一。