ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

tf frames position odomotry

asked 2018-03-20 06:00:18 -0500

haysgh gravatar image

Hi all,

I am trying to get the position of my robot based on odometry, so I have two encoders that are connected to the front wheel. I am trying to follow this REP but I could not understand is that why the odom frame is considered as a father frame in relation with the base link. If there are here people who could clarify that for me because the odometry encoder is considered as a sensor and it should be the children of the base link. To clarify more I have a world frame then a base_link then to odometry encoders.

Thank you in advance

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2018-03-20 10:41:14 -0500

updated 2018-03-21 07:02:47 -0500

The REP you referenced is a document that is describing best practices and standards used for coordinate systems in mobile robots in ROS. If you choose to follow those conventions, then indeed, the odometry frame (typically /odom would be a parent of the base frame (typically /base_link). The computer on your robot would need to read the values from the wheel encoders and integrate the kinematics of your robot to provide an estimate of where your robot is relative to where it started. This would be provided to the rest of the ROS world as a transform from the odometry to the base frame (and typically a topic of type nav_msgs/Odometry). If your robot never had any drift, wheel slippage, integration error, etc. then the transform from a truly world-fixed frame to the odometry frame would be constant; of course, this will never happen and there will always be drift in your odometry estimate.

Typically the location of the sensors themselves would be described by further transforms that are children of the base frame (e.g. /base_link -> /sensor_1). This is usually done with a URDF and a robot_state_publisher.

There are likely other choices that could make sense for describing this same information (you seem to have an idea of how you would prefer this same information to be described), and you are free to use whatever description you want. That being said, beware that if you don't follow the REP, there are many other packages that may not work with your robot.

edit flag offensive delete link more


Thank you for your answer it really clarified many things. I am willing to use the robot_localization_package in the future that's why I should follow the REP. For more clarification the real position of the robot is defined by the base frame not the odom ?

haysgh gravatar image haysgh  ( 2018-03-20 11:50:49 -0500 )edit

The "real" position is more complicated than that. Definitely, robot_localization is designed to fuse sensors and provide an estimate of the position of the robot by publishing a transform from an "odom" frame to a "base" frame.

jarvisschultz gravatar image jarvisschultz  ( 2018-03-20 13:43:24 -0500 )edit

I suggest you study the picture on this robot_localization wiki page. Note that the odom frame is created facing the same direction as the robot. IIRC the map frame should face True or Magnetic North.

M@t gravatar image M@t  ( 2018-03-21 21:02:11 -0500 )edit

The heading of map depends somewhat on how you've set up navsat_transform. Due to ROS conventions and how these localization packages tend to work, the position of the robot in the odom frame tends to drift...

M@t gravatar image M@t  ( 2018-03-21 21:07:32 -0500 )edit

So the "real" position of your robot is (usually) the pose and orientation of base_link relative to map

M@t gravatar image M@t  ( 2018-03-21 21:08:12 -0500 )edit

Question Tools

1 follower


Asked: 2018-03-20 06:00:18 -0500

Seen: 1,113 times

Last updated: Mar 21 '18