trajectory relays: velocity calculation final segment incorrect?

[gavanderhoorn]

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 of ros-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?

[simonschmeisser]

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

[gavanderhoorn]

Code is here:

https://github.com/ros-industrial/industrial_core/blob/a85789b6b33bd0a460c236a6b89c14dbf125e2c0/industrial_robot_client/src/joint_trajectory_interface.cpp#L229-L280

in essence: perc = target_vel_in_rad / max_joint_vel, for all joints, then take lowest one.

[gavanderhoorn]

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.

[gavanderhoorn]

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_).