Intermittent error: "Dropping trajectory point(s), as they occur before the current time. Last point is 0.000000s in the past."

Question

I have started to get these errors intermittently with our two UR5e robots:

[ WARN] [1620713227.477543383]: Dropping all 1 trajectory point(s), as they occur before the current time.
Last point is 0.000000s in the past.

Reading answers like this, it seems likely that the time needs to be synchronized between the robots and the machine, and I assumed that the error is due to a small time shift between the machines. However, I did not manage to fix it.

The Timing issues, TF complaining about extrapolation into the future? section of wiki/ROS/NetworkSetup on checking using ntpdate does not work (ntpdate[167705]: no server suitable for synchronization found), and most Google results seem to only mention ISPs blocking ntp packets, which is not the case here because the network is not online. Does this method not apply for UR controller boxes?

Using clockdiff gives a result, but it seems that there is no significant time offset:

$ sudo clockdiff -o 192.168.1.41
..................................................
host=192.168.1.41 rtt=0(0)ms/0ms delta=28233228ms/28233227ms Tue May 11 15:14:07 2021
$ sudo clockdiff -o 192.168.1.42
.......................................
host=192.168.1.42 rtt=0(0)ms/0ms delta=156542ms/156542ms Tue May 11 15:14:17 2021

What could be the issue?

PS: Another link that did not solve the problem.

edit: It seems that my question doesn't display a paragraph on ntpdate that does appear in my preview post when I edit it. How strange.

---

Originally posted by fvd on ROS Answers with karma: 2180 on 2021-05-11

Post score: 0

---

Original comments

Comment by fexner on 2021-05-11:
I assume using the ur_robot_driver with the scaled_joint_traj_controller?

Timestamp of the robots don't really matter. The warning you posted comes from the controller running on the ROS machine. Usually, I've seen that when there has been something wrong in the trajectory. As you seem to send a trajectory containing one TrajectoryPoint and seeing this warning, I assume that the time_from_start field contains a 0 time. Try setting the time to something larger than 0.

Comment by gvdhoorn on 2021-05-11:
I agree with @fexner: nothing is running on the UR controller box (or at least, nothing which prints that error), so synchronising the clocks will not change anything here.

And pedantic, but a trajectory with a single point is not really a trajectory.

It seems that my question doesn't display a paragraph on ntpdate that does appear in my preview post when I edit it.

Askbot doesn't like something in the URL and then drops the entire parapgraph. Removing the direct link helped.

Comment by fvd on 2021-05-11:
That's good news, I don't want to touch the UR's clocks.

The trajectory comes from a MoveIt plan, but it's true that a point with no time_from_start makes no sense. I'll have a closer look.

Answer 1

I can't reproduce this, except irregularly when I repeatedly try to plan to the same pose. Normally MoveIt registers that the goal constraints are already satisfied, but I assume that the noise in the joint_states messages is sometimes higher than the tolerance, so it plans an infeasibly short motion.

It seems safe to ignore this error. Thanks for noticing that the trajectory itself was nonsensical.

---

Originally posted by fvd with karma: 2180 on 2021-05-11

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by gvdhoorn on 2021-05-11:
I've marked your answer as the answer here, as it seems to be the best resolution for now.

One suggestion: could you please change the title of your question to better reflect the symptoms you observed instead of mentioning a problem with a solution you had already selected (ie: avoid the xy-problem)?