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!
Asked by JotaDePicas on 2020-01-10 12:34:04 UTC
Comments
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
Asked by TuanVo213 on 2021-09-08 21:20:04 UTC
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.readthedocs.io/en/latest/algo_walkthrough.html). 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 a really broad subject, but I hope my pointers help you!
Asked by JotaDePicas on 2021-09-09 09:42:38 UTC
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.
Asked by JotaDePicas on 2021-09-09 09:46:20 UTC
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.
Asked by TuanVo213 on 2021-09-13 22:58:51 UTC