3、MAVLink协议入门：MAVLink简介、消息结构与微服务、常见消息类型
3.1 MAVLink是什么？—— 无人机界的“普通话”
各位同学好。今天我们来聊聊MAVLink协议。说实话，我第一次接触MAVLink是在2015年做开源飞控移植的时候。当时看着一堆十六进制数据在串口线上跳来跳去，心里直犯嘀咕：这玩意儿到底怎么把飞控和地面站连起来的？
后来我明白了。MAVLink，全称Micro Air Vehicle Link，说白了就是无人机系统里的一套“普通话”。它定义了飞控、地面站、摄像头、机械臂等各个模块之间怎么打招呼、怎么传数据。你想想看，如果没有一个统一的标准，大疆的飞控和你的地面站软件根本没法对话——就像我说中文，你说西班牙语，谁也听不懂谁。
MAVLink目前有两个主流版本：v1.0和v2.0。我个人习惯在项目里直接用v2.0，因为它的扩展性更好。v1.0的消息ID只有8位，最多256种消息；v2.0扩展到了24位，理论上可以定义1600多万种消息。嗯，这个数字听起来有点夸张，但实际项目中确实用得上。
核心要点：MAVLink是一种轻量级的、面向消息的通信协议。它专门为无人机等资源受限的嵌入式系统设计。一个典型的MAVLink数据包只有8-28字节，非常适合在低带宽、高延迟的无线链路上传输。
3.2 消息结构——拆开MAVLink数据包看看
我们先来看一个MAVLink v2.0的数据包长什么样。我习惯把它想象成一个“信封”：外面是固定的包头，里面是可变的内容。
MAVLink v2.0 数据包结构：
+------+------+------+------+------+------+------+------+------+------+
| STX | LEN | INC | CMP | SEQ | SYS | COMP | MSG ID (3字节) | PAYLOAD |
| 0xFD | | FLG | FLG | | ID | ID | | |
+------+------+------+------+------+------+------+------+------+------+
| PAYLOAD (续) | CRC1 | CRC2 |
+---------------+------+------+
各字段说明：
- STX: 起始标志，v2.0固定为0xFD
- LEN: 负载长度（1字节）
- INC FLG: 不兼容标志（1字节）
- CMP FLG: 兼容标志（1字节）
- SEQ: 序列号（1字节），用于丢包检测
- SYS ID: 系统ID（1字节），比如飞控是1，地面站是255
- COMP ID: 组件ID（1字节），比如飞控的自动驾驶仪是1，GPS是5
- MSG ID: 消息ID（3字节），标识消息类型
- PAYLOAD: 负载数据（最多255字节）
- CRC: 16位循环冗余校验（2字节）
这里我要特别强调一下SYS ID和COMP ID。我在一个项目中遇到过这样的坑：地面站同时连接了两架无人机，结果因为SYS ID都设成了1，数据全混在一起了。后来我规定每架无人机必须分配不同的SYS ID，地面站用255，这才解决了问题。
个人经验：建议在项目初期就规划好SYS ID分配方案。比如：飞控=1，地面站=255，摄像头=2，机械臂=3。这样后期扩展时不会乱。
3.3 微服务机制——MAVLink的“插件化”设计
MAVLink v2.0引入了一个很有意思的概念：微服务。说白了，就是把一些常用的功能封装成独立的“服务模块”。比如参数读写、航点上传、任务控制等，每个服务都有自己的一套消息交互流程。
为什么会这样设计？你想想看，如果所有功能都塞进一个巨大的协议里，那维护起来得多痛苦。微服务的好处是：你可以按需加载。比如你的无人机不需要摄像头，那就不实现摄像头相关的微服务，代码量能省不少。
常见的微服务包括：
- 参数协议（PARAM）：读写飞控参数，比如PID系数、传感器校准值
- 任务协议（MISSION）：上传/下载航点任务
- 命令协议（COMMAND）：发送即时指令，比如“起飞”、“降落”、“返航”
- GPS漂移协议（GPS_GLOBAL_ORIGIN）：设置GPS原点坐标
每个微服务通常由一对请求-响应消息组成。比如参数协议：地面站发一个PARAM_REQUEST_LIST，飞控就回复一串PARAM_VALUE。这种设计模式，我在做工业级无人机地面站时深有体会——它让代码结构非常清晰，调试起来也方便。
避坑指南：我曾经在实现任务协议时，忽略了飞控的“任务接受”确认消息。结果地面站以为航点上传成功了，飞控其实根本没收到。后来我加了一个超时重传机制，才彻底解决了这个问题。记住：MAVLink的微服务大多需要双向确认，别偷懒。
3.4 常见消息类型——你一定会用到的那些
MAVLink定义了上百种消息类型，但实际项目中常用的也就二三十种。我整理了一份“必知消息清单”，供大家参考：
| 消息名称 | 消息ID | 用途 | 频率建议 |
|---|---|---|---|
| HEARTBEAT | 0 | 心跳包，表明设备在线 | 1Hz |
| SYS_STATUS | 1 | 系统状态，电池电压、传感器健康度 | 1-5Hz |
| GPS_RAW_INT | 24 | GPS原始数据，经纬度、海拔、速度 | 5-10Hz |
| ATTITUDE | 30 | 姿态数据，横滚、俯仰、偏航角 | 10-50Hz |
| LOCAL_POSITION_NED | 32 | 本地坐标系位置（北东地） | 10-50Hz |
| RC_CHANNELS | 65 | 遥控器通道值 | 10Hz |
| COMMAND_LONG | 76 | 发送长命令，如起飞、降落 | 按需 |
| PARAM_VALUE | 22 | 参数值响应 | 按需 |
这里我重点说说HEARTBEAT。它是最基础的消息，每个MAVLink设备都必须发送。我在调试一个新飞控时，第一件事就是看HEARTBEAT能不能收到。如果连心跳都没有，那后面的所有消息都不用看了——肯定是连接或者配置有问题。
ATTITUDE消息也很关键。它包含了飞行器的横滚、俯仰、偏航三个角度。我记得有一次做飞行测试，地面站显示的姿态数据一直在抖动，后来发现是飞控的IMU采样率设置得太低，导致姿态解算跟不上。把采样率从100Hz调到200Hz后，数据就平滑了。
实战建议：刚开始做MAVLink开发时，不要试图一次性实现所有消息。我建议先实现HEARTBEAT、SYS_STATUS、ATTITUDE这三个，确保基本通信链路通了，再逐步添加其他消息。这样调试起来压力小很多。
3.5 消息频率与带宽——别把无线链路撑爆了
很多新手容易犯一个错误：把所有消息都设成最高频率发送。结果无线链路直接堵死，丢包率飙升。我见过最夸张的一个案例，有人把ATTITUDE设成了200Hz，GPS数据也设成了50Hz，再加上其他杂七杂八的消息，整个链路带宽被吃掉了80%以上。
实际上，不同的消息对实时性要求不一样。我的经验是：
- 姿态数据（ATTITUDE）：10-50Hz就够了，飞控内部控制环路通常跑在200-400Hz，但地面站显示不需要那么快
- GPS数据：5-10Hz，GPS本身更新率也就10Hz左右，设高了也没用
- 心跳包：1Hz，太频繁浪费带宽，太慢又检测不到掉线
- 参数读写：按需发送，不要周期性广播
你可以算一笔账：一个ATTITUDE消息大约28字节（含包头），如果50Hz发送，每秒就是1400字节。再加上其他消息，总带宽大概在5-10KB/s。对于常见的915MHz数传电台（空中速率通常几十kbps），这个负载是完全可以接受的。但如果你用蓝牙或者Wi-Fi，带宽就更充裕了。
小技巧：我习惯在地面站软件里加一个“带宽监控”功能，实时显示当前MAVLink链路的利用率。一旦超过50%，我就会考虑降低某些消息的频率。这个功能在调试阶段特别有用。
3.6 总结与下一步
好了，这一章我们聊了MAVLink的基本概念、数据包结构、微服务机制，以及几种最常用的消息类型。说白了，MAVLink就是一套让无人机各个部件能“好好说话”的规则。你掌握了这些基础，后面学消息编解码、实现自定义消息就会轻松很多。
下一章，我会带大家手写一个MAVLink消息解析器，从裸数据流里把消息一个个拆出来。嗯，那才是真正考验功底的地方。咱们下节课见。