Revision history [back]

Thank you for providing sample input messages. It might be helpful if you could capture two messages from when the robot is actually being rotated.

A few possibilities spring to mind.

Given the much smaller covariance for the IMU (which makes sense), I wonder if your wheel encoder odometry is producing the wrong sign when turning. One thing you didn't show in your image was the rotation for raw odometry.
What is providing the base_footprint->imu transform? Without it, your IMU data is not going to get fused.
You should turn off the use_control parameter while you sort this out.

This error slowly builds up and increases the more I rotate the robot.

This is to be expected, regardless of what you change. Your IMU's yaw is coming from a magnetometer (I assume), so it won't be subject to drift. In the EKF, you are only fusing yaw velocity, and the errors in that velocity are going to integrate over time.

Thank you for providing sample input messages. It might be helpful if you could capture two messages from when the robot is actually being rotated.

A few possibilities spring to mind.

Given the much smaller covariance for the IMU (which makes sense), I wonder if your wheel encoder odometry is producing the wrong sign when turning. One thing you didn't show in your image was the rotation for raw odometry.
What is providing the base_footprint->imu transform? Without it, your IMU data is not going to get fused.
You should turn off the use_control parameter while you sort this out.

This error slowly builds up and increases the more I rotate the robot.

EDIT in response to updated question:

I am still rather confused about the base_footprint->imu transform though. May I ask why this transform is necessary and just the /imu topic itself is insufficient? Also, if there is to be more than one imu, then wouldn't there be multiple imu frames needed? I do not recall seeing any options to set the imu frame.

I'd recommend that you have a look at the tf2 wiki, but just as a short example, consider a system where you have two identical IMUs mounted on your robot. One is mounted upside-down, and the other is mounted right-side-up. If we just fused their data in the EKF, then when we rotate our robot clockwise, one sensor would read +Z angular velocity, and the other would read -Z angular velocity. That obviously doesn't make sense, but how can the EKF know that one of the sensors is upside-down?

The answer is that you need to use transforms to tell the EKF how that sensor is mounted. So you define a transform from base_link to imu_rightsideup, and it might be just the identity transform (which means the IMU is mounted at your robot's body origin). In that IMU's mesages, you would want to make sure that the frame_id was set to imu_rightsideup. Then the EKF knows to look for a transform (via tf2) from that frame_id to the frame_ids that it knows about. For the other IMU, you would define a transform from base_link to imu_upsidedown. That transform would have a roll angle of pi radians. Then you would configure the IMU node to change the frame_id in the message to imu_upsidedown. When the EKF receives that message, it can again use tf2 to look up how to transform that data into a frame that it can use.