Revision history [back]

First, I'd give this a complete read-through, if you haven't already.

It sounds like your GPS already provides data in a local world frame, thus eliminating the need for navsat_transform_node. If I were you, I'd set the gps/rtkfix frame_id and child_frame_id to map and base_link, respectively.

Then, make sure you have a static_transform_broadcaster that defines the transform from the robot's base_link frame to the imu frame.

I would then run two EKF instances:

1. In the first instance, set the world_frame to odom. Fuse wheel encoder odometry (I'd stick with velocities) and IMU data (again, I'd use velocities).
2. In the second instance, set the world_frame to map. Fuse the same data as in (1), but also fuse the gps/rtkfix data.

Does the gps/rtkfix data provide orientation? You need to be careful if you plan to fuse absolute IMU orientation instead of velocities, because what your IMU says is 0 radians may not agree with that the RTK unit says is 0 radians, so you'll get flip-flopping behavior. Even if the RTK unit doesn't provide orientation, you need to make sure that the orientation in the IMU is consistent with the RTK data. In other words, if the RTK says you went from (0, 0) to (1, 1), then your IMU should have a heading of pi/4. If that's not the case, I'd stick with fusing velocities from the IMU. If the RTK provides orientation, then you're golden: fuse the orientation from the RTK and angular velocity from the IMU.