# How many range readings does a sensor_msgs::LaserScan contain?

When I look at the definition of the sensor_msgs::LaserScan I notice the following parameters that influence the number of range readings I would expect:

float32 angle_min        # start angle of the scan [rad]
float32 angle_max        # end angle of the scan [rad]
float32 angle_increment  # angular distance between measurements [rad]


I didn't notice a separate parameter for the number of range readings in the message format, and no information regarding whether angle_max can be treated both as an included and excluded upper bound.

This question's answer seems to suggest that the value of angle_max is included in the dataset. Which seems to be the common practice for "real" laser scanner drivers. (And I have seen at least one library that expects the scan to have a length of exactly (angle_max - angle_min) / angle_increment + 1.)

In contrast, I have seen authors of publisher nodes calculate the size of the ranges array similar to this:

num_readings = std::ceil( (angle_max - angle_min) / angle_increment );


or the angle_increment similar to this:

angle_increment = (angle_max - angle_min) / num_readings;


Which seems to imply that the range of valid angles does not include the value of angle_max. (Consider for example the settings angle_min = -1, angle_max = 1, angle_increment = 1; which would allow only two valid values, thus not include the value of angle_max.)

Is it up to the writer of the publisher to decide, and subscribers should rather query the size like this: msg->ranges.size() and ignore the value of angle_max or is this a bug on the side of the publishers?

edit retag close merge delete

1

subscribers should rather query the size like this: msg->ranges.size()

regardless of the answer you get to your main question, I would say that: yes, that is probably how you should process the ranges vector/list/array.

How would you want to do it otherwise?

( 2018-03-27 08:50:08 -0500 )edit

@gvdhoorn Right now I'm dealing with a library that throws errors because it approached the task the inconsistent way :(

( 2018-03-27 09:02:42 -0500 )edit

I must agree with you that it appears to be underdocumented whether angle_min and angle_max should be treated as inclusive or exclusive. That could definitely lead to undesirable situations, as you describe.

Perhaps @tfoote has some insight here.

( 2018-03-27 09:04:35 -0500 )edit