Submap Deletion

[domeinzer]

We would like to use cartographer for a long time (i.e. >8h): However cartographer is consuming a lot of RAM at the moment.
Our suggestion would be to remove old/unnecessary data, such as submaps and respective constraints, to do so.
This was already mentioned in #197. So, the simplest idea to start with would be to remove the oldest data and have a sliding window of size n over the
submaps. More advanced idea to delete submaps are possible, too, but may be harder to start with.

We were digging into submap deletion and have several concerns about the implementation:
Probable problems:
- constraints to the submap index i have to be reformulated or preferably removed completely (RAM is also influenced by constraint list size)
- submaps are often identified by their index in different list structures either these indexes have to be recomputed and changed acordingly in other data structures that use it as a reference or a unique id should be implemented as such a reference instead (i.e. convert lists to dictionaries etc.)
- submaps are defined as 'const' everywhere

Maybe no problems, but good to keep in mind:
- (optimized_)submap_transforms may not be correct until new run_optimization() execution
- GetConnectedTrajectories() may not be correct
- we need to keep enough submaps to cover the whole area (at least once) --> larger area, more submaps to keep

Also, we may want to delete even trajectory_nodes j from a deleted submap i in order to save RAM. However, this would cause new problems, because trajectory_node j may be used in a constraint from another submap.

Does anybody work on a related topic?
Where could we start the easiest way?

Our plan is to focus on submap deletion first, while doing the following:

1. create interface to delete a submap
2. come up with a good method to detect unnecessary submaps --> enables everybody to remove outdated/redundant information

[SirVer]

Hi and welcome to the Cartographer project! Out of curiosity, when you say "We" what organization are you talking about?

@wohe and myself are interested in getting pure localization working - i.e. a trajectory that only adds a sliding window of Submaps to the optimization problem. This is actually in some sense the culmination of livelong mapping since it requires serialization of Catographer's state as well as deleting of submaps. I think if this is in place, you could experiment with more complex deletion strategies.

constraints to the submap index i have to be reformulated or preferably removed completely (RAM is also influenced by constraint list size

Constraints to deleted submaps must be deleted as well. That should not be difficult.

submaps are often identified by their index in different list structures either these indexes have to be recomputed and changed acordingly in other data structures that use it as a reference or a unique id should be implemented as such a reference instead (i.e. convert lists to dictionaries etc.)

This is #256. We are making good progress on that right now, but it is a difficult refactoring.

submaps are defined as 'const' everywhere

I think this is correct - a Submap will not change, you can only drop it as a whole. At least that is the design we currently favor. Why does that concern you?

we need to keep enough submaps to cover the whole area (at least once) --> larger area, more submaps to keep

I think the strategy of which submaps to delete depends on the domain problem and should be kept outside of Cartographer.

[ahundt]

One approach is to have a canonical map/model that is kept up to date so old data can be discarded after a certain limit without being lost completely.