Revision history [back]

The problem is that the sensor_msgs/Imu message contains only a single frame_id, yet most of them report data in two separate frames: linear acceleration and angular velocity are in the sensor frame, yet the orientation is in a world-fixed frame. r_l assumes that the frame_id is relative to the body frame, and so if you have your IMU mounted with a 90-degree offset, it's going to apply that offset. This makes sense in general, though: if I have a robot pointing at magnetic north, and its IMU is rotated so it's off by 90 degrees, that IMU is going to read 90 degrees, even though my robot is facing 0 degrees. r_l will correct for that, and tell you the robot is facing 0.

In your case, you have two options:

1. Handle all the transformations of your IMU data onboard, since you wrote the driver anyway. Then you can just zero out the camera->IMU transform.
2. You should do this regardless, but note that you are fusing yaw from two different sources. The yaw from your IMU presumably comes from a magnetometer. The rtabmap yaw value will likely start at 0 when you start running and your poses will be relative to that. Those two headings are not necessarily going to agree. As stated in the wiki, if you have two sources of pose information, choose the best one, and fuse the other one either (a) as a velocity, if available, or (b) enable differential mode for it.