You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With rtabmap's odometry nodes, we have a sync callback for images, and another independent callback for IMU topic, it seems callback executor behavior doesn't provide received topics in FIFO manner if our callback is longer than frame rate of the input topics, causing this error even if in reality imu topics with recent stamps are already in the callback queue: [rgbd_odometry-2] [ERROR] [1725236241.284662243] [rtabmap.rgbd_odometry]: Overwriting previous data! Make sure IMU is published faster than data rate. (last image stamp buffered=1725236241.217457 and new one is 1725236241.250856, last imu stamp received=1725236241.196509)
While we were busy processing latest data (last 50 ms) in previous odometry iteration, we received image (30 Hz) and imu topics (200 Hz). The callback queue may then contain 1-2 images and a dozen of imu topics, that may be arranged like this (where I is image and U an imu):
A deterministic executor would process them in order FIFO, avoiding the error above. A non-deterministic one could process them in that order:
U1
U2
I1 (<triggering a wait till we have imu U5 before to continue)
U3
I2 (<triggering the error above, overwriting previous image, we now wait till U12 is processed)
U4
U5
U6
Note also that could be why it is so difficult now to tune approximate synchronizers if they also not receive topics in order.
The text was updated successfully, but these errors were encountered:
matlabbe
changed the title
ROS2 Jazzy: callbacks not called anymore in same order than topics received
ROS2: callbacks not called in same order than topics received
Sep 2, 2024
With rtabmap's odometry nodes, we have a sync callback for images, and another independent callback for IMU topic, it seems callback executor behavior doesn't provide received topics in FIFO manner if our callback is longer than frame rate of the input topics, causing this error even if in reality imu topics with recent stamps are already in the callback queue:
[rgbd_odometry-2] [ERROR] [1725236241.284662243] [rtabmap.rgbd_odometry]: Overwriting previous data! Make sure IMU is published faster than data rate. (last image stamp buffered=1725236241.217457 and new one is 1725236241.250856, last imu stamp received=1725236241.196509)
While we were busy processing latest data (last 50 ms) in previous odometry iteration, we received image (30 Hz) and imu topics (200 Hz). The callback queue may then contain 1-2 images and a dozen of imu topics, that may be arranged like this (where I is image and U an imu):
A deterministic executor would process them in order FIFO, avoiding the error above. A non-deterministic one could process them in that order:
Note also that could be why it is so difficult now to tune approximate synchronizers if they also not receive topics in order.
Other related discussions:
The text was updated successfully, but these errors were encountered: