Missing covariance for the position estimate

[jola6897]

Hi,

thanks for providing this driver. I was testing this driver with a PwrPak7D and I noticed that covariance for x, y and z is zero all the time. As it turns out the covariance is read from the GNSS message but not written into the navsat/odom msg (see inspvax_handler() in novatel_span_driver/src/novatel_span_driver/publisher.py line 185-214).

Basically we need only to add something like:
odom.pose.covariance[0] = pow(inspvax.latitude_std, 2) --> x covariance
odom.pose.covariance[7] = pow(inspvax.longitude_std, 2) --> y covariance
odom.pose.covariance[14] = pow(inspvax.altitude_std, 2) --> z covariance
before publishing odom.

Since UTM coordinates (as far as I understand) have an associated distortion (which depends on x,y), I do not know if we can straight forward convert the standard deviation given in long, lat and altitude into UTM x,y,z.

Does anyone know how to handle this correctly?

[mikepurvis]

Would love to see this handled correctly as well, but I'm also not sure how it should work. Please feel free to send a PR if you figure it out!

[JWhitleyWork]

@jonla1 - Given that I have a very limited understanding of this topic, here are some things to consider from my brief research:

1. Variability does not change if the unit conversion involves only the addition or subtraction of constant values. However, if the unit conversion involves multiplying by a constant value, the variability is changed by the square of the conversion factor. I don't know how more complex calculations affect the variability.
2. The WGS84 -> UTM conversion is very complicated and involves multiplication by several factors, including the standard UTM scaling factor 0.9996 to account for variance between a standard Transverse Mercator projection and the actual earth ellipsoid (evened out over all zones). Here is a paper on it: http://www.ccgalberta.com/ccgresources/report11/2009-410_converting_latlon_to_utm.pdf
3. While the scaling factor above is accurate enough to give a 0.1% variance across all zones, we are likely looking for more accurate values on a per-zone basis and have to take into account the distortion values if we want something that is accurate enough to, say, use for automated robots.
4. Because the conversion is so complicated, I don't have the background necessary to calculate the variance scaling. If someone else does, they can have at it.

Long story short, IMO, the conversion is not, unfortunately, that straight-forward and the variance values that are derived from your example above would not be close enough for any meaningful use as any amount of scaling factor changes the variance values by it's square.

As a side note: It appears that, on lines 182 and 191 of the file you mentioned, the altitude value is being used directly as the Z value. However, because the WGS84 elipsoid and the UTM projection spheroid don't match, I don't think this is correct. Thoughts?