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

Hello,

What is the impact of using only the first IMU reading to publish the world_frame->utm transform?


Specifically let's assume that you are using a robot with wheel encoders, an IMU, and a GPS and that we are integrating GPS data using the method suggested in the official documentation. If the initial absolute yaw of the robot reported by the IMU is slightly off, this initial offset will impact any subsequent odometry/gps published by the navsat_transform_node. This impact could be huge if your robot is driving over long distances.

Partial self-answer: I guess one might argue that if you are going to fuse this odometry/gps with other sensor data (wheel encoders, IMU) then the drift caused by the initial reading of the IMU is nothing compared to the drift of the IMU/wheel encoders over long distances so it is fine to fuse it.

edit retag close merge delete

Sort by » oldest newest most voted

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.

more