1. MAVLink协议概述
各位同学好，我是老周。做无人机通信这行十几年了，MAVLink 是我打交道最多的协议，没有之一。今天咱们就来聊聊这个协议到底是个什么东西，它从哪来，能干什么。
说白了，MAVLink 就是无人机世界里的“普通话”。飞控、地面站、机载电脑之间要说话，总得有个统一的语言吧？MAVLink 就是干这个的。
核心定义：MAVLink（Micro Air Vehicle Link）是一种轻量级的、用于微型飞行器的通信协议。它定义了消息格式、数据结构和通信规则，让不同厂商的硬件和软件能够互相理解。
1.1 MAVLink的起源与发展
MAVLink 最早是 2009 年由苏黎世联邦理工学院的 Lorenz Meier 发起的。那时候无人机还叫“四轴飞行器”，大家各玩各的，协议五花八门。我记得当时做项目，换个飞控就得重写通信代码，烦得很。
Lorenz 当时在做一个叫 PIXHAWK 的项目，需要一个轻量、高效的通信协议。于是 MAVLink 就诞生了。最初只是 PIXHAWK 的内部协议，后来因为太好用，慢慢被整个社区接受了。
发展历程其实挺清晰的：
- 2009年：MAVLink v1 发布，只有 8 字节的消息头，非常精简
- 2013年：随着 PIXHAWK 开源，MAVLink 开始被广泛采用
- 2017年：MAVLink v2 发布，解决了 v1 的一些痛点
- 现在：几乎所有的开源飞控（PX4、ArduPilot）都默认使用 MAVLink v2
为什么会发展这么快？你想想看，一个协议能同时被飞控、地面站、机载电脑、甚至仿真环境使用，生态效应就起来了。
1.2 MAVLink在无人机生态中的地位
MAVLink 在无人机生态里的地位，我觉得可以用一句话概括：它是开源无人机世界的“事实标准”。
咱们来看看它到底覆盖了哪些东西：
| 生态角色 | 典型产品/项目 | MAVLink的作用 |
|---|---|---|
| 飞控固件 | PX4、ArduPilot | 飞控内部任务调度、外设通信 |
| 地面站软件 | QGroundControl、Mission Planner | 遥测数据显示、指令下发 |
| 机载计算机 | 树莓派、NVIDIA Jetson | 视觉处理、高级任务控制 |
| 仿真环境 | Gazebo、AirSim | 硬件在环仿真、软件在环仿真 |
| 配件设备 | 数传模块、RTK GPS | 参数配置、状态上报 |
我在项目中遇到过最典型的场景：飞控通过串口发 MAVLink 消息给机载电脑，机载电脑处理完图像识别后，再通过 MAVLink 把控制指令发回飞控。整个过程，全靠 MAVLink 在中间搭桥。
个人经验：如果你做无人机相关开发，MAVLink 是绕不开的。哪怕你用大疆的 SDK，底层很多概念也是从 MAVLink 衍生出来的。早点吃透，后面省很多事。
1.3 MAVLink v1与v2的区别
很多新手会问：v1 和 v2 到底差在哪？我直接说结论：v2 解决了 v1 的几个硬伤，但兼容性做得很好。
咱们直接看对比表：
| 对比项 | MAVLink v1 | MAVLink v2 |
|---|---|---|
| 消息头长度 | 8 字节 | 12 字节 |
| 消息ID范围 | 0-255（1字节） | 0-16777215（3字节） |
| 目标系统/组件 | 不支持 | 支持（2字节） |
| 签名机制 | 无 | 可选（13字节签名） |
| 兼容性 | - | 可自动检测并回退到v1 |
几个关键点我展开说说：
- 消息ID扩展：v1 只有 256 个消息ID，社区发展起来后根本不够用。v2 直接扩展到 1600 多万个，想怎么定义都行。
- 目标寻址：v1 发消息是广播式的，所有设备都能收到。v2 加了目标系统ID和目标组件ID，可以精确控制消息发给谁。这个在复杂系统里特别有用。
- 签名机制：v1 没有任何安全措施，谁都能伪造消息。v2 可选加签名，虽然会增加 13 字节开销，但在安全敏感场景下是必须的。
避坑指南：我曾经在一个项目里直接用了 v2 的消息格式，结果老款数传模块只支持 v1，死活不通。后来发现 v2 协议里有个 MAV_PROTOCOL_CAPABILITY 标志位，可以协商版本。建议新项目直接上 v2，但要做好兼容性检测。
1.4 MAVLink的典型应用场景
咱们来看看 MAVLink 在实际项目中是怎么用的。我挑三个最常见的场景说：
飞控内部通信
飞控是 MAVLink 的核心使用者。PX4 和 ArduPilot 内部都用 MAVLink 来调度任务、处理传感器数据、控制执行器。飞控通过串口或 USB 把姿态、位置、电池状态等信息打包成 MAVLink 消息发出去。
举个例子，飞控每秒会发几十次 HEARTBEAT 消息，告诉地面站“我还活着”。同时还会发 ATTITUDE、GLOBAL_POSITION_INT 等消息，报告当前状态。
地面站软件
地面站是 MAVLink 消息的“消费者”。QGroundControl 或 Mission Planner 收到飞控发来的消息后，解析出数据，显示在界面上。同时，地面站也会发 MAVLink 指令给飞控，比如“起飞”、“降落”、“改变航点”。
我记得有一次调试，地面站显示的高度和实际高度差了 10 米。查了半天，发现是飞控发的 GLOBAL_POSITION_INT 消息里，高度单位是毫米，地面站却当厘米解析了。这种坑，只有亲手调过才知道。
机载计算机
这是 MAVLink 最灵活的应用场景。机载电脑（比如树莓派）通过串口或 UDP 和飞控通信，接收飞控的状态数据，同时发送控制指令。
我做过一个项目，机载电脑跑着 YOLO 做目标检测。检测到目标后，通过 MAVLink 的 SET_POSITION_TARGET_LOCAL_NED 消息，告诉飞控飞到目标位置。整个过程，MAVLink 就是那个“翻译官”。
下面这张图，是我自己总结的 MAVLink 在典型无人机系统中的通信架构：
从这张图可以看出来，MAVLink 就像一条“数据高速公路”，把飞控、地面站、机载电脑连在一起。每个节点既可以是消息的发送者，也可以是接收者，甚至同时扮演两个角色。
我的建议：刚开始学 MAVLink，不要急着看协议细节。先搭一个最简单的环境：飞控（仿真也行）+ 地面站，看看消息是怎么收发的。等理解了“消息”这个概念，再深入源码会轻松很多。
好了，第一章的内容就到这里。MAVLink 的起源、地位、版本差异和应用场景，咱们都过了一遍。这些东西是后面所有章节的基础，尤其是 v1 和 v2 的区别，后面讲消息格式和通信流程时会反复用到。