Occupancy grid and Working Memory

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Occupancy grid and Working Memory

dnozik
This post was updated on .
hi , Is there way to display/publish full occupancy grid  during mapping with Working Memory MemoryThr=XXX.
Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Occupancy grid and Working Memory

matlabbe
Administrator
Hi,

the full occupancy, no. I don't see why we would want to keep old parts transferred to LTM, as if they disappear, it means rtabmap doesn't optimize anymore that part of the map, so it will eventually drift from reality.

cheers,
Mathieu
Reply | Threaded
Open this post in threaded view
|

Re: Occupancy grid and Working Memory

dnozik
Hi , at any point during mapping total number of signatures = LTM + WM or LTM ( WM is part LTM)?
If I have huge area to map operator like to know what part of area already covered and what not , do view once in awhile full occupancy grid needed.

Thanks,
Dima
Reply | Threaded
Open this post in threaded view
|

Re: Occupancy grid and Working Memory

matlabbe
Administrator
Hi Dima,

For every new node, its data is saved to database by default (in case the robot loses power, we can recover the database up to last node added). WM is nodes in RAM, while LTM contains all nodes on hard-drive.

To keep feedback of what has been mapped so far with memory management enabled, I don't have a solution for that, except that the operator would "know" what he mapped so far. That "workaround" cannot work for autonomous exploration, as the robot would indefinitely re-visit parts of the map moved to LTM.

In that kind of application, we don't use memory management, but instead we enable options to reduce CPU usage and give low res feedback to the operator. One trick is to look at the timing statistics in the resulting database and check how high CPU usage can be reduced with some tuning.

Here are some examples of CPU saving on parts of rtabmap increasing with size of the environment:
* Loop closure detection is relatively fast, but re-balancing visual vocabulary (causing high processing time peaks) could be disabled by setting Kp/FlannRebalancingFactor to 1 without big difference of loop closure performance.
* For graph optimization, GTSAM/Incremental could be enabled, Optimizer/Epsilon could be increased
* For grid map assembling, GridGlobal/UpdateError could be increased to trigger full updates less often. If you are using rtabmap_viz, you can increase resolution under Prefrences->Grid Map Assembling to save time on rendering.

We saw on some systems that RAM usage would bust before real-time threshold because visual vocabulary becomes too large. I am planning to optimize that at some point: https://github.com/introlab/rtabmap/issues/1201

cheers,
Mathieu