Understanding and correct drift when using BreezySLAM (aka tinySLAM / CoreSLAM)

Question

I was looking for a Python implementation of SLAM and stumbled upon BreezySLAM which implements tinySLAM aka CoreSLAM.

My robot is equipped with the hokuyo urg-04lx-ug01.

I have odometry hence passing it to the updater:

self.slam.update(ls_array, (dxy_mm, dtheta_deg, dt));

As I start moving the robot starts discovering room A and then room B & C already the map seems to have rotated. I come back to room A and return the initial pose end=start using the same path. Now I noticed room A has significantly rotated in relation to the other room. Consequently the map isn't correct at all, neither is the path travelled by the robot.

1. Wasn't the SLAM supposed to store and keep the boundaries for the first room it discovered?
2. Why this rotation may be happening?
3. How could I try to troubleshoot this issue with the data I have collected (odometry, calculated position, liDAR scans)?
4. Can I tune SLAM to do a better job for my robot?

SLAM is pretty new to me, so please bear with me, any pointers on literature that may clarify and moderate my expectations of what SLAM can do.

Extra

... and Here the best video I found to understand particle filter

Answer 1

You'll find that Gmapping works a lot better. I have used core slam quite a bit with the 04lx, tweaked the code, and tuned the algorithm. It works in a lot of cases, but...

If you really want to keep using it, adjust your parameters so that it searches more (more particles) and really make sure that the robot motion is inside the search domain.

While tuning (and in general) monitor your map and restart with better parameters if the map jumps or rotates.

Answer 2

Till now this is the easiest SLAM implementation that I've found. It works pretty well, however, there is a lot of room for improvement using the same principle used in the original code online.

"1- Wasn't the SLAM supposed to store and keep the boundaries for the first room it discovered?

2- Why this rotation may be happening?"

In the implementation you have I would say it failed match the new scan to the already constructed map (there are lots of reasons for this problem)

3- How could I try to troubleshoot this issue with the data I have collected (odometry, calculated position, liDAR scans)?

it depends what hardware you are using. If you are correctly acquiring the Hukuyo scans the algorithm should work even if you have some errors from odometry or IMU, unless, the errors are too large (eg instead of calculating 5cm using odometry you get 100, 200 or 500 for example)

IMU and odometry can help a lot however in the algorithm you are using you can just use the LIDAR, thus the priority is to check your LIDAR scans.

4-Can I tune SLAM to do a better job for my robot?

Of course, you can also rewrite it to include lots of optimizations adapted to the robotic platform you are using.

EDIT:

2- Why this rotation may be happening?"

Try to decrease the maximum rotation speed of your robot

I can't explain the whole algorithm in this post, and as I've previously said there are lots of other reasons, study the theory + read the code to understand what's going on, good luck