Revision history [back]

On top of what Tom said, there are also situations where even with proper covariances and filter configuration, you might get very large discutinuities in your map frame, while the odom frame can still serve as a continuous frame for control. Consider the setup mentioned by Tom with odom+IMU+GPS, and all covariances are set up perfectly. Now if the robot goes to an area without GPS coverange (e.g. inside or close to a building), and the GPS does not provide any input for a certain period of time, the filter will estimate position purely on odometry data. The positional covariance will correctly grow by a substantial amount in this time. When the robot gets the GPS fix again, and the first GPS position with a (correct) small variance is fused, the filter position will (correctly) jump close to that measurement immediately.

Now if you assume your odometry can drift lot at (without being corrected for certain periods of time), you will run into additional problems. E.g. when doing global planning, your bad position estimate might result in abstacles from a map and obstacles from onboard sensors (e.g. laser scanner) not overlapping anymore and as a whole blocking all paths. If your localization can get that bad at certain points, you will have to deal with that regardsless of whether you are using a single frame, or the map->odom->base_link setup. However, the odom frame can still have the invariant, that over a short period of time is a good approximation of the relative movement of the robot, regardless of what happens to global localization. Sometimes you need that property e.g. for control, or maybe for planning local maneuvers that don't depend on a global position.

Apart from that, there is actually one more utility to the map->odom->base_link tf frame setup. It provides a simple means to fuse slower global localization with a more frequent odometry. E.g. in the amcl+wheel_odom setup, you might have odom->base_link updating at 50Hz from your wheel ancoders, but map->odom updating only at 10Hz. Still, on the TF tree you will get the chain map->base_link updating at 50Hz (provided you set up the transform_tolerance appropriately, which addmittedly is a bit of a kludge). Now you can certainly acheive the same with "proper" sensor fusion algorithms like a kalman filter and just a single frame, but this is how it has been used in simple, default setups in ROS for a long time.