ros
tf_prefix backwards compatibility?
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 call tf::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?
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 tf:base_link -> tf:/ns/base_link tf:/base_link -> tf:/base_link foo:fancy_newid_001212 -> foo:fancy_new_id_001212
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"?
<launch>
<node pkg="openni_tracker" name="openni_tracker" type="openni_tracker" output="screen">
<param name="tf_prefix" value="/skeleton" />
</node>
</launch>
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. That did change in hydro, the TransformPublisher does not care for the prefix anymore. So in theory the program has to do it by itself. Not many nodes do that for a simple reason. On the publisher side, fuerty & groovy had transparent support for tf_prefix and all nodes automatically worked fine with it. In hydro that is gone which leads to the situation that now (nearly) all tf emitters are ignoring tf_prefix and therefore tf_prefix is totally broken right now.
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.
@tfoote, I don't know enough about tf to comment on @roehling's proposal, is this something that is feasible?
