2. MAVLink协议栈架构：消息定义、序列化/反序列化、校验机制（CRC）、心跳包机制
各位同学，今天我们聊聊MAVLink协议栈的核心骨架。说白了，就是搞清楚一条消息从“脑子里想好”到“电线上飞走”，再到“对方看懂”的全过程。
我最早接触MAVLink时，觉得它不就是个通信协议嘛，能有多复杂？结果第一次做飞控移植，被CRC校验坑了一整天。嗯，从那以后，我再也不敢小看这些“基础机制”了。
2.1 消息定义：协议栈的“语法书”
MAVLink的消息定义，本质上是一套结构体描述。你想想看，无人机要告诉地面站“我现在的高度是100米”，总得有个统一的格式吧？
我个人习惯把消息定义分成三层来看：
- 消息ID：每条消息的唯一编号。比如心跳包是0，飞控状态是1，GPS信息是24。这个ID决定了接收方该用哪个结构体去解析。
- 载荷字段：实际要传的数据。比如高度、速度、姿态角。每个字段都有明确的类型（uint8_t、float、int16_t等）。
- 元信息：包括消息长度、CRC种子、目标系统/组件ID等。这些不直接出现在载荷里，但编解码时必须知道。
核心要点：MAVLink 2.0的消息定义比1.0多了个“兼容标志”字段。我在项目中遇到过，如果地面站只支持1.0，飞控发了2.0的消息，对方直接丢弃——这就是兼容性没处理好。
来看一个实际的心跳包定义（简化版）：
// 心跳包消息定义（MAVLink 2.0）
message heartbeat {
uint8_t type; // 飞控类型（1=固定翼，2=多旋翼...）
uint8_t autopilot; // 飞控固件类型（3=ArduPilot，4=PX4...）
uint8_t base_mode; // 基础模式（是否已解锁、是否在自动模式）
uint32_t custom_mode; // 自定义模式（具体飞控的私有模式）
uint8_t system_status; // 系统状态（0=未初始化，4=已激活...）
}
你看，就5个字段，加起来才8个字节。但就是这8个字节，地面站能判断出“飞机是什么类型、是否已解锁、当前在什么模式”。这就是消息定义的精妙之处——用最少的数据，传递最核心的信息。
3.2 序列化与反序列化：数据怎么“打包”和“拆包”
序列化，就是把结构体变成字节流。反序列化，就是把字节流变回结构体。听起来简单，但坑不少。
我记得第一次自己写序列化代码时，直接用了memcpy。结果在ARM和x86之间通信，数据全乱了。为什么？因为大小端不一样。
MAVLink的序列化规则很明确：
- 小端序：所有多字节字段都按小端（低位在前）排列。这是为了和大多数嵌入式MCU保持一致。
- 无填充：结构体字段之间没有padding字节。编译器默认的对齐方式在这里不适用。
- 固定顺序：字段按定义顺序依次排列，不能乱。
避坑指南：我曾经在STM32上遇到一个问题——结构体里有个uint64_t字段，编译器自动给它对齐到了8字节地址，导致序列化后的字节流多出4个填充字节。接收方一校验CRC，直接报错。解决方案很简单：用__attribute__((packed))强制取消对齐。
序列化的伪代码大概是这样：
// 序列化：结构体 → 字节流
void mavlink_msg_heartbeat_pack(uint8_t *buf, const heartbeat_t *msg) {
uint16_t offset = 0;
// 按顺序写入每个字段（小端序）
buf[offset++] = msg->type;
buf[offset++] = msg->autopilot;
buf[offset++] = msg->base_mode;
buf[offset++] = msg->custom_mode & 0xFF; // 低8位
buf[offset++] = (msg->custom_mode >> 8) & 0xFF; // 高8位
buf[offset++] = (msg->custom_mode >> 16) & 0xFF;
buf[offset++] = (msg->custom_mode >> 24) & 0xFF;
buf[offset++] = msg->system_status;
// 计算CRC并追加到末尾
uint16_t crc = mavlink_crc_calculate(buf, offset);
buf[offset++] = crc & 0xFF;
buf[offset++] = (crc >> 8) & 0xFF;
}
反序列化就是反过来：先校验CRC，再按顺序读出每个字段，组合成结构体。注意，CRC校验必须在反序列化之前做——如果CRC不对，数据已经损坏了，解析出来也没意义。
2.3 校验机制（CRC）：数据完整性的“守门员”
CRC（循环冗余校验）是MAVLink保证数据完整性的核心手段。说白了，就是发送方给数据算一个“指纹”，接收方收到后重新算一遍，看指纹对不对得上。
MAVLink用的CRC算法是CRC-16-IBM（多项式0x8005）。但有个特殊之处：每条消息的CRC计算时，会混入一个消息特定的CRC种子。这个种子在XML定义文件里就写死了。
注意：不同版本的消息，CRC种子可能不同。我遇到过最坑的一次：飞控固件升级后，心跳包的CRC种子变了，但地面站没更新。结果地面站收到的每个心跳包都CRC校验失败，直接显示“飞控离线”。排查了整整两天才发现是CRC种子不匹配。
CRC计算流程：
- 初始化CRC寄存器为0xFFFF
- 对每个字节（包括消息ID、载荷、目标系统等）进行CRC计算
- 最后异或上消息特定的CRC种子
- 将结果（2字节）追加到消息末尾
这里有个细节：MAVLink 2.0的CRC计算范围比1.0多了个“签名”字段。如果你在移植时没注意这个差异，CRC永远算不对。
2.4 心跳包机制：飞控的“生命体征”
心跳包（HEARTBEAT）是MAVLink里最重要的消息，没有之一。它的消息ID是0，优先级最高，发送频率通常为1Hz（每秒一次）。
为什么叫“心跳”？因为它就像飞控的脉搏——只要地面站还能收到心跳包，就说明飞控还活着。一旦心跳丢失超过一定时间（通常是3-5秒），地面站就会触发“飞控离线”告警。
心跳包的内容我之前已经展示过了，这里重点说说它的设计哲学：
- 极简：只有8字节载荷，确保在任何链路条件下都能传过去。
- 自描述：通过type和autopilot字段，地面站能自动识别飞控类型，不需要手动配置。
- 状态指示：base_mode和system_status能反映飞控的实时状态（是否解锁、是否在自动模式、是否有故障）。
实战经验：我在做多机编队项目时，每架无人机的心跳包不仅要发给地面站，还要发给其他无人机。这时候心跳包的custom_mode字段就派上用场了——我把它编码成编队ID和位置编号，其他无人机收到后就知道“这是3号机，它在我的左边”。
心跳包的发送逻辑通常是这样：
// 心跳包发送任务（1Hz）
void heartbeat_task(void) {
heartbeat_t hb;
// 填充心跳包内容
hb.type = MAV_TYPE_QUADROTOR; // 多旋翼
hb.autopilot = MAV_AUTOPILOT_PX4; // PX4固件
hb.base_mode = get_current_mode(); // 从飞控状态机获取
hb.custom_mode = get_custom_mode();
hb.system_status = get_system_status();
// 序列化并发送
uint8_t buf[MAVLINK_MAX_PACKET_LEN];
uint16_t len = mavlink_msg_heartbeat_pack(buf, &hb);
uart_send(buf, len);
}
你可能会问：为什么心跳包要每秒发一次？频率高了不是更及时吗？嗯，这里有个权衡。1Hz是MAVLink社区多年实践下来的经验值——既能及时检测飞控离线，又不会占用太多带宽。要知道，在数传链路上，带宽是很宝贵的资源。
好了，这一章的内容就到这里。消息定义、序列化/反序列化、CRC校验、心跳包机制，这四个部分构成了MAVLink协议栈的基石。理解了它们，你就掌握了MAVLink通信的“内功心法”。
个人建议：如果你要自己移植MAVLink，先从心跳包开始。把心跳包调通了，其他消息就水到渠成。我每次做新平台的移植，都是先让心跳包跑起来，再逐步添加其他消息。