When using navsat_transform_node, isn't it a problem to use IMU yaw to compute transform between map and base_link ?

edit

Ah, so I think the issue here is one if being descriptive vs. prescriptive. In the image from navsat_transform_node, all I am trying to do is visualize the parameters in question and the need for them. However, note that the drawing is not inconsistent with the use case of fusing yaw in your EKF state estimate. At time t0, the robot's state really is as the picture above shows, since you have not received an IMU measurement when the node starts. It just so happens that the EKF doesn't publish the state at time t0, which would just be a zero state (unless you specify a starting state).

However, it doesn't actually matter. navsat_transform_node does not assume that your robot's first pose is (0, 0). Imagine a scenario in which you start your robot indoors (without GPS signal), and then drive around for a while, and then go outside. We have to be able to support that use case, and we do. navsat_transform_node considers the robot's pose at the time it receives its initial GPS fix when it calculates the map->utm transform.