Things after EKF2 innovations fail


I want to use the ekf2 inovations for analysing the fly aways.

After we see the EKF2 innovations check fail in velocity and position failures, the x4 flies away. I know that this means the sensor readings from IMU and the readings from GPS have difference bigger than some threshold, namely the test ratios are bigger than the gate values.
Am i right?
If so, what i am asking is, does the ekf2 rejects the IMU for the velocity and position estimations and switching only to GPS velocity and positon?


EKF2 reject measurements if the test ratio is bigger than one. The gate parameters define when this happens. No, velocity and position test ratios higher than one indicates that the GPS measurements are being rejected, not the IMU data, which are treated as time varying parameters, not measurements.

So the test ratios bigger than one means that the GPS based velocity and the IMU based velocities differ, is it true? How can i debug which sensor is giving erroneous values in this case? I see an increase in EST4.VxI and EST4.VyI, also the EST2.IC gives 1 and 3 just before fly away. The log is

And also in the ring buffer there may be any big delay in the timestamps between sensors which can not be compensated for the delayed time horizon, which also results in rejecting the GPS, right?

Test ratios larger than one indicates that the innovations are larger than the variance scaled by the gate parameter, so could be due to several reasons. I am not sure what you mean by a big delay in the timestamps in the buffer, but you might need to tune your sensor delay parameters if you are using non standard sensors.
Here is a lot of documentation regarding the ekf

Yes, i have read the wiki, thanks. So in this case, the x4 flied away as it entered a dead reckoning i think. The thing is, when i looked at the gps, it seems it didn’t failed in epv and eph, but because of the test ratio, it has been rejected. This is what i haven’t understood.

Is there a specific reason to why you are using the old logger? If not please use the new one and upload the logs to

Your delta velocity bias states are diverging

Are you flying the the newest stable release?

I will switch to ulog.

Flying with 1.5.5 stable release.

This fly away occurs repeatedly in all flights at exact time (nearly 2:30 minutes).
The problem is, this does occur only in HOLD mode after takeoff. If i switch to POS CTRL mode, it doesn’t fly away for nearly 11 minutes.

The interesting thing is, when i switch back to 1.6.5 stable release, this does not occur in hold mode. (if the imu was problematic, this will occur in 1.6.5 also)

A lot of things have changed from 1.5 to 1.6. If you really need to be using old code I would suggest to at least update just the ecl submodule in order to get all the improvements and robuatifications that has gone in since then. Even if there is nothing “wrong” with your IMU the updated ecl handles e.g. things like time slips much better.
Note that you will of course have to also adjust some of the interface to the ekf.

If you fly away just in hold mode, can you check your mag data or mag innovation data. As I think that when hold, the mag fusion / learn can lead the data diverging.
So I guess your uavs before fly away, it will tolit /circle some times. lose control, then fly away. Am I right?

during hold, why are you only suspecting mag? i think it also observes gps velocities and predicts imu velocities then estimates the velocities.
It is interesting that no toilet before fly away, it was sharp fly away with only roll to go anywhere. i think it rejected gps. looking at the innovations, the velocity has failed. btw sometimes it enters toilet effect only. i checked that mc pos ctrl has no velocity limits in 1.5.5.

can you have a review at this pr:
Hope it can give you some ideas.