Why RPLidar + gmapping has a bad result?

edit

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 ...