1、MAVLink协议概述
各位同学，咱们今天正式开讲《MAVLink在PX4中的部署实践》的第一章。说实话，每次带新人入门，我都要先问一句：你知道无人机和地面站之间，到底是用什么语言在聊天吗？
嗯，答案就是MAVLink。这玩意儿在无人机圈子里，就像HTTP之于互联网一样基础。我最早接触它是在2015年，那时候还在用APM飞控，调参全靠Mission Planner里那一串串看不懂的十六进制数。后来才明白，原来那些数字就是MAVLink报文。
MAVLink的起源与发展
MAVLink全称是Micro Air Vehicle Link，微小型飞行器通信链路。它最早由苏黎世联邦理工学院的Lorenz Meier在2009年设计出来，当时就是为了解决无人机飞控和地面站之间的轻量化通信问题。
为什么叫“微”？因为它的报文头只有6个字节。你想想看，在2009年那个年代，飞控的RAM可能只有几十KB，Flash也就几百KB，一个协议如果太臃肿，根本跑不起来。MAVLink的设计哲学就是：能省则省，能简则简。
发展到现在，MAVLink已经成了无人机行业的事实标准。PX4、ArduPilot、QGroundControl、Mission Planner……几乎所有主流的飞控和地面站都在用。我个人习惯把它比作无人机界的“普通话”——不管你是大疆的飞控，还是开源的PX4，只要说MAVLink，大家就能互通。
核心事实：MAVLink是目前无人机生态中应用最广、支持最完善的通信协议，没有之一。
MAVLink在无人机生态中的角色
说白了，MAVLink就是无人机系统的“神经系统”。它负责传递三类关键信息：
- 遥测数据：高度、速度、姿态、GPS坐标、电池电压……这些是地面站要看的“仪表盘”
- 控制指令：起飞、降落、航点上传、模式切换……这些是地面站发给飞控的“命令”
- 系统状态：心跳包、错误码、参数读写……这些是保证系统正常运行的“体检报告”
我在项目中遇到过最典型的一个场景：客户说无人机飞着飞着突然失控了。排查了半天，最后发现是MAVLink的心跳包超时，地面站以为飞控挂了，自动触发了紧急降落。你看，一个简单的协议细节，直接决定了飞行安全。
为了让你更直观地理解MAVLink在整个无人机系统中的位置，我画了一张图：
我的经验：刚开始学MAVLink时，别急着看报文细节。先搞清楚数据是怎么从飞控到地面站的——串口线、数传电台、4G模块，甚至WiFi，这些传输方式决定了你选v1还是v2。
MAVLink v1与v2的区别
好，接下来是本章的重头戏。MAVLink目前有两个版本在广泛使用：v1和v2。你可能会问：为什么要有两个版本？直接用一个不就行了？
嗯，原因很简单：v1的设计太“省”了，省到后来不够用了。
v1的报文头只有6个字节，系统ID和组件ID各占1个字节。这意味着什么？整个网络里最多只能有255个系统，每个系统最多255个组件。对于大多数消费级无人机来说，这绰绰有余。但如果你在做集群编队，几十上百架无人机同时通信，v1的地址空间就捉襟见肘了。
v2就是在这样的背景下诞生的。它把报文头扩展到了12个字节，引入了几个关键改进。我整理了一张对比表，你一看就明白：
| 对比项 | MAVLink v1 | MAVLink v2 |
|---|---|---|
| 报文头长度 | 6 字节 | 12 字节 |
| 系统ID范围 | 0-255 | 0-255（兼容） |
| 组件ID范围 | 0-255 | 0-255（兼容） |
| 签名机制 | 无 | 支持（13字节签名） |
| 消息ID范围 | 0-255 | 0-16777215（3字节） |
| 有效载荷长度 | 0-255 字节 | 0-255 字节（兼容） |
| 兼容性标志 | 无 | 有（2字节标志位） |
看到没？最大的变化是消息ID从1字节扩展到了3字节。这意味着v2可以定义超过1600万种不同的消息类型。v1只有255种，说实话，到后期已经快用完了。我记得有一次要给一个新传感器定义消息，翻遍了v1的ID表，愣是找不到一个空闲的ID——那种感觉，就像住在一个没有空位的停车场里找车位。
避坑指南：我曾经在项目中遇到过一个问题：飞控用的是v2，地面站用的是v1，结果地面站死活收不到心跳包。排查了半天才发现是版本不匹配。v2虽然向下兼容v1，但反过来不行。所以，如果你在搭建新系统，我建议直接上v2，省得以后踩坑。
v2的签名机制
v2还有一个v1没有的杀手锏——报文签名。说白了，就是给每个报文加了一个13字节的“防伪标签”。这在安全敏感的场景下特别重要，比如军用无人机或者工业巡检。
签名机制的工作原理是这样的：
- 发送方和接收方预先共享一个密钥（32字节）
- 发送方对报文内容+时间戳+密钥计算SHA-256哈希，取前13字节作为签名
- 接收方用同样的方式验证签名，不匹配就丢弃报文
这样做的好处是：即使有人截获了你的无线信号，他也伪造不了合法的MAVLink报文。嗯，当然，前提是你的密钥没有泄露。
我的建议：如果你只是在实验室里调参，签名可以不开。但如果是产品级部署，尤其是通过4G公网通信的，一定要开启签名。我曾经帮一个客户排查过“无人机被劫持”的案例，最后发现就是有人在地面站和飞控之间插了一个伪造的MAVLink报文，把航点给改了。开了签名之后，这个问题再也没出现过。
v1与v2的报文结构对比
最后，咱们来看看两种版本的报文在“长相”上有什么区别。我直接贴代码，你感受一下：
// MAVLink v1 报文结构
uint8_t magic; // 0xFE
uint8_t length; // 有效载荷长度
uint8_t seq; // 序列号
uint8_t sysid; // 系统ID
uint8_t compid; // 组件ID
uint8_t msgid; // 消息ID (0-255)
uint8_t payload[0-255]; // 有效载荷
uint16_t checksum; // CRC校验
// MAVLink v2 报文结构
uint8_t magic; // 0xFD
uint8_t length; // 有效载荷长度
uint8_t incompat_flags; // 不兼容标志
uint8_t compat_flags; // 兼容标志
uint8_t seq; // 序列号
uint8_t sysid; // 系统ID
uint8_t compid; // 组件ID
uint8_t msgid[3]; // 消息ID (0-16777215)
uint8_t payload[0-255]; // 有效载荷
uint8_t checksum[2]; // CRC校验
// 如果签名开启，后面还有13字节签名
你看，v2的magic字节从0xFE变成了0xFD。这是协议栈用来区分v1和v2的关键标志。收到一个报文，先看第一个字节——0xFE就走v1解析流程，0xFD就走v2解析流程。就这么简单。
另外注意v2多了两个标志位字段：incompat_flags和compat_flags。这两个字段的作用是：
- incompat_flags：如果接收方不理解这个标志位，就必须丢弃报文。比如签名标志位就放在这里
- compat_flags：如果接收方不理解这个标志位，可以忽略并继续处理。这为未来的扩展提供了空间
这种设计很聪明。你想想看，如果以后要加一个新功能，只需要定义一个新的compat_flag，老版本的地面站虽然不认识，但也不会崩溃——直接忽略就行了。这就是v2的“向前兼容”设计哲学。
一句话总结：MAVLink v1是“够用就好”的经典设计，v2是“面向未来”的升级版本。新项目选v2，老项目看情况迁移。