Output Parameter Outside Kinematic Limits

[hugols16]

Given an InputParameter with current and target values within the kinematic limits, Ruckig seems to produce an OutputParameter with values that violate limits. Below are the values used for this simple test:

timestep = 0.00729941
Input Position: 1.1456, 1.32491, 1.4281, -1.13679, -1.31609, -1.46135, 
Input Velocity: 0.745756, 2.18417, 2.58052, -0.564599, -2.00301, -2.97533, 
Input Acceleration: -3.71964, 2.04996, 0.686652, 6.20144, 0.431844, -2.14729, 
Velocity Limits: 2.58309 2.58309 2.58309 3.00197 3.00197 3.00197
Acceleration Limits: 17.3088 17.3088 17.3088 20.7345 20.7345 20.7345
Jerk Limits: 65 65 65 82 82 82
Target Position: 1.1516, 1.30319, 1.45479, -1.1516, -1.30319, -1.45479, 
Target Velocity: 0.86103, 1.72206, 2.58209, -0.86103, -1.72206, -2.58309, 
Target Acceleration: 2.00717e-11, 3.77821e-11, 5.66731e-11, -2.00717e-11, -3.77821e-11, -5.66731e-11, 
Output Position: 1.15094, 1.3409, 1.44695, -1.14074, -1.3307, -1.48312, 
Output Velocity: 0.716873, 2.1974, 2.5838, -0.517148, -1.99768, -2.98881, 
Output Acceleration: -4.1941, 1.57549, 0.21219, 6.79999, 1.0304, -1.54873, 

Joint 3 violates velocity limits with an output value of 2.5838 even though the input velocity is 2.58052 and the velocity limit is 2.58309. This may be due to an infeasible target, but shouldn't Ruckig fail in that case, instead of violating limits? When passing the output to the input, the next update will then raise a -100 result (InvalidInput).

[pantor]

Hi! The input state leads to an inevitable velocity violation of joint 3, as the limited jerk cannot decelerate fast enough. We can calculate the maximum velocity solely based on the current velocity, current acceleration and maximum jerk to

(3 a0^2)/(2 jMax) + v0 = 2.5914.

In general, jerk limited trajectories might violate velocity limits in the future, although all values are within bounds. Ruckig currently doesn't output an error in this case, it just calculates the time-optimal trajectory to get within the limits as fast as possible. Then, the usual time-optimal trajectory towards the target state is generated.

However, I'm not understanding the -100 result when using the next output as input. Doing a quick check on my system shows that it works fine, and that is what I expect Ruckig to do.

[hugols16]

You're right, the next result isn't -100 because when validating the input, Ruckig only checks that the target is within bounds. However, violating bounds to reach a target can have negative consequences on a robotic system. The arm could either be lacking behind the trajectory, creating an increasing deviation, or the arm could simply reject the command throw a limits violation fault. Does this mean that with the current state of Ruckig, there is no way to guarantee that the output will always be within the limits as long as the result is either Working or Finished?

[pantor]

Yeah, this is a very fundamental problem of jerk-limited trajectory generation. For instance, when the current velocity and acceleration are both at their respective maxima, every jerk-constrained trajectory will violate the velocity in the future. For this reason it is the task of the user to make sure that the initial kinematic state is and will be within the bounds (in particular for online trajectory generation).

To make that easier, Ruckig should add a method to check and validate the current state for future violations. I'm thinking about a strict mode for the validate_input method, e.g. ruckig.validate_input(input, strict=true). As long as this method would return true, Ruckig is able to guarantee that the trajectory will be within the limits. What do you think of that solution?

Just to make sure: These inevitable velocity violations are only because of the initial state, and only happen during a time-optimal braking trajectory to get within the bounds as fast as possible. In particular, the Ruckig Community Version and Ruckig Pro do not violate any limits outside this braking-trajectory.

[pantor]

With the latest commit, this can now be checked using

ruckig.validate_input(input, true, true);

that checks both the input and target state for constraint violations. Please find more information in the updated Readme.