4、QGC架构解析：从整体到细节
QGC（QGroundControl）这个项目，我第一次接触时其实有点懵。代码量不小，目录结构也复杂。但摸清楚它的骨架之后，你会发现它设计得相当清晰。说白了，它就是一个典型的「三层架构」：通信层在最底下干活，业务逻辑层在中间做决策，UI层在最上面跟用户打交道。
嗯，我们先从整体架构看起。
4.1 整体架构：三层一总线
QGC的架构可以用一张图说清楚。我个人习惯把它理解成「三层一总线」——三层就是通信层、业务逻辑层、UI层，一总线就是内部的信号/槽总线。
核心架构图：QGC三层结构
你想想看，这种分层的好处是什么？每一层只管自己的事。通信层只管收发数据包，业务逻辑层只管算状态、做决策，UI层只管画界面。改一个层不影响另外两个。我在项目中遇到过好几次，因为换了通信链路（从串口换成4G模块），只需要改通信层的实现，上层代码一行没动。
4.2 Qt与QML技术栈：为什么选这个组合？
QGC选Qt + QML，不是拍脑袋决定的。这里有个历史原因——早期的地面站大多用MFC或者纯C++写界面，改个按钮位置都要重新编译。QGC团队想要一个「界面可以热加载」的方案，QML正好满足。
具体来说，技术栈分两层：
- Qt C++：负责底层逻辑、通信、性能敏感的计算。比如MAVLink协议解析、飞行状态机、参数读写。
- QML：负责界面布局、动画、交互。QML文件是文本格式，改了直接刷新，不用编译。
我的经验：QML和C++的交互通过「上下文属性」和「信号/槽」完成。在C++侧注册一个对象到QML上下文，QML里就能直接调用它的方法和属性。我曾经踩过一个坑——在QML里频繁调用C++方法做大量计算，导致界面卡顿。后来把计算移到C++线程里，只把结果通过信号发给QML，问题就解决了。
这里有个关键点：QML本身不适合做复杂逻辑。它擅长的是「声明式UI」——你描述界面长什么样，Qt自动帮你渲染。但如果你在QML里写循环、做字符串拼接、处理大数据，性能会很难看。
| 技术 | 职责 | 性能特点 | 典型场景 |
|---|---|---|---|
| Qt C++ | 业务逻辑、通信、数据处理 | 高性能，多线程友好 | MAVLink解析、飞行状态机、参数管理 |
| QML | 界面布局、动画、手势交互 | 声明式渲染，GPU加速 | 仪表盘、地图控件、设置面板 |
| Qt Quick | QML的渲染引擎 | 硬件加速，60fps流畅 | 所有QML界面的底层渲染 |
4.3 核心模块拆解：通信层、业务逻辑层、UI层
我们一层一层往下看。
4.3.1 通信层：MAVLink的搬运工
通信层是QGC的「耳朵和嘴巴」。它负责从物理链路（串口、UDP、TCP等）读取字节流，然后按照MAVLink协议解析成结构体。反过来，把要发送的命令打包成MAVLink帧，扔到链路上。
核心类就几个：
- LinkInterface：抽象基类，定义打开、关闭、读写接口。
- SerialLink、UDPLink、TCPLink：具体实现。
- MAVLinkProtocol：负责编解码，校验CRC，处理消息ID映射。
我记得有一次调试一个奇怪的丢包问题。飞机在50米外，QGC时不时收不到心跳。查了半天，发现是串口缓冲区的读取线程优先级太低，被UI线程抢了CPU。后来把读取线程提到实时优先级，问题消失。嗯，通信层的线程模型一定要设计好。
4.3.2 业务逻辑层：大脑所在
这一层是QGC最复杂的部分。它不关心数据从哪来，也不关心界面长什么样，它只做一件事：根据当前状态，决定下一步做什么。
几个关键模块：
- Vehicle：代表一架无人机。管理它的所有状态——位置、姿态、电池、模式、参数。
- MissionManager：任务规划引擎。上传航点、下载任务、计算航线。
- ParameterManager：参数读写缓存。飞机上有几百个参数，不能每次都去读，得有本地缓存。
- GeoFenceManager：地理围栏检测。一旦飞机接近边界，立刻触发保护逻辑。
注意：业务逻辑层最容易出现「状态不一致」的问题。比如飞机已经切到RTL模式，但Vehicle对象里还显示「悬停」。我曾经因为一个信号连接顺序写反了，导致UI显示的模式和实际模式差了2秒。调试这种问题很痛苦，建议在关键状态变更处加日志。
4.3.3 UI层：用户看到的一切
UI层全部用QML实现。主界面是一个StackView，里面压着多个页面：飞行页面、规划页面、设置页面、分析页面。
每个页面又由若干「控件」组成。比如飞行页面里有：
- 人工地平仪（AttitudeIndicator）
- 地图控件（MapControl）
- 状态栏（StatusBar）
- 虚拟摇杆（VirtualJoystick）
UI层通过「属性绑定」自动更新。比如飞机的roll值变了，C++侧发出信号，QML里绑定的属性自动刷新，人工地平仪就跟着转。不需要手动写刷新代码。
4.4 插件机制与扩展开发
QGC的插件机制，说白了就是「留了几个钩子，让你在不改核心代码的前提下加功能」。这个设计很聪明——你想加一个自定义传感器显示，或者对接一个私有协议，不需要fork整个项目。
插件机制分两种：
- 自定义MAVLink消息处理：通过注册消息回调，处理非标准的MAVLink消息。
- 自定义UI插件：在QML里通过Loader动态加载外部QML文件，实现界面扩展。
举个例子。我有个客户用的飞控不是PX4，而是自己写的私有固件，但通信协议基于MAVLink做了扩展。标准QGC不认识那些自定义消息。怎么办？
我在QGC的MAVLinkProtocol里注册了一个自定义消息处理器。当收到消息ID为 0x1F0 的包时，不走默认解析流程，而是调用我写的解析函数。解析结果通过信号发给QML，在界面上显示。整个过程没动QGC一行核心代码。
插件开发核心步骤：
- 继承
MAVLinkProtocol或Vehicle类 - 重写消息处理虚函数
- 在
main.cpp中注册插件实例 - QML侧通过
Loader加载自定义界面
这里有个坑要注意：插件和核心代码运行在同一个进程里，内存是共享的。如果你在插件里写了野指针或者死循环，整个QGC都会挂。我建议插件开发者至少做基本的压力测试，别让一个插件拖垮整个地面站。
嗯，关于插件机制，QGC官方文档写得不算详细。我个人的习惯是直接看源码里的 plugins 目录，里面有几个示例插件，照着抄一遍就懂了。
最后说一句：QGC的架构设计，其实给所有做地面站的人提供了一个很好的参考模板。三层分离、信号/槽解耦、插件扩展——这些思想放到任何嵌入式地面站项目里都适用。你想想看，如果你的项目一开始就按这个思路搭架子，后面加功能、换硬件、改界面，都会轻松很多。