Closed martiniil closed 3 years ago
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 https://github.com/ros-controls/ros_controllers/pull/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
.
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.
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.
Conclusion/Open question?