G.A. vd. Hoorn

> What about the velocity values in the message, the maximum value is 0.521296 in pkt 2673. If the controller received that value, should we not be expecting faster speeds?...

> The execution of the arm does not seem to correspond to the speeds it is receiving. yes, I agree with you. > Increasing the acceleration limits set in the...

Could it be you've interpreted maximum velocity attainable as the velocity at which motions are *always* executed? Motions must be planned to be smooth, so velocity profiles always include ramp...

> Is there another layer of smoothing occurring besides the trajectories generated by moveit? My comment was a general one, not one specific to your usage with ROS or plain...

But with your latest comments about native performance with VAL3, it starts to look like the driver reaches similar performance. I'm not claiming here everything is OK and it can't...

#8 will improve the situation, but there will still be a few left (such as in [fetchStatus](https://github.com/ros-industrial/staubli_val3_driver/blob/1280ba7f587eb352b52955d0cd35976edc1269e8/staubli_val3_driver/val3/ros_server/fetchStatus.pgx) fi).

I'm not sure I understand what you write. As a high-level comment: > because now the val3 driver will ignore "duration time" while we execute` trajectory_msgs.msg` the driver does not...

In order to be able to say anything, we're going to need more information. Please provide the following: 1. a full copy-paste of the output on your console after `roslaunch`ing...

> I increased the value of the "eef_step" parameter and that seems to have solved the problem. So you did not check the return value (ie: `fraction`) to see whether...

As this appears to not be a problem with the package in this repository, I'm going to close it. Feel free to keep commenting on it.