飞行控制系统基础:飞控计算机、传感器、执行机构、控制律的基本组成与工作原理
飞行控制系统是无人机、导弹及有人机的“神经中枢”,其核心任务是通过传感器感知飞行状态、由飞控计算机完成控制解算、再驱动执行机构改变气动舵面或发动机推力,最终使飞行器按照期望轨迹运动。在硬件在回路(HIL)测试中,我们通常将真实的飞控计算机接入仿真环境,而将传感器、执行机构用数学模型或真实硬件接口替代。因此,理解飞控系统的物理组成与信号流关系,是搭建HIL测试平台、设计故障注入用例、分析测试结果的前提。本章将围绕飞控计算机、传感器、执行机构与控制律四个核心模块,从工程视角剖析其工作原理与测试关注点。
上图展示了飞控系统各组件之间的信号流向以及HIL测试的接口映射关系。在后续章节中,我们将逐一拆解每个模块的内部结构、关键参数与测试方法。
2.1 飞控计算机:系统核心的硬件架构与余度设计
飞控计算机(Flight Control Computer, FCC)是飞行控制系统的计算核心,负责采集传感器数据、执行控制律算法、生成执行机构指令,并完成系统状态监控与故障处理。在HIL测试中,FCC通常作为被测对象(UUT)真实接入仿真回路,因此其硬件接口、时序特性、故障响应行为直接影响测试的真实性。
核心原理
现代飞控计算机普遍采用“CPU+FPGA”或“多DSP+ASIC”的异构架构。CPU负责复杂的控制律解算、导航算法和任务管理,FPGA则承担高速信号采集、接口协议转换、PWM生成等实时性要求高的任务。以典型无人机飞控为例,其内部功能模块包括:
- 模拟量采集单元:通过ADC将传感器输出的电压/电流信号转换为数字量,采样率通常为100Hz~2kHz,分辨率12~16bit。
- 数字接口单元:支持RS-422/485、CAN、ARINC-429、MIL-STD-1553B等总线,用于连接GPS、大气数据计算机等智能传感器。
- 离散量输入/输出:接收起落架收放状态、舱门开关等开关量信号,输出继电器控制指令。
- 伺服驱动接口:输出PWM或模拟电压指令控制舵机,同时采集舵面位置反馈(如LVDT/RVDT信号)。
- 余度管理单元:双余度或三余度配置下,进行信号表决、故障隔离和通道切换。
判断方法或操作流程
在搭建FCC的HIL测试环境时,建议按以下流程操作:
- 接口清单梳理:从FCC技术手册中提取所有I/O接口定义,包括信号类型、电平范围、更新率、协议格式。
- 信号调理匹配:确认仿真设备的输出阻抗、驱动能力与FCC输入要求匹配,必要时增加信号调理板卡。
- 时序同步配置:设置仿真机与FCC的同步时钟源,确保传感器数据更新与FCC采样时刻对齐。
- 故障注入通道预留:在关键信号路径上设计开关矩阵或可编程电阻网络,用于模拟传感器短路、断路、漂移等故障。
案例拆解
某型固定翼无人机FCC采用双余度架构,主备通道通过CAN总线交互状态。在HIL测试中,我们发现当仿真平台以100Hz频率发送GPS数据时,FCC偶发丢失定位信息。通过分析时序日志,定位到问题根源:仿真平台的CAN消息发送时刻与FCC的接收中断存在竞争,导致消息缓冲区溢出。解决方案是将GPS消息发送周期调整为与FCC采样周期同步,并增加消息重发机制。这一案例说明,HIL测试不仅要验证功能逻辑,还需关注接口时序的鲁棒性。
常见误区
2.2 传感器系统:状态感知的精度与延迟约束
传感器是飞控系统的“眼睛”,其测量精度、更新率、延迟和噪声特性直接影响控制品质。在HIL测试中,传感器通常以数学模型或信号仿真器形式接入,因此必须准确建模传感器的物理特性,否则测试结果将偏离真实飞行。
核心原理
飞控系统常用的传感器包括:
| 传感器类型 | 测量参数 | 典型输出 | 更新率 | HIL仿真方式 |
|---|---|---|---|---|
| IMU(惯性测量单元) | 三轴角速度、三轴加速度 | SPI/RS-422数字量 | 200Hz~2kHz | 信号级注入(电压/数字波形) |
| GPS接收机 | 位置、速度、时间 | NMEA/UBX协议串口 | 1~20Hz | 总线消息仿真(串口/CAN) |
| 空速/高度传感器 | 动压、静压、攻角 | 模拟电压或数字总线 | 50~200Hz | 模拟量输出或总线注入 |
| 磁力计 | 地磁场矢量 | I2C/SPI数字量 | 50~100Hz | 数字接口仿真 |
传感器信号在进入FCC前通常经过信号调理电路,包括滤波、放大、电平转换和隔离。例如,压阻式压力传感器输出毫伏级差分信号,需经仪表放大器放大至ADC输入范围(如0~5V),并采用二阶低通滤波器抑制高频噪声。
判断方法或操作流程
在HIL测试中,传感器建模需遵循以下步骤:
- 误差模型建立:根据传感器数据手册,建立包含刻度因子误差、零偏、非线性、噪声和温度漂移的误差模型。
- 延迟补偿:测量传感器从物理激励到数字输出的总延迟(包括采样时间、处理时间、传输时间),在仿真模型中添加等效延迟环节。
- 故障模式注入:设计传感器故障注入用例,如IMU输出饱和、GPS信号丢失、空速管堵塞等。
案例拆解
某四旋翼无人机在HIL测试中,发现姿态控制在高频振动下出现发散。初步怀疑是控制律参数问题,但通过频谱分析发现,IMU仿真模型输出的角速度信号含有明显的50Hz工频干扰。进一步检查发现,仿真平台的模拟量输出板卡未正确接地,导致地环路噪声耦合。解决措施是在仿真输出端增加隔离放大器,并优化接地拓扑。该案例表明,传感器信号质量对控制性能的影响不容忽视,HIL测试环境本身也可能引入额外噪声。
常见误区
2.3 执行机构:从指令到舵面响应的动态特性
执行机构是飞控系统的“手脚”,其动态响应特性(带宽、延迟、饱和、死区)直接影响控制回路的稳定性和跟踪精度。在HIL测试中,执行机构可以真实接入(如使用真实舵机)或采用负载模拟器,后者更为常见。
核心原理
常见的执行机构包括电动舵机、液压作动器和电液伺服阀。以电动舵机为例,其内部包含直流电机、减速齿轮组、位置传感器(电位计或磁编码器)和驱动电路。FCC输出的PWM指令信号经驱动电路转换为电机电压,电机通过减速机构带动舵面偏转,位置传感器将实际舵面角度反馈给FCC形成闭环。
执行机构的动态特性通常用一阶惯性环节加延迟近似描述:
G(s) = K / (τ·s + 1) · e^(-Td·s)
其中,K为增益,τ为时间常数(典型值20~100ms),Td为纯延迟(典型值5~20ms)。此外,还需考虑舵面偏转速率限制(如±60°/s)和位置饱和(如±25°)。
判断方法或操作流程
在HIL测试中,执行机构的建模与接入方式选择需考虑以下因素:
- 真实舵机接入:适用于验证FCC与舵机之间的电气接口兼容性,但需要配套机械负载模拟装置,成本较高。
- 数学模型仿真:适用于控制律验证和故障注入测试,通过参数化模型模拟不同舵机特性。
- 硬件在环负载模拟:使用电机或液压加载系统模拟气动铰链力矩,适用于全系统集成测试。
案例拆解
某大型无人机在HIL测试中,发现副翼通道在快速滚转指令下出现振荡。通过分析舵机电流和位置反馈信号,发现舵机在接近最大偏转速率时出现明显的速率饱和,导致相位滞后增大。解决措施是在控制律中增加速率限制补偿器,并优化指令滤波参数。测试结果表明,加入补偿后,滚转通道的相位裕度从35°提升至52°,振荡现象消失。
常见误区
2.4 控制律:从经典PID到现代鲁棒控制
控制律是飞控系统的“大脑”,其算法设计决定了飞行器的稳定性、机动性和抗干扰能力。在HIL测试中,控制律通常以代码形式运行在FCC中,测试目标包括验证算法正确性、参数鲁棒性和故障切换逻辑。
核心原理
飞行控制律通常采用内外环级联结构:内环为角速率环(阻尼回路),外环为姿态环(稳定回路),最外层为轨迹环(制导回路)。以纵向通道为例,俯仰角速率反馈用于增加短周期阻尼,俯仰角反馈用于保持姿态,高度反馈用于轨迹跟踪。
现代飞控系统广泛采用增益调度PID控制,即根据飞行状态(如动压、马赫数)在线调整PID参数。此外,鲁棒控制(H∞、μ综合)、自适应控制(模型参考自适应、L1自适应)也在新型飞行器中得到应用。
判断方法或操作流程
在HIL测试中,控制律验证通常分为以下阶段:
- 单元测试:在纯软件环境中验证控制律代码的逻辑正确性,如限幅、抗饱和、指令滤波等功能。
- 硬件在环测试:将控制律代码下载至真实FCC,接入仿真传感器和执行机构模型,验证闭环性能。
- 故障注入测试:模拟传感器故障、执行机构卡死、舵面损伤等场景,验证控制律的容错能力。
案例拆解
某飞翼布局无人机在HIL测试中,发现其横航向控制律在侧风干扰下出现荷兰滚模态发散。通过分析仿真数据,发现控制律中的偏航阻尼增益在动压较低时不足,导致荷兰滚阻尼比低于0.3。解决措施是重新设计增益调度表,在低动压区域增加偏航阻尼增益,并加入侧向过载限制器。修改后,荷兰滚阻尼比提升至0.5以上,满足适航要求。
常见误区
2.5 系统集成与HIL测试要点总结
飞控系统的四个核心模块并非孤立工作,而是通过信号流紧密耦合。在HIL测试中,需要从系统层面关注以下要点:
| 集成要素 | 测试关注点 | 典型故障模式 | 应对策略 |
|---|---|---|---|
| 信号时序 | 传感器数据更新率与控制律运行频率的匹配 | 数据丢失、相位滞后 | 同步时钟、缓冲队列 |
| 电气接口 | 电平匹配、阻抗匹配、隔离 | 信号衰减、地环路干扰 | 信号调理、隔离放大器 |
| 故障传播 | 单点故障对系统的影响范围 | 传感器故障导致控制发散 | 余度管理、故障隔离 |
| 实时性 | 控制律计算时间、总线传输延迟 | 超时、任务堆栈溢出 | 任务优先级配置、看门狗 |
在HIL测试平台搭建过程中,建议采用“分层验证”策略:首先验证单个模块的接口正确性,然后进行模块间联调,最后进行全系统闭环测试。每一层测试都应设计明确的通过/失败判据,并记录测试数据用于后续分析。