joint_trajectory_controller: unreliable stop trajectory

[martiniil]

Concerning the joint_trajectory_controller /command topic. If you add a time stamp to the message, the trajectory will start at that time. But time is already passing when the message is sent. So the controller has less time to execute the trajectory, which can lead to unexpected behavior like very fast movements.

If you omit the time stamp, this will not happen. However I was able to make following observations:

A discontinuity of the velocity makes the computation of the stop trajectory unreliable. The stop trajectory itself then leads to dangerous robot motions.

[ INFO] [1590757563.373062468]: old_desired_state: -0.5, vel: 0.000231155
[ INFO] [1590757563.373146195]: desired_state: -0.5, vel: 41.6635
[ INFO] [1590757563.383092302]: old_desired_state: -0.5, vel: 41.6635
[ INFO] [1590757563.383179588]: desired_state: -0.0833648, vel: 41.6635
[ERROR] [1590757563.383339692]: Speed limit violated by link 'prbt_link_3'! Desired Speed: 14.477m/s, speed_limit: 0.25m/s
[ERROR] [1590757563.383447246]: END STATE OF HOLD TRAJECTORY: 4.70794

Conclusion/Open question?

• The formula for the stop trajectory is not robust enough.
• It should not happen that a trajectory is generated consisting of 2 segments with highly discontinuous velocities.

 segment start time: 8.67
 segment end time: 13.6616
 segment start state (position): -0.501154, (velocity): 0.000231155
 segment end state (position): -0.5, (velocity): 0.000231155
 segment start time: 13.67
 segment end time: 13.694
 segment start state (position): -0.5, (velocity): 41.6635
 segment end state (position): 0.5, (velocity): 41.6635

[martiniil]

The short answer is, you can get this behaviour also with the action interface. (If I am correct).

More specific:
The discontinuity of the velocity is due to linear interpolation in the segments. This happens when you don't specify a velocity in the trajectory message.

(The controller does not always execute a trajectory with such "velocity jumps". It depends on the tolerances.)
edit: Not entirely true, see #395

Using the /command topic, you always have the default tolerances (e.g. see constraints in manipulator_controller.yaml) of the controller. Using the action interface, you can get more strict via goal.path_tolerance.

[matthew-reynolds]

If you add a time stamp to the message, the trajectory will start at that time. But time is already passing when the message is sent. So the controller has less time to execute the trajectory

Yeah, the ROS interfaces (topics, services, actions, whatever) are not deterministic, the normal approach is to generate trajectories for the future. By which I mean generating and sending the next trajectory before the current trajectory has completed.

I'm not really sure what action is needed on this issue. I'm going to close it, please feel free to re-open if I misunderstand and there's some action needed.