Servers by jDrones

EKF have a glitch in POS.Alt estimation


(Thai Binh Nguyen) #1


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.


(Thai Binh Nguyen) #2

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.


(Pompe Cukor) #3

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.


(Pompe Cukor) #4

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


(James Stewart) #5

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.


(Pompe Cukor) #6

@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.


(tridge) #7

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


(James Stewart) #8

@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”…


(Thai Binh Nguyen) #9

Well, I was using 3.9.6 Plane then.


(Thai Binh Nguyen) #10

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


(Thai Binh Nguyen) #11

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


(Thai Binh Nguyen) #12

Have anyone had a clue about this?