0
$\begingroup$

Rosanswers logo

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


Originally posted by serhat on ROS Answers with karma: 72 on 2021-10-12

Post score: 0

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

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:

  1. detection too close to determine true distance but not cause an erroneous measurement
  2. an erroneous measurement that has no useful physical quantification; and
  3. 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?


Originally posted by gvdhoorn with karma: 86574 on 2021-10-12

This answer was ACCEPTED on the original site

Post score: 1


Original comments

Comment by serhat on 2021-10-12:
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.

Comment by serhat on 2021-10-13:
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) ; 
}
$\endgroup$
0
$\begingroup$

Rosanswers logo

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.


Originally posted by siddharthcb with karma: 100 on 2021-10-12

This answer was NOT ACCEPTED on the original site

Post score: 1


Original comments

Comment by serhat on 2021-10-12:
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 me to give for such situations?

Comment by siddharthcb on 2021-10-12:
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)
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.