# Failsafe in case of an FMU crash for an Airplane

**URL:** <https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209>\
**Category:** PX4 Autopilot\
**Created:** [August 20, 2017, 9:21am UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209 "2017-08-20T09:21:57Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![acfloria](https://discuss.px4.io/user_avatar/discuss.px4.io/acfloria/32/1568_2.png) [@acfloria](https://discuss.px4.io/u/acfloria)\
**Post date:** [August 20, 2017, 9:21am UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/1 "2017-08-20T09:21:58Z")

</div>

Hello,

I am currently testing the 1.6.5 release of the PX4 autopilot for a fixed wing aircraft. In the normal flight mode everything works fine. When simulating a crash of the FCU the OVERRIDE flag in the PX4io is correctly set to true. Therefore the plane can be still controlled in the manual mode. When switching to the manual mode all control surfaces are controllable but the right aileron which is connected the output MAIN2.

I already tried to do some debugging but was not able to find the reason for this behaviour. The mixer loaded in the px4io driver looks good.

**Setup:**  
PX4 Firmware version: v1.6.2  
QGC Version: v3.2  
Airframe: Bormatec Maja

---

<div class="post-metadata">

**Author:** ![dagar](https://discuss.px4.io/user_avatar/discuss.px4.io/dagar/32/22_2.png) [@dagar](https://discuss.px4.io/u/dagar)\
**Post date:** [August 22, 2017, 5:51pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/2 "2017-08-22T17:51:22Z")

</div>

That’s odd, does MAIN 1 respond correctly for both roll and pitch stick movements?

I’m going to give this a try with a different configuration and make sure it’s still working.

---

<div class="post-metadata">

**Author:** ![acfloria](https://discuss.px4.io/user_avatar/discuss.px4.io/acfloria/32/1568_2.png) [@acfloria](https://discuss.px4.io/u/acfloria)\
**Post date:** [August 22, 2017, 7:18pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/3 "2017-08-22T19:18:27Z")

</div>

Yep, MAIN 1 responds correctly, as well as all other outputs.

---

<div class="post-metadata">

**Author:** ![dagar](https://discuss.px4.io/user_avatar/discuss.px4.io/dagar/32/22_2.png) [@dagar](https://discuss.px4.io/u/dagar)\
**Post date:** [August 22, 2017, 8:08pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/4 "2017-08-22T20:08:15Z")

</div>

For clarity can you go through the other outputs? What about flaps?

---

<div class="post-metadata">

**Author:** ![acfloria](https://discuss.px4.io/user_avatar/discuss.px4.io/acfloria/32/1568_2.png) [@acfloria](https://discuss.px4.io/u/acfloria)\
**Post date:** [August 22, 2017, 8:20pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/5 "2017-08-22T20:20:28Z")

</div>

The airframe I use is the Bormatec Maja but the actual plane is an EasyGlider which has no flaps. But I will check the output tomorrow.

So in the normal mode (where the FMU is working) the outputs MAIN 1 through MAIN 5 are working properly. When I kill the FMU MAIN 1 and MAIN 3 through MAIN 5 are working.

---

<div class="post-metadata">

**Author:** ![dagar](https://discuss.px4.io/user_avatar/discuss.px4.io/dagar/32/22_2.png) [@dagar](https://discuss.px4.io/u/dagar)\
**Post date:** [August 22, 2017, 8:39pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/6 "2017-08-22T20:39:00Z")

</div>

Ok that’s fine. This is the mixer the Bormatec Maja is using. [https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu\_common/mixers/AAERTWF.main.mix](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/mixers/AAERTWF.main.mix)

I don’t have an explanation for why it’s MAIN 2, but if I counted correctly there are 9 outputs in this mixer and I’m not sure how the PX4IO handles that.

Are you able to test mixer changes? I’d be interested to know if dropping the last three makes a difference. [https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu\_common/mixers/AAERTWF.main.mix#L86-L96](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/mixers/AAERTWF.main.mix#L86-L96)

You could also try dropping airbrakes from each of the ailerons here. [https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu\_common/mixers/AAERTWF.main.mix#L24](https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/mixers/AAERTWF.main.mix#L24)

If there’s no change we’ll need to dive into debugging the PX4IO.

---

<div class="post-metadata">

**Author:** ![acfloria](https://discuss.px4.io/user_avatar/discuss.px4.io/acfloria/32/1568_2.png) [@acfloria](https://discuss.px4.io/u/acfloria)\
**Post date:** [August 23, 2017, 3:34pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/7 "2017-08-23T15:34:36Z")

</div>

Thanks, removing the airbrakes from the ailerons was the solution.

I did some more testing by changing the index of the airbrakes input. By using a value of 4 or lower for the airbrakes the mixer still works, meaning the control surfaces are set according to the mixer and the RC input. By choosing a value of 6 or higher the problem with the right aileron

However, while testing I discovered another issue. When the FMU crashes in the _stabilized_ mode all servos get set to their default position and cannot be controlled anymore. But if it crashes in the _manual_ mode the servos will respond to the RC input after a crash of the FMU.

---

<div class="post-metadata">

**Author:** ![acfloria](https://discuss.px4.io/user_avatar/discuss.px4.io/acfloria/32/1568_2.png) [@acfloria](https://discuss.px4.io/u/acfloria)\
**Post date:** [August 24, 2017, 1:59pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/8 "2017-08-24T13:59:23Z")

</div>

I figured it out. In the stabilized mode the manual override is not allowed. However, this means that the plane will crash for sure if the FMU dies in the stabilized mode. By allowing the manual override the pilot could at least attempt to save the plane. I opened an [issue](https://github.com/PX4/Firmware/issues/7860) for the activation of the manual override and [one](https://github.com/PX4/Firmware/issues/7861) for mixer.

---

<div class="post-metadata">

**Author:** ![dagar](https://discuss.px4.io/user_avatar/discuss.px4.io/dagar/32/22_2.png) [@dagar](https://discuss.px4.io/u/dagar)\
**Post date:** [August 24, 2017, 2:46pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/9 "2017-08-24T14:46:48Z")

</div>

Hmm, I wonder how intentional that is. It seems like you’d want the servos to go to the failsafe values unless you were already in manual (then continue in manual mode). You should also be able to switch into manual mode in that state. Is the px4io capable of interpreting mode switches? I need to review the code.

Do you want to open a pull request for the mixer change? The airbrakes channel isn’t used anywhere in the controllers.

---

<div class="post-metadata">

**Author:** ![acfloria](https://discuss.px4.io/user_avatar/discuss.px4.io/acfloria/32/1568_2.png) [@acfloria](https://discuss.px4.io/u/acfloria)\
**Post date:** [August 24, 2017, 2:59pm UTC](https://discuss.px4.io/t/failsafe-in-case-of-an-fmu-crash-for-an-airplane/4209/10 "2017-08-24T14:59:02Z")

</div>

Yeah, I will open a PR for the mixer changes.

During testing and an FMU crash I was not able to switch from the stabilized to the manual mode.
