[ros-users] merging different joint_states

Thu Jan 20 13:04:30 UTC 2011

Hi again,

I just read https://code.ros.org/trac/ros-pkg/ticket/4464
and have two comments about the solution that was proposed there
(namely, that if the robot_state_publisher receives a partial joint 
state message, it only publishes corresponding set of tf messages):

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.

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.)

Extending the joint state message and having a joint state aggregator 
(as Lorenz just proposed in the next twig of the discussion) is of 
course another solution.

Best regards,
Ingo

On 01/20/2011 01:34 PM, Ingo Kresse wrote:
> Hi,
>
> On 01/20/2011 12:40 PM, Weißhardt, Florian wrote:
>> Hi,
>>
>> I know about the mentioned shortcomings, but for us the error was acceptable if you run the aggregator fast enough.
>>
>> Of course the better way is to modify the joint_state_publisher: Do you have a solution for it which you could share?
>
> There is an implementation in tum-ros-pkgs:
>
> https://tum-ros-pkg.svn.sourceforge.net/svnroot/tum-ros-pkg
>
> in the package robot_state_chain_publisher. It consumes arbitrary
> messages on /joint_states and stores time, name and angle. It also sends
> tfs for joints, which have sent no joint state message for a while (so
> the robot is still visible in rviz, even without a joint state publisher).
>
> The task is a bit tricky: The timestamps should not be touched, since
> jitter in the timestamps induces jitter in the tfs. Duplicating a tf
> message (with the same timestamp!) also affects the interpolation. And,
> of course, we want to limit the tf publishing rate.
>
> As the name suggests, this version does not make the tf tree a "bush"
> but keeps the transform chains. We need this information for the
> calculation of uncertainties in the transforms.
>
> But these are two completely independent features.
>
> Best regards,
> Ingo
>
> P.S.: There are still some nodes which do not use tf but the joint state
> message directly, like the robot self filter. So at our lab we'll need
> both: a joint state aggregator and an enhanced robot_state_publisher.
>
>
>>
>> Regards,
>> Florian
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ros-users-bounces at code.ros.org [mailto:ros-users-bounces at code.ros.org] Im Auftrag von Lorenz Mösenlechner
>> Gesendet: Donnerstag, 20. Januar 2011 09:42
>> An: User discussions
>> Betreff: Re: [ros-users] merging different joint_states
>>
>> Hi,
>>
>> we found this solution pretty impractical. It introduces an error to
>> the TF transforms' time stamps.
>>
>> The problem is that, since the JointState message has only one time
>> stamp for all joint states, I don't see a correct way to calculate the
>> correct time stamp for the merged message. That means the TF
>> transforms' time stamps will we wrong in any case. The only solution
>> we found is to not use an aggregator but to extend the
>> joint_state_publisher to be able to handle joint states from different
>> topics that produces different time stamps for the tf frames from the
>> different sources.
>>
>> Lorenz
>>
>>> Hi,
>>>
>>> we solved the problem with a joint state aggregator. You can find the package in the cob_driver stack (installation with sudo apt-get install ros-cturtle-care-o-bot), the package is called cob_joint_state_aggregator.
>>>
>>> The aggregator collects all messages on the topic "joint_states" and combines them to a unique message published to "joint_states_combined" which is then used as an input for the joint_state_publisher to calculate tf. To configure it for your robot have a look at the /ros/launch/cob3-yaml file, where you have to specify the joint_names for your robot.
>>>
>>> I hope this helps.
>>>
>>> Regards,
>>> Florian
>>>
>>>
>>>
>>>
>>> -----UrsprÃ¼ngliche Nachricht-----
>>> Von: ros-users-bounces at code.ros.org im Auftrag von David Lu!!
>>> Gesendet: Mi 19.01.2011 21:07
>>> An: User discussions
>>> Betreff: Re: [ros-users] merging different joint_states
>>>
>>> Ugo-
>>> Your email reminded me that I was thinking about adding this feature to
>>> joint_state_publisher. I've attached a version that I'll upload to our
>>> repository after a little more testing.
>>>
>>>       <node name="joint_state_publisher" type="joint_state_publisher"
>>> pkg="joint_state_publisher" output="screen">
>>>           <param name="robot_description" textfile="model.urdf" />
>>>           <rosparam param="source_list">[head_states, body_states]</rosparam>
>>>       </node>
>>>
>>> This is how I launch it to merge the JointStates published on head_states
>>> and body_states.
>>>
>>> Let me know how well it works.
>>>
>>> -David!!
>>>
>>>
>>> On Wed, Jan 19, 2011 at 8:42 AM, Ugo Cupcic<ugo at shadowrobot.com>   wrote:
>>>
>>>> Hi,
>>>>
>>>> I have an arm and a hand publishing different joint_states messages and I'd
>>>> like to merge them (having seen this discussion:
>>>> http://ros-users.122217.n3.nabble.com/robot-state-publisher-with-joint-states-in-different-messages-does-not-compute-tf-for-all-joints-td1945465.html
>>>> )
>>>>
>>>> Is there an existing node to merge the joint_states messages, or do I need
>>>> to implement mine?
>>>>
>>>> Cheers,
>>>>
>>>> Ugo
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> ros-users mailing list
>>>> ros-users at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-users
>>>>
>>>>
>>>
>>
>>> _______________________________________________
>>> ros-users mailing list
>>> ros-users at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-users
>>
>>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users