Not time-optimal result

[githublth]

hi, i compare ruckig and TopiCo, when the condition is below:

the result is like this:

obviously, Acceleration is different, and TopiCo is better, is more time saving. I want to know if rucig can do this and how to do ? thanks!

[pantor]

Hi @githublth,

after checking the analytical solution of your problem, I think Ruckig is correct and TopiCo is wrong (or at least inexact). Please correct me if I'm wrong, but TopiCo calculates two time steps t1=0.41 and t2=0.49. This way, the reached state is given by

a_t = 0.5
v_t = 0.37
p_t = 0.142112

Note the difference between the desired target position (0.1421083333) and actually reached position (0.142112). Ruckig guarantees a numerical robustness of 1e-8, so that this is not a valid trajectory from our perspective. Also note that a two-step solution is in general not able to reach a kinematic target state with position, velocity, and acceleration.

[pantor]

If you really want to get the inexact result, we recommend to increase the maximal jerk a bit. With jMax = 1 + 1e-12, Ruckig outputs a similar trajectory to TopiCo.

[githublth]

@pantor , your method is good, and can get the same shape as TopiCo, but i test TopiCo using MATLAB, the result is below, result is exact. not 0.142112. anyway, thanks, I will continue to compare ruckig and TopiCo.

[pantor]

Ah, I've made a mistake in my calculation above (used 0.125 instead of 0.1215). Now I see your issue, and indeed Ruckig does not give a time-optimal solution for this trajectory. This is because of a numerical issue and I'll try to fix that later. However also note that calculating trajectories for states that are already on time-optimal trajectories is inherently numerical unstable.

[pantor]

The exact position that is reached with the two-step profile is p=0.114210833333333330875. With the latest commit on the master branch, Ruckig is able to calculate the desired profile with this exact target position. Note that in the first screenshot you've posted, the target position is given by p=0.1142108333333333 (with 9 threes and a precision of 15 digits). As the double type has a precision of around 16 digits, Ruckig needs one more three (the tenth three before the ...0875) to work properly. Of course, more digits and a higher precision will always work. The stated numerical robustness of 1e-8 is the guaranteed worst case, in this case here Ruckig works with the numerical precision of the underlying double type.

Also note that Ruckig will immediately switch to the slower trajectory if the target position is slightly above this exact position. These sudden switches of the profile are inherent to the trajectory generation problem. When calculating trajectories for states that are already on time-optimal trajectories, a minimal deviation (e.g. a change of 1e-16 due to a rounding error) might lead to a completely different profile type. This is the numerical unstable behavior I referred to earlier.