What factors can affect the graph size other than the Odometry ?
I had an observation with RTAB-MAP when increasing the MaxFeatures for both Kp and Vis.
( I also set UseOdomFeatures false and LoopClosureReextractFeatures True)
I noticed that the graph size tends to decrease with a larger number of features, but I could not point out the reason. I do though have the following hypotheses:
1- The nodes with bad signatures are discarded from the graph. But this is doubtful since the #poses in the WM and the #bad signatures neither sum up to the full #poses expected (given a detection rate of 1 and the mapping record time) nor to the #poses in the global graph.
2- The odometry is lost at those poses, thus, locations are rejected. But what if the Odometry is from a VIO source (for instance like ZED mini)?
3- RTAB-MAP rejects frames that take a processing time > detection time (e.g. 1 sec). Can this be the reason even if the memory management system is disabled? I am also curious about what happens if the RTAB-MAP takes too long to process a frame? Is it like the sensory memory serves as a buffer to keep the new frames? or do we lose the frames when exceeding the detection rate?
If none of these is correct, then what do you expect is the reason?
Re: What factors can affect the graph size other than the Odometry ?
It would be 3. You can show the processing time using this:
rtabmap-report Timing/Total/ms rtabmap.db
Do "rtabmap-report --stats rtabmap.db" to show all avaialble statistics.
If processing time is over Rtabmap/DetectionRate, rtabmap will skip frames, keeping only latest ones. Rtabmap/ImageBufferSize (default 1) could be increased (or set to 0=inf) to make sure to process all data, however if rtabmap cannot process under the detection rate again, the buffer will increase and rtabmap will be late.