-
Notifications
You must be signed in to change notification settings - Fork 275
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
tf_prefix backwards compatibility? #29
Comments
This was the stupidest possible way to "fix" the tf prefix issue. If the TransformListener would have started resolving all frame_ids in lookupTransform(), the prefix support would have worked transparently for all nodes. |
@roehling Unfortunately that doesn't work. If a frame id from a different prefix is referenced either by name or data is passed between nodes in different tf_prefixes this will prepend the wrong prefix. |
@tfoote Oh, you are right, I did not think of that. So taking one further step, why not resolve in the publisher? The frame_id already is part of the standard header, so from a technical viewpoint, it should not be too difficult to prepend the actual node namespace to any relative frame_id without leading slash. The current implementation effectively punishes everyone who read the tf documentation and implemented the prefix feature correctly. :-( |
I have an idea, which I would be willing to implement: Let the tf frame id have the following format [ type ":"] id If type is omitted, it defaults to tf. Frame ids with "tf" type are automatically resolved by the core libs with the node namespace (or "/"), everything else is left alone. So base_link -> tf:/ns/base_link This way, tf::resolve() remains idempotent, but we can phase out its usage, and if someone comes up with a fancy new frame_id system that does not need resolving, it can be implemented as a new type. And its fully backwards compatible to Groovy. |
I have a simple launch file that runs an openni_tracker node using a tf_prefix so that all frames belonging to a skeleton can be separated from any other tf trees being published. This has worked very nicely since at least Fuerte but now appears broken in Hydro. I guess I don't understand what is meant be "backward compatibility" here or perhaps I am doing something wrong but why does the following launch file no longer place all my skeleton frames under "/skeleton"?
|
In principle hydro is backwards compatible. BUT they changed the TransformPublisher object. In fuerte and groovy the TransformPublisher would use the tf_prefix and add that to tf_frames when publishing transforms. You'll need to have a look if the openni_tracker node allows you to set the frame it uses for its tf. If so you can manually do the tf_prefix resolve already in the launch file (i.e. param name="frame" value="/skeleton/previos_frame_value"). If you have a lot of nodes that used the tf_prefix before, that introduces a lot of pain, of course... but the ROS people did not find a smart way for the tf_prefix stuff on the receiver side and sensor-messages side and therefore decided to kill it. I guess we'll have to live with that. |
http://www.ros.org/wiki/hydro/Migration#tf2.2BAC8-Migration.Removal_of_support_for_tf_prefix states that tf_prefix is deprecated but "should keep working in the cases where tf_prefix was previously used".
In groovy, the TransformBroadcaster called
tf::resolve()
by itself to resolve frame_ids in transforms which are not fully resolved. This is not the case anymore currently in hydro. Is this a bug or should the user calltf::resolve()
before filling the TransformStamped data structure in cases where tf_prefix is needed (e.g. for simulating multiple robots in one Gazebo instance)? What is the recommended solution in such cases if tf_prefix support is totally dropped?tf_prefix is currently not working with the static_transform_publisher for the same reason, too.
If both, the user and TransformBroadcaster, would call
tf::resolve()
, would this lead to multiply prefixed frame_ids now?The text was updated successfully, but these errors were encountered: