If some odometry topics are published faster than sensor data, we could miss reset events or large covariances. Note that this would not happen with the multi-threaded version (https://github.com/introlab/rtabmap_ros/pull/1214) if the sensor rate is in sync with odometry rate (like when we use visual odometry or icp odometry).
I tested decoupling odometry to its own callback so we don't miss any messages, though it makes it harder to "wait for odom tropic" if we receive sensor data faster than odometry delay. The current message_filters approach already solve that. Another drawback was for rtabmap_viz when we want to synchronize odometry info topic with the same sensor data generating that odom (to correctly overlay detected features on same image they were generated). Again, the message_filters approach solves that already.
Similar to inter_odom callback, we could look in parallel with a dedicated callback to just detect those reset events and appropriately not miss any covariance.
If some odometry topics are published faster than sensor data, we could miss reset events or large covariances. Note that this would not happen with the multi-threaded version (https://github.com/introlab/rtabmap_ros/pull/1214) if the sensor rate is in sync with odometry rate (like when we use visual odometry or icp odometry).
I tested decoupling odometry to its own callback so we don't miss any messages, though it makes it harder to "wait for odom tropic" if we receive sensor data faster than odometry delay. The current message_filters approach already solve that. Another drawback was for rtabmap_viz when we want to synchronize odometry info topic with the same sensor data generating that odom (to correctly overlay detected features on same image they were generated). Again, the message_filters approach solves that already.
Similar to inter_odom callback, we could look in parallel with a dedicated callback to just detect those reset events and appropriately not miss any covariance.