What happend to child_frame_id in tf2?

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

1366 ●27 ●69 ●60

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.

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

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

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. https://github.com/ros/geometry2/blob...

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

Comments

@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 ( 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 ( 2019-02-11 17:04:27 -0500 )edit

add a comment

What happend to child_frame_id in tf2?

1 Answer

Comments

Question Tools

Stats

Related questions

What happend to child_frame_id in tf2? edit

1 Answer

Comments

Question Tools

Stats

Related questions

What happend to child_frame_id in tf2?