Using Precomputed Dictionary

[sumitsarkar1]

Any tips on how to use precomputed dictionary instead of increamental dictionary. Like how to set "Path to a pre-computed dictionary"

[matlabbe]

When setting Kp/IncrementalDictionary to false, you have to set Kp/DictionaryPath to a path of a database created previously (ideally in similar area to have similar visual features).

With the standalone:

1. Make a new map with default parameters
   • Advanced users could uncheck "Keep sensor compressed data." under Preferences->Database to just keep the visual words (smaller database).
2. Close/Save the database (e.g., dictionary.db)
3. Go in Preferences->Vocabulary, unckeck incremental dictionary and set path to just saved database.
4. Close Preferences, click on New Database
5. Create a new map, you are now using a the fixed dictionary.

[hellovuong]

Hello @matlabbe, I think the checkbox "Keep sensor compressed data." is not working as described.
It calls function Parameters::kMemImageKept() - which is only decided that should we keep the raw data in the RAM (Because it chagened the parameters kMemImageKept only - line_cpp and line_ui). As the result, if we want to keep/not keep compressed sensor data in the database there is no option, it will save the compressed sensor data in the database anyway (this line). Please correct me if I misunderstood the code!

Do you think it is a good practice if we don't save image/depth compressed data in the database (smaller .db file size), in the case that there is no plan to reprocess the database or detected more loop closures in future?

[matlabbe]

Description of those 2 parameters:

Param: Mem/BinDataKept = "true"                            [Keep binary data in db.]
Param: Mem/ImageKept = "false"                             [Keep raw images in RAM.]

Mem/ImageKept is mostly UI related, to avoid decompression of image data when showing the 3D point clouds. Rendering would be then slightly faster, but would use a lot more RAM, it is why it is disabled by default.

For Mem/BinDataKept, this will affect the data saved in the database. There is indeed no way to save "not compressed" data to database. It is either we keep the compressed data or not. Examples below show the size of the two databases generated with and without Mem/BinDataKept. Compression is lossless for all kind of data (depth image and lidar data), expect for RGB images by default. If you want to save lossless RGB images, set Mem/ImageCompressionFormat to .png.

Saving the binary data can help to debug better the map afterwards, or reprocess with different parameters. If you don't save RGB+Depth images, you won't be albe to change the feature type when reprocessing it, but you can still reprocess the database with the saved features in the database (you can then tune all other rabmap parameters except those related to feature keypoint detection and extraction). You won't be also able to regenerate the local occupancy grids (if they were generated from depth images).

In general, you may switch to Mem/BinDataKept=false on production, but keep it Mem/BinDataKept=true for development.

rtabmap-info rtabmap.db

Path:               rtabmap.db
Version:            0.18.3
Sessions:           3
Total odometry length:104.904915 m
Total time:         437.211651s
LTM:                416 nodes and 61089 words (dim=32 type=8U)
WM:                 404 nodes and 60639 words
Global graph:       416 poses and 988 links
Optimized graph:    404 poses (x=988->-1, y=3->-7, z=3->0)
Maps in graph:      3/3 [0(201), 1(101), 2(102)]
Ground truth:       0 poses
GPS:                0 poses
Links:
  Neighbor:         802
  GlobalClosure:    186
  LocalSpaceClosure:0
  LocalTimeClosure: 0
  UserClosure:      0
  VirtualClosure:   0
  NeighborMerged:   0
  PosePrior:        0
  Landmark:         0
  Gravity:          0

Database size:      98 MB
Nodes size:         66 KB	(0.07%)
Links size:         340 KB	(0.35%)
RGB Images size:    47 MB	(48.68%)
Depth Images size:  29 MB	(29.90%)
Calibrations size:  114 KB	(0.12%)
Grids size:         4 KB	(0.01%)
Scans size:         0 Bytes	(0.00%)
User data size:     0 Bytes	(0.00%)
Dictionary size:    3 MB	(3.59%)
Features size:      16 MB	(17.21%)
Statistics size:    510 KB	(0.52%)
Other (indexing, unused):-420044 Bytes	(-0.43%)

rtabmap-info rtabmap_nobindata.db

Path:               rtabmap_nobindata.db
Version:            0.18.3
Sessions:           3
Total odometry length:104.904915 m
Total time:         437.211651s
LTM:                416 nodes and 61089 words (dim=32 type=8U)
WM:                 404 nodes and 60639 words
Global graph:       416 poses and 988 links
Optimized graph:    404 poses (x=988->-1, y=3->-7, z=3->0)
Maps in graph:      3/3 [0(201), 1(101), 2(102)]
Ground truth:       0 poses
GPS:                0 poses
Links:
  Neighbor:         802
  GlobalClosure:    186
  LocalSpaceClosure:0
  LocalTimeClosure: 0
  UserClosure:      0
  VirtualClosure:   0
  NeighborMerged:   0
  PosePrior:        0
  Landmark:         0
  Gravity:          0

Database size:      20 MB
Nodes size:         66 KB	(0.32%)
Links size:         340 KB	(1.64%)
RGB Images size:    0 Bytes	(0.00%)
Depth Images size:  0 Bytes	(0.00%)
Calibrations size:  114 KB	(0.55%)
Grids size:         4 KB	(0.02%)
Scans size:         0 Bytes	(0.00%)
User data size:     0 Bytes	(0.00%)
Dictionary size:    3 MB	(17.03%)
Features size:      16 MB	(81.75%)
Statistics size:    510 KB	(2.46%)
Other (indexing, unused):-783612 Bytes	(-3.78%)

[hellovuong]

@matlabbe Thank you for the intuitive and informative answer as always!