# turtlebot robot_pose_ekf/odom? or odom?

Hi, I was wondering what is more accurate for turtlebot odometry the /robot_pose_ekf/odom or just /odom.

If its robot_pose_ekf/odom, why would the turtlebot gmapping and amcl demos have the move_base node subscribing to /odom instead of robot_pose_ekf/odom

edit retag close merge delete

Sort by » oldest newest most voted

/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. /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.

more

I think the benefit of robot_pose_ekf is it can combine visual odom,imu and odometry data and give you a better result. am i wrong ? does amcl's pose algorithm combine such datas ?

( 2012-08-10 09:47:13 -0600 )edit

You're right robot_pose_ekf combines visual odometry, imu and odometry (the buzz word for this is "sensor fusion"). AMCL only uses the laser scan and odometry, but it is a general method and could be modified to use data from other sensors.

( 2012-08-10 09:58:02 -0600 )edit

is there a disadvantage of using the odom tf provided by robot_pose_ekf for gmapping and amcl ? I am a little bit confused i am sorry

( 2012-08-10 10:06:32 -0600 )edit

There's no need to, all these techniques attempt to solve the same problem. Which one is best depends on your circumstances. If you have a map, use AMCL with the unfiltered pose. At best, using the filtered pose will introduce extra lag, and will not significantly improve performance, if at all.

( 2012-08-10 10:20:04 -0600 )edit

it is robot_pose_ekf/odom because it is filtered by extended kalman filter. Amcl and gmapping uses the frame of odometry which you can set as a parameter of robot_pose_ekf

to be more specific here is the robot_pose_ekf.launch file from my robot

<launch>
<node pkg="robot_pose_ekf" type="robot_pose_ekf" name="robot_pose_ekf">
<param name="output_frame" value="odom_combined"/>
<param name="freq" value="20.0"/> <!-- 10 'du 20 yaptim -->
<param name="sensor_timeout" value="1.0"/>
<param name="odom_used" value="true"/>
<param name="imu_used" value="false"/>
<param name="vo_used" value="false"/>
<param name="debug" value="false"/>
<param name="self_diagnose" value="false"/>
</node>
</launch>


i set output_frame to odom_combined as turtlebot does. you may set this to odom as you wish.

here the provided tf transforms

odom_combined → base_footprint


in my robot

more

1

sorry this doesn't really answer my question

( 2012-08-10 07:01:30 -0600 )edit

I think it depends on what information you want. The robot_pose_ekf/odom topic gives only the pose, while the /odom topic includes the velocity as well. If you are referring to accuracy of pose, it is the filtered one from ekf for reasons mentioned by the others.

As for the /odom topic, it is subscribed by move_base not for the pose information but for the velocity. In particular, it is the local planner that subscribes to this (see http://www.ros.org/wiki/base_local_planner#TrajectoryPlannerROS and also in the diagram).

As for the localization algorithms AMCL and GMapping, they provide the transform map->base_link. They do listen to the transform odom->base_link (through tf topic), but mostly to transform the laser scans as explained here and here

REP105 explains the difference between map and odom frames even though both give robot pose information. I think there are merits to having both, but there are some algorithms like hector slam that can do away with the odom frame.

more