Your robot only needs to publish odometry topic and not odometry TF frame when using robot_pose_ekf
node. As you already noticed if they both publish to TF you will end up with multiple parents for your robot's base_link, which can't happen. robot_pose_ekf
subscribes to odometry and imu topics, merges them and then publishes odom_combined TF frame, which you can use in navigation stack. Usually robot base drivers have a parameter that let's use enable/disable odometry frame broadcast on TF.
Originally posted by arebgun with karma: 2121 on 2011-07-07
This answer was NOT ACCEPTED on the original site
Post score: 1
Original comments
Comment by mbj on 2011-07-14:
But, when you try to use the odom_combined generated by the robot_pose_ekf node in the navigation stack, this last expects an "nav_msgs/Odometry" and robot_pose_ekf/odom_combined publish a "geometry_msgs/PoseStamped". What about this? There is necessary some change or adaption before send the "corrected" odometry to move_base node? Thanks.
Comment by 2ROS0 on 2014-07-09:
My robot_pose_ekf subscribes to /encoder and /imu What should be the headers of these two topics? Currently, my /encoder has frame_id: odom_combined and child_frame_id: base_footprint while my /imu has frame_id: base_link.
My tf tree is odom->base_footprint->base_link
Comment by 2ROS0 on 2014-07-09:
Will that ^ be a problem considering that my /encoder msg has a child_frame_id which is not even on my tree (not being broadcast). The node doesn't throw any errors so I am wondering if robot_pose_ekf actually uses the frame_id ?