飞控系统架构与执行器模型

大家好，我是老张。今天咱们聊聊飞控容错控制里最基础、也最关键的一环——执行器。说白了，你算法写得再漂亮，执行器不听使唤，飞机照样摔。我见过太多项目，仿真跑得飞起，真机一飞就炸，十有八九是执行器模型没吃透。

四旋翼执行器配置

四旋翼的配置，大家应该很熟悉了。标准的X型布局，四个电机，编号从1到4。但这里有个细节，我刚开始做飞控时踩过坑——电机旋转方向。

为什么强调这个？因为容错控制里，一旦某个电机失效，你得知道剩下的电机怎么配合。我曾经在项目中遇到一个情况：电机2堵转，飞控还在按原来的混控矩阵算输出，结果飞机直接翻了个跟头。后来我养成了一个习惯——先做执行器映射测试，再谈算法。

固定翼执行器配置

固定翼比四旋翼复杂一些。执行器种类多：副翼、升降舵、方向舵、油门。每个舵面都有它的作用，但容错时，你得知道哪些舵面可以互相补偿。

举个例子，副翼失效了怎么办？可以用方向舵和升降舵配合，实现滚转控制。但这里有个前提——你得知道舵面的气动效率。我见过一个团队，副翼卡死在0度，他们用方向舵硬拉，结果飞机进入螺旋。说白了，方向舵的滚转力矩有限，你得算清楚。

执行器	主要作用	容错替代方案
副翼	滚转控制	方向舵+升降舵差动
升降舵	俯仰控制	油门+襟翼
方向舵	偏航控制	副翼差动
油门	速度控制	俯仰角调整

执行器动态模型

执行器不是理想的。你给一个PWM信号，电机不会瞬间达到目标转速。这里有个一阶惯性环节：

// 电机动态模型
// tau: 时间常数，通常 0.05-0.1s
// u: 输入PWM (1000-2000us)
// omega: 实际转速

omega_dot = (u - omega) / tau;

为什么这个模型重要？因为容错控制里，你判断执行器是否失效，得知道它应该在什么状态。如果模型不准，你可能会误判。我记得有一次，一个电机响应慢了50ms，飞控以为是故障，直接切了容错模式，结果飞机乱晃。后来发现是电池电压低了，电机响应变慢。

这里有个避坑指南：执行器模型参数要在线辨识。我曾经在代码里加了一个简单的递推最小二乘，实时估计时间常数tau。效果很好，电池电压变化、温度变化都能自适应。

故障注入模型

做容错控制，你得先有故障。故障注入模型就是用来模拟执行器失效的。常见的故障类型：

• 卡死故障：执行器固定在某个位置，不再响应控制信号
• 饱和故障：执行器只能输出最大值或最小值
• 效率下降：执行器响应变慢或力矩变小
• 完全失效：执行器无输出

我习惯在仿真里这样注入故障：

// 故障注入函数
// fault_type: 0=正常, 1=卡死, 2=饱和, 3=效率下降
// fault_value: 卡死位置或效率系数

float inject_fault(float control_signal, int fault_type, float fault_value) {
    switch(fault_type) {
        case 0: // 正常
            return control_signal;
        case 1: // 卡死
            return fault_value;  // 固定输出
        case 2: // 饱和
            return (control_signal > 0) ? 1.0 : -1.0;  // 最大或最小
        case 3: // 效率下降
            return control_signal * fault_value;  // fault_value < 1.0
        default:
            return control_signal;
    }
}

嗯，这里要注意：故障注入的时机。我建议在飞行稳定后再注入故障，否则你分不清是故障导致的不稳定，还是起飞阶段本身就不稳定。我曾经在仿真里一上天就注入故障，结果花了三天才调试好，后来发现是起飞阶段的震荡被误判为故障响应。

知识体系总览

说了这么多，咱们用一张图来总结一下本章的核心逻辑。这张图是我自己画的，每次做容错控制项目，我都会先过一遍这个框架。

这张图其实就说明了一个道理：容错控制不是空中楼阁。你得先搞清楚系统架构，再摸透执行器配置，然后建立准确的动态模型，最后才能设计故障注入和容错算法。每一步都踩实了，飞机才能安全。

好了，这一章就到这里。执行器模型是容错控制的基石，下一章我们会深入故障检测与诊断的具体方法。记住，模型越准，容错越稳。

---

公众号:蓝海资料掘金营，微信deep3321