How many points does RTabMap capture per second?

[mcb9216]

It's only a simple question that I'm curious about.
I'm working with kinect 2, and I want to know how many points RTabMap captures per second in order to shape the point cloud?
thanks

[matlabbe]

Hi,

The map is updated by default each second (1 Hz), so it adds a new point cloud each second. At each update, a node with RGB + depth images is added to map. The actual number of points that will be shown is depending on the visualization parameters. For example, if we acquire 640x480 images, we will have a point cloud containing 307 200 points added to map each second. By default, we decimate the images by 4 or 8 before creating the point clouds to limit the number of points. With the kinect v2 and HD images, that is 1920*1080=2 073 600 points per second if the images are not decimated.

cheers

[senia]

I would like to add a question to the post, I saw you referred to the Odometry/TimeEstimation and Timing/Total here as the actual mapping rate, yet when making a graph out of them, I get different and not complete results:

Whats the difference between them? How can I get the actual HZ/FPS of the mapping?
Thanks.

[matlabbe]

Hi,

You cannot show on the same graph Odometry statistics with statistics from other panels as they are not published at the same rate. There is an opened issue here to be able to set x-axis as time instead of sequence number. If your detection rate is 1 Hz, then "Timing/Total/ms" x-axis values are seconds. However for odometry, there is no direct relation between sequence number and time.

Odometry is running as fast as possible (according to input source rate), and in your case at an average of ~50 ms. So the maximum FPS for odometry on your machine is ~1000/50 = ~20 Hz. This would use 100% CPU of a core if camera input rate is equal or higher than 20 Hz (you could have 50% CPU usage if input rate is 10 Hz for another example).

For the mapping update rate, it is fixed by "Rtabmap/DetectionRate" parameter (default 1000 ms or 1 Hz). In your case, you have between 20 ms to 35 ms update time, it means that you are using 2% to 3.5% CPU of a core to update the map.

In summary:
- FPS mapping update is 1 Hz
- FPS odometry update is ~20 Hz

cheers

[senia]

Thanks for the fast replay
So just to make sure, this calculations are for a single core? If I have a quad core processor I could theoretically run at 4*20Hz?

[matlabbe]

The odometry approach is not multithreaded, it is 20 Hz on 1 core (no matter the number of core you have). It will not run at 80 Hz if you have 4 cores. It will just use one core at 20 Hz, the other cores would be idle or used for other threads (like mapping or visualization threads or other programs running at the same time).

cheers