Warning: Group 0 - Time difference between endTrajData (...) and startTrajData (...) is 0 or less.

[gavanderhoorn]

Just happened to notice it while working on something:

Processing next point in trajectory [Group #0 - T=3.899: ( 1.2294,  0.0132, -1.4978,  1.2743,  0.1970,  2.4911)]
Processing next point in trajectory [Group #1 - T=3.899: ( 0.8486,  0.0000,  0.0000,  0.0000,  0.0000,  0.0000)]
Processing next point in trajectory [Group #0 - T=4.000: ( 1.2287,  0.0112, -1.5007,  1.2794,  0.2003,  2.4942)]
Processing next point in trajectory [Group #1 - T=4.000: ( 0.8482,  0.0000,  0.0000,  0.0000,  0.0000,  0.0000)]
Processing next point in trajectory [Group #0 - T=4.000: ( 1.2287,  0.0112, -1.5007,  1.2794,  0.2003,  2.4942)]
Warning: Group 0 - Time difference between endTrajData (4000) and startTrajData (4000) is 0 or less.
Processing next point in trajectory [Group #1 - T=4.000: ( 0.8482,  0.0000,  0.0000,  0.0000,  0.0000,  0.0000)]
Warning: Group 1 - Time difference between endTrajData (4000) and startTrajData (4000) is 0 or less.

this could be a problem with the 'input' trajectory (ie: the submitted goal), but I haven't checked yet.

Trajectory generated by MoveIt.

[gavanderhoorn]

@ted-miller: would it not make sense to refuse to execute a trajectory which has this problem?

We iterate over all trajectory points when processing the incoming goal, and this seems like it falls in the "malformed input trajectory" category.

[ted-miller]

In this case, I don't see a problem with that trajectory. It just seems the last point is duplicated.

If there were any positional difference in the last two points, then yeah this would be problem.

So maybe only reject the trajectory if there's no difference, but there is a difference in position?

[schornakj]

I had a chance to investigate this today and I think I know what's happening. ROS JointTrajectory messages store durations with nanosecond precision, but MotoROS2 converts them to use millisecond precision. Sometimes the output from motion planning and time parameterization includes trajectory points that are separated by less than a millisecond, and that situation causes this check to fail because when cast to millisecond precision the points have the same timestamp.

Here's a trajectory I logged that shows the issue:

0:
 positions:
 - 1.75795
 - -0.104497
 - -0.728471
 - -0.443087
 - 0.441418
 - -1.20692
 velocities:
 - 0.00000
 - -0.00000
 - -0.00000
 - -0.00000
 - -0.00000
 - 0.00000
 accelerations:
 - 0.00000
 - 0.00000
 - 0.00000
 - 0.00000
 - 0.00000
 - 0.00000     
 effort: []
 time_from_start:
   sec: 0
   nanosec: 0
 
 1:
 positions:
 - 1.75795
 - -0.104497
 - -0.728471
 - -0.443087
 - 0.441418
 - -1.20692
 velocities:
 - 1.15917e-09
 - -1.00356e-08
 - -7.42579e-09
 - -5.01417e-09
 - -1.91215e-09
 - 4.79032e-09
 accelerations:
 - 0.115917
 - -1.00356
 - -0.742579
 - -0.501417
 - -0.191215
 - 0.479032
 effort: []
 time_from_start:
   sec: 0
   nanosec: 10

this could be a problem with the 'input' trajectory (ie: the submitted goal), but I haven't checked yet.

In this case the input trajectory was valid (timestamps monotonically increasing) and can be executed by my mock hardware interface, so I think MotoROS2 should be able to ingest it without failing. It probably isn't possible for the robot to actually perform the precise requested motion since the jerk is too high, so maybe the solution is to do some sort of filtering.

[gavanderhoorn]

Thanks @schornakj.

It probably isn't possible for the robot to actually perform the precise requested motion since the jerk is too high, so maybe the solution is to do some sort of filtering.

I would indeed suggest we implement a filter of sorts, as it's not just the jerk: the resolution (in time) of the trajectory you show is just too high.

---

Edit: could you say something about what sort of planner and/or time parameterisation you're using there? Getting to an acceleration of -1.00356 in 10 nanoseconds (from stand-still) almost seems like it would be physically impossible. Is what you're using aware of the robot's joint limits?

[schornakj]

Edit: could you say something about what sort of planner and/or time parameterisation you're using there? Getting to an acceleration of -1.00356 in 10 nanoseconds (from stand-still) almost seems like it would be physically impossible. Is what you're using aware of the robot's joint limits?

This is using Tesseract. The motion plan is generated using TrajOpt and parameterized by TOTG. I think part of the issue is it's not accounting for the robot's jerk limits. I'm still investigating if that's because I have my robot's description and planner configuration misconfigured or if it's just not taking in that limit to begin with.

[rjoomen]

This could also have to do with a TOTG bug that has been fixed in MoveIt1&2, where TOTG returns velocities/accelerations above the limits.

[schornakj]

Following up after digging into this more -- this is all upstream of MotoROS2 in the motion planning and time parameterization part of my system, so it's not related to anything that would need to be fixed in this repo.

Briefly, there are two different problems I had to address:

• There was a bug in my own code related to concatenating multiple trajectories together where the time delta between the last point of the first trajectory and the first point of the second trajectory was too small for MotoROS2.
• It's possible for time parameterization algorithms to naturally include points that are separated by small time deltas, for example as part of a finely-sampled Cartesian trajectory. This would need to be addressed in the time parameterization algorithm (for example, like in Allow setting minimum timestamp delta between trajectory points in Iterative Spline Parameterization tesseract-robotics/tesseract_planning#574).