2. MAVLink协议基础
好，咱们进入第二章。这一章要聊的是MAVLink最底层的骨架——消息帧格式。说白了，就是数据在线上怎么跑，接收方怎么认出这是一条完整的MAVLink消息。
我记得刚接触MAVLink那会儿，拿着逻辑分析仪抓了一堆数据，满眼都是0xFE、0xFD之类的字节。当时没搞懂帧结构，硬是看了半天。后来才明白，这些字节就是MAVLink的“身份证”。
消息帧格式概览
MAVLink目前有两个主流版本：v1和v2。v2是向后兼容的，但帧结构略有不同。咱们先看v2的帧格式，因为它更常用。
| 字段 | 名称 | 长度（字节） | 说明 |
|---|---|---|---|
| STX | 起始标志 | 1 | v1为0xFE，v2为0xFD |
| LEN | 载荷长度 | 1 | PAYLOAD的字节数（0-255） |
| SEQ | 序列号 | 1 | 每个组件独立计数，用于丢包检测 |
| SYS | 系统ID | 1 | 标识飞控、地面站等不同系统 |
| COMP | 组件ID | 1 | 标识同一系统内的不同组件（如GPS、IMU） |
| MSG | 消息ID | 3（v2）/ 1（v1） | v2用3字节，支持更多消息类型 |
| PAYLOAD | 载荷 | 0-255 | 实际数据内容 |
| CK | 校验和 | 2 | CRC16-CCITT校验 |
嗯，这里要注意：v1的MSG只有1字节，最多支持256种消息。v2扩展到3字节，能支持1600多万种。我有个项目就踩过这个坑——用v1协议，结果自定义消息ID超过了255，编译直接报错。
每个字段的实战意义
STX：一帧的开始
接收端通过检测STX来同步帧边界。v2的0xFD和v1的0xFE不会混淆。我曾经在调试时发现地面站一直收不到数据，抓包一看，原来是某模块把STX写成了0xFF。你想想看，接收端根本不认这个起始符，后面的数据全废了。
LEN：载荷有多长
这个字段告诉接收端：读完LEN个字节后，就该取校验和了。如果LEN和实际载荷对不上，CRC校验必挂。我建议在解析时先校验LEN是否在合理范围内（比如0-255），避免恶意数据或内存溢出。
SEQ：谁丢了包
每个发送组件维护自己的SEQ计数器，从0开始，每发一帧加1。接收端通过检查SEQ的连续性来判断丢包。举个例子：收到SEQ=5，下一个却是SEQ=8，那中间6和7就丢了。这在无人机链路里很常见，尤其是飞远了信号变差的时候。
SYS和COMP：谁发的消息
SYS标识整个系统（比如飞控是1，地面站是255），COMP标识系统内的子模块（比如飞控里的GPS组件是220）。这两个字段配合使用，能精确定位消息来源。我遇到过一个问题：两个飞控用了相同的SYS ID，结果地面站把A飞控的GPS数据当成了B飞控的，导航直接偏了。所以，多机场景下SYS ID必须唯一。
MSG：消息类型
MSG决定了PAYLOAD怎么解析。比如MSG=0是HEARTBEAT，MSG=30是ATTITUDE。v2用3字节，低24位有效。解析时要注意字节序——MAVLink统一用小端序。
CRC校验机制
CRC是保证数据完整性的最后一道防线。MAVLink用的是CRC16-CCITT，多项式是0x1021。计算范围包括：LEN、SEQ、SYS、COMP、MSG、PAYLOAD。STX不参与计算。
为什么STX不算？因为STX只是帧同步符，它本身不携带信息。如果STX也算进去，万一线路噪声把STX改了，CRC校验会失败，但接收端可能已经误判了帧起始位置。所以，STX单独拎出来，不参与CRC。
核心要点：CRC校验覆盖从LEN到PAYLOAD的所有字节。接收端计算本地CRC，与帧尾的2字节CK比较。一致则通过，不一致则丢弃整帧。
CRC计算的C代码示例
// MAVLink CRC16-CCITT 计算函数
uint16_t mavlink_crc_calculate(const uint8_t* data, uint16_t len) {
uint16_t crc = 0xFFFF;
for (uint16_t i = 0; i < len; i++) {
crc ^= data[i];
for (uint8_t j = 0; j < 8; j++) {
if (crc & 0x0001) {
crc = (crc >> 1) ^ 0x8408; // 0x8408是0x1021的反射多项式
} else {
crc >>= 1;
}
}
}
return crc;
}这段代码我用了好多年。注意那个0x8408，它是0x1021的反射形式。MAVLink的CRC是反射输入的，所以多项式也要反射。如果你直接用标准CRC16-CCITT库，记得设置输入反射和输出反射为true。
CRC的额外字节：v2的改进
v2在CRC计算中额外引入了一个“CRC extra”字节。这个字节由消息ID决定，每个消息类型都有一个固定的CRC extra值。计算时，把CRC extra追加到PAYLOAD后面一起算。
为什么要加这个？说白了，就是为了防止消息ID解析错误。假设接收端把MSG解析错了，但PAYLOAD长度恰好一样，CRC可能碰巧通过。加上CRC extra后，不同消息类型的CRC extra不同，即使MSG解析错，CRC也大概率对不上。
实战技巧：生成CRC extra表时，可以用MAVLink官方代码生成器。我习惯在编译时静态生成这个表，避免运行时计算开销。对于嵌入式MCU，查表比实时计算快得多。
帧解析流程
接收端怎么从字节流里提取出一帧？我画了个流程图，你看看就明白了。
这个流程看起来简单，但实际工程里有个坑：如果STX出现在PAYLOAD里怎么办？比如PAYLOAD里恰好有个0xFD。接收端会误以为这是新帧的开始，导致当前帧解析失败。
避坑指南：我曾经在一个数传链路上遇到频繁丢帧，排查了两天。最后发现是PAYLOAD里频繁出现0xFD，接收端不断误同步。解决方案有两个：一是用v2的帧尾标志（v2可选在CK后加0xFD作为帧尾），二是在解析时增加状态机，确保只有完整帧才触发解析。
v1与v2的差异对比
| 特性 | v1 | v2 |
|---|---|---|
| STX | 0xFE | 0xFD |
| MSG长度 | 1字节（0-255） | 3字节（0-16777215） |
| CRC extra | 无 | 有 |
| 签名 | 无 | 可选（13字节） |
| 兼容性 | 基础 | 向后兼容v1 |
v2的签名功能我没在实战中用过，但如果你做安全敏感的应用（比如军用或金融无人机），建议开启。签名基于SHA-256，能防止消息伪造。
常见CRC故障排查
CRC校验失败是MAVLink通信里最常见的故障。我总结了几种情况：
- LEN与实际不符：发送方填的LEN和实际PAYLOAD长度不一致。接收端按LEN读PAYLOAD，读出来的字节数不对，CRC必挂。
- 字节序错误：MAVLink用的小端序。如果你在STM32上用了大端序的CRC库，算出来的结果肯定不对。
- CRC extra遗漏：v2协议里忘了加CRC extra。接收端按v2标准算，发送端按v1标准算，两边对不上。
- 硬件干扰：无线链路上的比特翻转。这种情况只能靠重传机制弥补。
我的调试习惯：遇到CRC错误，先用逻辑分析仪抓一帧完整的原始数据。然后手动计算CRC，跟帧尾的CK对比。如果手动算出来一致，说明发送端没问题，问题在接收端。如果手动算出来不一致，那就是发送端的问题。这个方法虽然土，但特别有效。
好了，这一章的内容就到这儿。消息帧格式是MAVLink的基石，CRC校验是数据完整性的保障。搞懂了这些，后面分析日志、排查故障才能有的放矢。