0
$\begingroup$

Rosanswers logo

Hi,

I'm trying to use a compass to improve the odometry information of my robot, so I'm fusing it as an Imu message with the robot odometry using the robot_pose_ekf node. I have problems with the /odom frame published by my robot odometry and the /odom_combined frame published by robot_pose_ekf.

Could anyone help me understand how robot_pose_ekf should be integrated with the already extant frames and transformations?

Thank you


Originally posted by chcorbato on ROS Answers with karma: 202 on 2011-07-07

Post score: 1

$\endgroup$

2 Answers 2

0
$\begingroup$

Rosanswers logo

What you are trying to do is not really supported in the robot_pose_ekf. According to the documentation for the imu input to the robot_pose_ekf: "The Roll and Pitch angles are interpreted as absolute angles (because an IMU sensor has a gravity reference), and the Yaw angle is interpreted as a relative angle". What you are trying to do is to provide a Yaw angle from a compass, which is an absolute measurement, not a relative measurement. Although the robot_pose_ekf can give you a reasonable result, you will still see drift on your robot's Yaw angle because of this.


Originally posted by Wim with karma: 2915 on 2011-07-07

This answer was ACCEPTED on the original site

Post score: 2

$\endgroup$
0
$\begingroup$

Rosanswers logo

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 ?

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.