Revision history [back]

So your GPS data is _not_ given in the odom frame. If they were the same frame, you could fuse them directly, without the need for navsat_transform_node.

GPS devices are a bit strange, because they give world-fixed pose information, but we have to define a vehicle-relative transform/offset for them. navsat_transform_node makes the assumption that the GPS is mounted somewhere on your robot. If it's mounted directly in the center of the vehicle, then you can make its frame base_link. If it's mounted, e.g., 0.1 meters in front of the robot, then you need to define that in a static transform, and change the GPS message frame_id to gps (or whatever you want to name it). Keep in mind that the static transform for the GPS should _not_ have a rotation, as the orientation of the GPS sensor is meaningless.

One other note: you are just fusing IMU and GPS data. The filter won't play well with that, because it lacks bias estimation. You need a velocity reference. You have use_control turned on, but we are modelling controls as accelerations in the filters, so that won't help. If you have a wheel odometry source, feed that to the filter. If you don't, then take your motor command topic, and publish a TwistWithCovarianceStamped message with that data, and feed it to the filter as a velocity input. It'll help keep things on track.