navsat_transform_node - drift due to initial IMU reading for world_frame->utm transform

edit

The ramifications really aren't that severe. It really depends on what else you're fusing. If you have some other absolute pose estimate, then you will eventually see the filter jump back and forth between the two sources of data. This is pretty rare, though.

More than likely, you will probably not be fusing any other absolute position data, in which case the worst-case scenario would be that your robot's heading will be slightly off. That is, if you have some X body-frame velocity, it will predict that you went forward some amount in the world frame (i.e., some combination of X and Y in the world frame), but then it will get a GPS reading and correct your robot by moving it ever-so-slightly laterally. Not the end of the world.

In any case, the only other option is to use multiple IMU measurements to get a filtered/smoothed yaw estimate before the transform is computed. Conveniently, this is why we added the use_odometry_yaw parameter. Instead of using raw IMU data, it will use the yaw data from your EKF pose, which has been filtered. This does assume you are fusing your absolute yaw data into your EKF, of course.