Why RPLidar + gmapping has a bad result?

Question

Now I have a turtlebot 2, and I want to build a map. As gmapping needs odometry, so I think it would have a better result than hector_mapping. As RPLidar has 360 degree while kinect has only 57 degree, so while gmapping, I think RPLidar would has a better result.

However, to my disappointment, the map builded by RPLidar is too bad!

I found that the map builded by rplidar + hector_mapping is really good.

But I really want to know why RPLidar + gmapping could not have a good result, does anyone know this?

Thank you !!

My bagfile.

The bagfile

---

Originally posted by tanghz on ROS Answers with karma: 130 on 2015-03-29

Post score: 0

---

Original comments

Comment by afranceson on 2015-03-29:
I have the same problem. I'm working to some tests about this, maybe can be useful for you too:

Localization problem with gmapping and RPLidar

Comment by tanghz on 2015-03-29:
Thank you very much!!

Comment by tanghz on 2015-04-01:
Wow!!!! You are so great!!! Thank you, thank you so much!!!

Comment by afranceson on 2015-04-02:
Glad to have been helpful!

Comment by tanghz on 2015-04-02:
Thank you for taking the time to give me a hand. Now I have uploaded the RVIZ picture, in the picture,the red or green lines or points are the laser scan data. I increased the size of the laser size.

Now compared with yours, I think the only difference is the tf transform, let me try again. thanks!

Comment by tanghz on 2015-04-02:
I am sorry to have kept you waiting so long. I am a newer to ROS, and I have just learned how to use the rosbag. I upload the bagfile to my network disk. The bagfile I am sorry that I used a Chinese skydrive. To download the bagfile, click the 下载(4.4M) .

Comment by zl3612 on 2016-06-02:
Hey Tang, Could you please teach with using rplidar and hector together？

Comment by tanghz on 2016-07-18:
I am sorry that I see your question until now, and have you solved your question?

Answer 1

You will be happy to know that I fixed my problem with gmapping and LPLidar. You can find a full documentation about the fix here (including source code modification of course): I hope can be useful for you too!

UPDATE

GMapping use two parameters to define laser beam range:

• maxRange: the maximum range of the sensor. If regions with no obstacles within the range of the sensor should appear as free space in the map, set maxUrange < maximum range of the real sensor <= maxRange;
• maxUrange: the maximum usable range of the laser. A beam is cropped to this value.

(Description taken by ros gmapping wiki)

The long lines you see on your map are created when the laser measured range is between maxUrange and maxRange. You can try to set maxUrange = maxRange. By the way I think the real problem is another: why your laser measures this range if there is a wall?

Can you take a picture of RViz where laser scan data is shown too? I suggest to set decay to 120 secs so we can see more data. I want to check if long lines are really generated by laser measures of if they are artefacts of GMapping.

UPDATE

Can you register and upload a bag file of your test? Remember to move the robot in your environment recording data in order to have an idea of the expected map. You should record tf and your laser scan topic.

Further question: on the posted RViz screenshot I can see an entry referring AMCL, are you running it too?

UPDATE

I run some test on your bag data. This the result of odometry test:

Since you are working in large environment (I measured abut 5 meters square room) you can be happy about it! Any way I suggest you to follow this guide (if you already didn't): it will help you not only to improve your robot performances but you can also learn something about navigation stack in ROS.

BTW I ran GMapping with the parameters I suggested and, actually, I reproduced the same problem you claim about (sorry, my environment is not so large so I never experienced it!). Fortunately the solution is easy. Set following parameters:

odom_frame: odom 
delta: 0.025
minimumScore: 50
maxRange: 5.5
maxUrange: 5.5
linearUpdate: 0.2
angularUpdate: 0.25
temporalUpdate: 5

I got this result:

Maybe it is not perfect but:

• on my simulation map -> odom transformation came from your bag file instead my GMapping node. When you will run it on your robot result should be better (please post a picture... I'm curios!);
• RPLidar has a great value/price rate but it have short range laser (look here to appreciate more RPLidar value/cost rate!!). This will cause no optimal performance working in large environment. Any way a trick exists in order to have better result: move you robot close to the wall instead cross the centre of your room and you will se that built map will be better (a comparison picture is appreciated!);
• I saw same jumping in the plotted laser data during robot rotation. The guide I posted should help you (maybe is only noise during my tests caused by conflict between my GMapping and your bag file... better to check).

I hope this will fix your problem!!

---

Originally posted by afranceson with karma: 497 on 2015-04-01

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by tanghz on 2015-04-02:
I am sorry for my disturbing you again, I used all the GMapping parameters just like yours. However, the map has many long lines that over the border. Did you have encountered this problem? I have uploaded the map picture in the question above.

Thank you!

Comment by tanghz on 2015-04-02:
I’m sorry to have kept you waiting so long. Now my map is much better! All of this is under your help, Thank you so much！！

Comment by afranceson on 2015-04-03:
Glad to have been helpful!