Ask Your Question

What happend to child_frame_id in tf2?

asked 2019-02-11 07:22:31 -0500

peci1 gravatar image

updated 2019-02-11 17:00:54 -0500

I've just noticed that child_frame_id totally disappeared from tf2::Stamped<Transform>, whereas it used to be a part of tf::StampedTransform. This makes migration quite painful, as it's no longer just about changing function/datatype names, but you need to add (boilerplate) lines of code.

What's worse, if you convert geometry_msgs::TransformStamped to tf2::Stamped<Transform>, you get no warning about losing the child_frame_id, and in the opposite conversion, it is not easily spottable that child_frame_id has to be filled in separately. So what i'd expect to be an identity, is actually not:

geometry_msgs::TransformStamped tf = ...;
tf2::Stamped<tf2::Transform> tf2;
tf2::fromMsg(tf, tf2);
tf2::toMsg(tf2) == tf // doesn't hold

Isn't this weird? So there isn't any "tf2-native" datatype that'd correspond to geometry_msgs::TransformStamped? What was the reason for this omission in designing TF2? I assume this is also the reason why there's no tf2_ros::TransformBroadcaster::sendTransform(tf2::Stamped<Transform>& tf), which used to be useful in tf.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-02-11 13:36:19 -0500

tfoote gravatar image

The templated tf2::Stamped<> template is basically the same as tf::Stamped<> template.

I think what you're looking for is the tf2::TransformStorage (link) to compare with the tf::StampedTransform (link)

geometry_msgs::TransformStamped tf = ...;
tf2::toMsg(tf2::fromMsg(tf)) == tf // doesn't hold

This is a bug in the converters, conversions should hold bidirectionally. I don't know which implemenation you're including but guessing it's the default one. It looks like that implementation should really be using the tf2::TransformStorage not the templated version as that isn't the fully value.

If you could double check that you're using the default implementation in your includes and then open an issue that would be great. Or even better a PR. I think that the best approach would be to add a warning due to the data loss and deprecation note to the existing implementations and create a new parallel template specialization for the TransformStorage.

I'll need to do some checking about how to bias the template selection in cases like your example above where it's not specified both ways so that we can get the new implementation first if the value is not entirely there.

edit flag offensive delete link more


@tfoote I'm sorry for the confusion, the code excerpt I gave was written off the top of my head, so it didn't compile. See the edited version (there's no 1-arg version of fromMsg). But still, I don't think TransformStorage solves this - the frame IDs are stored there as uint_32, and no fromMsg...

peci1 gravatar image peci1  ( 2019-02-11 17:03:31 -0500 )edit

... is defined for TransformStorage (at least neither me nor the compiler could find it inside geometry2).

peci1 gravatar image peci1  ( 2019-02-11 17:04:27 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools



Asked: 2019-02-11 07:22:31 -0500

Seen: 245 times

Last updated: Feb 11 '19