Revision history [back]

It is not clear what you are referring to, there is not geometry_msgs::TransformStamped in the image. Do you mean the tf messages?

Odom is the odometry estimate of the robot, coming from a sensor that accumulates drift. base_link is attached to the robot, i.e. some defined position on the robot (or below, if projected to the floor for a wheeled robot). See REP105 for details.

Yes

No, not in general. The transformations need to form a tree. If you interchange you may end up with a frame with two parents

Original: It is not clear what you are referring to, there is not geometry_msgs::TransformStamped in the image. Do you mean the tf messages?messages?

Update: The two ways of sending the transformations (nav_msgs/Odometry on /odom and tfMessage on /tf) make the pose estimate of the robot available in a slightly different way. The /odom topic in general is only for Odometry messages, nothing else. These contain the pose and the velocity of the robot including the respective uncertainties (covariance matrices). The /tf topic on the other hand is only used for poses, but not only that of the odometry estimates, but all transformations the application tracks, e.g. the odometry, the position of sensors on the robot, objects detected in said sensors, poses of robot arms and grippers etc. Its purpose is to be able combine these transformations to answer questions like "where is the gripper with respect to the object I saw ten seconds ago". It is also incredibly useful in visualization, because everything can be displayed in a common coordinate frame.

Odom is the odometry estimate of the robot, coming from a sensor that accumulates drift. base_link is attached to the robot, i.e. some defined position on the robot (or below, if projected to the floor for a wheeled robot). See REP105 for details.

Yes

No, not in general. The transformations need to form a tree. If you interchange you may end up with a frame with two parents