What happend to child_frame_id in tf2?
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.
Asked by peci1 on 2019-02-11 08:22:31 UTC
Answers
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/d714a6534d9d1f81df8d460c1615f854faf7882e/tf2_geometry_msgs/include/tf2_geometry_msgs/tf2_geometry_msgs.h#L684
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.
Asked by tfoote on 2019-02-11 14:36:19 UTC
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...
Asked by peci1 on 2019-02-11 18:03:31 UTC
... is defined for TransformStorage (at least neither me nor the compiler could find it inside geometry2).
Asked by peci1 on 2019-02-11 18:04:27 UTC
Comments