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?
Asked by moooeeeep on 2018-03-27 08:20:01 UTC
Comments
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?
Asked by gvdhoorn on 2018-03-27 08:50:08 UTC
@gvdhoorn Right now I'm dealing with a library that throws errors because it approached the task the inconsistent way :(
Asked by moooeeeep on 2018-03-27 09:02:42 UTC
I must agree with you that it appears to be underdocumented whether
angle_min
andangle_max
should be treated as inclusive or exclusive. That could definitely lead to undesirable situations, as you describe.Perhaps @tfoote has some insight here.
Asked by gvdhoorn on 2018-03-27 09:04:35 UTC
Try out len(msg.ranges) if using python, where msg is the object published by your sensor.
Asked by sritee on 2018-10-19 01:45:18 UTC