sensor_msgs/LaserScan.msg ==> range_max should be discarded

asked 2021-10-12 02:46:57 -0500

serhat
72 ●9 ●11 ●19

Hi all, I have been dealing with slam_gmapping package and I have reached good results so far.(I created my map by the package) But I have a question about sensor_msgs/LaserScan.msg specifically. For describing my problem a lot faster, I want you to look at the picture below. In the picture, you can see my /scan topic and a view of Rviz. When you look at the /scan topic, I selected some of those ranges data where start off with the value of 65.53399. You can clearly see the relevant points in the Rviz screen too since they are far away from average measurements. As I pass such scan data into slam_gmapping package, the map is not created well.

I believe that the value of 65.53399 in the /scan topic is used for failed scan data or something like that. I should not take these measurements account in the context of creating a map. But how? In the LaserScan.msg there is an explanation goes like that:

float32[] ranges # range data [m] (Note: values < range_min or > range_max should be discarded)

What I should understand of discarding data in the ranges std::vector? What value I should give for such failed/max data instead of leaving them as they are? Any idea or useful links? Thank you all in advance!

image description

edit retag flag offensive close merge delete

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2021-10-12 05:44:31 -0500

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

updated 2021-10-12 05:46:32 -0500

I believe this is covered by REP-117: Informational Distance Measurements.

Specifically (I've changed the formatting slightly):

Specification

For any sensor measurement that reports physical distance (see Range, LaserScan, PointCloud2), three special conditions will be well-defined. These readings shall be:

detection too close to determine true distance but not cause an erroneous measurement

an erroneous measurement that has no useful physical quantification; and

no information within the useful range of the sensor but likely no object within range.

Detections that are too close to the sensor to quantify shall be represented by -Inf. Erroneous detections shall be represented by quiet (non-signaling) NaNs. Finally, out of range detections will be represented by +Inf.

I would suggest you update your lidar driver to follow this convention.

Consumers should then be able to correctly interpret your LaserScans.

I write the scan program by myself. I don't use any launch file or library.

this confuses me a little. The screenshot you show seems to imply you're using a Hokuyo scanner. Those have traditionally been very well supported in ROS, and the drivers should already conform to REP-117. Can you not use those?

edit flag offensive delete link

Comments

Hi gvdhoorn, thank you for your reply. I will work on the links you shared to improve my program. I appreciate.

I use this sensor(HOKUYO UAM-05LP). I will check some hokuyo laser scanner libraries/drivers such as http://wiki.ros.org/hokuyo_node in order to check I can use these drivers or not for my sensor. If I can use them properly, I'd switch to use them quickly instead of my own program.

serhat ( 2021-10-12 06:16:08 -0500 )edit

Hi all, I did an amendment according to this documentation(REP-117: Informational Distance Measurements) in my program. I added a if-statement like below. This solved my problem, I am able to use this scan_data to create a quality map with slam_gmapping package now. I guess, slam_gmapping package recognizes the value of -Inf,+Inf, and NaNs in the ranges vector in the /scan_topic. And handles all data by itself according to SLAM algorithm that it uses.

for (size_t i = 0; i < 1081; i++)
{
   float scan_item = scan_data[i] /1000.0  ;  
   if(scan_item == 65.53399658203125)
       laser_example.ranges.push_back( +INFINITY) ; 
   else
       laser_example.ranges.push_back( scan_item) ; 
}

serhat ( 2021-10-13 09:23:45 -0500 )edit

add a comment

answered 2021-10-12 03:44:27 -0500

siddharthcb

100 ●9 ●17 ●19

updated 2021-10-12 03:54:15 -0500

Usually your lidar launch file will have a range_max parameter. You can keep it to whatever your desired value is. If the range_max parameter is not in your launch file, try running your lidar launch file and doing rosparam list to see if there is a range related parameter.

As I can see in the image you have posted, your range_max is set to 100.

You can just modify it directly in your launch file.

float32[] ranges # range data [m] (Note: values < range_min or > range_max should be discarded)

It means that any distance value coming from the lidar that is less than your desired range_min or distance value more than your desired range_max will be either shown as 0 or removed from the list of your distance array.

edit flag offensive delete link

Comments

Hi siddharthcb, thank you for your reply. I write the scan program by myself. I don't use any launch file or library. In short, I publish what I got from the sensor(raw data). And the sensor gives these broken values occasionally.

If I assign 0(zero) for failed scan in the /scan topic; slam_gmapping will suppose that this specific angle in the map is occupied while we don't know whether this specific angle is occupied or not in reality. That's why I found illogical to assign 0 for unknown angles. Alternatively, if I remove the 65.53399 values in ranges vector; then my scan.ranges.size() will change and cause that I can't express 270 degree(angle_max-angle_min) with an array with 1081 elements(sensor resolution for 270 degree) no more. Because I remove some amount of measurements out of ranges vector. What slam_gmapping package expect ...(more)

serhat ( 2021-10-12 05:37:03 -0500 )edit

what is the maximum range you want your lidar to read? It has to be occupied because it corresponds to some angle. Btw, you can always set the max_range in your publishing node, suppose you do not want anything more than 50, just set

data.range_max = 50
pub.publish(data)

siddharthcb ( 2021-10-12 05:46:13 -0500 )edit

add a comment

sensor_msgs/LaserScan.msg ==> range_max should be discarded

2 Answers

Specification

Comments

Comments

Question Tools

Stats

Related questions

sensor_msgs/LaserScan.msg ==> range_max should be discarded edit

2 Answers

Specification

Comments

Comments

Question Tools

Stats

Related questions

sensor_msgs/LaserScan.msg ==> range_max should be discarded