TF_OLD_DATA error with MotoROS2 and Gazebo running concurrently

[Icon45]

Hi everyone,

we are currently trying to setup MotoRos2 with MoveIt! 2. we successfully created the connection between the Robot and the motoros_agent on our machine. However when we start our MoveIt environment (together with Gazebo) we get the following error for all 6 links of the robot.

[move_group-11] Warning: TF_OLD_DATA ignoring data from the past for frame link_6_t at time 119.497000 according to authority Authority undetectable
[move_group-11] Possible reasons are listed at http://wiki.ros.org/tf/Errors%20explained
[move_group-11] at line 294 in ./src/buffer_core.cpp

We have checked and made sure that the error has really something to do with MotoRos, because when we start the simulation by it self we don’t get this error, however as soon as we start the agent and connect to the Robot the error reappears.

We are using the use_sim_time parameter=true in our gazebo simulation but not in MoveIt. When tried to turn it to false nothing really changed.

Any ideas what’s going on here and how to fix it?

[gavanderhoorn]

we are currently trying to setup MotoRos2 with MoveIt! 2. we successfully created the connection between the Robot and the motoros_agent on our machine. However when we start our MoveIt environment (together with Gazebo) [..]

I'm slightly confused as to why you are trying to use Gazebo and MotoROS2 at the same time. MotoROS2 can't be used with Gazebo -- as in: MotoROS2 can't connect to Gazebo, nor the other way around.

Could you perhaps describe what you are trying to achieve, just so we can avoid discussing an xy-problem?

Having written that:

We have checked and made sure that the error has really something to do with MotoRos, because when we start the simulation by it self we don’t get this error, however as soon as we start the agent and connect to the Robot the error reappears.

The error message comes from move_group, and link_6_t is a link in the URDF of the robot you have loaded. The message also implies you have (at least) two TF authorities (ie: nodes broadcasting TF frames) which do not agree on the time source used.

The timestamp mentioned (119 seconds) is too small to be a wallclock timestamp, so it's almost certainly from a TF frame broadcast by an authority that's using simulation time (ie: the clock coming from your Gazebo instance).

MotoROS2 also publishes TF by default, but it would not be using simulation time as it's a hardware driver running on a real system.

Based on what you describe, I assume the issue is caused by move_group receiving TF frames from a robot_state_publisher instance which is configured with use_sim_time=true and additionally from MotoROS2 which is using wallclock (ie: 'real time').

As move_group receives TF frames with the same name, but some with timestamps (much) older than others, it will/may assume it's receiving old data and hence print the error message.

If you do really need to run MotoROS2 at the same time as a simulation (but see my earlier comments about that), you could consider turning off TF broadcasts from MotoROS2. You'd have to update this entry in the configuration file and update your config on the controller.

PS:

We are using the use_sim_time parameter=true in our gazebo simulation but not in MoveIt. When tried to turn it to false nothing really changed.

if you are trying to control a simulated robot/mechanism with MoveIt, you must set use_sim_time to true for all involved nodes (ie: move_group and whatever else you start).

That's unrelated to MotoROS2 though.

[Icon45]

Ok so we fixed some hardware issue that still persisted in our setup. however the original TF_OLD_DATA Error still persists.

we made sure that only Motoros and Gazebo+Moveit environment are running and that we are the only one on our ROS-Domain-Id.

if we run our Gazebo+MoveIt-Env. everything works, however as soon as we start the Motoros Agent ist still Shows in the terminal where we started our Simulation the TF-Error.

[gavanderhoorn]

I would suggest to ros2 topic echo /tf again. Record messages for some time and analyse which frames they define transforms between. Look at the stamps for those transforms.

Based on the transforms you should be able to figure out which node/authority is publishing them. Output of ros2 topic info -v /tf would probably also be insightful.

From your earlier tests it would seem MotoROS2 is not broadcasting any transforms anymore, so I'm wondering whether this is still a MotoROS2 issue.

---

Edit: what could be happening is you have a robot_state_publisher (RSP) that's subscribing to the /joint_states topic published by MotoROS2. If that RSP has the URDF for your HC10 loaded, it will perform FK based on the incoming JointState messages and then broadcast the result as TFs (on /tf). The RSP by default uses the timestamp of the incoming JointState messages as the stamp for any TF frames it broadcasts. That stamp would be wallclock, as MotoROS2 does not support use_sim_time.

This situation could again result in move_group receiving both transforms with wallclock stamps and transforms with stamps from Gazebo (ie: what we discussed in #391 (comment)).

[gavanderhoorn]

I would also suggest to carefully review the use_sim_time parameter for all nodes in your system.

As soon as a /clock publisher is involved, you should ideally set it on all nodes that will consume messages from that /clock publisher. Mixing-and-matching (ie: nodes with different settings) is a bit of an advanced subject and may result in unpredictable behaviour.

We'd need much more detail / information on your ROS 2 application in order to be able to help, but see my earlier comment.

[gavanderhoorn]

@Icon45 @JonaRo4: have you been able to make any progress here?

[JonaRo4]

Hi, no sadly i have not.
However i have found, that if i run ros2 node list in my Moveit+Gazebo environment without MotoRos2, it shows me two instances of the robot_state_publisher. I think that might cause conflicts.

Furthermore i get the Error Message:

[current_position-8] [INFO] [1742402736.349658292] [moveit_ros.current_state_monitor]: Didn't receive robot state (joint angles) with recent timestamp within 1.000000 seconds. Requested time 474.300000, but latest received state has time 474.299000.
[current_position-8] Check clock synchronization if your are running ROS across multiple machines!

This probably also has something to do with what you mentioned earlier with the usage of use_sim_time and the /clock publisher.