上个月，团队不幸经历了一次炸机事故。
事后复盘，我们翻遍了日志，却陷入困惑：GPS信号正常、遥控链路在线、电池电压充足、EKF（状态估计器）状态良好——所有预设的故障安全（Failsafe）条件无一触发。
但飞机却实实在在地偏离了航线，最终撞墙损毁。
问题究竟出在哪里？我们花了三天时间深入排查，终于发现了真相：
- GPS并未丢失，但其定位误差从正常的0.5米逐渐漂移到了2米。
- 电池没有出现低压报警，但内阻增大导致动力响应变慢。
- 数据链路没有中断，但延迟从稳定的20毫秒抖动到了150毫秒。
单独审视每一个指标，它们似乎都还在各自的“正常范围”内。然而，当这些轻微异常叠加在一起时，整个系统实际上已经处于危险的边缘。这次事故让我深刻意识到一个严重问题：当前主流的Failsafe逻辑，本质上是一种“事后反应”机制。它擅长识别“已经发生的故障”，却对“正在发生的性能衰退”视而不见。
一、当前Failsafe的本质：仍是“条件触发器”
如果你仔细研究PX4（以及大多数飞控系统）的Failsafe逻辑，其核心可以概括为：
if (GPS lost) → 切 RTL
if (RC lost) → 切 failsafe mode
if (battery low) → 降级 / 降落
if (EKF bad) → 切换模式
这套逻辑本身没有错误，而且非常符合工程实践：清晰明确、行为可验证、结果可预测。
但它的根本问题在于 假设了一个非黑即白的世界，即系统要么“完全正常”，要么“彻底故障”。
而真实的无人机飞行环境远比这复杂。更多时候，系统并非突然崩溃，而是处在一个 “正在逐步变坏” 的灰色地带。
二、那些不会触发Failsafe的“隐形风险”
在野外实际作业中，你很容易遇到以下几种情况：
- GPS信号还在，但定位精度已经开始缓慢漂移。
- 视觉定位（VIO）模块没挂，但偶尔发生位置跳变。
- 通信链路没断，但延迟和抖动明显增大。
- 电池电压没低压，但因内阻增大导致输出功率和响应速度下降。
这些情况的共同点是：都没有达到触发预设Failsafe条件的阈值。
但飞行表现已经开始“变味”：控制器响应变“虚”、修正动作频繁、轨迹跟踪性能下降、整个系统的稳定裕度被悄然侵蚀。
当前的Failsafe机制无法感知“风险正在累积”。它只能对既成事实做出反应，却无法对衰退趋势进行预警。
三、为何“触发式Failsafe”在复杂系统中捉襟见肘？
因为现代无人机本质上是一个 多源输入（GPS/VIO/IMU/RC/Link）、多层闭环（状态估计→运动控制→动力执行）、强耦合 的复杂系统。
在这种系统中，真正的危险往往不是某个部件的突然失效，而是 多个“轻微异常”产生的叠加效应。
设想一个典型场景：GPS定位稍微飘了一点，空中阵风大了一点，控制指令的延迟又抖了一下。单独看，每一项都在容限之内。但三者叠加，就可能导致系统稳定性大幅下降，飞行已经不再安全，却 不会触发任何一项Failsafe。
四、一个更合理的方向：从“触发器”演进为“风险感知器”
核心思想转变很简单：不再只问“有没有故障？”，而要持续评估 “系统当前的风险等级有多高？”。
1. 从单一条件判断到多指标融合
当前逻辑是：
GPS good / bad
可以演进为：
risk_score = f(gps_quality, estimator_consistency, control_effort, vibration_level, link_delay)
关键变化在于：从关注单个信号的“好坏”到评估系统整体的“健康度”。这一步是质的飞跃。
2. 从“硬性切换”到“渐进式降级”
当前逻辑是：
GPS lost → 直接 RTL
可以改进为：
GPS 精度下降 → 限制最大飞行速度
GPS 精度进一步下降 → 限制最大加速度
GPS 精度严重恶化 → 切换至返航（RTL）模式
这样做带来的工程价值是：系统行为不会发生“突变”，飞行状态的变化更连续、更平滑，也更容易被飞手理解和接管。
3. 在触发Failsafe之前，先实施“性能限制”
这一点至关重要，但目前实践中很少系统化地实施。
现状是：正常飞行 → 突然触发Failsafe。
更合理的流程应是：感知风险上升 → 控制器主动变保守（限性能） → 风险持续则触发Failsafe。
例如，当检测到GPS定位质量下降时，系统可以主动限制最大横向速度、降低最大加速度、限制加加速度（Jerk）、增加控制阻尼。让控制器 “先收着点飞” ，而不是等到状态估计彻底崩溃再慌乱切换。
4. 让控制器提前获知“系统即将进入Failsafe状态”
当前的一个问题是：控制器对Failsafe的触发毫不知情。
这导致的现象可能是：前一秒还在进行激进的控制，下一秒就因为模式切换而产生突兀的动作。
改进思路是引入一个中间状态，例如 ESTIMATOR_DEGRADED（估计器性能降级）。当系统进入此状态时，控制器能相应调整其行为：自动降低控制增益、限制输出幅度、提前稳定系统姿态。这样，Failsafe的切换就不再是“硬切换”，而是一种 “软过渡”。
五、算法层面可以如何实现？
这里是最能体现技术深度和工程智慧的部分。
1. 用风险评分替代简单的阈值判断
传统方法：
if innovation > threshold → reject
改进思路：
risk += innovation_norm
risk += vibration_score
risk += delay_variance
最终得到一个归一化的风险评分 risk ∈ [0, 1]，作为决策依据。
2. 区分“瞬时干扰”与“持续恶化”
这是实现智能响应的关键。
- 瞬时干扰（例如VIO因光照突变跳变一帧）：不应触发Failsafe，甚至不应大幅降级性能。
- 持续恶化（例如GPS精度持续缓慢漂移）：必须启动系统性能的逐步收敛。
实现方式可以结合滑动窗口统计、时间一致性检验、以及对风险分数进行指数衰减等策略。
3. 针对不同故障类型，采用差异化的响应策略
当前许多系统是：一个异常 → 切换到一个固定的备用模式。
但更合理的做法是针对不同根源的问题，采取最匹配的缓解措施：
| 故障类型 |
更合理的响应策略 |
| GPS 定位精度下降 |
限速 + 采用更保守的控制参数 |
| 视觉定位（VIO）跳变 |
数据门限（Gating）滤波 + 暂时忽略该次观测 |
| 通信链路延迟抖动 |
增加指令平滑 + 切入定点悬停（Hold） |
| 电池性能下降（非低压） |
限制最大推力输出 |
并非所有问题都需要“切换飞行模式”来解决。
4. 引入“异常可恢复性”判断
这是一个较高级但非常实用的概念。
核心在于：系统需要判断当前异常是 短暂、可恢复的，还是 持续、不可逆的。
举例：
- GPS短暂信号波动 → 忽略或降低其在融合中的权重。
- GPS精度持续缓慢下降 → 逐步降级系统性能（渐进式降级）。
- GPS信号完全丢失且无法恢复 → 触发最终的Failsafe流程。
这种基于趋势和上下文理解的决策，才是 “智能”故障处理的核心。对于这类复杂系统的设计优化与实践经验，云栈社区的基础综合板块常有不少深度探讨。
六、工程落地时最关键的一句话
你可以用下面这句话来概括这种设计哲学的转变，它非常有力量：
传统的Failsafe解决的是 “系统已经坏了，我们该怎么办？”
而下一代飞控系统更应该解决： “系统正在变坏时，我们能否提前感知并收敛风险？”
七、最后一个现实判断
这件事不是“要不要做”的选择题，而是“迟早要做”的必答题。
因为无人机系统正变得越来越复杂，传感器越来越多，应用场景越来越充满不确定性。依赖单一阈值的触发式保护机制，迟早会跟不上系统发展的需求。
炸机那次之后，我们在自己的飞控代码中尝试加入了初步的风险评分逻辑。虽然它还远非完美，但至少让我们对那些悄无声息靠近的“隐形杀手”有了一定的预警能力。
你是否也遇到过 “没有触发Failsafe但飞行已不安全” 的场景？欢迎在技术社区分享你的经历与思考，例如在 云栈社区 的开源实战板块与其他开发者交流，共同推动相关技术的进步。
发表于 4 天前
|
查看: 20|
回复: 0
