MAVLink协议基础：帧结构、消息类型与CRC校验

各位同学，今天我们来聊聊MAVLink协议。说实话，这个协议是QGC和无人机之间沟通的“共同语言”。你想想看，地面站要发指令，飞控要回传数据，总得有个双方都懂的格式吧？MAVLink就是干这个的。

我在做第一个QGC二次开发项目时，就吃过不懂MAVLink的亏。当时任务上传总失败，查了半天才发现是消息长度算错了。嗯，从那以后，我老老实实把协议啃了一遍。今天我把这些经验分享给你们。

MAVLink协议帧结构

MAVLink目前有两个主流版本：v1.0和v2.0。QGC默认用的是v2.0，但向下兼容v1.0。我个人建议新项目直接用v2.0，原因后面会讲。

先看v2.0的帧结构，说白了就是数据包的“包装盒”：

字节偏移	字段名	长度(字节)	说明
0	STX	1	起始标志，v2.0固定为0xFD
1	LEN	1	载荷长度（不含CRC）
2	INC_FLAGS	1	不兼容标志位
3	CMP_FLAGS	1	兼容标志位
4	SEQ	1	序列号，用于丢包检测
5	SYS_ID	1	系统ID，飞控通常为1
6	COMP_ID	1	组件ID，如MAV_COMP_ID_AUTOPILOT
7-9	MSG_ID	3	消息ID（v1.0只有1字节）
10..	PAYLOAD	LEN	消息载荷，最大255字节
最后2	CRC	2	16位CRC校验

我记得有一次调试，发现QGC收不到飞控的HEARTBEAT。抓包一看，SYS_ID写成了0。飞控默认SYS_ID=1，地面站只监听SYS_ID=1的包，当然收不到。这种低级错误，排查起来最费时间。

消息类型与分类

MAVLink的消息类型，说白了就三大类：

• 命令类（COMMAND）：地面站→飞控，比如起飞、降落、航点上传
• 数据流类（STREAM）：飞控→地面站，比如姿态、GPS、电池信息
• 任务类（MISSION）：航点任务的上传下载，这是咱们课程的重点

我挑几个和QGC航点任务强相关的消息，你们记一下：

消息名	MSG_ID(v2)	方向	用途
HEARTBEAT	0	飞控→地面站	心跳包，每秒1次，表明飞控活着
MISSION_COUNT	44	地面站→飞控	告知飞控要上传多少个航点
MISSION_ITEM_INT	73	双向	单个航点数据（推荐用这个，精度更高）
MISSION_ACK	47	飞控→地面站	任务上传/下载完成确认
COMMAND_INT	75	地面站→飞控	带坐标的命令，如起飞到指定点

CRC校验机制

CRC校验，说白了就是防止数据在传输过程中被“篡改”。MAVLink用的是CRC-16-CCITT，多项式是0x1021。

但MAVLink的CRC有个特殊之处——它给每个消息类型都分配了一个额外的CRC种子。这个种子是消息ID和载荷内容的“指纹”。

计算过程是这样的：

1. 先对整帧数据（从LEN到PAYLOAD末尾）做CRC-16
2. 再异或上该消息类型对应的CRC种子
3. 最终得到2字节的CRC校验值

为什么要加这个种子？我举个例子你就明白了。假设两个不同消息的载荷恰好相同，没有种子的话CRC值就一样，接收方可能误判。加了种子后，不同消息类型即使载荷相同，CRC也不同。

下面我用一张图把MAVLink的帧结构、消息类型和CRC校验的关系串起来：

这张图从左到右展示了MAVLink的核心流程：先按帧结构打包数据，再根据消息类型分类处理，最后通过CRC校验保证数据完整性。三个环节缺一不可。

实际开发中的注意事项

讲完理论，说点实际的。你在QGC里做航点任务开发时，这几个坑一定要避开：

• 序列号SEQ必须连续：飞控靠SEQ判断是否丢包。如果QGC发的SEQ跳变，飞控会认为丢包，触发重传机制，导致任务上传变慢。
• MISSION_ACK的响应超时：QGC默认等待ACK的超时时间是500ms。如果网络延迟高，建议调大到1000ms。我在4G数传链路上就遇到过这个问题。
• CRC计算要包含整个帧：有些新手只对PAYLOAD算CRC，忽略了前面的头字段。这样算出来的CRC，飞控肯定不认。

好了，MAVLink协议基础就讲到这里。记住帧结构、消息类型、CRC校验这三块，后面讲航点任务上传下载时，你会回来感谢我的。