map overlapping in corridor and loop closed not working

[casiarobot]

Hi,
Thanks for u last answer !

• map overlapping in corridor
  slam toolbox do great at first, but overlapping
  with nothing changing at the same environment. Not only along the direction of corridor, vertical direction may sometimes happen.
• another problem is that loop searching seems not working
  A square of 130*50 meters with rich features, I have tried many times and falied.

If needed I will upload the configurations and map later.

Thanks again!

[SteveMacenski]

I don’t understand your question or problem. Please upload your content and describe in more detail what you’re doing, what you expect, what your outcome is

[casiarobot]

I think #112 can describe things that have happened! What the difference is that I run slamtoolbox in 'mapping' mode instead of 'localization' mode.
Below are the some maps 'loop searching' failed.

[SteveMacenski]

Your odometry looks exceptionally bad and there’s no reasonable expectation with the default settings to be searching for loops with that incredible amount of deviation.

Please tune your parameters, see the readme for descriptions, as well as tune your odometry. Overall I don’t look at this and see a bug unless there’s more going on here that I’m misunderstanding

Have you made an earnest attempt to tune this software for your platform?

[casiarobot]

Thanks for you advices!
I make many tries these days,such as integrate odom->base_link tf with roll and pitch. However, when deeply read the src, I modify two parameters,

link_scan_maximum_distance: 6.0
loop_search_maximum_distance: 20.0
compared to ever:
link_scan_maximum_distance: 1.5
loop_search_maximum_distance: 3.0

and it works with the same bag data.
Figure is the new map and old.

However, the whole map fail loop closure. Slam toolbox become more and more slow in new scan data and new mapping area is sparely.

[SteveMacenski]

Again, I think your platform needs to focus on better odometry, that drift is really not great. There’s nothing this project is going to be able to do if the base properties don’t produce acceptable priors if you’re operating in large sparse spaces.

The values you had to increase are proportional to odometry quality. You increased the search space by over 6x, so it doesn’t surprise me that its getting slower. The best bang for your buck is to improve your odometry before looking for a slam solution. it doesn’t seem the odometry is suitable for the sparse environments you want to operate in.

[SteveMacenski]

Closing ticket- no action items.

Spend some time to tune your platform.