3、MAVLink通信模式：主从模式与点对点模式、消息流控与丢包重传机制、系统ID与组件ID的分配策略
这一章咱们聊聊MAVLink的通信骨架。说白了，就是数据怎么在设备之间跑，丢了怎么办，以及怎么给每个设备起个不重名的「身份证号」。这些概念看着基础，但我在实际项目中踩过的坑，十有八九都跟这几个点有关。
3.1 通信模式：主从 vs 点对点
MAVLink支持两种通信模式。很多人以为只能主从，其实不是。选哪种，取决于你的系统规模。
3.1.1 主从模式（Master-Slave）
这是最常见的模式。地面站（GCS）是主节点，飞控、相机、云台都是从节点。所有消息都经过主节点转发。
核心特征：
- 主节点是唯一的路由中心
- 从节点之间不直接通信
- 适合单地面站 + 多设备的场景
我早期做农业植保机项目时，用的就是主从模式。地面站发指令给飞控，飞控回传状态。简单、稳定，调试也方便。但有一次客户要求两架无人机协同喷洒，主从模式就卡住了——两架飞控没法直接交换位置数据，都得绕到地面站，延迟高得离谱。
3.1.2 点对点模式（Peer-to-Peer）
点对点模式下，任何两个设备都能直接通信。不需要中心节点。
适用场景：
- 多机编队（无人机之间直接交换位置）
- 中继通信（无人机A转发数据给无人机B）
- 分布式传感器网络
你想想看，编队飞行时，如果每架飞机都要先发给地面站再转发，那延迟早就撞上了。点对点模式让飞机之间直接对话，延迟从几十毫秒降到几毫秒。
| 特性 | 主从模式 | 点对点模式 |
|---|---|---|
| 拓扑结构 | 星型 | 网状/全连接 |
| 路由复杂度 | 低（主节点负责） | 高（每个节点需维护路由表） |
| 延迟 | 较高（需转发） | 低（直连） |
| 可靠性 | 依赖主节点 | 无单点故障 |
| 典型场景 | 单机巡检、测绘 | 编队、集群、中继 |
3.2 消息流控与丢包重传机制
无线链路嘛，丢包是家常便饭。MAVLink本身是UDP之上的协议，不保证可靠传输。但我们可以自己加机制。
3.2.1 消息流控
流控的目的是防止发送方太快，把接收方撑死。MAVLink没有内置的滑动窗口，但我们可以用两个土办法：
- 速率限制： 每条消息设置最大发送频率。比如HEARTBEAT最多10Hz，避免信道被心跳占满。
- 确认机制： 关键指令（如ARM/DISARM）需要接收方回复ACK，发送方收到ACK后才发下一条。
注意： 不要对所有消息都用ACK。心跳、姿态这类周期性消息，丢了就丢了，下一帧会补上。只有命令和关键参数才需要确认。
我曾经在一个项目中，把所有消息都加了ACK。结果信道被ACK包占了一半，有效吞吐量反而下降了。后来只对COMMAND_LONG和PARAM_SET做确认，效果立竿见影。
3.2.2 丢包重传机制
丢包重传，说白了就是「没收到就再发一次」。但怎么发、发几次、间隔多久，有讲究。
我常用的策略是这样的：
- 超时重传： 发送后启动定时器，超时未收到ACK则重传。超时时间建议设为RTT的2-3倍。
- 指数退避： 第一次重传等100ms，第二次200ms，第三次400ms……避免网络拥塞时雪上加霜。
- 最大重传次数： 一般设3-5次。超过次数就上报失败，不要死循环。
// 伪代码：带指数退避的重传
int retry_count = 0;
int max_retries = 3;
int base_timeout_ms = 100;
while (retry_count < max_retries) {
send_message(msg);
if (wait_for_ack(timeout_ms)) {
break; // 收到ACK，成功
}
retry_count++;
timeout_ms = base_timeout_ms * (1 << retry_count); // 指数退避
}
if (retry_count == max_retries) {
report_failure("消息发送失败，已重试3次");
}
经验值： 在2.4GHz WiFi链路上，RTT通常在10-30ms。我一般设超时50ms，重试3次，总耗时不超过350ms。用户基本感觉不到延迟。
3.3 系统ID与组件ID的分配策略
这是MAVLink里最容易出问题的地方。系统ID（System ID）标识一个完整的无人机系统，组件ID（Component ID）标识系统内的一个设备。
3.3.1 系统ID分配
每个无人机系统必须有唯一的系统ID。范围是1-255。我建议这样分配：
- 1-100： 地面站、遥控器、基站等地面设备
- 101-200： 无人机飞控
- 201-255： 其他设备（中继、传感器等）
为什么这么分？有一次在集群测试中，地面站和飞控的系统ID都是1，结果地面站发的指令被自己当成飞控的消息处理了，直接触发了紧急降落。从那以后，我强制规定地面站用1，飞控从101开始。
3.3.2 组件ID分配
组件ID标识系统内的具体设备。MAVLink标准定义了一些常用ID：
| 组件ID | 设备类型 | 说明 |
|---|---|---|
| 1 | 飞控（主控制器） | 每个系统必须有一个 |
| 100 | 相机 | 可见光相机 |
| 101 | 云台 | 三轴云台 |
| 154 | 激光雷达 | 测距/避障 |
| 200 | 自定义设备 | 用户自定义 |
嗯，这里要注意：同一个系统内，组件ID不能重复。我见过有人给两个相机都配了ID 100，结果地面站只显示一个相机的画面，另一个完全没反应。
3.3.3 多机系统的ID规划
多机编队时，ID规划要提前想好。我一般用这个方案：
- 系统ID = 编队编号（1, 2, 3...）
- 组件ID = 设备类型（飞控=1, 相机=100, 云台=101...）
举个例子：3架无人机编队，每架带一个相机。
- 无人机1：系统ID=1，飞控组件ID=1，相机组件ID=100
- 无人机2：系统ID=2，飞控组件ID=1，相机组件ID=100
- 无人机3：系统ID=3，飞控组件ID=1，相机组件ID=100
这样地面站通过「系统ID + 组件ID」就能唯一确定每个设备。不会搞混。
核心原则： 系统ID全局唯一，组件ID系统内唯一。两者组合，构成全局唯一标识。
3.4 知识体系总览
下面这张图把本章的核心逻辑串起来了。通信模式决定数据怎么流，流控和重传保证数据不丢，ID分配确保数据找对门。
这张图我每次培训都会拿出来讲。你仔细看，三个模块是并列的，但实际部署时，你得先定模式，再配流控，最后分配ID。顺序错了，后面全乱套。
部署检查清单：
- 确定通信模式（主从还是点对点）
- 配置消息速率限制（关键消息加ACK）
- 规划系统ID和组件ID（写进配置文件）
- 测试丢包重传（模拟丢包环境验证）
好了，这一章的内容就这些。通信模式、流控重传、ID分配，这三个东西看着简单，但真到现场部署时，每一个都能让你折腾半天。记住我踩过的坑，你就能少走弯路。