1. MAVLink 协议概述：无人机通信的“通用语言”
各位同学，咱们今天聊 MAVLink。说实话，这玩意儿在无人机圈子里，就跟 HTTP 在 Web 世界的地位差不多——你几乎找不到哪款开源飞控不支持它。我最早接触 MAVLink 是在 2015 年做植保无人机项目的时候，那时候 PX4 刚火起来，整天跟 QGroundControl 打交道，天天抓包看消息流。嗯，那段日子让我对这套协议有了切肤之痛的理解。
1.1 无人机通信协议发展史：从“各说各话”到“统一标准”
早期的无人机，说白了就是“各玩各的”。每家飞控厂商都有自己的私有协议，地面站和飞控之间怎么通信，全看厂商心情。你想想看，那时候做二次开发有多痛苦——换一家飞控，整个通信层就得重写。
我记得 2010 年左右，有个叫 MikroKopter 的德国团队，他们用的协议是纯二进制，连个校验都没有。后来有个叫 Lorenz Meier 的哥们儿（没错，就是后来 PX4 和 QGC 的创始人），在苏黎世联邦理工读博期间搞了个开源项目，把通信协议标准化了。这就是 MAVLink 的起源——Micro Air Vehicle Link，微型飞行器链路。
发展脉络其实很清晰：
- 2009 年：MAVLink v1.0 诞生，最初只支持 256 个消息 ID，每个消息最长 255 字节
- 2013 年：随着 PX4 和 APM 的普及，MAVLink 成为事实上的行业标准
- 2017 年：MAVLink v2.0 发布，解决了 v1 的诸多痛点
- 至今：v2 成为主流，v1 逐渐退居兼容模式
核心观点：MAVLink 的成功不在于它有多“先进”，而在于它足够“开放”。任何团队都可以扩展自己的消息集，只要遵循帧结构就行。这种“半标准化”的设计哲学，让它在学术圈和工业界都站稳了脚跟。
1.2 MAVLink v1 vs v2：到底升级了什么？
很多初学者会问：v2 比 v1 强在哪？我直接说结论——v2 解决了 v1 的三个硬伤：消息空间不够、安全性缺失、扩展性差。
咱们直接看对比表：
| 特性 | MAVLink v1 | MAVLink v2 |
|---|---|---|
| 消息 ID 空间 | 0-255（8 位） | 0-16777215（24 位） |
| 有效载荷长度 | 0-255 字节 | 0-255 字节（支持扩展） |
| 签名机制 | 无 | 可选 SHA-256 签名 |
| 兼容性 | 自包含 | 向后兼容 v1 |
| 目标系统/组件 | 无 | 支持 target_system/target_component |
| 包间隔标记 | 无 | 支持不连续传输 |
我挑几个重点说说：
第一，消息 ID 从 8 位扩展到 24 位。 你想想看，v1 时代只有 256 个消息槽位，官方定义的消息就已经占了大半，留给厂商自定义的空间少得可怜。我在做农业无人机项目时，想加一个“喷洒流量”的消息，发现 v1 的厂商自定义区间（0-255 里只有 0-9 可用）根本不够用。v2 直接给了 1600 多万个 ID，随便用。
第二，签名机制。 v1 没有任何安全防护，说白了就是“裸奔”。我在 2018 年参加一个无人机安全攻防比赛，亲眼看到有人用一台笔记本加一个 SDR 设备，直接伪造 MAVLink 包让飞控执行“紧急降落”。v2 的 SHA-256 签名虽然会增加 13 字节的开销，但能有效防止这种重放攻击和伪造攻击。
避坑指南：我曾经在一个项目中，因为偷懒没启用 v2 签名，结果在公开演示时被观众用手机 APP 劫持了无人机。嗯，从那以后，凡是涉及安全场景，我必开签名。记住：签名密钥要定期更换，别写死在固件里。
第三，目标系统/组件字段。 v1 的消息是“广播式”的，所有设备都能收到。v2 引入了 target_system 和 target_component，可以精确指定消息发给谁。这在多机协同场景下特别有用——比如你同时控制 5 架无人机，v1 你得自己解析 system_id 来过滤，v2 直接在协议层帮你做了。
1.3 MAVLink 在任务规划中的核心作用
任务规划，说白了就是“告诉无人机你要干什么”。MAVLink 在这中间扮演了三个角色：
- 命令通道：地面站通过 MAVLink 发送任务指令（起飞、降落、航点飞行）
- 状态反馈：飞控通过 MAVLink 回传位置、姿态、电池等状态
- 数据链路：任务上传/下载、参数读写、日志传输
我画了一张图，帮你理解 MAVLink 在任务规划中的位置：
你看这张图，地面站和飞控之间，MAVLink 就是那个“翻译官”。没有它，地面站说人话，飞控说机器话，两边根本聊不到一块儿去。
个人经验：我建议你在学习 MAVLink 时，先抓包看几个典型消息流。用 Wireshark 或者 mavlink-router 的日志功能，看看 HEARTBEAT 是怎么维持心跳的，MISSION_ITEM 是怎么上传航点的。亲眼看到二进制帧在线上跑，比看十遍文档都管用。
1.4 一个简单的 MAVLink 帧结构示例
咱们来看一个 v2 帧的实际结构。这是我从一个实际抓包中截取的 HEARTBEAT 消息：
帧头: 0xFD (v2 起始标志)
长度: 9 (有效载荷 9 字节)
不连续标志: 0x00
兼容标志: 0x00
签名标志: 0x00
序列号: 0x01
系统 ID: 0x01 (飞控)
组件 ID: 0x01 (自动驾驶仪)
消息 ID: 0x00 (HEARTBEAT)
有效载荷: [0x01, 0x00, 0x00, 0x00, 0x04, 0x00, 0x00, 0x00, 0x00]
- type: 1 (MAV_TYPE_QUADROTOR)
- autopilot: 0 (MAV_AUTOPILOT_GENERIC)
- base_mode: 4 (MAV_MODE_FLAG_STABILIZE_ENABLED)
- custom_mode: 0
- system_status: 0 (MAV_STATE_UNINIT)
校验和: [0xXX, 0xXX] (CRC16-CCITT)这个帧一共 28 字节（含校验）。你想想看，v1 的帧头只有 6 字节，v2 扩展到了 10 字节，多出来的空间就是为了支持签名和目标寻址。代价是每帧多了 4 字节开销，但在现代数传链路上，这点带宽根本不算什么。
注意：MAVLink v2 的校验和计算方式跟 v1 不一样。v2 把整个帧（包括帧头）都纳入了 CRC 计算范围。我曾经因为没注意这个细节，在移植协议栈时花了整整两天排查“为什么校验总是不对”。嗯，血的教训。
1.5 为什么任务规划离不开 MAVLink？
说白了，任务规划的本质就是“人机交互”。人通过地面站告诉无人机：你要飞哪些点、飞多高、到了之后干什么。无人机通过 MAVLink 告诉地面站：我现在在哪、还剩多少电、有没有异常。
我总结了三层依赖关系：
- 数据层：MAVLink 定义了标准的数据格式，地面站和飞控不需要关心对方用什么语言写的
- 控制层：MAVLink 的 COMMAND 协议（如 MAV_CMD_NAV_WAYPOINT）提供了统一的指令集
- 交互层：MAVLink 的 MISSION 协议支持任务的上传、下载、清空、重排序等操作
没有 MAVLink，每个地面站都得为每种飞控写一套通信驱动。有了 MAVLink，你只需要写一套协议栈，就能兼容 PX4、ArduPilot、甚至一些商业飞控。这就是标准化的力量。