# Multicopter lock if primary gyro fails

**URL:** <https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685>\
**Category:** PX4 Autopilot\
**Created:** [February 20, 2019, 2:27pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685 "2019-02-20T14:27:08Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![MTM](https://discuss.px4.io/letter_avatar_proxy/v4/letter/m/e274bd/32.png) [@MTM](https://discuss.px4.io/u/MTM)\
**Post date:** [February 20, 2019, 2:27pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/1 "2019-02-20T14:27:08Z")

</div>

Hello guys,

Problem:  
If the primary gyro fails the multicopter attitude controller will not fall-back on secondary gyro but instead it stops functioning. If for example, the primary gyro is an external IMU connected over a cable to PX4, this failure can not be excluded.

Cause:  
In the main loop in the method MulticopterAttitudeControl::run() line 838 we have the code:

```
while (!should_exit()) {

	poll_fds.fd = _sensor_gyro_sub[_selected_gyro];

	/* wait for up to 100ms for data */
	int pret = px4_poll(&poll_fds, 1, 100);

	/* timed out - periodic check for should_exit() */
	if (pret == 0) {
		continue;
           }

```

…

If the selected gyro timesout, the main loop will just wait indefinitely for it or for module exit. This can have “severely unpleasant” effects if happens in flight.

Proposed solution:  
Since the sensor modules falls-back on the secondary gyro, we can just update the \_selected\_gyro in case of time-out and then the controller can keep flying. It is enough to change the if statement to:

```
	if (pret == 0) {
                    sensor_correction_poll();
		continue;
           }

```

in order to achieve an automatic switch to the next gyro selected by sensor module.

Question:  
Do you see any problem with this mitigation?  
Do you consider a good idea to also attempt it after a certain number of consecutive failure of poll function (i.e. the next if statement in the code)?

Thank you,  
MTM

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [February 20, 2019, 2:33pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/2 "2019-02-20T14:33:13Z")

</div>

Oh, interesting! I think you’re right, this seems indeed wrong.

Would you mind making a pull request and to propose a solution? That would be great. If not, someone of the maintainers should definitely look into this.

@dagar do you agree?

---

<div class="post-metadata">

**Author:** ![Ray\_Gamero](https://discuss.px4.io/user_avatar/discuss.px4.io/ray_gamero/32/4460_2.png) [@Ray\_Gamero](https://discuss.px4.io/u/Ray_Gamero)\
**Post date:** [February 20, 2019, 4:24pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/3 "2019-02-20T16:24:49Z")

</div>

MTM gave me a build with that solution to test (because I have an external IMU on my system).  
While running the vehicle on a bench test (armed motors running), I disconnected the external IMU cable (which was primary) and the multicopter controller seemed unphased by the swap over to the internal IMU. Accel time outs were displayed an the motors seemed unaffected.

Reviewing the log, the EKF biases reset and the sensor combined took 50ms to get data from the backup imu.

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [February 21, 2019, 7:01am UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/4 "2019-02-21T07:01:03Z")

</div>

Right, I would expect the `sensors` module to swap automatically and thus `ekf2` to swap as well.

However, as @MTM showed, the `mc_att_control` attitude rate controller does not failover as it probably should.

---

<div class="post-metadata">

**Author:** ![MTM](https://discuss.px4.io/letter_avatar_proxy/v4/letter/m/e274bd/32.png) [@MTM](https://discuss.px4.io/u/MTM)\
**Post date:** [February 21, 2019, 3:01pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/5 "2019-02-21T15:01:40Z")

</div>

Created pull request:  
Failover in case of gyroscope failure #11516

---

<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:** [February 22, 2019, 4:50pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/6 "2019-02-22T16:50:54Z")

</div>

Fixed in [https://github.com/PX4/Firmware/pull/11516](https://github.com/PX4/Firmware/pull/11516)

---

<div class="post-metadata">

**Author:** ![MTM](https://discuss.px4.io/letter_avatar_proxy/v4/letter/m/e274bd/32.png) [@MTM](https://discuss.px4.io/u/MTM)\
**Post date:** [February 25, 2019, 12:59pm UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/7 "2019-02-25T12:59:45Z")

</div>

Thank you for your help with the issue.

---

<div class="post-metadata">

**Author:** ![JulianOes](https://discuss.px4.io/user_avatar/discuss.px4.io/julianoes/32/30_2.png) [@JulianOes](https://discuss.px4.io/u/JulianOes)\
**Post date:** [February 26, 2019, 6:58am UTC](https://discuss.px4.io/t/multicopter-lock-if-primary-gyro-fails/9685/8 "2019-02-26T06:58:31Z")

</div>

Great, thanks @MTM and @dagar!