Driver computes covariance incorrectly

[PaulBouchier]

In the review: 2010-05-31 GPS Proposal_API_Review of the NavSatFix message, the discussion appeared to initially treat HDOP as a measurement uncertainty, but late in the discussion, Chad noted, "I found a source here that claims you can use DOP to multiply the expected optimal measurement accuracy of your GPS: http://www.pobonline.com/Articles/Column/f785817cac0f6010VgnVCM100000f932a8c0____ "As an example, let’s say the measurement accuracy is 1 meter. If DOP is 1, then the positioning accuracy is 1 meter. What happens when the DOP is 5? The best positioning accuracy is 5 meters." So it looks like we can take the optimal case (DGPS, WAAS, Omnistar, etc) covariance matrix and multiply that by DOP^2. So this could still be done by the driver."

This matches what I've divined from reading. The implementation of the driver currently sets covariance to HDOP^2, but should multiply that by the measurement variance. HDOP is apparently supposed to be greater than 1.0, and the current (faulty) implementation has apparently worked well enough, possibly because the square of an HDOP of 1.0 - 2.0 is 1.0 - 4.0, which is in the ballpark of what aided GPS variance should be.

This doesn't work for RTK GPS, where the error is a few cm.

Determining the measurement error was left by the NavSatFix message architects as a detail for the driver. It has been asserted that NMEA doesn't standardize how GPS receivers should publish measurement error. Reportedly, each vendor uses proprietary ways of reporting error. However, there is a GPGST message that at least Trimble publishes. The Skytraq receiver will also publish it, so I think we should support it and use its data to compute covariance. The message definition is shown below.

Position error statistics

An example of the GST message string is:

$GPGST,172814.0,0.006,0.023,0.020,273.6,0.023,0.020,0.031*6A

The Talker ID ($--) will vary depending on the satellite system used for the position solution:

$GP - GPS only
$GL - GLONASS only
$GN - Combined

GST message fields Field Meaning 0 Message ID $GPGST 1 UTC of position fix 2 RMS value of the pseudorange residuals; includes carrier phase residuals during periods of RTK (float) and RTK (fixed) processing 3 Error ellipse semi-major axis 1 sigma error, in meters 4 Error ellipse semi-minor axis 1 sigma error, in meters 5 Error ellipse orientation, degrees from true north 6 Latitude 1 sigma error, in meters 7 Longitude 1 sigma error, in meters 8 Height 1 sigma error, in meters 9 The checksum data, always begins with *

I propose that covariance should be calculated using a heirarchy of inputs as follows:

• If a message known to express the accuracy of a fix (e.g. GST, or some vendor-specific message) is found, the horizontal 1-sigma std deviation provided should be used as the estimated error. This policy allows for receiver-specific driver code to collect the estimated error in any way appropriate if GST isn't provided.
• If a fix accuracy message is not found, error std. deviation should have a default value based on the fix quality in the GGA message: 1 Fix quality: 0 = invalid
  • 1 = GPS fix (SPS)
  • 2 = DGPS fix
  • 3 = PPS fix
  • 4 = Real Time Kinematic
  • 5 = Float RTK
  • 6 = estimated (dead reckoning) (2.3 feature)
  • 7 = Manual input mode
  • 8 = Simulation mode In both cases, std deviation should be multiplied by HDOP, the result squared, and placed on the covariance diagonal, unless the driver has better knowledge.

    Details of proposal

If GST is provided, error should be taken as the greater of lattitude or longitude 1-sigma error If GST is NOT provided, the fix quality should be mapped to 1-sigma error as follows: 0: 10^6 (This is arbitrary - the fix is invalid so Nan could be another option) 1: 4m. This is based on http://www.gps.gov/systems/gps/performance/accuracy/ wherein 2-sigma (95%) is stated as 7.5m, so 1-sigma should be half that (4m) 2: 10cm based on https://en.wikipedia.org/wiki/Differential_GPS 3: 3m based on half the 95% error of 5.9m stated here: http://www.navipedia.net/index.php/GPS_Performances 4: 2cm. I couldn't find a reference for 1-sigma for RTK so this is a proposal 5: 4m. A receiver shouldn't offer worse accuracy than SPS while it's trying to transition to RTK Fix mode - if it does (and I think the Swiftnav unit does) - I think it's broken. 6: ?? This is not estimatable. Perhaps Nan? 7: ?? This is not estimatable. Perhaps Nan? 8: 0m Perhaps a simulation should exhibit perfect accuracy

The proposals above do not reflect actual accuracy (except where provided by the receiver) - actual accuracy can be affected by the environment. They attempt to be a "best guess".

Will Nan in covariance blow-up the navigation stack? If so, perhaps a huge covariance is better.

I'm not super-experienced in this domain, and welcome better ideas. Thanks for your help.

Paul

[PaulBouchier]

Fixed in pull request #19 for jade & #20 for indigo

[asimay]

any update? should merge or not?

[sonyccd]

@PaulBouchier is this till an open issue ?

[PaulBouchier]

I think it's still an issue - covariance is computed incorrectly, and @mikepurvis suggested I do it differently. It looks like I dropped the suggested changes. There's now a conflict. It's been so long, and the requested pulls 19 & 20 into indigo & jade are less interesting than kinetic and/or lunar. I rather think the covariance change ought to go into a new distro, like lunar, since it changes the behavior of the driver.

I'll work on a change for lunar (or whatever comes after kinetic)

[sonyccd]

I would do Kinetic since it is the current long term support version. Most people will be using Kinetic for several years.

[PaulBouchier]

OK - thanks for the guidance. Please disregard pull requests 19 & 20, & I'll gen up a new one for Kinetic.

[tilk]

@PaulBouchier Are you still working on this?

[PaulBouchier]

not currently.

[evenator]

Addressed by #46