ROS2: callbacks not called in same order than topics received

[matlabbe]

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):

U1 U2 U3 U4 I1 U5 U6 U7 U8 U9 U10 U11 I2 U12 U13 U14 U15 U16

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.

Other related discussions:

• Document/Clarify executor processing order ros2/rclcpp#633

[matlabbe]

That would be fixed by PR above.