EKF have a glitch in POS.Alt estimation


While flying a quadplane at AUTO mode, the EKF suddenly have a glitch, in which, POS.Alt and POS.RelHomeAlt steeply dropped 120m. It then recovers because of the quadplane actually climbs up to ~300m. The altitude error remains until landing at -80m (appeared in GCS). Could anyone help me explain why and how to fix this?
Thank a bunch.

I found that when EKF isn’t available it will use barometer for getting relative altitude to home

// write a relative ground position to home in meters, Down
// will use the barometer if the EKF isn’t available
void AP_AHRS_NavEKF::get_relative_position_D_home(float &posD) const
{
Location originLLH;
float originD;
if (!get_relative_position_D_origin(originD) ||
!get_origin(originLLH)) {
posD = -AP::baro().get_altitude();
return;
}

posD = originD - ((originLLH.alt - _home.alt) * 0.01f);
return;

}

Is this a fraud when -baro = -150, POS.Alt = ~180
POS.Alt = 180 - 150 = 30m when EKF reset.

We had a very similar glitch today. As soon as we armed the plane, the EKF alt was reset. to -40m almost.
I would have not noticed except during the landing I noticed the UAV was higher than what was reported and when it started to (vtol) land is seemed to switch to baro alt which made it engage “final_alt” stage/speed prematurely. So it came down extremely slowly.
There was preflight calibration before arming.

@thethaibinh
Can you please say what version of firmware you are using that you got this bug.
For me it is latest master.

I’ve seen a similar issue myself, with a tiltrotor quadplane running Master. Reverting to 3.9.7 seems to fix it. Essentially, it will detect changes in altitude, but revert the alt back to 0 almost immediately. Luckily I caught it before ever attempting a transition, let alone auto, but it would have had serious issues had I flown Auto with it. I tried multiple different GPS units, notably 3 different Zubax units and a Here+. to make sure a bad GPS alt wasn’t causing it, but it ultimately came up as being a firmware related issue.

@lowlyelevated

Hi James, can you say how long ago you had the experience? Did you open an issue on it? Lets try and get this fixed. Devs cannot move if we do not supply data.

for all of these reports we need the on-board log

@pompecukor, yesterday was my first time seeing it. I’m working with a new platform that needs Master for some of the avionics. Haven’t opened an issue on it, I’ll leave that to my avionics/software guy once he gets a chance, he can describe it better than I can. I’m just a lowly test pilot…

@tridge, I’ll see what I can do. I only did a hop or two in Q_stabilize with the issue present, so I’m afraid I don’t have much practical data on it. And I’ve done so many power cycles that actually finding the logs from it will be… “fun”…

Well, I was using 3.9.6 Plane then.

I carried out a long flight test, so the log is pretty heavy. I am uploading it, anyway.

Here the log, my friend
https://drive.google.com/file/d/1q1fsqUqrYX_B54w296ZJhgz_ujDWhJu3/view?usp=sharing

Have anyone had a clue about this?