# Cartographer: how to minimize impact of robot rotation in map

Hi, I'm using cartographer (without odom, ie. cartographer itself provides odom) + nav2d, to SLAM + autonomous navigation.

Linear movement of the robot is handled pretty well by cartographer, but rotations usually cause the map to break, in the form of a second room being mapped, rotated from the previous one (instead of the robot rotating inside the existing room).

I see the laser scan data seems accurate, but rotations cause a lot of log entries similar to this one:

I0820 11:16:35.175624  4240 constraint_builder_2d.cc:267] Node (0, 100) with 202 points on submap (0, 0) differs by translation 0.02 rotation 0.005 with score 39.5%.


(actual numbers may differ, sometimes the score or the translation/rotation numbers as higher or lower)

It seems as if rotations almost are invalidating the map, and lots of entries like the one above appear in the log. When this entries stop, the map "stabilizes" again, but the result is a newly "rotated" room, while also preserving the previously mapped one. I see that if I constrain the robot angular velocity (maybe by a lot) the problem is somewhat mitigated, but not really resolved.

Is this a common problem? (dealing with rotations causing a lot of noise in the map and "phantom" rooms being added to it). Are there any general guidelines for addressing this type of problem?

Thanks!

edit retag close merge delete

Hi Jota I got the same problem. As I already added IMU topic to Cartographer, I saw that the problem is still there. Did you solve the problem

( 2021-09-08 21:20:04 -0500 )edit

Hi @TuanVo213. Well, yes. In short, when the map breaks like that it's most probably because cartographer cannot keep up with new data and/or submap matching is experiencing some problems. If the problem is little and looks like it needs "fine tuning", then probably trying different values for rotation weights, filters and so on, can produce some good results (refer to https://google-cartographer-ros.readt...). But if the map looks completely broken like it was my case, at least in my experience, it was because there was too much computation to do and that, in turn, could be because a) your cpu is too slow or it's throttled (that happened to me in a raspberry pi), o b) you are using the wrong scan matcher/wrong configurations, either real-time correlative scan matcher or ceres and again, it's too heavy to compute in a timely manner. This is ...(more)

( 2021-09-09 09:42:38 -0500 )edit

Oh and btw, adding more topics for cartographer to consume does not necessarily improve results. I'd recommend starting as small as possible (only with a /scan topic for example), make it work "good enough", and then build your way up from there. IMU, Odometry and so on, can in fact complicate things if your basic map building based on laser scans alone is not robust enough. At least that was my experience after long hours of trial and error.

( 2021-09-09 09:46:20 -0500 )edit

Hi Jota. I appreciate for your comments. I am reading to understand the parameters meaning. Now the result is a little bit better. I will try more.

( 2021-09-13 22:58:51 -0500 )edit

Sort by » oldest newest most voted

IMU should improve results significantly

more