[ros-users] Combine robot_state_publisher with tf::TransformListener?

[Mike Purvis]

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 at 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 at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20140917/1b877a12/attachment.html>