The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
/robot_pose_ekf/odom will be more accurate than /odom because the kalman filter uses the robot's motion model along with other observations to maintain a better estimate of the robot's pose.
AMCL and gmapping attempt to solve similar problems to that solved by robot_pose_ekf, so it doesn't really make sense to use an already filtered pose as input. Additionally I believe that AMCL and gmapping rely on certain properties of the pose that may not hold after kalman filtering.
| | 2 | No.2 Revision |
/robot_pose_ekf/odom will be more accurate than /odom because the kalman filter uses the robot's motion model along with other observations to maintain a better estimate of the robot's pose.
AMCL and gmapping attempt to solve similar problems to that solved by robot_pose_ekf, so it doesn't really make sense to use an already filtered pose as input. Additionally I believe that AMCL and gmapping rely on certain properties of the pose that may not hold after kalman filtering.
The reason that all these different pose estimates exist is because there are many different circumstances under which you may be using your robot. If you don't have a map, and don't want to build one, you should use /robot_pose_ekf/odom. If you don't have a map, but would like to build one as part of your application, you should use the map->odom tf frame provided by gmapping. If you already have a map and would like to localize your robot in it, you should use amcl_pose.
| | 3 | No.3 Revision |
/robot_pose_ekf/odom will be more accurate than /odom because the kalman filter uses the robot's motion model along with other observations to maintain a better estimate of the robot's pose.pose. /odom, on the other hand simply gives you the raw data provided by the turtlebot base, which is notoriously bad.
AMCL and gmapping attempt to solve similar problems to that solved by robot_pose_ekf, so it doesn't really make sense to use an already filtered pose as input. Additionally I believe that AMCL and gmapping rely on certain properties of the pose that may not hold after kalman filtering.
The reason that all these different pose estimates exist is because there are many different circumstances under which you may be using your robot. If you don't have a map, and don't want to build one, you should use /robot_pose_ekf/odom. If you don't have a map, but would like to build one as part of your application, you should use the map->odom tf frame provided by gmapping. If you already have a map and would like to localize your robot in it, you should use amcl_pose.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
