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

[Kelsey Hawkins]

The number of actual subscriptions would not change. For every
node->robot_state_publisher connection there would be a node->joint_states
to replace it. Only difference would be that there might be different
topics for different joint_states. This is easily overcome by making the tf
rosparam a list like this:
<rosparam>
robot_urdfs:
  - urdf: /robot_description
     joint_state: /joint_states
  - urdf: /sim/robot_description
     joint_state: /sim/joint_states
</rosparam>

Since the parameter could be global, every tf would know which parameters
to look at to find URDF/JointState topic pairs.  You could even potentially
customize a node to only look at specific joint states, so that it only has
access to certain sections of the tree.  Most of all, by just eliminating
the parameter all together you can make this feature totally optional, /tf
acts like normal.

Although its an interesting idea to integrate it as a ros-controller, it
still doesn't tackle the bandwidth issue.

Just a quick test on my 7DOF system with 32 tf frames:

/tf Bandwidth: 186 KB/s, 100 Hz

/joint_states Bandwidth: 33 KB/s, 100 Hz

This is a 6x increase in information, all of which must be deserialized in
tf::TransformSubscriber.  Although I'm sure ROS 2.0 will help, I'm not sure
it's an excuse for just ignoring lazy ROS communication.  If you want to
continually rosbag a robot system you often want to keep data throughput
low.  Actually what got me thinking about this was the web-interface talk,
where tf throttling becomes necessary when sending it through web-sockets.
For remote control, you'd like the communication to be efficient as
possible.


On Sep 17, 2014 9:40 AM, "Mike Purvis" <mpurvis at clearpathrobotics.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/1db3cb03/attachment.html>