Maximal trajectory duration

[Fubini2]

Dear Pantor,

following small problem

`int main() { Ruckig<3> otg; Trajectory<3> traj; InputParameter<3> input; OutputParameter<3> output;

// Set input parameters
input.current_position = { 0.0, 0.0, 0.0 };
input.current_velocity = { -6.6706965561032989, 24.622597745627097, 0.0 };
input.current_acceleration = { 0.21350997812776198, 0.057843623589371167, 0.0 };

input.target_position = { 51002.562712464198, 0, 0 };
input.target_velocity = { 0.0, 0.0, 0.0 };
input.target_acceleration = { 0.0, 0.0, 0.0 };

input.max_velocity = { 1.0000000000000002, 1.0000000000000002, 1.0000000000000002 };
input.max_acceleration = { 2.7182577263372942, 2.7182577263372942, 2.7182577263372942 };
input.max_jerk = { 1.0000000000000004, 1.0000000000000004, 1.0000000000000004 };

const ruckig::Result Result = otg.calculate(input, traj);
if (!((Result == ruckig::Result::Working) || (Result == ruckig::Result::Finished)))
{
    std::cout << "Ruckig fail! Code: " << Result;
}

std::cout << "Trajectory duration: " << output.trajectory.get_duration() << " [s]" << std::endl;

} ` does not give a solution with ruckig. I admit it violates your bound of 7600 for trajectory duration and comes from our experiments with simultaneous scaling of maximal velocity and jerk to be 1.0, see also https://github.com/pantor/ruckig/issues/71. The reason for the fail is ErrorSynchronizationCalculation(-111) since no time synchronization can be found (after deactivating the check on trajectory duration).

But where does this bound come from? Whats the mathematical reason behind it? Do you see a chance to weaken on this condition?

Thanks a lot!

Fubini

[pantor]

Hi! This maximum duration is explained in section V.A in the RSS paper, in particular using the equation on the top right of the page. So the intuition behind this constraint is that Ruckig will calculate the position step-by-step (for these 7-step profiles), so the numerical error will add up.

There are few possible solutions for this: One might to increase the numerical accuracy of the underlying number type from double to long double. Another solution might be to improve the equations that cause these errors for numerical accuracy (in this example the Step2 Velocity UDUD case for DoF 2). Finally, one might add more profile types to Step2 (as Ruckig doesn't guarantee an exact trajectory here anyway).