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

Can tf/tf2 resolve "hidden transforms" ?

asked 2017-08-06 10:46:06 -0500

Galto2000 gravatar image

updated 2017-08-06 10:46:28 -0500

Howdy folks,

I have question relating to the following transform tree:

[/nav_frame]->[/base_link]->[/sensor_platform] -> [/IMU_AHRS]

The sensor platform is literally a platform that has sensors mounted on it (GPS antenna, IMU-AHRS, etc.) and is attached to the robotic platform (/base_link).

The nav_frame is a local ENU frame in which I do my navigation computations: it's placed on the WGS84 ellipsoid at the same location as the base_link, and it always points north.

I got an IMU-AHRS system (with magnetometer and world magnetic map) mounted on the sensor_platform that I will use to resolve the transformation between nav_frame and base_link.

So, I have the following situation:

[/nav_frame]->[/base_link] UNKNOWN, this is what I need to resolve

[/base_link] ->[/sensor_platform] is a known and fixed transform

[/sensor_platform] -> [/IMU_AHRS] is a known and fixed transform

My Question: Can tf (or tf2) somehow automatically (internally) resolve the hidden transform [/nav_frame]->[base_link] when it's given the measured transform [/nav_frame] -> [/IMU_AHRS] as produced by the IMU-AHRS system, or do I (as the programmer) have to explicitly compute this transform (which is easy enough using the IMU-AHRS measurements and the fixed transforms relating the IMU_AHRS frame w.r.t. the base_link) and explicitly publish this as the [/nave_frame] -> [/base_link] transform?

if tf/tf2 can do this "internally", then how?

Thanks in advance

Best regards,


edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted

answered 2017-08-07 02:46:19 -0500

tfoote gravatar image

You have to explicitly do this as tf[2] is just a tree that can be queried. Computing that value requires assumptions about connectivity that tf does not have.

There are some strategies that include creating duplicate leaf frame_ids that then can be used to let the tf API compute the value which is then published so you don't have to do the math.

Your sort of problem is the standard way that most localization methods work. Where they simply query for the transform the the base_link and subtract that from the navigation fix. And then publish the result as nav_frame -> base_link.

Note that I strongly recommend that you read through REP 105 which defines standard coordinate frames for robots. Using common names makes code reuse easier. And also you are skipping the 'odom' frame which is highly recommended if you're doing anything with obstacles.

edit flag offensive delete link more


Thanks tfoote

That's what I figured about tf[2]. Not a big deal, just wanted to make sure I wasn't missing out on better methods.

Indeed, I do adhere to REP 105 whenever I can, but this project is a little different :)

Galto2000 gravatar image Galto2000  ( 2017-08-07 08:36:05 -0500 )edit

Question Tools



Asked: 2017-08-06 10:46:06 -0500

Seen: 307 times

Last updated: Aug 07 '17