sensor_msgs/Range lacking variance (error) field
okalachev opened this issue · 6 comments
All the sensor related messages have variance/covariance field: FluidPressure, Illuminance, Imu, MagneticField, NavSatFix, RelativeHumidity, Temperature; while Range lacks it.
Though rangefinders' datasheets often provide such information, and it can be quite useful for the consumers of rangefinder drivers.
Indeed that's something that could be considered being added. There's a tradeoff between sending the data every time and having the information self contained versus minimizing the data size for communication overhead. This is an early message as well as the LaserScan and I think that many people use the sensor type as a proxy for variance estimates. Do you have a sensor that has a high or significantly different variance than most others?
All the range sensors have different variances, for example ultrasonic rangefinders might have cm error, while laser rangefinders might have mm error.
There's a tradeoff between sending the data every time and having the information self contained versus minimizing the data size
Almost all the other messages have this field, so adding would be good in terms of consistency.
This information can be useful fo state estimation nodes, that fuse rangefinders with other sensors. And hardcoding this information to the estimation nodes parameters seems not that good.
Also, some sensors can estimate their current error themselves. For example, VL53L1X rangefinder, that I'm writing a ROS driver for, provides SigmaMilliMeter value for each measurement, which looks like the estimation of the current measurement accuracy.
I agree, that extending an existing message might not be easy, so it's just a proposal. Maybe to add a new RangeWithVariance message (also seems not good and would not be supported by rviz and other tools soon).
Unfortunately, there is no some extending mechanism for messages, that is not breaking compatibility, as far as I know.
I second the desire for uncertainty information in the range measurement messages. At the moment we are evaluating and fusing Ainstein US-D1 radar altimeters and Garmin LIDAR-Lite v3-HP which have different resolution and uncertainty, some of it even range dependent.
If the variance and maybe even resolution information was included in the message we could more easily share and rerun rosbags without providing additional parameters for each range sensor topic. Of course this would increase the size of the message in my opinion self containment is more important than size in this case.
Unfortunately, there is no some extending mechanism for messages, that is not breaking compatibility, as far as I know.
As long as you only add and do not remove fields the code should still build I think. It's just that you cannot replay old rosbags if you do not have the old message built. Is there a best practice?
As long as you only add and do not remove fields the code should still build I think
Yeah, but existing binaries, I guess, would not work unfortunately. Anyway, that's better to ask of ROS authors.
We can evolve the message, extending is typically less intrusive. Whatever we do there needs to be a migration path for users. A parallel message is often a good way to make sure to have compatibility.
For logged data you can write a rosbag migration rule to migrate the data forward to the new format for compatibility.