航模飞控之FAILSAFE机制

1. 源由

鉴于最近的严重丢机事件，一直耿耿于怀。先把视频这里放一下，诶！！！这就是悲剧！！！

视频

“失败乃成功之母”话虽不错，但是用在自己身上总是那种隐隐作痛！从失败中总结经验，找到应对方法，才是学习的一种螺旋式上升。

注：这里先不吐槽，先找原因，然后等所有的东西都整理出来，其实有一些想法，从产品的角度值得我们去思考和提升的。

好了，话不多说，但是源由，动力就是来自这里！

2. 需求

首先，我想还是先不去看任何详细的设计资料，就从现有的生活、知识结构角度来看这个FAILSAFE的【原始】需求。

为什么说是【原始】需求，因为这个所谓的需求一定不是从技术角度出发的，而是从目的出发。这也是通常PM人员最为头疼的“需求”。

个人感觉，需求可以分几个层面来探讨：

1. 【原始】需求
2. 【场景】需求
3. 【功能】需求
4. 【技术】需求

2.1 【原始】需求

定义：基于用户最终目的的需求。

解释：通常看似简单，实际复杂，且存在歧义等诸多不实际或者矛盾的问题。

2.2 【场景】需求

定义：基于应用场景期望得到某种最优解。

解释：如果某种情况发生，希望能够如何解决，可实际情况事态会如何发展。

2.3 【功能】需求

定义：对实际最优解进行了语言上的抽象归纳。

解释：基于用户最终目标，且满足场景的基础上，对上述需求进行了抽象归纳。

2.4 【技术】需求

定义：通过技术的语言，将功能进行细化、量化、具体化。

解释：通常会提供技术上的规格、参数等要求。

3. FAILSAFE需求

3.1 【原始】需求

飞机怎么飞出去的，原原本本的安全返回，从而确保不丢机，损失最小化。

注：这里针对多轴航模，可能涉及GCS软件。

3.2 【场景】需求

根据多轴航模飞行器的需求，做一个场景整理。

这部分内容实际上非常关键，因为这里的交流基本上用户、PM都听得懂，可以说是领域白话文。

越细化，越具体，越明确，对于后续产品开发，尤其系统设计至关重要。

注：当然每个行业都有一些专业术语，这部分内容是需要进行知识补齐的。但是场景整理的方法和目的是一样的。

3.2.1 单点异常

1. 遥控信号异常
2. 电传信号异常
3. GPS信号异常
4. 磁力计异常
5. baro高度传感异常
6. FPV视频信号异常
7. 电池耗尽
8. 控制板异常(IMU, SOC)
9. 电机异常
10. 桨叶异常

3.2.2 模块异常

1. 动力系统异常
2. 通讯系统异常
3. 飞控系统异常

3.2.3 典型场景

1. FPV视频丢失，无法手动飞行
2. 遥控信号断链，无法手动飞行
3. GPS信号异常，无法维持自动导航
4. 电量耗尽，无法维持飞行
5. 控制板异常，无法维持飞行

3.3 【功能】需求

通过场景需求的澄清以后，功能需求的整理就是逻辑的梳理过程。当然有些地方可能存在冲突或者矛盾，只要梳理顺了，那么从逻辑角度就不存在业务问题。接下去就是具体的技术实现环节。

好，根据上面开列这些需求，整理下功能列表。

3.3.1 基本分析

目的：不丢机，损失最小化。

从上述目的的角度，如果出现意外，业务逻辑角度分析可以分一下几个操作：

1. 返航：安全飞回来
2. 降落：不能安全飞回来，安全降落
3. 避险：不能安全降落，采取避险措施

注：以上是最为基础的一个业务上的逻辑分析结果。

3.3.2 概念澄清

从常规航模应用的角度，【返航】 优先于 【降落】 优先于 【避险】
从用户损失（时间，精力）的角度看，【返航】 优先于 【降落】 优先于 【避险】

• 返航

返航的方式不同可能会产生安全隐患，前面指出的是安全返航。

1. GPS精度【RTL-Fixed】给定高度下返航，该高度是安全高度，因此安全。
2. GPS精度【RTL-AtLeast】至少在给定高度下返航，当异常时，高度高于给定高度，则使用当前高度，如果低于给定高度，爬升到给定高度。避免飞越障碍物返航碰到障碍物。
3. GPS精度【RTL-Slope】当高度大于给定高度时，节能返航，根据高频信号可视距通信原理，采用当前高度、起飞点给定返航高度、返航水平距离，以斜坡的方式返航。
4. GPS精度【RTL-Terrain】根据地形数据、返航设定高度，以及返航轨迹，进行有效路径计算后，智能安全返航。

鉴于航模通常飞控内置IMU和baro传感器（可靠），外置磁力计和GPS传感器，且相对来说磁力计和GPS受到外部干扰较大会导致自动导航失效的情况。

