PX4-Autopilot: Incorrect units of variance in GPS topic
Couple of issues and concerns which I had while upstreaming the GPS-VIO interface which will also allow an offboard estimator to use the GPS accuracy information:
1 . This is from the vehicle_gps_position
topic :
float32 s_variance_m_s # GPS speed accuracy estimate, (metres/sec)
float32 c_variance_rad # GPS course accuracy estimate, (radians)
For velocity, variance should be in (m/s)^2 and for course, in rad^2. The comment and field name are both incorrect, and it is not understandable whether we want variance or standard deviation here.
- From the mavlink message
GPS_INPUT
:
speed_accuracy float GPS speed accuracy in m/s
horiz_accuracy float GPS horizontal accuracy in m
vert_accuracy float GPS vertical accuracy in m
The units suggest that these are standard deviations, however field spec is not clear from the word “accuracy”. Judging from other messages with better docs e.g WIND_COV
(horiz_accuracy float Horizontal speed 1-STD accuracy), it means sqrt variance.
- Is there an objection to switching the
vehicle_gps_position
topic to covariances only (pos_cov
andvel_cov
), and derive the other uncertainty fields where needed? Seems kinda unnecessary to transporthdop
,vdop
,epv
,eph
,s_variance_m_s
,c_variance_rad
, etc. Also, modern estimators and any cascaded setup will benefit from the covariance availability. @LorenzMeier
I will send in a PR with the fixes and the new interface when as my concerns are confirmed by another pair of eyes.
About this issue
- Original URL
- State: open
- Created 7 years ago
- Reactions: 2
- Comments: 16 (13 by maintainers)
I agree it should be more precise & consistent.
s_variance_m_s
&c_variance_rad
come directly from the ublox gps. The protocol spec just says it’s the ‘Speed accuracy estimate’ in [m/s] and ‘Heading accuracy estimate (both motion and vehicle)’ in [rad]. So it should be standard deviation.The value currently being passed through for the UBlox receivers is a speed accuracy with units of m/s, not a variance with units of (m/s)**2 and the EKF and other consumers are using it as such. The use of ‘variance’ in the name is misleading, however the description is correct and the name contains the units. If we either change name or units, then we will break replay of logs gathered using the legacy topic definition. I think what we should do here is add a note above the s_variance_m_s and c_variance_rad variables to make it clear.
@mhkabir can you continue that? I had the same confusion between variance and std dev of the speed accuracy today.
Kabir vs. the Bot – who would win?