Incorrect use of covariance in distance-sensor uORB topic

[priseborough]

The uORB distance sensor topic incorrectly contains a covariance field:

https://github.com/PX4/Firmware/blob/master/msg/distance_sensor.msg#L7

The issue is that you cannot have a covariance for a single measurement because a covariance is a measure of the amount of correlation between two random variables. For a single variable, the correct name to use is 'variance' which should have units of m^2

An inspection of the various publishers of this message shows that all but one are publishing a 0 value. The ulanding distance sensor driver is populating it as if it is a variance with units of m^2 using a fixed value.

The distance_sensor message needs to be corrected so that it:

1. Uses correct variable names and units
2. Makes the distinction between noise variance and accuracy clear. For example a distance sensor could have only 0.05m RMS noise (a noise variance of 0.0025) but could have a range accuracy of 0.1m. To be used fully by various estimators, the distance sensor message should contain both a 'noise_variance' and a 'accuracy' field.

A 'noise_variance' calculated from the data can be used by the sensor driver to determine if the sensor data is invalid. Sonar sensors are prone to very noisy data under certain circumstances and a noise variance validity test, spike rejection filter and median select filter should be available for each distance sensor.

[xdwgood]

Just curious: The sensor driver only publishes the raw data, why isn't the data processing and judgment done by ekf, because ekf is more clear about what it needs.

[priseborough]

The large varying data we get from the sonar sensor under certain conditions which this check will detect is a failure mode specific to that type of sensor which is why I would rather not have it in the ekf2 module.

We may also be able to use the noise variance internal to the EKF to set the observation noise variance, but this is yet to be determined.

[LorenzMeier]

@priseborough Could you send a PR that renames that field and initializes it with a sane value for all sensors? Happy to assist there, but changing makes total sense, yes.

[TSC21]

@LorenzMeier @priseborough it probably makese sense to sync with mavlink/mavlink#917

[priseborough]

I have a branch which can be rebased and submitted as a PR when #9865 is merged

See:

https://github.com/priseborough/Firmware/commits/pr9865

[kyuhyong]

Is this issue relate to my experience with sonar?
http://discuss.px4.io/t/distance-sensor-covariance-value-not-updating/7267?u=kyuhyong_you
Log data shows no indication of updating covariance in sonar data.

I just wonder what this distance sensor correlate to other sensor signal too.

[TSC21]

Still relevant

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[bresch]

done in #11520