VERY VERY poor quality of map? Please help

[krishnaallani]

Hello all,

I recently came across google cartographer for turtlebot and gave it a try. This is the specification of my system:

1) Ubuntu 14.04 2) Turtlebot 3) ROS Indigo 4) Using Kinect 1.0

I collected a data bag using the turtlebot I have and generated a map using demo_lidar_2d.launch. I have modified the launch file so that it listens to right topics. Here is the link to the launch file:

https://drive.google.com/file/d/0B433_L9e51r-dmRZQlItMkR4ODA/view?usp=sharing

Here is the link to the bag file:

https://drive.google.com/file/d/0B433_L9e51r-aHpHbGRuVmxBaDQ/view?usp=sharing

here is the map I got:

Can someone please help me? I am not able to figure out what I am doing wrong.

Thanks.

[krishnaallani]

@wohe can you help me, please?

[wohe]

I'll be on vacation until October 2. If you still need help by then, I can have a look.

[krishnaallani]

Please take a look once you are back from vacation. Happy vacation!!!

[SirVer]

I looked into your data now. Some assorted comments:

• Running rosrun cartographer_ros cartographer_rosbag_validate -bag_filename ~/Downloads/4_aisle_carto.bag gives me the output I posted into this Gist. It shows that your IMU data is bogus, it jumps backwards in time a few times making it completely unusable. I therefore disabled using the IMU and only use scan matching + odometry.
• At the very beginning of your bag, the laser fan is "fuzzing out" towards the moving direction of the robo. It looks like there is a ramp there or the floor is uneven. This violates the assumptios of 2D SLAM and will make your results poor. But of course this is not the big issue here.
• The first big issue is your odometry: it overestimates left turns and underestimates right turns, leading me to believe that one of your wheels is slipping or has different size than the other. This is most notable in the third 90 degrees rotation of the robot. For a while the laser only sees a tiny part of a wall and apparently odometry slips there, which yields to an overestimation of the angle. Unfortunately we cannot throw odometry away too, since it is required to fix the large featureless hallway mentioned below.
• Then, the robot drives down a long hallway. Loop closure finds good matches in this hallway, leading to a shrinkage of the corridor. Increasing min_score and the confidence in the current movement state of the robot helped a lot here - this requires odometry for speed estimation though.
• Reducing the search window for loop closure was also quite important since your environment is self similar.
• I increased the voxel size of the grid for quicker tuning and also to make the scan matching easier.
• Later in the bag the robot drives for a few seconds so close to a wall that all points of the laser returns bogus readings - this makes the robot basically blind for 5 seconds or so.

Generally speaking your data is of very poor quality. I suggest you start out by fixing your IMU timing and calibrating your wheel odometry. You will have a much easier time getting good maps then.

You can see the tuning that I did in this branch, it makes the map much better than the one you posted, but still unusable, see screenshot below.

[krishnaallani]

Hello @SirVer , Thanks for looking into the problem, I added a few comments:

• Running rosrun cartographer_ros cartographer_rosbag_validate -bag_filename ~/Downloads/4_aislecarto.bag gives me the output I posted into this Gist. It shows that your IMU data is bogus, it jumps backwards in time a few times making it completely unusable. I therefore disabled using the IMU and only use scan matching + odometry. How can i fix my IMU data so that it doesn't jump back in time?_

• At the very beginning of your bag, the laser fan is "fuzzing out" towards the moving direction of the robo. It looks like there is a ramp there or the floor is uneven. This violates the assumptios of 2D SLAM and will make your results poor. But of course this is not the big issue here.

• The first big issue is your odometry: it overestimates left turns and underestimates right turns, leading me to believe that one of your wheels is slipping or has different size than the other. This is most notable in the third 90 degrees rotation of the robot. For a while the laser only sees a tiny part of a wall and apparently odometry slips there, which yields to an overestimation of the angle. Unfortunately we cannot throw odometry away too, since it is required to fix the large featureless hallway mentioned below. I am using turtlebot 2.0 and I checked their documentation and they mentioned that their is no need fo any calibration. But I have been using that turtlebot for awhile. If i want to calibrate it how can should i do it? Then, the robot drives down a long hallway. Loop closure finds good matches in this hallway, leading to a shrinkage of the corridor. Increasing min_score and the confidence in the current movement state of the robot helped a lot here - this requires odometry for speed estimation though. Reducing the search window for loop closure was also quite important since your environment is self similar. I increased the voxel size of the grid for quicker tuning and also to make the scan matching easier. Later in the bag the robot drives for a few seconds so close to a wall that all points of the laser returns bogus readings - this makes the robot basically blind for 5 seconds or so.

Generally speaking your data is of very poor quality. I suggest you start out by fixing your IMU timing and calibrating your wheel odometry. You will have a much easier time getting good maps then.

Repeating the same questions at above, what can i do to imprve my sensor data i.e IMU and odom?

Also, Is there any documentation that I can go through to understand what each parameter in the algorithm means?

You can see the tuning that I did in this branch, it makes the map much better than the one you posted, but still unusable, see screenshot below.

I am not very versed with github, i don't know how to make a pull request so I manually changed the files and i got better results. Thank you very much for your help.

[SirVer]

How can i fix my IMU data so that it doesn't jump back in time?

You have to record it properly. It depends entirely on your recording setup, nothing I can help you with.

I am using turtlebot 2.0 and I checked their documentation and they mentioned that their is no need fo any calibration. But I have been using that turtlebot for awhile. If i want to calibrate it how can should i do it?

I'd drive it along a known path that returns to its starting location. Then calculate wheel odometry and optimize the wheel sizes or so. There are papers for wheel odometry calculations too. Again, this is out of scope of Cartographer.

Also, Is there any documentation that I can go through to understand what each parameter in the algorithm means?

there is https://google-cartographer-ros.readthedocs.io/en/latest/tuning.html and https://google-cartographer.readthedocs.io/en/latest/configuration.html, both are still incomplete. The source is the most reliable documentation for now.