ErrorExecutionTimeCalculation (-110) errors due to numerical issues

[personal-fork-robot]

Hi, @pantor

I'm testing Ruckig in a 6 dof robot motion planning, and in this situation the input.target_position and current_position is automatically calculated. I found an extremel case where the current and target position are all zero or infinitely close to zero, and in the case https://github.com/pantor/ruckig/blob/5ad83c019b35960294efd04387b8ed3cd9210763/src/position-step1.cpp#L417 https://github.com/pantor/ruckig/blob/5ad83c019b35960294efd04387b8ed3cd9210763/src/position-step1.cpp#L418

time_none(profile, _vMax, _aMax, _aMin, _jMax); will execute. And due to the numerical issue, the current and target position are all zero or infinitely close to zero but in C++ it can be turned into something like this

https://github.com/pantor/ruckig/blob/5ad83c019b35960294efd04387b8ed3cd9210763/src/position-step1.cpp#L8 the pd will be less than zero and in function PositionStep1::time_none(), profile.t[0] = std::cbrt(pd / 2*jMax) also will be less than zero so that the -110 error occurs.

Maybe (also in position-step2.cpp) https://github.com/pantor/ruckig/blob/5ad83c019b35960294efd04387b8ed3cd9210763/src/position-step1.cpp#L8 can be replaced by

if (std::fabs(pf - p0) < DBL_EPSILON)
{
    pd = 0;
}
else
{
    pd = pf - p0;
}

When I did that, the -110 error didn't happen anymore. If I think wrong, please correct.

[pantor]

Thanks for this detailed issue! I've fixed it with the latest commit on the master branch.