3. MAVLink 1.0 vs MAVLink 2.0：版本差异、签名机制、兼容性处理
做无人机通信的，迟早要面对版本选择的问题。MAVLink 1.0 用了很多年，稳定、简单，但到了实际项目中你会发现——嗯，它有点不够用了。我最早接触 MAVLink 2.0 是在一个多机协同的项目里，当时被包长度限制坑了一把，才下定决心升级。
这一节，咱们就把两个版本掰开揉碎，看看它们到底差在哪，签名怎么用，以及新旧版本怎么共存。
3.1 核心差异：从 8 字节到 12 字节的头部
先看最直观的变化——消息头。
| 字段 | MAVLink 1.0 | MAVLink 2.0 |
|---|---|---|
| 起始标识 | 0xFE | 0xFD |
| 头部长度 | 8 字节 | 12 字节 |
| 消息 ID | 8 位（0-255） | 24 位（0-16777215） |
| 有效载荷 | 最大 255 字节 | 最大 255 字节（可扩展） |
| 签名支持 | 无 | 可选（13 字节签名） |
| 兼容性标志 | 无 | 2 字节（incompat/compat） |
说白了，MAVLink 2.0 最大的改进就是消息 ID 从 8 位扩展到了 24 位。这意味着什么？你想想看，1.0 最多只能定义 256 种消息类型，对于复杂的无人机系统来说，根本不够用。我在一个农业植保项目里，光自定义传感器数据就占了十几个 ID，再加上标准消息，差点撞车。
另外，2.0 的头部多了两个标志字节：incompat_flags 和 compat_flags。前者用来标记接收方必须支持的特性（比如签名），后者是可选的兼容性提示。这个设计很聪明——它让协议有了扩展能力，又不会破坏老版本。
3.2 签名机制：给数据上个锁
签名是 MAVLink 2.0 最实用的新增功能。我参与过的一个行业无人机项目，客户要求所有遥控指令必须防篡改，那时候 1.0 根本做不到，只能自己在应用层加校验，麻烦得很。
签名的工作原理：
- 使用 SHA-256 算法，基于共享密钥生成 13 字节签名
- 签名覆盖：头部 + 有效载荷 + CRC + 时间戳 + 链接 ID
- 接收方用相同密钥验证，不匹配则丢弃
签名放在消息末尾，结构如下：
MAVLink 2.0 带签名消息结构：
[起始标识 0xFD] [头部 12 字节] [有效载荷 N 字节] [CRC 2 字节] [签名 13 字节]
签名内容：
- 时间戳（6 字节）：防止重放攻击
- 签名数据（7 字节）：SHA-256 哈希的前 7 字节
这里有个关键点——时间戳。签名里包含了 6 字节的时间戳，精度到 10 微秒。接收方会检查时间戳是否在允许的偏差范围内（默认 1 秒）。我曾经遇到过一个问题：飞控和地面站的时间不同步，导致所有带签名的消息都被丢弃。排查了半天才发现是 RTC 电池没电了。
注意：签名密钥必须安全分发。不要硬编码在代码里，更不要通过无线链路传输。我建议用预共享密钥 + 设备序列号派生，或者通过安全通道（如 HTTPS）下发。
3.3 兼容性处理：新旧版本如何共存
实际项目中，很少能一次性把所有设备都升级到 2.0。你可能会遇到：飞控是 2.0，但老旧的数传模块只支持 1.0；或者地面站升级了，但机载电脑还是老版本。怎么办？
MAVLink 官方推荐的做法是 自动检测 + 透明转换。
3.3.1 自动检测版本
接收方通过起始字节判断版本：
- 收到
0xFE→ MAVLink 1.0 - 收到
0xFD→ MAVLink 2.0
就这么简单。我习惯在协议栈的底层做一个版本嗅探，不需要上层关心。代码大概长这样：
uint8_t detect_mavlink_version(uint8_t first_byte) {
switch (first_byte) {
case 0xFE:
return MAVLINK_VERSION_1;
case 0xFD:
return MAVLINK_VERSION_2;
default:
return MAVLINK_VERSION_UNKNOWN;
}
}
3.3.2 透明转换
如果网络中存在不同版本的节点，需要一个转换网关。转换规则：
- 1.0 → 2.0：添加 2.0 头部，设置兼容标志，消息 ID 直接映射（1.0 的 ID 范围在 2.0 中保留）
- 2.0 → 1.0：检查消息 ID 是否在 0-255 范围内，超出则丢弃或降级；去掉签名和扩展标志
经验之谈：2.0 转 1.0 时，如果消息 ID 大于 255，我通常会把它映射到一个自定义的 1.0 消息 ID，并在数据段里附带原始 ID。虽然有点 hack，但总比丢数据强。
3.4 性能对比：带宽与处理开销
很多人担心 2.0 头部更大、还有签名，会不会影响性能？咱们看一组实测数据：
| 场景 | MAVLink 1.0 | MAVLink 2.0（无签名） | MAVLink 2.0（有签名） |
|---|---|---|---|
| 心跳包（9 字节载荷） | 19 字节 | 23 字节 | 36 字节 |
| GPS 数据（36 字节载荷） | 46 字节 | 50 字节 | 63 字节 |
| 大包（255 字节载荷） | 265 字节 | 269 字节 | 282 字节 |
| CPU 开销（STM32F4） | ~12 µs/包 | ~15 µs/包 | ~45 µs/包（含签名验证） |
可以看到，2.0 的头部开销只多了 4 字节，对于 115200 bps 的链路来说，影响微乎其微。签名确实增加了计算开销，但 45 µs 对于大多数飞控来说完全可以接受。我在 F4 和 H7 上都跑过，没发现明显的延迟问题。
3.5 版本选择建议
说了这么多，到底该用哪个版本？我的建议很简单：
- 新项目一律用 MAVLink 2.0，哪怕暂时不需要签名。扩展性更好，以后不用折腾升级。
- 老项目升级：如果只是简单通信，1.0 够用就别动；如果需要安全认证或自定义消息，果断升 2.0。
- 混合网络：在网关或地面站做版本转换，不要改飞控固件。
一句话总结：MAVLink 2.0 不是颠覆性的重写，而是在 1.0 基础上做了合理的扩展。签名是锦上添花，24 位消息 ID 才是刚需。
3.6 核心逻辑框架图
下面这张图展示了两个版本的结构差异和兼容处理流程：
从图上可以清楚看到：两个版本的结构差异主要在头部长度和签名支持上。兼容处理层负责在它们之间做透明转换，而签名机制是 2.0 独有的安全增强。
3.7 避坑指南
最后分享几个我踩过的坑：
- 签名时间戳溢出：6 字节时间戳从 2015 年开始计数，能用到 36812 年，但如果你用 32 位单片机，注意别把时间戳截断了。
- 混合版本中的 CRC 冲突：1.0 和 2.0 的 CRC 算法不同，转换时一定要重新计算，不能直接复制。
- 签名密钥更新：不要在飞行中更新密钥。我曾经试过，结果所有节点都失联了，差点炸机。
重要：如果你在现有 1.0 网络上引入 2.0 节点，务必先在测试环境验证兼容性。我见过有人直接在生产环境升级，结果地面站收不到心跳，整个机队停飞了半天。
好了，版本差异就聊到这。记住一句话：能用 2.0 就用 2.0，但别为了用而用，搞清楚自己的需求再选。