Only MoveIt uses the values from the file you mention. The controllers you're using with gazebo_ros_control (or at least: I'm assuming you're using gazebo_ros_control) do not use them.

So in essence you've told MoveIt your robot's joints have very high velocity and acceleration limits, but the controllers will not be aware of that and will just use the values from the urdf.

What could be happening is that your controllers are unable to achieve the performance you specified in the joint_limits.yaml file, causing MoveIt's trajectory execution manager to abort execution of the trajectory as it determines there is too much divergence between the calculated max duration of the trajectory execution and the time your simulated robot is taking (due to lower joint limits enforced in/by the controllers and/or hardware_interface).

It's unclear from your phrasing whether this is what you describe with "arriving before the end".

I would check to make sure execution of the trajectory is not actually aborted. If so, you should update the title of your question.

The fact your action returns or you can press "plan & execute" again in the RViz MoveIt plugin doesn't mean execution was successful.

It is not aborted, and even says trajectory finished sucessfully so that is not the problem. The controller I use for the actuator won't let me specify goal position tolerance like the ros controllers, but when using low acceleration and velocity limits are set it finishes on time. But with the high values it says it succeeds too early and when I starts a new movement it returns an error because it is still moving a bit from the last trajectory.

It is not aborted, and even says trajectory finished sucessfully so that is not the problem.

Then that could suggest your controller is flagging completion too soon.

MoveIt relies on the controller/driver for execution completion. It doesn't determine that by itself.

From what you describe I would take a look at how your driver/controller determines when a trajectory has finished execution.

If you want better answers/comments you'll have to provide more information. We don't have access to your special controller, nor do we know how you've actually set things up.

Ah thanks the trajectory is executed using moveit commander but as I understand from you the specific controller is responsible too. I use Hebi actuators and their control, I understand I shouldn't ask specific questions about the controller here, but I thought the trajectory controller would be responsible for things like goal tolerance.

but as I understand from you the specific controller is responsible too

No, flagging completion is the sole responsibility of the driver/controller.

MoveIt is just a consumer of that information.

If you're using the standard JointTrajectoryController, that would make it a generic ROS problem. If not, it would be something to check with Hebi.

I'm still not sure whether the configuration you've created will work for what you're trying to do though.

Yess I use the JointTrajectoryController , would you have any proposals of how to increase goal accuracy while keeping the velocity limits high? And what makes you think the configuration is ill-suited?

My apologies I was mistaken. I use the FollowJointTrajectory, for all the controllers but JointTrajectoryController, for all but hebi. Therefore I think you're right and it is a problem to check with hebi. Bedankt Gijs

And what makes you think the configuration is ill-suited?

I believe you've changed the wrong limits. As I wrote earlier: the limits you've changed are only used by MoveIt (or: are typically only used by MoveIt). So this generates trajectories with unrealistic time_from_start, velocity and accelerations.

If you're trying to optimise motion by tuning PIDs of your controllers (ie: the ones executing the motions), should you not do that using realistic trajectories and then optimise execution of those?