3、飞控系统架构：传感器、作动器、飞控计算机、控制律在系统中的位置与作用

飞行控制律设计不是孤立的算法推演，而是嵌入在完整飞控系统硬件与软件架构中的核心环节。理解传感器、作动器、飞控计算机（FCC）与控制律之间的物理连接、信号流向和功能边界，是进行控制律设计、参数整定、故障排查和适航认证的前提。本章从系统架构视角出发，厘清各组成部分的职责、接口关系及对控制律设计的影响。

3.1 飞控系统架构的核心原理与功能边界

飞控系统的本质是一个闭环反馈控制系统，其物理载体由传感器、飞控计算机、作动器和飞机本体四个基本环节构成。控制律并非独立存在的软件模块，而是运行在飞控计算机中的核心算法，它接收传感器提供的状态反馈，按照设计好的控制逻辑解算出作动器指令，从而改变飞机气动构型或推力状态，最终影响飞机的运动响应。

从信号流角度看，系统存在两条关键回路：外回路（导航/制导回路）和内回路（姿态/增稳回路）。外回路以位置、速度等导航信息为反馈量，生成姿态指令；内回路以角速率、姿态角为反馈量，生成舵面指令。控制律设计通常聚焦于内回路，但必须理解外回路对它的指令约束和接口关系。

各组成部分的功能边界如下：

• 传感器：负责感知飞机当前运动状态和环境参数，包括角速率（陀螺仪）、线加速度（加速度计）、姿态角（通过姿态解算）、空速/高度（大气数据）、位置/速度（GNSS/惯导组合）等。传感器是控制律的“眼睛”，其精度、延迟和故障特性直接影响控制品质。
• 飞控计算机（FCC）：是控制律运行的硬件平台，负责信号采集、数据融合、控制律解算、余度管理、指令输出和系统监控。FCC 的运算能力、采样率、时延和可靠性是控制律工程实现的关键约束。
• 作动器：是控制律的“手”，将 FCC 输出的电指令转换为舵面或油门的机械位移。作动器的带宽、速率限制、饱和特性和动态响应滞后，是控制律设计中必须建模的环节。
• 控制律：是飞控系统的“大脑”，它决定了系统如何根据反馈误差计算控制指令。控制律的结构（PID、LQR、H∞、动态逆等）和参数决定了闭环系统的稳定性、响应速度和鲁棒性。

3.2 各组成部分的工程特性与设计约束

控制律设计人员必须深入了解每个组成部分的工程特性，因为这些特性直接决定了控制律的适用范围和设计边界。

3.2.1 传感器特性与控制律设计的关系

传感器的主要特性参数包括：测量范围、分辨率、带宽、延迟、噪声密度、标度因数稳定性、零偏重复性和故障模式。从控制律设计角度，最关键的三个参数是延迟、噪声和故障行为。

• 延迟：传感器从物理量变化到数字量输出的时间差，包括采样延迟、滤波延迟和传输延迟。延迟会降低相位裕度，限制控制律可用的带宽。例如，若传感器延迟为 20ms，控制律设计时通常要求闭环穿越频率不超过延迟倒数的 1/10~1/5（即 5~10 rad/s）。
• 噪声：传感器输出中的随机波动，通常以功率谱密度（PSD）或 Allan 方差描述。噪声会通过控制律放大，导致舵面频繁偏转，增加功耗和机械磨损。控制律中常需设计低通滤波器或观测器来抑制噪声，但滤波又会引入额外延迟。
• 故障行为：传感器可能发生硬故障（输出饱和、恒值）或软故障（漂移、精度下降）。控制律必须配合余度管理策略，在检测到故障后及时切换或降级。

3.2.2 作动器特性与控制律设计的关系

作动器的主要特性包括：带宽（-90° 相移频率）、速率限制（最大偏转速度）、位置饱和、延迟、死区和滞环。其中，速率限制是控制律设计中必须特别关注的非线性因素。

当控制律输出指令变化过快时，作动器可能达到速率饱和，导致实际舵面偏转滞后于指令，这种现象称为“速率饱和诱发的相位滞后”。在极端情况下，可能引发极限环振荡（PIO，飞行员诱发振荡）。控制律设计时，通常需要限制指令变化率，或采用抗饱和补偿器（如条件积分、动态抗饱和）来缓解这一问题。

3.2.3 飞控计算机的工程约束

FCC 的约束主要体现在：采样率（通常 50~200 Hz）、计算时延（从采样到指令输出的总延迟）、字长与量化误差、内存与存储限制、余度架构（双余度、三余度或四余度）以及表决/监控逻辑。控制律从连续域设计到离散域实现时，必须考虑采样保持效应和计算延迟，必要时需进行离散化修正或延迟补偿。

组成部分	关键参数	对控制律设计的影响	典型设计应对
传感器（IMU）	延迟 5~30ms，噪声密度 0.01~0.1°/s/√Hz	限制开环穿越频率，影响相位裕度	延迟补偿、状态观测器、低通滤波
传感器（ADS）	延迟 20~100ms，更新率 10~50Hz	影响速度/高度回路带宽	采用惯性参考速度，避免直接微分
作动器	带宽 10~30Hz，速率限制 30~100°/s	限制内回路增益，可能引发PIO	指令限幅、抗饱和补偿、结构滤波
FCC	采样率 50~200Hz，计算延迟 1~10ms	离散化误差，相位滞后	离散化设计、延迟补偿、多速率处理

