Revision history [back]

Adding to the previous answer, odom frame is called so because it is the frame where the odometry is used to update the pose of the robot. In this frame, there is no correction or jumps in the robot's pose, it is continually updated based on the data coming from the motor's encoders (sometimes fused with accelerometer and gyro).

Map frame is the frame representing the world, where your map (mostly occupancy grid map with black areas represent obstacles and walls) is defined.

Now in order to run robot localization and model the drifts of the robot while it is navigating, a transform between the frame map and the frame odom was introduced. At the beginning map and odom frame are overlapping. While the robot navigates and localizes (using amcl for example) it will correct its drift but it will not do this correction by changing its pose in the odom frame (this pose published under the topic /odom) but it will update the transform between map and odom frames such that when you chain the transforms to get the pose of the robot in the map frame, you will get the corrected pose (thus the transform between map and odom frames represents the offset in the robot's pose that is given in the odom frame).

Do not confuse the frame odom with the robot's pose published under the topic /odom. The frame Odom is just a coordinate system where the robot has to be located. This location of the robot would then be the coordinates of base_link in the odom frame. These coordinates are published in the /odom topic. If you do a rosrun tf_echo odom base_link you will get exactly the same thing as in rostopic echo /odom (here the topic might change depending on the robot model and your software). So when you turn on the robot, base_link and odom are overlapping as the robot's pose is zero at the beginning. But once the robot's wheels start rotating, base_link will get away from odom. So base_link is a mobile frame and odom a fixed one.

Adding to the previous answer, odom frame is called so because it is the frame where the odometry is used to update the pose of the robot. In this frame, there is no correction or jumps in the robot's pose, it is continually updated based on the data coming from the motor's encoders (sometimes fused with accelerometer and gyro).

Map frame is the frame representing the world, where your map (mostly occupancy grid map with black areas represent obstacles and walls) is defined.

Now in order to run robot localization and model the drifts of the robot while it is navigating, a transform between the frame map and the frame odom was introduced. At the beginning map and odom frame are overlapping. While the robot navigates and localizes (using amcl for example) it will correct its drift but it will not do this correction by changing its pose in the odom frame (this pose published under the topic /odom) but it /odom). It will update the transform between map and odom frames such that when you chain the transforms to get the pose of the robot in the map frame, you will get the corrected pose (thus the transform between map and odom frames represents the offset in the robot's pose that is given in the odom frame).

Do not confuse the frame odom with the robot's pose published under the topic /odom. The frame Odom odom is just a coordinate system where the robot has to be located. This location of the robot would then be the coordinates of base_link in the odom frame. These coordinates are published in the /odom topic. If you do a rosrun tf_echo odom base_link you will get exactly the same thing as in rostopic echo /odom (here the topic odom might change depending on the robot model and on your software). So when you turn on the robot, base_link and odom are overlapping as the robot's pose is zero at the beginning. But once the robot's wheels start rotating, base_link will get away from odom. So base_link is a mobile frame and odom a fixed one.