Numerical issue on plc

[Danielxyz123]

Hi Pantor,

i had an issue with some trajectories with higher jerks >100000. (If you need the parameters, tell me) => ruckig::Result::ErrorExecutionTimeCalculation

But only on the PLC with GCC 6.3.0... In Visual Studio everything works fine...

This issue appeared in "PositionStep1::time_vel". The "profile.check" caused this fault in the marked line on the following picture.

I changed the value to 1e-8, after that it's working fine. What does ist mean "This is not really needed..."?

Is it ok to change this value?

thx

Daniel

[pantor]

Can you post the corresponding InputParameter?

Regarding the comment: All mathematical equations in the positionStep1 and positionStep2 files are rewritten in such a way that the final acceleration will always be equal to the target acceleration. However, there can always be numerical issues (and bugs...) So it should be ok to change the value in theory, however I'm not so sure anymore because of this issue.

Usually high jerks behave quite friendly regarding numerical issues, but I suspect that this is not the case here.

[Danielxyz123]

The parameters are: (Only 1 DOF)

// Set input parameters
input.max_velocity = { 1800 };
input.max_acceleration = { 20000 };
input.max_jerk = { 200000 };

input.current_position = { 0.0 };
input.current_velocity = { 0.0 };
input.current_acceleration = { 0.0 };

input.target_position = { 400.0 };
input.target_velocity = { 0.0 };
input.target_acceleration = { 0.0 };

Note: It's working fine on the PC with Visual Studio...

[Danielxyz123]

One more information…

The value of a[7] was smaller than 1e-11, not far away from the limit of 1e-12.

[pantor]

Can you check if replacing lines 92 and 93 in src/position-step1.cpp

const double h1 = Sqrt(af_af/2 + jMax*(vMax - vf))/Abs(jMax);
const double h2 = Sqrt(a0_a0/2 + jMax*(vMax - v0))/Abs(jMax);

to

const double h1 = Sqrt(af_af/(2*jMax_jMax) + (vMax - vf)/jMax);
const double h2 = Sqrt(a0_a0/(2*jMax_jMax) + (vMax - v0)/jMax);

fixes your issue?

[Danielxyz123]

No unfortunately not The calculation in "PositionStep1::time_vel" seems to be equal.

Left side PLC, right side PC

[pantor]

There might be changes in the 15th position after the decimal point. But in general this issue is hard to debug, as it works on my hardware as well...

With the latest commit, I've improved the numerical stability for large jerks, and in particular increased the threshold from 1e-8 to 1e-10. I want to be very careful in increasing this threshold, so I hope that change suffices for now. I think the best way to handle those situations in the future is to normalize the input.

[Danielxyz123]

Sounds good, i‘ll test it.

Thx a lot!

What about line 89 with 1e-12, is it the same like the other line?

[pantor]

I think it's alright to keep the tighter bounds in the velocity interface for now, as it is much less prone to numerical issues.

[Danielxyz123]

Hi Pantor,

i tested the last commit. It works fine, thx a lot! What do you mean with "to normalize the input".

[pantor]

When changing the input by a constant factor (e.g. you could either input everything in [m] or [mm]), the output can be scaled back easily by the used factor. This way, Ruckig could normalize the input automatically, e.g. by setting the largest input value to 1. This should improve numeric stability.