In a complex system, you're likely to have multiple nodes producing joint info, and multiple nodes consuming TF, so it makes sense to have a central clearinghouse for that info to avoid everything subscribing to everything. It's also a logical abstraction to have hardware deal in joints, and higher-level code deal in transforms.

Three further thoughts on this—

- First, robot_state_publisher is embeddable as a library, so if you don't like the separate process and serialization overhead, you could consider compiling it directly into whatever hardware node you have primarily producing joint information.
- Along the same lines, there's already a joint_state_controller which publishes joint_states from the ros_control framework. It's not hard to imagine that it could optionally also publish tf, eliminating the need for a separate node doing this job.
- Finally, with ROS 2.0 offering the option to run all your nodes in a single process as a launch-time decision, much of the overhead here becomes an optional switch you can throw— if the abstraction costs nothing, it makes that much more sense to have it in place.

On 17 September 2014 07:49, Kelsey Hawkins <kphawkins@gmail.com> wrote:

I'd bet that 90-100% of transform requests in typical ros systems run through a chain delivered through robot_state_publisher. Wouldn't it make sense to optionally allow tf::TransformListener to parse a URDF and subscribe to /joint_states in addition to /tf? The advantage is that you can do proper interpolation between joint configurations and you vastly reduce the bandwidth of /tf. Plus, you eliminate a processor intensive node which is mostly relaying redundant information easily read from the URDF.

I'm sure this isn't a novel idea, but are there any plans to integrate this behavior into ROS core? Any caveats?

-Kelsey


_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users