2. MAVLink 1.0 vs 2.0：版本差异、签名机制、兼容性策略

聊到MAVLink，绕不开的就是版本问题。我记得刚入行那会儿，项目里用的还是MAVLink 1.0，那时候觉得这协议挺够用的。直到有一次做长距离无人机巡检，遇到了严重的丢包和篡改问题……嗯，从那以后我才真正开始研究2.0。

说白了，MAVLink 2.0不是推翻重来，而是在1.0的基础上做了「精准升级」。我个人的习惯是：新项目直接上2.0，老项目迁移时做好兼容层。今天咱们就把这两个版本的差异掰开揉碎了讲清楚。

2.1 帧结构差异：一眼看出区别

先看最直观的——帧头。MAVLink 1.0的帧头是 0xFE，2.0改成了 0xFD。你可能会问：就改个字节？没那么简单。

我给大家列个对比表，一目了然：

看到没？2.0的帧头从8字节扩展到了12字节（不含签名）。多出来的4个字节，就是「不兼容标志」和「兼容标志」，以及扩展的消息ID。我在项目中遇到过一个问题：用1.0的解析器去读2.0的包，结果把兼容标志当成了载荷长度……那画面太美不敢看。

2.2 签名机制：安全性的核心升级

这是2.0最让我心动的特性。1.0时代，数据包在无线链路上是「裸奔」的。你想想看，如果有人恶意篡改GPS坐标，无人机可能直接飞丢。我曾经在测试中模拟过这种攻击——往1.0的包里塞假数据，飞控照单全收，吓得我赶紧把签名加上。

具体流程是这样的：

// 伪代码：MAVLink 2.0 签名生成
uint8_t secret_key[32];  // 共享密钥
uint64_t timestamp;      // 当前时间戳

// 1. 构建签名缓冲区
uint8_t buffer[packet_len + 7 + 32];
memcpy(buffer, packet_header, packet_len);
memcpy(buffer + packet_len, &timestamp, 7);
memcpy(buffer + packet_len + 7, secret_key, 32);

// 2. 计算SHA-256
uint8_t hash[32];
sha256(buffer, sizeof(buffer), hash);

// 3. 取前6字节作为签名
memcpy(packet_signature, hash, 6);

2.3 兼容性策略：让1.0和2.0和平共处

实际项目中，你不可能一夜之间把所有设备都升级到2.0。所以兼容性策略很重要。MAVLink官方给出的方案很聪明——自动检测 + 降级。

具体做法：

1. 发送端：先发一个2.0的包，如果收到NACK或者超时，自动降级到1.0
2. 接收端：根据帧头（0xFE或0xFD）自动选择解析器
3. 混合模式：同一个链路上可以同时存在1.0和2.0的包

我建议在飞控固件里这样实现：

// C语言示例：兼容性处理
typedef enum {
    MAVLINK_PARSE_STATE_UNINIT,
    MAVLINK_PARSE_STATE_IDLE,
    MAVLINK_PARSE_STATE_GOT_STX,
    // ...
} mavlink_parse_state_t;

mavlink_parse_state_t parse_state = MAVLINK_PARSE_STATE_IDLE;

uint8_t parse_byte(uint8_t c) {
    switch (parse_state) {
        case MAVLINK_PARSE_STATE_IDLE:
            if (c == 0xFE) {
                // 进入1.0解析模式
                version = 1;
                parse_state = MAVLINK_PARSE_STATE_GOT_STX;
            } else if (c == 0xFD) {
                // 进入2.0解析模式
                version = 2;
                parse_state = MAVLINK_PARSE_STATE_GOT_STX;
            }
            break;
        // ... 后续解析逻辑
    }
}

2.4 消息ID扩展：从256到1600万

1.0的消息ID只有1字节，最多256种消息。对于简单的飞控+地面站来说够用。但现在的无人机系统越来越复杂——视觉定位、激光雷达、多机协同……256种消息根本不够用。

2.0把消息ID扩展到了3字节，支持16777216种消息。你想想看，就算每个传感器厂商定义1000种消息，也能容纳16000个厂商。我参与的一个项目里，光自定义消息就用了200多个，要是还在1.0时代，早就撞ID了。

消息ID的分配策略：

• 0-255：保留给MAVLink 1.0兼容消息
• 256-65535：官方扩展消息
• 65536-16777215：用户自定义消息

我个人习惯把自定义消息ID放在 0x10000 以上，这样既不会和官方冲突，也方便后期维护。

2.5 实际项目中的选择建议

说了这么多，到底该用哪个版本？我给大家一个参考：

最后说一句：如果你正在设计新产品，别犹豫，直接上MAVLink 2.0。签名机制带来的安全性提升，远大于那多出来的几个字节开销。毕竟，无人机在天上飞，安全永远是第一位的。