cartographer-project / cartographer

Cartographer is a system that provides real-time simultaneous localization and mapping (SLAM) in 2D and 3D across multiple platforms and sensor configurations.
Apache License 2.0
7.15k stars 2.25k forks source link

Global loop closure optimization breaks the map #141

Closed esonetec closed 7 years ago

esonetec commented 7 years ago

Hello guys,

i am testing cartographer now since few weeks and have occasionally the problem, that the global loop closure optimization makes the almost perfect map much worse.

See this example: image (before optimization)

image (after optimization)

I am running cartographer with a 2d lidar (40hz, <60m range) and an imu (40hz) on ubuntu 14.04, ros indigo. I use the latest sources of cartographer.

You can find here an example bag files to reproduce the issue i am describing: https://drive.google.com/file/d/0B9jUq7WkDIxbOE95cHhJVGlPMFU/view The lua configuration i use: https://drive.google.com/open?id=0B9jUq7WkDIxbbkVXRjBYanNRT00 Launch file: https://drive.google.com/open?id=0B9jUq7WkDIxbdkRyaGxDbU5lTnc

I read in #127 the advice increasing the huber_scale and min_score. I played around with different values and in many cases the quality of the map is getting worse.

Is the cause for worse maps in my case the same reasons as described in #127? Are their any other parameters one can/should tune for getting the global optimization produce more "stable" results?

Thanks in advance!

damonkohler commented 7 years ago

First, sorry for the delay.

I experimented with your bag and found some settings that work reasonably well.

The generally guidance is that, as the sensor FOV is decreases, reliance on local SLAM must increase. Since your laser scanner is only 180 degrees, I increased the number of scans per submap, increased the minimum score required for loop closure detection, and decreased the Huber scale:

TRAJECTORY_BUILDER_2D.submaps.num_laser_fans = 270

SPARSE_POSE_GRAPH.optimize_every_n_scans = 270
SPARSE_POSE_GRAPH.optimization_problem.huber_scale = 1e1
SPARSE_POSE_GRAPH.constraint_builder.min_score = 0.8

Enabling correlative scan matching also helps a bit.

image

I also noticed that the transformation for your IMU seems incorrect. It seems to be oriented z-down and your static transform for it is looks to be around yaw, not pitch or roll.

Lastly, setting the variance of odometry has no effect since you have no odometry. Setting it to 0 in any case would be a bad idea as well.

esonetec commented 7 years ago

Hey damonkohler,

thanks a lot for looking into it! I can confirm that the map is now looking as good as in your screenshot.

You are right that the TF for the IMU is incorrect. I had put the wrong orientation data in the launch file accidently while extracting it from our code.