2. 飞控系统基础
飞控设备驱动调试与日志诊断，必须建立在对飞控系统整体结构的理解之上。飞控（Flight Controller）并不是一块“会飞的单片机”，而是一个由计算核心、传感器、执行机构、通信接口、电源与软件栈共同构成的实时闭环控制系统。驱动层位于硬件与飞控应用之间，是调试时最先接触、也最容易出问题的一层。本节从飞控组成入手，梳理传感器与执行机构、驱动层作用，并对比常见硬件平台与操作系统，为后续驱动调试和日志分析打基础。
一、飞控系统的整体组成
从功能视角看，飞控系统可以划分为五个部分：感知层（IMU、磁力计、气压计、GPS、光流等）、决策层（姿态解算、位置估计、控制律）、执行层（电调、舵机、电机）、通信层（UART、CAN、I2C、SPI、USB、数传、遥控接收机）以及支撑层（电源管理、存储、时钟、看门狗）。驱动层则贯穿感知、执行与通信三部分，负责把寄存器操作封装成飞控应用可调用的统一接口。
下图给出飞控系统的分层结构：应用层运行姿态控制与导航算法，中间件提供 uORB/参数/日志服务，驱动层直接操作外设，底层是 MCU 与总线。
二、传感器与执行机构
传感器是飞控的“感官”。IMU（惯性测量单元）通常由三轴加速度计与三轴陀螺仪组成，是姿态解算的核心；磁力计提供航向参考，气压计提供高度信息，GPS 提供绝对位置与速度，光流与超声波用于低空定位。执行机构则是飞控的“手脚”，多旋翼通过电调驱动无刷电机，固定翼通过舵机控制舵面，部分机型还包含云台、投放机构等。
传感器与执行机构都通过特定总线与 MCU 相连，驱动层需要处理采样率、量程、滤波、时间戳、校准等细节。例如 ICM-42688 通过 SPI 以 8 kHz 采样，驱动需保证数据就绪中断与读取时序匹配；电调通过 DShot 或 PWM 接收油门指令，驱动需保证脉宽精度与刷新率。
| 对象 | 典型器件 | 接口 | 驱动关注点 |
|---|---|---|---|
| IMU | ICM-42688、BMI088 | SPI/I2C | 采样率、量程、温度补偿、时间戳 |
| 磁力计 | IST8310、QMC5883 | I2C | 校准、软硬磁干扰、数据就绪 |
| 气压计 | MS5611、BMP388 | I2C/SPI | 温度补偿、滤波、零偏 |
| GPS | u-blox M9N | UART | 波特率、协议解析、定位质量 |
| 电调 | BLHeli_32、T-Motor | DShot/PWM | 刷新率、脉宽、遥测回传 |
| 舵机 | 数字舵机 | PWM | 频率、行程、死区 |
三、驱动层的作用
驱动层是飞控软件中直接与硬件打交道的部分，其核心职责可以概括为四点：设备抽象（把不同型号传感器统一为同一接口）、总线管理（SPI/I2C/UART/CAN 的读写与仲裁）、数据发布（将采样结果以标准消息发布到 uORB）、异常处理（超时、校验失败、设备掉线）。
以 PX4 为例，驱动通常以独立模块运行，通过 start 命令加载，注册到设备节点后由应用层订阅。调试时常用命令如下：
# 查看已加载驱动模块
ls /dev
# 启动 IMU 驱动
icm42688 start -S -R 8
# 查看 uORB 消息
listener sensor_accel
# 查看驱动日志
dmesg | grep -i spi
四、常见飞控硬件平台与操作系统
飞控硬件平台按算力与用途可分为三类：MCU 型（STM32F4/H7、GD32 等，运行 NuttX 或 RT-Thread，适合实时控制）、SoC 型（如高通、瑞芯微，运行 Linux，适合视觉与导航）、异构型（MCU+SoC，如 PX4 搭配机载计算机）。操作系统方面，NuttX 是 PX4 的默认 RTOS，具有 POSIX 风格接口；ArduPilot 可运行在 ChibiOS、NuttX、Linux 上；RT-Thread 在国内飞控中应用广泛；Linux 则常见于伴飞计算机与地面站。
不同平台对驱动调试的影响很大：NuttX 下驱动以任务形式运行，日志通过 dmesg 与 uORB 获取；Linux 下驱动可能是内核模块或用户态 SPI/I2C 设备，日志通过 dmesg、journalctl 查看。理解平台差异，才能选对调试工具与日志路径。
五、案例与复盘
某四旋翼在起飞后出现姿态抖动，日志显示 sensor_gyro 频率从 1 kHz 掉到 200 Hz，且伴随 SPI 超时。复盘发现：驱动中 SPI 时钟配置为 10 MHz，但该 IMU 在长线缆下最高只能稳定到 8 MHz，导致偶发校验失败并触发重试，采样率下降。将时钟降至 6 MHz 并增加重试上限后，抖动消失。这个案例说明：驱动层的参数配置与总线时序，会直接表现为飞行品质问题。