Low FPS (~3-4 Hz) on /odom Topic When Using Multi-Camera Setup in RTAB-Map ROS

[AayushEIC]

Hello,

We are encountering low frame rates (around 3-4 FPS) on the /odom topic (rgbd-odometry node) when using RTAB-Map ROS on Orin Nano . This issue occurs both with a single RGB-D camera and a multi-camera setup(3 Realsense Camera) , but our main objective is to run RTAB-Map with multiple RGB-D cameras for better localization and mapping.

Details: ROS Version: Humble RTAB-Map Version: 0.22.1 Platform: Ubuntu 22.04.5 Cameras used: Realsense D435 Platform : Orin Nano

We have already tested: Using a single camera — FPS remains low (~3-4 Hz) for /odom. Using multiple cameras — FPS remains low (~3-4 Hz) for /odom.

Questions: What could be causing this FPS bottleneck? Are there any recommended parameters or optimizations to improve the /odom rate, especially for multi-camera configurations?

[matlabbe]

Can you show what the topic diagnostics of rgbd_odometry node say? (maybe a screenshot of it)

ros2 run rqt_runtime_monitor rqt_runtime_monitor

Can you also show the processing time used by rgbd_odometry? the log appearing at each update. If the processing time is under 200 ms, the bottleneck may be the publisher or synchronization of the cameras. The runtime monitor would show the actual input rate it is synchronizing the topics.

[AayushEIC]

Hi @matlabbe , Thanks for support..! We have attached screenshot of diagnostics of rgbd_odometry and logs appearing at each update.

log_rtabmap.txt

[KimchiPizza]

I think it's camera problem, Check the camera FPS without rtabmap node and sync node.

[AayushEIC]

Hi @KimchiPizza ,

We are running three RealSense cameras at 15 FPS. Up to the synchronization node, our pipeline has three main stages:

Camera Input – Each RealSense camera publishes RGB, depth, and camera-info topics at 15 FPS.

Software Synchronization – Using a message filter, the three camera streams are synchronized. This node outputs synchronized RGB, depth, and camera-info topics at about 13–14 FPS.

Registration – The synchronized streams are registered. This node publishes three RGB images, three RGB camera-info messages, and the registered depth image, operating at around 12–13 FPS.

[matlabbe]

@AayushEIC you can click on "rgbd_odometry: Input status" to show the actually statistics on the right panel.

EDIT: looking at the log file, there are a couple of issues that we can see, here two of them:

[rgbd_sync-1] [WARN] [1758626995.542895230] [rgbd_sync1]: The time difference between rgb 
and depth frames is high (diff=0.107114s, rgb=1758626994.982943s, depth=1758626995.090056s). 
You may want to set approx_sync_max_interval lower than 0.01s to reject spurious bad synchronizations 
or use approx_sync=false if streams have all the exact same timestamp. Setting approx_sync_max_interval 
will suppress this warning.
[...]
[rgbd_odometry-4] [INFO] [1758626995.629428245] [rgbd_odometry]: Odom: quality=243, 
std dev=0.008269m|0.017423rad, update time=0.082615s delay=0.539361s

1. The time diff between RGB and depth for synchronization can be very high (> 100 ms). That would give very poor depth registration when the robot is moving.
2. That something the diagnostic can show, the processing time versus output delay. In that case, processing the frames took 80 ms, but the output delay is over 500 ms. That means 420 ms were lost in synchronization.

Note that when looking at frequency of all input topics, you should do a ros2 topic hz for every topics at the same time, to really estimate the actual frequency.