Why won't the /scan topic display rounded values?

asked 2018-03-27 07:26:04 -0500

Lando
13 ●1 ●1 ●4

Hello,

I am a student at a university of applied sciences, working on a robot that uses the Hokuyo UBG-04LX-F01 LIDAR.

The robot that I use runs on Ubuntu 12.0.4.5 with ROS Hydro Medusa.

The LIDAR of this robot supposedly has a minimum detection range of 20 millimetres and a maximum detection range of 5600 millimetres. This LIDAR is already installed on the robot and it is publishing data to the /scan topic with sensor_msgs/LaserScan messages.

However, when I echo the content of the /scan topic with the rostopic echo /scan command, it shows the following data:

seq: 75922
  stamp: 
    secs: 1522051099
    nsecs: 302610304
  frame_id: laser
angle_min: -1.50330114365
angle_max: 1.49716520309
angle_increment: 0.00613592332229
time_increment: 2.44140628638e-05
scan_time: 0.0250000003725
range_min: 0.019999999553
range_max: 5.59999990463
ranges: [<omitted for readability>]
intensities: []

This output shows that the LIDAR has a minimum range of 0.019999999553 metres. Why such a strange value? Is this due to rounding errors between integers and floats? The same thing goes for other fields like the angle_min and angle_max, which are configured with an angle of -1.5 and 1.5 radians respectively.

I notice a comparable thing with the turtlebot, running in a gazebo simulation on ubuntu 16.0.4.4 with ROS Kinetic Kame, which shows a minimum range of 0.449999988079 (range_min: 0.449999988079).

Could somebody explain what is going on here? Why can't the output of the /scan topic have rounded values?

Comments

Like somebody should send a PR to round values to two decimals.

glm ( 2019-09-09 11:59:54 -0500 )edit

add a comment

answered 2018-03-27 07:32:57 -0500

gvdhoorn
86574 ●283 ●1432 ●1054 http://cor.tudelft.nl/

updated 2018-03-27 07:40:11 -0500

I'm slightly confused, because what you show are exactly 'rounded values'. What you mean I believe is why there are so many decimals, and why those numbers are not 'nice' numbers (ie: 0.4999987003.. instead of 0.5).

Is this due to rounding errors between integers and floats?

Unless I'm misunderstanding you, integers have nothing to do with this. But float and double do indeed have a maximum number of significant digits they can encode. For float (or a single precision floating point number) this is about 7, for double, this is about 15 to 16 (that is total number of significant digits, not just 'after the comma').

So for a float32 you can only realistically use the first 7 decimals.

A sensor_msgs/LaserScan uses float32 for all fields. You could ask whether it wouldn't have been better to use float64, but for all intents and purposes 5.59999990463 is equal to 5.600000.. (unless you start multiplying it with large values). Chances are that in most cases, the uncertainty (or noise) contributed by other (sub)systems will be worse than those 7 significant digits can encode, and this loss of precision won't matter much. That is not always the case though, and for those, the extra 7 digits that float64 provides may be important.

If you want to know more about this, some references:

The first link is a simpler explanation of the original article.

edit flag offensive delete link

Comments

Note that this is actually completely off-topic for this site: it's not a ROS problem at all.

gvdhoorn ( 2018-03-27 07:33:16 -0500 )edit

Thank you for the quick response. I never encountered any issues with floating point arithmetic until I started working with ROS, where a LaserScan message has values with many decimal places. I thought it was a ROS issue as the turtlebot shows similar behaviour.

Lando ( 2018-03-27 08:09:06 -0500 )edit

I never encountered any issues with floating point arithmetic until I started working with ROS,

what sort of issues are you referring to here?

rostopic echo not displaying 'nice' numbers is not really an issue.

gvdhoorn ( 2018-03-27 08:12:27 -0500 )edit

Indeed, the noise is far worse than the floating point precision, it is not about just 'nice' numbers. The problem is that I cannot explain why there is a difference between the datasheet and what is posted on a rostopic.

Lando ( 2018-03-27 08:22:35 -0500 )edit

That I can't help you with I'm afraid (and would be a new question).

You could always try to see what the situation is 'at the source' (ie: the driver), to make sure the conversion to float32 (if there is any) does not result in a catastrophic loss of precision.

gvdhoorn ( 2018-03-27 08:26:17 -0500 )edit

It is most presumably due to floating point precision, I have marked your answer as correct. Thank you for your time!

Lando ( 2018-03-27 08:58:26 -0500 )edit

If your question was really about why your datasheet states something, but you're seeing something else, then I believe this was an xy-problem.

The reason you're seeing 'strange' nrs on the scan topic is most definitely due to limited precision in floating point nrs.

gvdhoorn ( 2018-03-27 09:00:33 -0500 )edit

add a comment

Why won't the /scan topic display rounded values?

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Why won't the /scan topic display rounded values? edit

Comments

1 Answer

Comments

Question Tools

Stats

Related questions

Why won't the /scan topic display rounded values?