EKF position differs from RTK GPS Position up to 60cm

The EKF position innovations are in the range of -20 to 20 cm.
I would expect this value to be much lower.
We use a UBLOX @5Hz and a Septentrio AsteRX-m2 at 10Hz.
The GPS library has been patched send ONLY GPS2 to the EKF.
The flight speed is mostly constant at ~5 m/s the flight path is a circle.

When Vx is aprox 0 the X position innovations are also almost zero.
The larger the Vx the larger the X innovations.

The same on the Y axis. Small Vy -> small Ypos innovations, the bigger the Vy the bigger the innovations.
So it looks like at small speeds the EKF does a good job.
At 5m/s it just fails miserably.

When comparing GPS positions with EKF positions we used this formula:
(GPS2.Lat-Pos.Lat)*111275.93
(GPS2.Lgn-POS.Lgn)*67980.245
And see that they differ up to 60cm from each other.

How can the difference between EKF and GPS grow from zero to up-to 60cm within 100ms ??
The copter is flying at ~5m/s that is 50cm/100ms.

We flew with previously with EK2_GPS_DELAY at 110ms (default).
To try to compensate for the innovation errors I’ve reduced the EK2_GPS_DELAY to 55 ms.
The position of the GPS relative to the PH2.1 has been taken care by a (0.11, 0, -0.125) meter offset.

We will try to fly again today with https://github.com/ArduPilot/ardupilot/pull/8409 to see if that helps

Airframe type
3DR X8+

Hardware type
Pixhawk 2.1

Logs

What testing was done to determine the 55 ms lag? When I did flight tests with a AsteRx-M it came out to 80 ms lag. (It’s of course possible the M2 is faster, but the driver is only providing the 80 ms number to EKF3 at the moment, and if we should be more flexible that’s worth knowing/bringing in).

We did sqrt( NKF3.IPN^2 + NKF3.IPE^2 ) / (GPS2.Spd*100) And that told us the the EFK innovations were off by around 55ms

I hope we can post a new flight log today.

So, I recompiled #8409 on top of master, and my small GPS2 patch… and I got this log of a 3 circle flight at 5m/s:

It contains both a UBLOX (GPS1) and a septentrio AsteRX-m2 (GPS2) . The EKF2 is patched to exclusively use the GPS2.

The formula that I posted above needs to be simplified to:
sqrt( NKF3.IPN^2 + NKF3.IPE^2 ) / GPS2.Spd
Because of some recent fixes in master.

I changed EK2_GPS_DELAY to 90ms

I hope this is what you wanted @tridge

thanks for the logs @amilcarlucas!
based on your log I’ve developed a new version that should fix the jitter issue. I’ve updated the PR https://github.com/ArduPilot/ardupilot/pull/8409 with the new code

Hi @tridge,

we did a new flight with your latest patch. This time we flew longer and increased the speed a bit.
I hope this helps.

thanks Amilcar, that shows 80ms lag on the SBP, and 200ms on the uBlox. The long lag on the uBlox is a surprise. If you fly again, can you setup faster LOG_BITMASK? (use 65535) so we get better time resolution

Okay damn i didn’t read this up until now. Just got done flying
Will try to fly again next week!

I tested Tridge’s binary with the following log results. Log 3 was the flight itself.

thanks Nate! That is a very interesting result, as the patch didn’t work well at all. Looks like I have more work to do!

I have now set LOG_BITMASK to 587773 (IMU_FAST off, IMU_RAW on) and disabled batch sampling. Will fly again tomorrow.

1 Like

@amilcarlucas any news on this topic ?

I finaly had some time to further persue this one.
I have a new branch: https://github.com/ArduPilot/ardupilot/pull/9380

I will let you know how that goes.