1. 课程导入
各位同学好，我是老周。做无人机飞控系统有些年头了，今天咱们聊聊MAVLink——这个在无人机圈子里几乎人手一份的通信协议。
说实话，我刚入行那会儿，MAVLink还是个刚冒头的小众协议。那时候大家各玩各的，飞控和地面站之间通信全靠私有协议，换个地面站就得重写驱动。后来MAVLink慢慢成了事实标准，我才算从这种噩梦里解脱出来。
1.1 MAVLink的起源与发展
MAVLink最早是2009年由苏黎世联邦理工学院的Lorenz Meier搞出来的。他当时在做PIXHAWK项目，需要一套轻量级的通信协议来连接飞控、地面站和外设。
为什么叫MAVLink？全称是Micro Air Vehicle Link，说白了就是「微型飞行器链路」。名字里带个「Micro」，说明它从一开始就奔着轻量化去的。
我印象很深，2012年我第一次在项目里用MAVLink v1.0，整个协议栈才几百行C代码，编译完不到2KB。这在当时资源受限的STM32F1上简直是救命稻草。
发展历程大致是这样的：
- 2009年：MAVLink v1.0诞生，随PIXHAWK开源
- 2013年：被ArduPilot社区采用，成为主流飞控协议
- 2017年：MAVLink v2.0发布，引入签名、扩展帧等特性
- 2020年至今：成为无人机行业事实标准，被ISO 21805采纳
核心认知：MAVLink不是OSI模型里的完整协议栈，它只覆盖应用层和部分传输层。底层走串口、UDP、TCP还是蓝牙，它不管。这种设计让它极其灵活。
1.2 MAVLink v1.0 vs v2.0 核心差异
很多新手问我：「老周，现在该用v1还是v2？」我的回答永远是：能用v2就别用v1。除非你还在维护十年前的硬件。
咱们直接看对比表：
| 特性 | MAVLink v1.0 | MAVLink v2.0 |
|---|---|---|
| 帧头长度 | 6字节 | 10-14字节 |
| 消息ID范围 | 0-255（1字节） | 0-16777215（3字节） |
| 有效载荷 | 最大255字节 | 最大255字节 |
| 消息签名 | 不支持 | 支持（13字节签名） |
| 目标系统/组件 | 固定字段 | 可选字段 |
| 兼容性标志 | 无 | 有（2字节标志位） |
v2.0最大的改进是什么？我个人觉得是消息签名。你想想看，无人机在天上飞，如果有人伪造地面站指令，后果不堪设想。v1.0完全没有防伪机制，v2.0加入了SHA-256签名，虽然增加了13字节开销，但安全性上了个大台阶。
还有一个容易被忽略的点：兼容性标志。v2.0帧头里有2字节的标志位，告诉接收端「我这个消息用了哪些扩展特性」。如果接收端不支持，可以直接忽略扩展部分，不会解析出错。这种向前兼容的设计，我在实际项目中深有体会——太重要了。
避坑指南：我曾经在一个项目中，飞控固件升级到了v2.0，但地面站还是v1.0的库。结果地面站收到v2.0帧头时，把扩展字段当成了有效载荷，解析出一堆乱码。后来我强制飞控在握手阶段检测地面站版本，不匹配就降级到v1.0。记住：v2.0不兼容v1.0的帧格式，必须做版本协商。
1.3 MAVLink在无人机生态中的角色
MAVLink在无人机生态里到底扮演什么角色？我用一张图来说明：
从这张图能看出来，MAVLink是整个无人机系统的通信中枢。飞控把姿态、位置、电池状态通过MAVLink发给地面站；地面站把航线、指令通过MAVLink发给飞控；机载计算机通过MAVLink获取传感器数据，再通过MAVLink下发控制指令；GPS、数传这些外设也通过MAVLink接入系统。
说白了，没有MAVLink，这些设备之间就得各自定义私有协议，系统复杂度会指数级上升。我见过一些工业级无人机项目，硬要自己搞一套通信协议，结果光协议文档就写了200多页，最后维护成本高得吓人。
我的建议：除非你有极其特殊的性能要求（比如微秒级实时控制），否则别自己造轮子。MAVLink已经经过十几年的实战检验，支持200多种标准消息类型，覆盖了飞控、电池、GPS、摄像头、舵机等几乎所有无人机场景。直接用，省心。
1.4 本章小结
这一章咱们把MAVLink的来龙去脉理清楚了：
- 它诞生于2009年，从PIXHAWK项目里长出来
- v2.0相比v1.0，核心改进是消息签名、扩展消息ID和兼容性标志
- 在无人机生态里，它是连接飞控、地面站、机载计算机和外设的通用语言