飞控系统基础：飞控硬件架构、软件栈、传感器与执行器接口

飞控系统（Flight Control System, FCS）是无人机与飞行器的“大脑”与“神经中枢”。在进行故障注入与仿真测试之前，必须对飞控的物理组成与逻辑分层有清晰认知。本章从硬件架构、软件栈、传感器与执行器接口三个维度展开，帮助学员建立从“引脚电平”到“控制律输出”的完整映射关系。只有理解了信号从哪里来、经过什么处理、到哪里去，才能精准设计故障注入点并判断故障影响范围。

2.1 飞控硬件架构：从MCU到外围电路

飞控硬件架构的核心是主控MCU（Microcontroller Unit），当前主流方案采用ARM Cortex-M7或M4内核，例如STM32H743、STM32F427等。MCU负责运行实时操作系统（RTOS）与控制律算法，并通过各类总线与传感器、执行器交互。硬件架构可划分为四个功能域：计算域（MCU及存储）、感知域（传感器接口）、执行域（PWM/舵机驱动）、电源域（PMU与电压调节）。

在故障注入测试中，硬件层的关键在于信号完整性与电源稳定性。例如，IMU通常通过SPI总线以1kHz频率输出加速度与角速度数据，若SPI时钟线受到干扰或片选信号时序异常，会导致数据丢帧或校验错误。电源域方面，飞控通常采用5V输入，经LDO或DC-DC转换为3.3V（MCU与传感器）和5V（舵机/电调）。若电源纹波超过50mV，可能引发ADC采样抖动或MCU复位。

2.2 软件栈分层：RTOS、驱动与控制律

飞控软件栈通常分为四层：板级支持包（BSP）、实时操作系统（RTOS）、中间件与驱动、应用层（控制律与状态估计）。以PX4为例，其软件架构基于NuttX RTOS，采用发布-订阅（uORB）消息机制进行模块间通信。控制律模块（如mc_att_control）以250Hz频率运行，状态估计模块（如EKF2）以500Hz-1kHz频率运行。

软件栈的故障注入重点在于任务调度延迟与消息丢失。例如，若EKF2模块因CPU占用过高导致调度周期从1ms延长至3ms，飞控的姿态估计将出现明显滞后，进而影响控制律输出。在仿真测试中，可通过人为增加任务负载或修改任务优先级来模拟此类故障。

// 示例：PX4 uORB消息订阅（伪代码）
int sensor_sub = orb_subscribe(ORB_ID(sensor_combined));
struct sensor_combined_s sensor_data;
orb_copy(ORB_ID(sensor_combined), sensor_sub, &sensor_data);
// 若此处阻塞或数据未更新，则控制律将使用旧数据

2.3 传感器接口：SPI/I2C/UART的时序与协议

传感器接口是飞控与外界交互的“触角”。不同传感器采用不同总线协议，其故障模式也各不相同。SPI（Serial Peripheral Interface）通常用于高速IMU，时钟频率可达10MHz以上，支持全双工通信，故障模式包括时钟极性错误、片选信号毛刺、MISO数据线短路。I2C（Inter-Integrated Circuit）用于磁力计、气压计等低速设备，采用开漏输出与上拉电阻，故障模式包括总线挂死（SDA被拉低）、地址冲突、时钟拉伸超时。UART（Universal Asynchronous Receiver/Transmitter）用于GPS与数传模块，故障模式包括波特率不匹配、帧格式错误、缓冲区溢出。

在故障注入测试中，针对SPI总线，可模拟“片选信号提前释放”或“时钟频率突变”；针对I2C，可模拟“从设备无应答”或“总线仲裁失败”；针对UART，可模拟“数据位反转”或“停止位丢失”。这些故障可通过硬件注入或软件模拟实现。

2.4 执行器接口：PWM、DShot与舵机控制

执行器接口是飞控控制律输出的“最后一公里”。传统PWM信号以50Hz-500Hz频率输出，脉宽范围通常为1000μs-2000μs，对应电机转速或舵机角度。DShot协议则采用数字编码，速率可达300kbps-1Mbps，具有更高的分辨率与抗干扰能力。执行器接口的故障模式包括：PWM脉宽超限（如超过2000μs）、通道无输出、信号毛刺导致舵机抖动、DShot帧CRC错误。

在仿真测试中，可通过修改PWM定时器比较寄存器来模拟脉宽异常，或通过DMA中断屏蔽模拟通道无输出。对于舵机，还需关注其机械限位与堵转情况，这可能导致电流过大并反噬飞控电源。

2.5 常见误区与测试复盘

在飞控系统测试中，常见误区包括：只关注数据正确性而忽略时序、将传感器故障与执行器故障混为一谈、忽略电源域对信号的影响。例如，当GPS信号丢失时，飞控可能切换至无GPS模式，此时若测试人员仅关注GPS数据是否更新，而忽略了模式切换带来的控制律参数变化，则可能误判故障影响。

另一个典型误区是在仿真中过度简化接口时序。例如，在纯软件仿真中，SPI通信通常被抽象为函数调用，忽略了时钟延迟与信号竞争。这会导致某些硬件故障（如时钟毛刺）无法在仿真中暴露。因此，建议采用硬件在环（HIL）测试，将真实传感器与执行器接入仿真回路，以覆盖接口层的时序故障。