move EKF_GPS_DELAY to GPS library

[rmackay9]

The EKF has the EKF_POS_DELAY and EKF_VEL_DELAY parameters which should be set based upon the GPS type that is being used. A better solution would be to have these expected delay parameters in the GPS library instead and have the values default set based upon the detected GPS type.

If using a Ublox GPS we'd like the delays to be slightly different for each variety.
6 = 0.22
7 = 0.20
8 = 0.18

[priseborough]

I would recommend starting with

6 = 0.22 (existing default)
7 = 0.20 (what Solo uses)
8 = 0.15 (needs testing)

[ghost]

Hi all,
these are new and slightly more conservative numbers compared to Paul's initial suggestion of 120ms for the M8.
Re "8 = 0.15 (needs testing)": how should a test look like?
Best regards,
Thorsten

[magicrub]

once known-good values are determined, can these be baked into the GPS
driver?

On Tue, Sep 15, 2015 at 1:53 PM, Thorsten notifications@github.com wrote:

Hi all,
these are new and slightly more conservative numbers compared to Paul's
initial suggestion of 120ms for the M8.
Re "8 = 0.15 (needs testing)": how should a test look like?
Best regards,
Thorsten

—
Reply to this email directly or view it on GitHub
#2850 (comment)
.

[priseborough]

Perform hard accelerate and stop manoeuvres north-south and east-west. Log the data using the 400Hz data rate option. Replay through the EKF replay and adjust the delay parameters until the magnitude of the EKF3.IPN EKF3.IPE, EKF3.IVN and EKF3.IVE (the GPS position and velocity innovations) is minimised.

I got 0.12 sec from my initial testing, but that was some time ago, so have backed off a bit on the value as it is better to over-estimate rather than under-estimate the delay.

On 16 Sep 2015, at 6:53 am, Thorsten notifications@github.com wrote:

Hi all,
these are new and slightly more conservative numbers compared to Paul's initial suggestion of 120ms for the M8.
Re "8 = 0.15 (needs testing)": how should a test look like?
Best regards,
Thorsten

—
Reply to this email directly or view it on GitHub #2850 (comment).

[WickedShell]

@magicrub there is a get_lag function in the gps driver ( libraries/AP_GPS/AP_GPS.h#L326 )that currently just returns a value of 0.2 the plan is to allow the drivers to provide a real value that is correct if it knows the hardware version/what it should be (although this is the first time we are explicitly handling hardware version detection in the ublox driver). If the user fills out a value in the GPS_DELAY other then 0 that would be returned rather then the one provided by the driver. (And if detection fails then we return the current default).

At least this is the plan as I understand it. If this is incorrect then someone should stop me before I go do it this way :)

[WickedShell]

This went in with #5407