Appending new scans on top of a large db

[Pierre]

Hi Mathieu,

Again questions about large scans :)

Often I have a situation where I already have a large scan of an area, on which I closed relevant loops, and about which I'm somehow satisfied. Reprocessing such a large scan can easily take 3 full days for rtabmap-reprocess, typically. Linking all pieces which weren't connected automatically can also take quite some time as browsing the graph in the dbviewer can be hard for large scans (c.f. issue 1376).
Then I scan some more and want to append the new pieces to the existing scan. I use rtabmap-reprocess -a, and it starts by making a copy of the first database. RAM gets filled increasingly (with the full vocabulary tree and BoW related information ?), and it finally the program gets killed, usually after copying ~350gb from the first scan given my configuration.
Hence my only solution is to reprocess everything, which means I have to restart from scratch.
Keeping track of what manual loops I added to link non-connected pieces does help in such a scenario, but it is still far from optimal.

I was wondering if it could be relevant to add the options to append
- in place, so no copy of the original database
- without loading too many things in RAM, this would imply that the relocalisation of the new pieces is not guaranteed, but somehow this is already what happens when we reprocess from scratch: nodes in the WM can very well be far appart from the new pieces.

A similar but different question is about merging databases. I believe that there is no way currently to merge two already processed databases, purely using global/user loops, say. This would imply merging the two vocabulary trees before merging the graphs. For not-too-large databases, loading visual words in RAM like the current version of rtabmap -a does (I believe ?) would be a way of automatically finding relevant loops; in the case of large databases, I could imagine a small GUI displaying the two graphs, where the user can select by hand areas with possible intersections.
Would this be too specific for multisession offline mapping, or could this be something deserving to be integrated to the RTABMap project ?

Thanks for the discussion and the help,

Best,
Pierre

[matlabbe]

Hi Pierre,

You have some interesting suggestions.

- in place, so no copy of the original database

In-place append could be possible to do. Created a ticket.

- without loading too many things in RAM, this would imply that the relocalisation of the new pieces is not guaranteed, but somehow this is already what happens when we reprocess from scratch: nodes in the WM can very well be far appart from the new pieces.

We can disable Mem/LoadVisualLocalFeaturesOnInit to reduce significantly the RAM usage when loading an existing database. For the visual words dictionary, we don't have a way to use it without having it completely in RAM. Using large local feature descriptors would increase the size of the dictionary faster. I think if the dictionary is getting larger than 10 GB, you may consider creating a fixed dictionary of about 5-10 GB (see Kp/IncrementalDictionary and Kp/DictionaryPath parameters).

A similar but different question is about merging databases. I believe that there is no way currently to merge two already processed databases, purely using global/user loops, say.

Not sure if it is exactly what you mean, but we can use option "-pub_loops" option for rtabmap-reprocess.

in the case of large databases, I could imagine a small GUI displaying the two graphs, where the user can select by hand areas with possible intersections.

so would it be used to direct better "detect more loop closures" tool around areas that we know should overlap? Is the goal to avoid long "detect more loop closures" iterations in the graph that we don't care about, or making it faster to focus on only one part of the graph? Is seems that could be relatively easy to add to the CLI tool with a range of nodes we want to search loop closures in. For the UI, we could add these range options in the existing dialog. Currently in the UI, we cannot show at the same time two disjoint sessions at the same time, we would need to optimize from one session, take note of the range of nodes we want to use, then optimize from the other session, take note of the similar paths we want to work with, then launch the detect more loop closures process on these two ranges of nodes.

cheers,
Mathieu

[Pierre]

Hi Mathieu,

Thanks a lot for your answer.

matlabbe wrote

We can disable Mem/LoadVisualLocalFeaturesOnInit to reduce significantly the RAM usage when loading an existing database.

This explains a lot. I hadn't seen that parameter. I suppose that this will more or less solve my problem; an --in_place option would help even more but that was my main issue.

matlabbe wrote

Not sure if it is exactly what you mean, but we can use option "-pub_loops" option for rtabmap-reprocess.

It's part of what I meant and solves most of the issues I had ! Again an option I ignored :)

matlabbe wrote

Not sure if it is exactly what you mean [...]
so would it be used to direct better "detect more loop closures" tool around areas that we know should overlap? Is the goal to avoid long "detect more loop closures" iterations in the graph that we don't care about, or making it faster to focus on only one part of the graph?

I realise I wasn't very clear. I was thinking of a situation where an area was processed in several parts having some intersections. User already closed relevant loops in each reprocessed pieces, and is simply willing to merge them into one large db without doing a full reprocessing of any of them. Main difference with the append function is that the situation is symmetric, there is no prefered db.
I don't know what would be the best way to do that, if it can be done automatically, I thought that a user input on where the intersections are could make the merge easier (a bruteforce detectMoreLoops on common intersection areas could work for instance).

Best
Pierre