3.3 控制律在系统架构中的位置与接口关系

控制律在飞控系统中处于“承上启下”的核心位置。向上，它接收来自导航/制导系统的指令（如姿态角指令、速度指令）；向下，它输出舵面偏转指令给作动器；同时，它实时接收传感器反馈，形成闭环。

从软件架构看，控制律模块通常包含以下子功能：

1. 指令整形：对输入指令进行滤波、限幅和速率限制，避免过激指令进入控制回路。
2. 误差计算：将参考指令与反馈信号比较，生成误差信号。
3. 控制律核心解算：根据误差和系统状态计算控制量，可能是线性反馈、非线性动态逆或自适应律。
4. 控制分配：将虚拟控制量分配到多个作动器（如副翼、扰流板、差动平尾），考虑作动器位置和速率限制。
5. 指令输出与监控：输出最终指令，并监测指令合理性、作动器响应是否正常。

控制律与系统其他部分的接口通常通过数据总线（如 ARINC 429、MIL-STD-1553、AFDX）或模拟信号实现。接口设计必须明确信号定义、数据格式、更新率、超时检测和故障标志。

3.4 案例拆解：某无人机纵向控制律的架构适配

为帮助理解上述概念，以下通过一个小型固定翼无人机纵向控制律设计案例，展示系统架构各环节如何影响控制律设计。

背景与约束：某无人机翼展 3.2m，起飞重量 12kg，巡航速度 25m/s。飞控硬件采用 Pixhawk 衍生的自研 FCC（STM32H7，采样率 200Hz），传感器为消费级 IMU（延迟约 8ms，陀螺噪声密度 0.03°/s/√Hz），作动器为数字舵机（带宽约 8Hz，速率限制 120°/s，位置范围 ±25°）。控制律需实现俯仰角稳定和高度保持功能。

初始现象：在首次飞行试验中，俯仰角响应出现持续小幅振荡（约 ±2°，频率约 3Hz），且舵机频繁抖动，电池消耗明显加快。

分析过程：

1. 首先检查传感器数据：IMU 角速率信号中叠加了明显的高频噪声（峰峰值约 ±5°/s），该噪声经控制律放大后驱动舵面频繁偏转。
2. 检查作动器响应：舵机带宽仅 8Hz，而控制律中俯仰阻尼回路的增益设置较高，导致在 3Hz 附近产生约 40° 的相位滞后，进一步降低了系统阻尼。
3. 检查 FCC 时延：从 IMU 采样到舵机指令输出，总延迟约 12ms（含滤波、解算和总线传输），在 3Hz 处引入约 13° 附加相位滞后。

关键参数与调整：

原始控制律参数（俯仰阻尼回路）：
  俯仰角速率增益 Kq = 0.35 (deg/s)/(deg/s)
  俯仰角增益 Ktheta = 2.5 (deg/deg)
  舵机指令限幅 = ±25°
  低通滤波器：20Hz 一阶

调整后控制律参数：
  俯仰角速率增益 Kq = 0.22
  俯仰角增益 Ktheta = 1.8
  低通滤波器：12Hz 二阶（Butterworth）
  增加指令速率限制：最大 60°/s
  增加舵机指令前馈补偿：超前环节 +2ms

实际操作步骤：

1. 在仿真环境中建立包含传感器延迟（8ms）、舵机一阶惯性（时间常数 0.02s）和速率限制（120°/s）的完整模型。
2. 将原控制律参数代入模型，复现 3Hz 振荡现象，确认根因是相位裕度不足（仅约 25°）。
3. 降低 Kq 和 Ktheta，将穿越频率从 4.2 rad/s 降至 2.8 rad/s，相位裕度提升至 48°。
4. 增加 12Hz 二阶低通滤波器，进一步抑制高频噪声，但需验证滤波器在 2.8 rad/s 处引入的相位滞后（约 8°）可接受。
5. 加入指令速率限制，防止飞行员或制导律给出过激指令时舵机进入速率饱和。
6. 在硬件在环（HIL）测试中验证调整后的参数，确认振荡消失，舵机活动量降低约 60%。

结果对比：

指标	调整前	调整后	变化
俯仰角稳态误差	±1.5°	±0.8°	改善 47%
振荡频率	3.1 Hz	无持续振荡	消除
舵机平均活动率	82%	31%	降低 62%
相位裕度（仿真）	25°	48°	提升 23°

风险与代价：降低增益后，俯仰角响应的快速性有所下降（上升时间从 0.6s 增至 0.9s），但仍在任务可接受范围内。若需恢复快速性，可考虑升级更高带宽的舵机或采用状态观测器补偿传感器延迟，但这会增加硬件成本或算法复杂度。

复盘经验：控制律设计必须将传感器延迟、作动器带宽和速率限制作为一阶约束纳入设计模型。仅凭线性连续域设计无法发现此类问题，必须进行包含非线性环节（速率饱和、位置饱和）和延迟的时域仿真验证。

3.5 常见误区与设计复盘

在飞控系统架构与控制律协同设计中，以下误区值得警惕：

总结复盘：飞控系统架构是控制律设计的物理基础。传感器决定了“能看见什么”，作动器决定了“能做什么”，FCC 决定了“能算多快”，而控制律则是在这些约束下寻找最优策略。一个成功的控制律设计，必然是算法与硬件深度协同的结果。建议在项目启动时即建立包含延迟、噪声、饱和、故障模式的系统级仿真模型，并贯穿设计、实现、验证全过程。