Open gavanderhoorn opened 4 years ago
I think this code was mainly written to support velocity in "sparse" trajectories (only start and end point)
But this is a general issue I have been planning to think about for some time now ... how to best translate from velocities in rad/s as given by MoveIt (or its message format) back to % as used by some industrial controllers
Code is here:
in essence: perc = target_vel_in_rad / max_joint_vel
, for all joints, then take lowest one.
There will always be a discrepancy between how ROS encodes joint state in JointTrajectoryPoint
, while industrial robot controllers expect maximum velocity / duration for the next segment. Those two are completely different.
I think this code was mainly written to support velocity in "sparse" trajectories (only start and end point)
I seem to remember (from our private email conversation, teaches me to not insist on discussing things on the tracker here ;) ) that the same behaviour is seen on trajectories with more than 1 segment (ie: incorrect or too low velocities on the last segment).
The last edit by the OP of the ROS Answers question shows this for the trajectory:
Pt Velocity Duration
0 0.10000000 10.00000000
1 0.04617230 0.51089500
2 0.07436170 0.21314300
3 0.09077400 0.16620200
4 0.10204400 0.14174000
5 0.10610300 0.13089500
6 0.10610300 0.13089500
7 0.10610300 0.13089500
8 0.10204400 0.13089500
9 0.09077400 0.14174000
10 0.07436170 0.16620200
11 0.04617230 0.21314300
12 0.10000000 0.51089500 <- odd high velocity of 0.1 on last point
That 0.1
is most likely the default velocity ratio assigned to segments (default_vel_ratio_
).
This is triggered by Moveit executor sends wrong velocity on last waypoint? on ROS Answers (note that the title is most likely incorrect: it's not MoveIt related).
I seem to remember @simonschmeisser reporting a similar observation, but using
fanuc_driver(_exp)
. I believe he added some commits to their fork ofros-industrial/fanuc
(these: https://github.com/ros-industrial/fanuc/compare/82757cea68cc82ee02575c9b272091ace9ae0f6b...c5f818933fd6f765ed00faf4b6eb06ea9f162ea8) to work around/fix this.But I'm not entirely sure what the cause was.
@simonschmeisser: could you perhaps clarify?