1. MAVLink协议概述：从起源到生态地位

大家好，我是这门课的主讲人。今天咱们聊聊MAVLink——这个在无人机圈子里几乎无人不知的通信协议。

我第一次接触MAVLink是在2015年，当时在做一个四旋翼的飞控二次开发。说实话，那时候我对协议栈的理解还很浅，踩了不少坑。后来慢慢摸透了它的设计哲学，才觉得这东西确实精巧。

1.1 MAVLink的起源：一个开源项目的通信需求

MAVLink全称是Micro Air Vehicle Link，微小型飞行器链路协议。它诞生于2009年，由苏黎世联邦理工学院的Lorenz Meier在PX4项目早期开发。

当时的情况是这样的：飞控需要和地面站通信，但串口带宽有限，数据包必须足够轻量。Lorenz设计了一套基于C语言结构体的二进制协议，每个消息都紧凑到极致。嗯，说白了，就是要在有限的带宽里塞进尽可能多的信息。

我记得第一次看MAVLink的源码时，被它的消息定义方式惊艳到了——用XML文件描述消息结构，然后自动生成C代码。这种思路在2009年算是相当超前了。

1.2 版本演进：v1.0 vs v2.0

MAVLink目前有两个主流版本：v1.0和v2.0。我建议你直接学v2.0，但也要理解v1.0，因为很多老设备还在用。

为什么会推出v2.0？说白了，v1.0的消息ID只有8位，最多256种消息。早期够用，但后来PX4、ArduPilot生态越来越庞大，256个ID根本不够分。v2.0把消息ID扩展到24位，支持超过1600万种消息。

特性	MAVLink v1.0	MAVLink v2.0
消息ID宽度	8位（0-255）	24位（0-16777215）
最小消息长度	8字节	12字节
签名支持	无	可选（SHA-256）
兼容性	基础	向后兼容v1.0
目标系统/组件	无	支持（8位+8位）

我在项目中遇到过一个问题：用v2.0的飞控和v1.0的老地面站通信，结果地面站死活不认数据。后来发现是v2.0的起始标志位（0xFD）和v1.0（0xFE）不同，地面站直接丢弃了。所以做兼容性测试时，一定要确认两端的版本。

1.3 协议栈结构：从物理层到应用层

MAVLink的协议栈其实不复杂，你想想看，它主要分三层：

• 物理层：串口（UART）、UDP、TCP、蓝牙等
• 链路层：帧封装、CRC校验、消息分片重组
• 应用层：消息定义、命令系统、参数协议

我个人习惯把MAVLink的帧结构画成一张图，这样理解起来更直观。下面是我自己整理的MAVLink v2.0帧结构：

你想想看，每个字段都有它的设计意图：

• STX：起始标志，v1.0是0xFE，v2.0是0xFD。接收端靠它判断版本。
• LEN：载荷长度，最大255字节。我一般建议载荷控制在64字节以内，超过的话在低带宽链路上容易丢包。
• INC/CMP：v2.0新增的标志位。INC表示不兼容特性（比如签名），CMP表示兼容特性。接收端可以根据这两个标志决定是否处理。
• SEQ：序列号，用于检测丢包。我在做链路质量分析时，就是靠统计SEQ的跳变来估算丢包率的。
• SYS/COMP：系统ID和组件ID。一个无人机可以有多个组件（飞控、相机、机械臂），靠这两个字段区分。
• MSG ID：消息ID，v2.0扩展到24位。常用的消息ID有HEARTBEAT（0）、SYS_STATUS（1）、GPS_RAW_INT（24）等。
• CRC：16位CRC校验，覆盖整个帧（不含STX）。我曾经遇到过CRC计算错误导致通信中断的问题，后来发现是CRC种子没对齐。

1.4 在无人机生态中的地位

MAVLink现在几乎是无人机通信的事实标准。你打开任何一个开源飞控项目——PX4、ArduPilot、Cleanflight——底层通信清一色都是MAVLink。

为什么它能占据这个位置？我总结了几点：

1. 开源免费：BSD许可证，商用无限制。很多公司直接拿它做产品原型。
2. 生态庞大：地面站（QGroundControl、Mission Planner）、机载计算机（ROS、DroneKit）、仿真环境（Gazebo、AirSim）都原生支持。
3. 扩展灵活：你可以定义自己的消息类型。我在做农业无人机项目时，就自定义了喷洒流量控制消息，直接嵌入MAVLink协议栈。
4. 跨语言支持：官方生成工具支持C、C++、Python、Java、JavaScript等。我个人最常用Python做原型验证，C做嵌入式部署。