ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
![]() | 1 | initial version |
You are seeing the correct behavior. You can take a look at the REP for Coordinate Frames for more information about the frame conventions.
In a nutshell, the odom
frame contains the pose of the robot in the world as reported by some odometry sensor. The odom
pose is continuous; however, due to errors in odometry, it accumulates error over time.
To correct for the drift of odometric sensors, packages such as slam_gmapping introduce a transform between map
--> odom
. This transform is the correction that has been computed, based on sensor input such as laser scanners. It is not continuous (it can jump at various time intervals) because slam_gmapping usually computes corrections at a lower frequency.
If you have perfect odometry sensor, the map
--> odom
tf will always be 0.
![]() | 2 | No.2 Revision |
You are seeing the correct behavior. You can take a look at the REP for Coordinate Frames for more information about the frame conventions.
In a nutshell, the odom
frame contains the pose of the robot in the world as reported by some odometry sensor. The odom
pose is continuous; however, due to errors in odometry, it accumulates error over time.
To correct for the drift of odometric sensors, packages such as slam_gmapping introduce a transform between map
--> odom
. This transform is the correction that has been computed, based on sensor input such as laser scanners. It is not continuous (it can jump at various time intervals) because slam_gmapping usually computes corrections at a lower frequency.
If you have a perfect odometry sensor, the map
--> odom
tf will always be 0.
![]() | 3 | No.3 Revision |
You are seeing the correct behavior. You can take a look at the REP for Coordinate Frames for more information about the frame conventions.
In a nutshell, the odom
frame contains the pose of the robot in the world as reported by some odometry sensor. The odom
pose is continuous; however, due to errors in odometry, it accumulates error over time.
To correct for the drift of odometric sensors, packages such as slam_gmapping introduce a transform between map
--> odom
. This transform is the correction that has been computed, based on sensor input such as laser scanners. It is not continuous (it can jump at various time intervals) because slam_gmapping usually computes corrections at a lower frequency.
If you have a perfect odometry sensor, sensor and a "perfect" laser, the map
--> odom
tf will always be 0.