Database Post Processing - Save refined links

[DavideR]

Hi Mathieu,
I need to ask you about a strange not expected behavior post-processing a database.
I'll briefly describe my scenario:

1. Database creation without Link ICP refinement.
2. Open the created database with Database Viewer, change Reg strategy from 0 to 1
3. Refine all neighbour links with ICP Libpointmatcher (I then get a more likely posegraph layout)
4. Close the database saving the changes of the refined links

subsequently to these steps, when i open the database again or when I load it for localization mode in ROS, the graph layout is different from the time I saved it.

I expected somehow that when I saved it at 4. , the graph wouldn't change anymore neither optimized.

Am I doing something wrong?

Thank you for the support

Cheers

Davide

[matlabbe]

Hi Davide,

The behavior should be as you expect, keeping the changes when re-opening the database. Which rtabmap version are you using?

When rtabmap initialize, we load the last optimized graph saved from the last mapping session. In SLAM mode, it is likely that graph will get re-optimized with the new constraints. In localization, it is used "as is". However, those saved optimized poses should be cleared (forcing a re-optimization) when we save refined links with DatabaseViewer.

I re-tested and the changes appear in the next session when when reloading the database in DatabaseViewer. Do you have a database to share to reproduce the problem?

cheers,
Mathieu

[DavideR]

Hi Mathieu,
I'm currently using the last standalone RTAB-Map version 0.19.6
I've also just tried pulling the last version from master branch, but with same results.

I post the image of an analysis of the extracted poses from rtabmap-databaseViewer:

1.The Blue line refers to the graph as soon as it is opened for the first time before any processing.
2.The Red line refers to the refined graph via ICP, before closing it, the poses are exported and plotted.

At this step, the refined graph gets closed and the refined links saved.
Then the same just saved database gets opened again.

3.The Yellow line refers to the graph loaded the second time.

As you can see, the last graph really differs with respect to the second one (we expect them to overlap).

I sent you an e-mail with the link to the database.

Thank you a lot for your support!!

Cheers

Davide

[matlabbe]

Hi Davide,

It seems to be a g2o issue. If I set Optimizer/Strategy=2 (GTSAM) instead, the modified graph is exactly the same when re-opening the database. I think g2o fails because it is a little more sensible to covariances in the links. When we refine, we change those covariances. But why it doesn't re-optimize exactly the same on reload is still an open question... we would have to debug if the poses+covariances that we feed to optimizer are the same just after refining and when we reload the database.

Note that in the database, Reg/Strategy=0, set to 1 if you want to refine with lidar. PM/OutlierRatio=0.01 is very low, normally it would be between 0.5 and 0.9 (the lower the more robust to dynamic objects). In general outdoor, I would not set Reg/Force3DoF to true because the terrain is rarely perfectly flat.

cheers,
Mathieu

[DavideR]

Hi Mathieu,
thank you for working on this issue!

I tried with GTSAM and the graph did not change indeed.

Quoting you:

"But why it doesn't re-optimize exactly the same on reload is still an open question"

My question is why we would want to re-optimize the graph everytime we reload it if we want to just use the database for localization?


PUSH rtabmap-databaseViewer CORE PARAMETERS INTO SAVED CHANGES

Do you think would be a good idea to let the user push the core parameters into the saved changes of the post-processed database?

I find indeed that even though I changed the Reg/Strategy and the Optimizer/Strategy to process the database, this parameters then are not pushed into it. So everytime I open it I find the original parameters.
I think that is why you found Reg/Strategy=0 even though I refined the links with  Reg/Strategy=1.

========================================

Regarding your tips, thanks a lot for your advices!
For PM I'm actually using a lipointmatcher config YAML File where the ratio is set as you said. Would be nice though to have a place to share our filters configuration :).

Regarding the parameter Reg/Force3DoF, I agree on you but when I tried it I found particulary hard and unstable to not have a vertical (Z-Direction) drift, causing a noticeable graph divergence.

Thank you a lot for your dedication.

cheers,
Davide

[matlabbe]

Hi DavideR,

I fixed the problem with the graph not optimized the same way before closing databaseViewer and re-oppeing it.

When we change the graph, the global map should be also re-assembled on ROS side. To easier way to do this is when we modify the graph in DatabaseViewer, we clear all optimized stuff saved in the database to force rtabmap to re-update everything depending on the graph. This is done only one time though, if you re-use the same database in localization mode multiple times, the last optimized graph and map of the previous session will be used directly.

For the parameters modified in DatabaseViewer, they are not indeed pushed back to database, which is keeping the original parameters. I kinda like keeping the original parameters in the database for debugging purpose. Also, if someone changes the parameters and does nothing with them (e.g., changing registration strategy without refining all links), the database could have inconsistencies the next sessions if we push them, which may add bugs difficult to debug. If you want to modify them, it is possible in the launch files: parameters set in the launch files overwrite those saved in the database. Another way is to reprocess the database with the new parameters:

$ rtabmap-reprocess --Reg/Strategy 1 map.db output.db

that way we make sure that all data contained in the database has been reprocessed with the same parameters.

For the libpointmatcher config files, the only way right now is to copy/paste them in a post of a forum or in an issue on github.

cheers,
Mathieu