Numerical accuracy stability issue

[lg609]

    Ruckig<1> otg(0.005);  // control cycle
    InputParameter<1> input;
    OutputParameter<1> output;

    // Set input parameters
    input.current_position = {0.024910};
    input.current_velocity = {0.416965};
    input.current_acceleration = {3.28077};

    input.target_position = {0.136553};
    input.target_velocity = {0.136894};
    input.target_acceleration = {0.};

    input.max_velocity = {1.15145};
    input.max_acceleration = {5};
    input.max_jerk = {40};

    // Generate the trajectory within the control loop
    std::cout << "t | position" << std::endl;
    while (otg.update(input, output) == Result::Working) {
        std::cout << output.time << " | " << join(output.new_position) << std::endl;

        output.pass_to_input(input);
    }

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

The result is: Trajectory duration: 0.285641 [s].

when I change the input

input.current_position = {0.0249108};

The result is: Trajectory duration: 0.450706 [s].

[pantor]

Hi! Trajectory generation and motion planning are complex non-smooth problems, and a slightly different input can result in drastically different trajectories. Ruckig calculates the time-optimal trajectory to a target state, and for example at some point the positional distance doesn't suffice to slow down the robot to reach the target velocity directly. Then, the robot needs to swing back first, resulting in this positional "overshooting". However, this is the time-optimal solution to the given target state within the given limits.

For both your inputs Ruckig seems to calculate the valid and time-optimal solution. Nevertheless, the Ruckig community version has some numerical stability issue which are solved/improved in the commercial version.

I saw that you work at Aubo. Jinqiang Zhao from Aubo has reached out to us a while ago but doesn't respond right now. Are you able to check if he got our last email? Thanks!

[lg609]

Hi! Trajectory generation and motion planning are complex non-smooth problems, and a slightly different input can result in drastically different trajectories. Ruckig calculates the time-optimal trajectory to a target state, and for example at some point the positional distance doesn't suffice to slow down the robot to reach the target velocity directly. Then, the robot needs to swing back first, resulting in this positional "overshooting". However, this is the time-optimal solution to the given target state within the given limits.

For both your inputs Ruckig seems to calculate the valid and time-optimal solution. Nevertheless, the Ruckig community version has some numerical stability issue which are solved/improved in the commercial version.

I saw that you work at Aubo. Jinqiang Zhao from Aubo has reached out to us a while ago but doesn't respond right now. Are you able to check if he got our last email? Thanks!

Thank you for your response. This algorithm feature may not meet our practical needs, and we expect that when the input changes continuously, the output trajectory also changes continuously. Zhao has received your email and will provide a response immediately.