当GPS失效，而磁力计有效时，可以通过磁力计和加速度计进行非高精度的返航，以期望尽可能返回或者靠近出发点。

6. 非高精度返航【RTL-Fixed】
7. 非高精度返航【RTL-AtLeast】
8. 非高精度返航【RTL-Slope】

上述非高精度返航，至少需要以下有效数据：

起飞点位置
GPS信号丢失前有效位置
飞行姿态前方向与返航方向夹角
高度数据
当前位置与起飞点直线距离
磁力计，加速度计数据

• 降落

降落通常是不知道位置或者动力不足以返航，所采取的一种安全策略。

1. 【高度有效，可控降落】可控速度安全降落（以触地检测为真，标志降落成功）
2. 【高度无效，可控降落】以给定降落动力输出（以触地检测为真，标志降落成功，同时当超过给定时间认为降落成功，避免“窜天猴”）

• 避险

避险通常发生在飞行器姿态不可控时，此时已经完全失去控制，但是一个桨叶高速旋转的飞行器和不转的飞行器，从危险性的角度来说，桨叶不转更加安全。

3.3.3 功能列表

功能的角度，更应该将应用做解耦。

这里的意思就是，用户喜欢采用哪种业务逻辑处理应用场景应该让用户有更多的主动权，比如：穿越机树林里面飞来飞去，突然信号丢失，就是直接触发避险，难道要做“窜天猴”？？？这样更容易发生意外。

所以整理如下功能列表：

1. 支持业务逻辑【RTL】
   ==> GPS精度【RTL-Fixed】
   ==> GPS精度【RTL-AtLeast】
   ==> GPS精度【RTL-Slope】
   ==> GPS精度【RTL-Terrain】
   ==> 非高精度返航【RTL-Fixed】
   ==> 非高精度返航【RTL-AtLeast】
   ==> 非高精度返航【RTL-Slope】
2. 支持业务逻辑【LAND】
   ==> 【高度有效，可控降落】
   ==> 【高度无效，可控降落】
3. 支持业务逻辑【DROPit】
   ==> Disarm
4. 支持【RTL】业务逻辑可配置
   ==> 遥控信号异常
   ==> 电传信号异常
   ==> 电池告警
5. 支持【LAND】业务逻辑可配置
   ==> 遥控信号异常
   ==> 电传信号异常
   ==> 电池告警
6. 支持【DROPit】业务逻辑可配置
   ==> 遥控信号异常
   ==> 电传信号异常
   ==> 电池告警
   ==> 动力系统异常（此时只能DROP）
7. 支持遥控开关可配置业务逻辑【RTL】、【LAND】、【DROPit】
   ==> FPV视频信号异常
8. 支持传感器异常监测和业务逻辑降级
   ==> GPS信号异常
   ==> 磁力计异常
   ==> baro高度传感异常

注1：控制板异常(IMU, SOC)/飞控系统异常需要通过冗余硬件来做主备飞控应对，这里不讨论。
注2：电机、桨叶实际上就是动力系统异常，此时无法控制，只能损失最小化。当然X8等飞控算法已有相应的冗余控制方法应对。
注3：通讯系统大致主要就是遥控信号、电传信号、FPV信号。

3.4 【技术】需求

注：技术需求是相对来说是比较详细的，整个会涉及如下内容（但这里我们不做展开，点到为止）。

• 【MUST】业务流
• 【MUST】数据流
• 【Nice2Have】功能原理
• 【MUST】功能规格
• 【Nice2Have】状态机
• 【Nice2Have】真值表

举例：

以一个简单的分析，来对【技术】需求做介绍 – “8. 支持传感器异常监测和业务逻辑降级”的传感器真值表

【RTL】–降级–>【LAND】–降级–>【DROPit】

【RTL】以下情况可实现：

【LAND】以下情况可实现：

【DROPit】以下情况只能DROP，其他情况都可以配置：

4. 总结

以上需求方面的整理，是笔者，尚没有对PX4/ArduPilot/iNav/Betaflight/Paparazzi等飞控软件现有功能进行整理和研究的前提下提出的。

当然，上述整理也就花了2个小时左右，大量的码字，把资料整理出来，肯定是考虑不够充分的，但是至少是现有一些知识、经验结构给出的【原始】需求对应的功能列表。

当我们将开源飞控上述FAILSAFE实现的资料进行研读后，做一个对比，看看当前技术上已经到了什么程度。希望有后续对比的小伙盘记得点赞收藏，有idea的也评论，共享哦！

后续开源飞控文档链接如下：

1. Betaflight飞控之FAILSAFE机制
2. iNav飞控之FAILSAFE机制
3. ArduPilot飞控之FAILSAFE机制
4. PX4待研究，后续补充链接
5. Paparazzi待研究，后续补充链接

5. 参考资料

【1】四轴飞控DIY简明步骤介绍
【2】四轴飞控DIY集成FPV功能