search

ros / common_msgs

Commonly used messages in ROS. Includes messages for actions (actionlib_msgs), diagnostics (diagnostic_msgs), geometric primitives (geometry_msgs), robot navigation (nav_msgs), and common sensors (sensor_msgs), such as laser range finders, cameras, point clouds.
http://wiki.ros.org/common_msgs
177 stars 191 forks source link

sensor_msgs/Range lacking variance (error) field #142

Open okalachev opened 5 years ago

okalachev commented 5 years ago

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.

tfoote commented 5 years ago

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?

okalachev commented 5 years ago

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.

okalachev commented 5 years ago

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.

rikba commented 4 years ago

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?

okalachev commented 4 years ago

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.

tfoote commented 4 years ago

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.