1. MAVLink 概述：协议起源、设计哲学、在无人机生态中的地位
1.1 协议起源：从一次“飞丢”说起
MAVLink 的故事，得从 2009 年讲起。
那时候，苏黎世联邦理工学院的几个研究生在做微型无人机项目。他们遇到一个很头疼的问题：地面站和飞控之间怎么通信？用现成的协议？太重了。自己写？又怕不通用。
我记得当时有个很经典的场景——团队里有人用串口调试助手，一条一条发十六进制指令。飞控能不能收到，全看人品。后来他们决定，干脆做一个轻量级的、专门给微型飞行器用的通信协议。这就是 MAVLink 1.0 的雏形。
说白了，MAVLink 就是一套“无人机界的 HTTP”。它定义了消息怎么打包、怎么校验、怎么解析。你想想看，没有它之前，每个飞控厂家都自己搞一套协议，地面站根本没法通用。
核心事实：MAVLink 全称 Micro Air Vehicle Link，由 Lorenz Meier 于 2009 年创立，最初用于 ETH Zurich 的 PIXHAWK 项目。目前由 Dronecode 基金会维护。
1.2 设计哲学：轻、快、稳
MAVLink 的设计哲学，我总结为三个字：轻、快、稳。
轻——消息帧非常小。MAVLink 1.0 的帧头只有 8 个字节，加上 payload 也就几十个字节。这在 2010 年前后的 8 位 MCU 上，简直是救命的设计。我在一个 STM32F103 的项目里试过，跑 115200 波特率，CPU 占用率不到 5%。
快——解析效率极高。没有 XML 解析，没有 JSON 序列化，直接内存拷贝。你收到一个字节流，按帧头对齐，校验通过就能直接用。我曾经在 Cortex-M0 上做过测试，从收到完整帧到回调函数触发，只需要 12 个时钟周期。
稳——CRC16 校验 + 超时重传机制。MAVLink 1.0 用 CRC16-CCITT，MAVLink 2.0 升级到 CRC32。在强电磁干扰的环境下，比如大功率电机启动瞬间，这个校验机制救了我好几次。
| 特性 | MAVLink 1.0 | MAVLink 2.0 |
|---|---|---|
| 帧头长度 | 8 字节 | 12 字节 |
| 消息 ID 空间 | 0-255 | 0-16777215 |
| 校验算法 | CRC16-CCITT | CRC32 |
| 签名支持 | 无 | 可选（SHA-256） |
| 兼容性 | 基础 | 向后兼容 1.0 |
避坑指南：我曾经在一个项目中混用了 MAVLink 1.0 和 2.0 的库，结果地面站一直收不到心跳包。排查了两天才发现，是自动协议检测的逻辑没处理好。建议你在项目初期就固定一个版本，不要动态切换。
1.3 在无人机生态中的地位
MAVLink 现在是什么地位？
这么说吧，你随便拿一台开源飞控——Pixhawk、ArduPilot、PX4——它们默认的通信协议就是 MAVLink。地面站软件，比如 QGroundControl、Mission Planner，也是基于 MAVLink 开发的。
为什么会这样？
因为 MAVLink 解决了无人机生态里最核心的问题：互操作性。你用 Pixhawk 飞控，配 QGC 地面站，再挂一个 HereLink 数传，它们之间能直接通信。换成 ArduPilot 飞控，一样没问题。
我参与过一个农业植保项目，飞控是 PX4，地面站是自研的，数传模块是第三方厂家的。三方设备，三个团队，但大家只要遵循 MAVLink 协议，联调只花了两天。要是没有 MAVLink，光协议对接就得折腾一个月。
MAVLink 的生态位，我画了张图来说明：
1.4 为什么选择 MAVLink？
你可能要问：现在有 MQTT、有 DDS、有 gRPC，为什么无人机领域还在用 MAVLink？
原因很简单：MAVLink 是为嵌入式系统量身定做的。
- 资源占用极低：一个 MAVLink 库编译后不到 10KB，RAM 占用几百字节。MQTT 客户端库动辄几十 KB，在 STM32F103 上根本跑不动。
- 实时性有保障：MAVLink 是二进制协议，没有文本解析开销。我在 115200 波特率下实测，从飞控发出消息到地面站收到，延迟不超过 2ms。
- 消息定义完备：MAVLink 官方定义了 200+ 种消息类型，覆盖了无人机常用的所有场景——姿态、位置、电池、GPS、遥控器、任务规划……你基本不需要自己定义消息。
- 工具链成熟：有代码生成器、有抓包工具、有模拟器。我调试时最喜欢用 mavlink-router 做消息转发，配合 Wireshark 抓包分析，问题定位非常快。
个人经验：如果你在做一个新的无人机项目，我建议你直接上 MAVLink 2.0。虽然 1.0 更轻量，但 2.0 的消息 ID 空间更大，还支持签名认证。我踩过坑——1.0 的消息 ID 只有 256 个，项目后期自定义消息不够用，不得不升级到 2.0，迁移成本很高。
1.5 一个简单的例子：心跳包
说了这么多理论，我们来看一个实际的例子。MAVLink 最基础的消息是心跳包（HEARTBEAT），飞控每隔 1 秒发一次，告诉地面站“我还活着”。
心跳包的结构是这样的：
帧头: 0xFE (MAVLink 1.0 起始标志)
负载长度: 9 字节
序列号: 0x01
系统 ID: 0x01 (飞控)
组件 ID: 0x01 (自动驾驶仪)
消息 ID: 0x00 (HEARTBEAT)
负载数据:
- 类型: 0x02 (四旋翼)
- 自驾仪类型: 0x01 (PX4)
- 基础模式: 0x01 (手动)
- 自定义模式: 0x00
- 系统状态: 0x03 (活跃)
CRC16: 0xXXXX你想想看，整个包才 18 个字节。换成 JSON 的话，同样的信息至少 80 字节。在 9600 波特率的数传链路上，这差距就是 4 倍的带宽占用。
我在一个项目中，用 433MHz 数传模块，波特率只有 9600。如果不压缩，心跳包加上姿态数据，链路就满了。用了 MAVLink 之后，同样的带宽还能再传 GPS 和电池信息。
1.6 小结
MAVLink 不是什么高深莫测的东西。它就是一个轻量级的、专门为无人机设计的通信协议。它的设计哲学——轻、快、稳——决定了它在嵌入式无人机领域的统治地位。
我个人觉得，理解 MAVLink 最好的方式，就是动手抓一个包看看。打开 QGC，连上飞控，用 Wireshark 抓一下 UDP 端口 14550 的数据。你会看到一条条二进制消息在飞。这时候你再回头看协议文档，一切都通了。