Open gaschler opened 6 years ago
Following as I'm currently also tuning for better efficiency.
@gaschler do you think the problem exists or is worse if you create a map of 400 submaps on a small area but by doing multiple laps? I might be wrong but I do not think that cartographer "merge" the submaps.
is worse if you create a map of 400 submaps on a small area but by doing multiple laps?
Yes, the constraint search on a large set of submaps is expensive.
I might be wrong but I do not think that cartographer "merge" the submaps.
Right, but here's currently some experimental work going on to filter maps with redundant, overlapping data.
exists or is worse if you create a map of 400 submaps on a small area but by doing multiple laps?
Where submaps are located does not matter for global constraint search.
If you are localized (i.e., trajectories are connected by a constraint), global search is off and this issue is less severe and will only show up at even larger numbers of submaps when informed constraint search takes too much time.
Informed constraint search may search more when the are many (overlapping) submaps in your area, but I haven't seen this issue in practice.
Right, but here's currently some experimental work going on to filter maps with redundant, overlapping data.
@MichaelGrupp great, is it possible to have more information about this feature?
Informed constraint search may search more when the are many (overlapping) submaps in your area, but I haven't seen this issue in practice.
I think I ran into this case but I need to investigate further.
IIRC, this was covered in one of the last open house sessions (see README), but is still an experimental thing that's not in master. @pifon2a can tell you more probably.
Overlapping trimmer is in master.
Also the executable?
@MichaelGrupp there is no separate executable. Just enable it in the TrajectoryBuilderOptions.
For localization on a frozen map of 400 submaps, for instance on a map generated with default config from https://storage.googleapis.com/cartographer-public-data/bags/backpack_2d/b2-2015-02-16-12-43-57.bag, global SLAM can no longer keep up with default config (and is limited by constraint search), which is undesirable for real-time localization. It can keep up with a lower
POSE_GRAPH.global_sampling_ratio
and lowerPOSE_GRAPH.constraint_builder.sampling_ratio
(and easily localizes) or higher numbers of threads.https://github.com/googlecartographer/cartographer/blob/e8b0bfb2852e18acc6d73373c99a705d781d7776/configuration_files/pose_graph.lua#L80
Before a global match is found, the computation is particularly expensive because constraints are searched globally.
A suggestion would be to configure a maximum number of constraint searches for a new node rather than a ratio. This would be easier to tune for real-time pure localization on larger maps.