Hello.
I'm currently trying to fuse IMU with wheel odometry as an input to rtabmap. IMU provides acceleration while wheel odometry technically provides a pose, but I'm setting it in differential mode in robot_localization so it is effectively integrating the velocity. This, along with a positive process noise covariance, means that the growth of covariance is unbounded. This is covered in this answer. So far so good.
My understanding is that this kind of imu + wheel odometry fusion usually serves as the input to rtabmap. Rtabmap (in mapping mode) will use this information to map, and to perform loop closure. Upon loop closure, rtabmap will perform localization and broadcasts a map -> odom transform, which should "correct" the pose information.
My question is: since rtabmap performs localization upon loop closure, is there a way to propagate this information to the robot_localization process of the input such that the covariance of the "input" odometry stays bounded? Is this even necessary, and if not, does it mean it's okay for the odometry input to rtabmap to stay unbounded?
Originally posted by cactus on ROS Answers with karma: 3 on 2021-06-19
Post score: 0
Original comments
Comment by Mike Scheutzow on 2021-07-17:
I have not run rtabmap myself, but my understanding of what happens during mapping is different from what you describe. I'll assume you have set up rtabmap to use camera images. rtabmap saves each image, along with the current robot pose. This current pose is from odometry, which is created by integrating input from wheel encoders and/or imu. This odom may drift. If closure is detected, rtabmap goes back and adjusts every saved pose associated with every saved image that belongs to the closure path, thus hopefully correcting for the odom drift.
Comment by cactus on 2021-07-17:
Yeah I understand all of that. That said, rtabmap corrects the odometry in the map frame. My problem is not that. My problem is that the input odometry will have an unbounded covariance growth. I understand that tf has no covariance component, but the Odom message does (as output by robot_localization). My original concern was that the unbounded covariance should cause problems for rtabmap, as I assumed that the nodes created in rtabmap used the pose covariance of the input odometry. This is evidently not true as per Labbe's answer below.
That said, I do wonder how this works with other SLAM packages that rely on an external input odometry, like gmapping.