Revision history [back]

It's mainly because velocities in ROS are commonly reported in the robot's body frame. The nav_msgs/Odometry message provides different frame_ids for the pose and twist data, and pretty much every odometry source I've encountered produces velocity data in the robot's body frame.

If you remove that assumption in the filter, then you'd have to do the rotations when you receive the sensor data anyway. That would get awkward because of the way we handle measurement queuing. It would also mean we'd have to predict, rotate the measurement using the predicted world state rotation to get the velocity into the world frame, then correct.

In any case, while I'm sure there are other ways to skin this cat, the CPU usage for typical use cases is minute, and the Jacobians are calculated analytically, so we're not having to do any kind of auto-differentiation.