[ros-users] merging different joint_states

[Wim Meeussen]

All,

Using the robot state publisher with multiple sources of joint state
is indeed a feature we want to add. I didn't realize that so many
people were waiting for this to happen, and even implemented their own
robot state publishers!  We would love to see those efforts getting
channeled into the released version of the robot state publisher.
We're trying to be more open about our development process, and let
people know what features are planned for our stacks, and how you can
contribute. This page has some useful pointers
<http://www.ros.org/wiki/Get%20Involved>, but comments are always
welcome.

Our current proposal for this feature is described in ticket
<https://code.ros.org/trac/ros-pkg/ticket/4464>. If you have comments
or ideas, feel free to add them to the ticket. I also added this
ticket to the handoff list
<http://www.ros.org/wiki/Get%20Involved/Handoff%20List>, so if you're
interested in contributing, you can pick up the ticket and get your
patches into the 'official' robot state publisher.


Ingo, I added the comments below to the ticket:

> 1) How should the rate of tfs be limited? Our experience is, that a tf
> receiver getting tfs at 1000 Hz is a bit slow.

We can use the same mechanism as we currently use: the user specifies
a desired tf publish rate that applies to all joints, and based on
this rate we skip some of the callbacks of the joint state messages.
With multiple sources of joint states this mechanism will get more
complex, but it can still work. So the tf publish rate can not be
higher than the joint state publish rate.

> 2) When should the static transforms be published? (This was our primary
> use case for the "repeat old messages" feature, for the position of
> lasers etc.)

For fixed joints we can create a separate thread that publishes tf at
the desired rate. It might be useful here to future-date the tf
messages by the publishing period, to minimize delays.


But if you're using the current version of the robot state publisher
you can use the following workarounds to use multiple joint state
publishers:

 * Aggregate the joint states (this has timestamp problems though)
 * Split up your kinematic tree in different parts that correspond to
the joint state publishers, and create a robot state publisher for
each part

Wim

ps. The robot state publisher that will go into Diamondback supports
both flattened trees and full trees. The default is set to full trees.

-- 
--
Wim Meeussen
Willow Garage Inc.
<http://www.willowgarage.com)