📚 课程目录第3章链路性能核心指标

3. 链路性能核心指标

MAVLink v2.0 不是简单的版本号升级。说实话，v1.0 在早期无人机项目里够用，但随着任务复杂度上升，它的局限性越来越明显。我记得第一次在集群编队项目里遇到消息冲突时，debug 了整整两天，最后发现是 v1.0 的 payload 太小，不得不拆包发送，结果丢包率飙升。

v2.0 的出现，说白了就是补上了这些坑。下面我挑几个最实用的新特性，结合实战经验跟你聊聊。

3.1 签名机制：给消息上把锁

无人机通信最怕什么？被篡改。v1.0 没有签名，任何设备都能伪造消息。我在一个农业植保项目里就遇到过——有人用地面站模拟了“紧急降落”指令，差点把飞机摔了。

v2.0 引入了基于 SHA-256 的签名机制。每个消息帧末尾附加 13 字节的签名信息：

// v2.0 签名结构
typedef struct {
    uint8_t magic;          // 签名标记，固定 0xFD
    uint64_t timestamp;     // 时间戳，防重放攻击
    uint8_t signature[6];   // SHA-256 截断签名
} mavlink_signature_t;

签名流程其实不复杂：

发送方用 32 字节的共享密钥对消息内容 + 时间戳做 HMAC
接收方用同样的密钥验证签名
时间戳窗口默认 3 秒，超时直接丢弃

我的习惯：在机载计算机和地面站之间启用签名，但数传链路带宽有限时，我会把时间戳窗口放宽到 5 秒。太严格的话，信号延迟稍大就会误杀合法消息。

3.2 兼容模式：新老设备混搭

升级最怕什么？老设备不兼容。v2.0 设计了一个巧妙的兼容模式：

自动检测：接收方通过帧起始字节判断版本——0xFE 是 v1.0，0xFD 是 v2.0
透明转发：v2.0 网关可以原样转发 v1.0 消息，不做转换
降级策略：如果链路中检测到 v1.0 节点，自动切换到 v1.0 帧格式

我在一个混合机队项目里用过这个特性。机队里有 3 架老飞控（v1.0）和 5 架新飞控（v2.0），地面站是 v2.0。只要在网关配置里打开 MAVLINK_COMPAT_MODE=1，所有消息自动降级为 v1.0 格式。代价是 payload 变小，但至少不用换硬件。

注意：兼容模式下签名机制自动失效。如果你需要安全通信，必须确保全链路都是 v2.0 设备。

3.3 扩展负载：从 255 到 512 字节

v1.0 的 payload 上限是 255 字节。对于简单的 GPS 数据、姿态信息够用，但一旦涉及高分辨率图像、点云数据或者自定义调试信息，就得拆包。拆包带来的问题很明显：

消息数量翻倍，带宽占用增加
接收方需要重组，增加 CPU 负载
丢一个包，整条消息作废

v2.0 把 payload 上限提升到 512 字节。怎么做到的？看帧结构对比：

字段	v1.0	v2.0
起始字节	0xFE (1 字节)	0xFD (1 字节)
payload 长度	1 字节 (0-255)	2 字节 (0-512)
兼容标志	无	1 字节
签名	无	13 字节 (可选)
总帧头	6 字节	10 字节

你想想看，多出来的 257 字节能干什么？

一次传输完整的 200 个航点数据
打包 10 帧 IMU 原始数据，减少发送频率
嵌入自定义调试结构体，不用再搞二次封装

    实战建议：别盲目用满 512 字节。我测试过，在 115200 bps 的链路上，单包超过 400 字节后，重传率会明显上升。建议根据链路质量动态调整 payload 大小。

3.4 目标系统/组件过滤：精准投递

v1.0 的消息是广播式的。所有设备收到所有消息，然后自己判断要不要处理。这在多无人机场景下简直是灾难——每架飞机都在解析别人的数据，CPU 空转。

v2.0 在帧头里增加了两个字段：

target_system (1 字节)：目标系统 ID，0 表示广播
target_component (1 字节)：目标组件 ID，0 表示广播

接收方收到消息后，先检查这两个字段。不匹配的直接丢弃，不进入解析流程。我在一个 10 机编队项目里做过对比：

v1.0 模式下，每架飞机每秒处理约 200 条无关消息
v2.0 过滤后，每架飞机只处理约 30 条相关消息
CPU 占用率从 45% 降到 8%

我的习惯：地面站广播控制指令时用 target_system=0，但机间通信一定要指定目标 ID。我曾经因为忘记设置 target_system，导致一架飞机执行了本该发给另一架飞机的降落指令——还好高度够，没出事。

3.5 消息裁剪：按需定制

v2.0 允许你定义消息的“裁剪版本”。什么意思呢？比如 GLOBAL_POSITION_INT 消息包含 12 个字段，但你只需要经纬度和高度。你可以定义一个裁剪版本，只发送这 3 个字段。

裁剪通过兼容标志位实现：

// 兼容标志位定义
#define MAVLINK_MSG_FLAG_SIGN     0x01  // 启用签名
#define MAVLINK_MSG_FLAG_TRIM     0x02  // 启用裁剪
#define MAVLINK_MSG_FLAG_RES1     0x04  // 保留位
#define MAVLINK_MSG_FLAG_RES2     0x08  // 保留位

裁剪的好处很明显：

减少带宽占用，适合低速数传链路
降低接收方解析开销
可以针对不同接收方定制消息内容

但要注意，裁剪后的消息不能被标准解析器识别。你需要确保接收方也支持裁剪协议。我在一个遥测链路只有 9600 bps 的项目里用过裁剪，把 SCALED_IMU 从 22 字节裁到 8 字节，刷新率从 5 Hz 提升到 20 Hz。

避坑指南：我曾经在裁剪消息时漏掉了校验字段，结果接收方解析出乱码。记住，裁剪只能去掉你确认不需要的字段，关键字段（如时间戳、坐标系标识）必须保留。

3.6 知识体系总览

下面这张图把 v2.0 的核心特性串起来了。你可以看到，每个特性都对应一个具体的性能优化点：

从这张图你能看出来，v2.0 的每个特性都不是孤立的。签名和裁剪可以组合使用，兼容模式和扩展负载也能共存。我在实际项目中，通常根据链路质量和安全需求，选择 2-3 个特性组合使用。