|
Administrator
|
Hi,
To help to understand, there are three main threads going on in RTAB-Map: Camera thread, odometry thread (i.e., SLAM front-end) and mapping thread (i.e., SLAM back-end).
Camera thread
If the camera rate is 0 (which means infinity), the camera thread will publish images as fast as the sensor can. For example, a Kinect would send images at 30 Hz.
Odometry Thread (SLAM front-end)
The odometry thread doesn't have a rate parameter, as it just try to process received images as fast as possible (yes, it will use 100% of a CPU if the camera rate is higher than the time to compute odometry). For example on my computer, the odometry thread may process only 1 image on 2 if the Kinect is sending images at 30 Hz, so the odometry thread will send new poses at ~15Hz (while using 100% of a CPU). To reduce Odometry CPU usage, you may reduce the Camera rate at the cost of less good odometry.
Mapping thread (SLAM back-end)
In this example, the mapping thread receives odometry data at 15 Hz, but the map doesn't need to be updated as fast. It is why the mapping thread has also a detection rate parameter (i.e., the Rtabmap's detection rate) that is set by default to 1 Hz (if the map updates take 300 ms, I'll have a 30% CPU usage on another CPU). You can reduce the Rtabmap's detection rate to reduce the number of map updates, and at the same time to reduce CPU usage (say if I set to 0.5Hz and it still takes 300 ms to update, I'll have 15% CPU usage), at the cost of loop closures detected less often.
On the GUI (or rtabmapviz), you can increase decimation or voxel size parameters to reduce the number of points shown in the 3D Map view. This will save a lot of CPU. See Preferences->3D Rendering panel.
cheers
|
Locked
