Clarification about the input synchronization step

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

Clarification about the input synchronization step

1fabrism
Hello, I have a question about how exactly RTAB-Map synchronizes the input topics camera images and odometry.

My Setup:
I have a RealSense camera which I already set to sync the color and depth images (as well as camera info) when publishing them on their respective ROS topics. Then I have an EKF from the robot_localization ROS package that fuses wheel encoders with IMU and visual odometry to produce a filtered odometry. This is what goes into RTAB-Map.

I looked into how ROS syncs topics, with the ExactTime or ApproxTime policies, and I was wondering if this is what is controlled by RTAB-Map's "ApproxSync" parameter? If I set this to "False", will RTAB-Map only create a node if and only if the camera and odometry topics have the same nanosecond-precision timestamp? Or does that parameter just control the synchronization of the camera images?
Basically, what I want to know more about is how does RTAB-Map sync odometry with camera images. How does it ensure that the data points from the two topics were taken at the same time?

Thanks in advance.
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about the input synchronization step

matlabbe
Administrator
Hi,

Yes, the approx_sync parameter refers to Approximate (when true) and Exact (when false) time policies: http://wiki.ros.org/message_filters#Policy-Based_Synchronizer_.5BROS_1.1.2B-.5D

When false, it means that the input topics should have exactly the same stamps. If odometry messages don't share exactly the same stamp than RGB and depth images, approx_sync would be set to true. I say "would" because it depends if we use odometry from the topic or TF. In case we are using TF by setting odom_frame_id (with odom_tf_angular_variance and odom_tf_linear_variance), approx_sync should be false. If odom_frame_id is not set, the odom topic will be synchronized. In this case approx_sync needs to be true. The problem is that we don't want to do approximate synchronization of RGB and Depth images. The rgbd_sync node can be used to pre-sync the image data before rtabmap node. So we exactly synchonize RGB and depth images to rgbd_sync (with approx_sync=false), then the output of rgbd_sync is fed to rtabmap synchronizing with odom topic (with approx_sync=true and subscribe_rgbd=true). See this example for details. See also Figure 6 in this paper.

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

Re: Clarification about the input synchronization step

1fabrism
The RealSense ROS package offers a parameter called "enable_sync" which I set to True and already syncs the camera topics to the same timestamp. So as I understand I don' t need RTAB-Map's own rgbd-sync nodelet. Indeed I'm not using it and I set approx_sync to false in both rgbd_odometry and rtabmap nodes, and it works.

My parameters:
approx_sync=false
odom_frame_id=""
subscribe_rgbd=false
(complete list from my launch file here: https://pastebin.com/hBj2KVpL)

So does this mean that the way I set it up RTAB-Map only creates a map node if and only if the filtered odometry and camera topics have the exact same timestamp? Because it doesn't seem to be this way, as I'd imagine it would take forever for a new node to be created while in reality it's 1 Hz frequency.
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about the input synchronization step

matlabbe
Administrator
Hi,

If you are using rgbd_odometry, you can indeed use approx_sync to false and not use rgbd_sync, as odometry topic has exactly the same stamp than the input images. rtabmap will synchronize exactly RGB+depth+odom, which is correct in your case. rgbd_sync would be used when we want to synchronize with external odometry that is not synchronized with the cameras.

The detection rate of rtabmap is set to 1 Hz by default (Rtabmap/DetectionRate). In your case, it should be able to synchronize exactly the input topics (they have all the same stamps), so rtabmap should update at 1 Hz.

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

Re: Clarification about the input synchronization step

1fabrism
I am actually passing the rgbd odometry to a kalman filter node to be fused with other sensors. The odometry that goes to rtabmap is /Kalman/odometry/filtered. I haven't checked the timestamps but I doubt the filtered odometry would be synced with the camera topics, also because they're published at different rates (24 vs 30 Hz).
I'm still not using rgbd_sync though, without getting any errors. Does that mean that in this case rtabmap is automatically reverting back to approxymate synchronization?

Thanks for your patience!
Reply | Threaded
Open this post in threaded view
|

Re: Clarification about the input synchronization step

matlabbe
Administrator
No, it is still using exact synchronization. I think when the kalman filter is updated with an image, it outputs its update with the same stamp, which could explain why it is working.