Cartographer_ros: Confusion about TF frames used

Created on 17 Apr 2017  路  5Comments  路  Source: cartographer-project/cartographer_ros

So we have these frames map_frame, tracking_frame, and published_frame. On my robot I have an existing TF frame that looks like this:

world -> base -- comes from robot odometry
base->imu --comes from URDF
base->lidar --comes from URDF

I have IMU messages published in the imu frame, and the world->base frame comes from odometry. My question is, what should I be setting map_frame, tracking_frame, and published_frame to? The documentaiton seems to suggest that published_frame must both exist already in the TF tree, and simultaneously it gets published by cartographer.

This seems like a catch-22 to me, and indeed when I set published_frame to base I get TF lookup errors saying that there are competing publishers for the world->base transform.

question

Most helpful comment

I can relate to the confusion, since I had some trouble grasping the concepts of ROS's TF tree as well. @Entropy512 is exactly right in the description and REP 105 is the authority on this.

What helped me is groking the following facts:

  • TF is a tree, and there is only ever exactly one for a ROS setup.
  • odom and map are fixed reference frames, i.e. both usually describe 'distance from origin of the robot in meters`.
  • map is your coordinate frame of the world, @mklingen called it world, but map is the ROS terminology.
  • odom is also fixed, but base_link -> odom is meant to be changing smoothly over time, i.e. never suddenly jumping.

For example, after turning your robot on, odom -> map is identity, and for a while odom -> base_link and map -> base_link will very similar. The odom transform will drift over time, so loose it's metric exactness - but it will be smooth, so you can use arithmetic over this to figure out how your robot moved between two time stamps and make decisions locally.

The map transform will jump - most strongly when loops are closed. It will always answer the question 'how have I moved from my starting pointmost accurately. Thesejumpswill be fully contained inodom->map` transform, which will change non-smoothly.

All 5 comments

I ran into these same issues myself last week as I got odometry up and running.

REP-105 is useful - http://www.ros.org/reps/rep-0105.html

Note - I'm going to use slightly different naming conventions to what you're using, which are fairly consistent with REP-105 and my current setup. Instead of world I have map, instead of base I have base_link

In this case, you want the transform tree to be as follows:
map->odom->base_link

Your odometry solution should publish the transform between odom and base_link

Set up your configuration file so that tracking_frame is base_link and published_frame is odom - with use_odometry set to true and provide_odometry_frame set to false - Cartographer will publish the transform between map and odom.

published_frame and tracking_frame are the same in some of the examples - you'll note that these examples do NOT have odometry provided by the base, and instead Cartographer provides the odometry.

Note: Something I've said here might be wrong. In which case, we both need the same assistance... But the configuration I describe above seems to be working well for me.

I can relate to the confusion, since I had some trouble grasping the concepts of ROS's TF tree as well. @Entropy512 is exactly right in the description and REP 105 is the authority on this.

What helped me is groking the following facts:

  • TF is a tree, and there is only ever exactly one for a ROS setup.
  • odom and map are fixed reference frames, i.e. both usually describe 'distance from origin of the robot in meters`.
  • map is your coordinate frame of the world, @mklingen called it world, but map is the ROS terminology.
  • odom is also fixed, but base_link -> odom is meant to be changing smoothly over time, i.e. never suddenly jumping.

For example, after turning your robot on, odom -> map is identity, and for a while odom -> base_link and map -> base_link will very similar. The odom transform will drift over time, so loose it's metric exactness - but it will be smooth, so you can use arithmetic over this to figure out how your robot moved between two time stamps and make decisions locally.

The map transform will jump - most strongly when loops are closed. It will always answer the question 'how have I moved from my starting pointmost accurately. Thesejumpswill be fully contained inodom->map` transform, which will change non-smoothly.

Ah, I see, I was missing an intermediate frame. So my new TF tree should be

map -> odom --provided by cartographer
odom -> base_link -- provided by odometry
base_link -> ... -- provided by urdf

With tracking_frame set to imu, published_frame set to odom and use_odometry=true, provide_odometry_frame=false. It would help to have these frames better documented.

It would help to have these frames better documented.

Yes, that is probably true. Since you just went through the understanding process just now, you are especially well suited to documenting them in a way that will be helpful to the next person. Could you draft a PR?

Hi everybody!

I have the same config file:

map_frame = "map",
  tracking_frame = "base_link",
  published_frame = "odom",
  odom_frame = "odom",
  provide_odom_frame = false,
  use_odometry = true,

But when I turn on the robot (pioneer p3at) with RosAria that gives me Odometry and publish the odom -> base_link transform, cartographer doesn't publish map -> odom transform.

Any suggest?
Thank You so much in advance.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ozgudum picture ozgudum  路  6Comments

duchengyao picture duchengyao  路  5Comments

gaschler picture gaschler  路  8Comments

shreyasgokhale picture shreyasgokhale  路  5Comments

monabf picture monabf  路  9Comments