Fix time step in generated MoveIt trajectories
I currently am trying to integrate MoveIt on a custom robot. The robot already has the capability to accept position-velocity trajectories which are defined over a fixed control rate (i.e t1-t0 = t2-t1 = dt) and execute.
Therefore my implementation of a FollowJointTrajectory action would be very simple as long as I make sure it only accepts goals with a fixed time step. I think this also makes sense from a real-time control perspective. The time step can change per trajectory, but must be the same within each one.
My problem is the trajectories generated by MoveIt have sporadic time deltas. I have tried setting the rate parameter in controllers.yaml but appears to do nothing and I can't really find any documentation that deals with this issue. Here is an example of the time deltas of a MoveIt trajectory:
Is there anyway I can force MoveIt to generate trajectories evenly spaced along time? I would rather not have to interpolate the trajectory points in my action server, although this is currently my backup solution.
Not an answer, but something to consider:
If you don't do the interpolation there, you're essentially putting the burden on all your clients to import specific implementation details about your robot ..
.. into their application (as without the knowledge that your specific action server / robot requires trajectories with equidistant dts clients cannot successfully use its services).
In component based applications, this would seem to be really undesirable, and looking at
FollowJointTrajectory.... it would also seem to go against the specification of the msg/interface (which is, granted, not as explicit as it could have been).
FollowJointTrajectoryaccepts a goal with aJointTrajectory. Those containJointTrajectoryPoints, which havetime_from_startfields. This particular .... design does not include any specific requirements on values for
time_from_start, other than that they are 'strictly increasing in time'. So an action server that imposes additional constraints (like equidistanttime_from_startvalues) would appear to violate the interface specification.You are obviously completely free in how you implement your server, but if you value coherence, substitutability, separation of concerns and there is a chance that others might want to use your component, it would probably make the most sense to have your driver guarantee equidistant dts.
Btw: this goes two ways: applications will become less flexible if they're build 'around' your component (with the special action server) and your component is less re-usable (as it has special requirements).