Fix: Prevent fake joint publisher from publishing TF_REPEATED_DATA

[matthias-mayr]

• During startup it can happen that the clock does not increase. Checking the time prevents double-sending to "joint_states"
• In some configuration Gazebo also published data for the wheel leading to collisions with this publisher creating these msgs: "TF_REPEATED_DATA ignoring data with redundant timestamp for frame mir/left_wheel_link at time 45.782000"

This spams the log a lot. This patch allows to configure the fake_mir_joint_publisher to only publish the caster wheels. In our setup in noetic this is needed. I think it's the joint_state_publisher that typically publishes these, e.g. from Gazebo.

[mintar]

I think all your problems can be solved without this PR.

First off: You shouldn't be running fake_mir_joint_publisher.py in Gazebo. If you start mir_gazebo/launch/mir_empty_world.launch, the following happens:

• Gazebo publishes joint states for the two actuated wheels only on the topic /mir/joint_states.
• This topic is read by joint_state_publisher, augmented by joint states for the caster wheels, and the complete joint state is published on /joint_states:

https://github.com/dfki-ric/mir_robot/blob/b52e60e7f16cced923e5ebe364304d650b8658b2/mir_gazebo/launch/mir_gazebo_common.launch#L40-L44

This solves your "duplicate joint state" problem

During startup it can happen that the clock does not increase.

As I already mentioned, you shouldn't be running the fake publisher in Gazebo. But even if you do this problem should not occur. Is it possible that the fake joint publisher is started before rosparam set use_sim_time true? In that case, it will be using wall time. If it's using sim time, the problem should not occur, because Gazebo should not publish duplicate clock messages. If it does, that's a bug in Gazebo.

[matthias-mayr]

Thanks for the feedback and the clarification.

If I do not run the fake publisher, MoveIt or the "robot model" visualization in RViz complain about incomplete state and missing the caster joints. Am I missing something there?

I can not reproduce first duplicate right now. When I see it appear again, I can report the timestamps.

[mintar]

If I do not run the fake publisher, MoveIt or the "robot model" visualization in RViz complain about incomplete state and missing the caster joints. Am I missing something there?

In Gazebo? Do you run the joint_state_publisher as I wrote above? What's the output of rostopic echo /joint_states?

[matthias-mayr]

I digged into it and it seems that we ditched the remapping + joint_state_publisher when creating our MIR+UR5e setup. But it seems like this combination also works in that configuration, so then all joint states are published and this merge request is actually obsolete.

Thanks a lot for the comments. Closing.