Fix reverse motions the have different signs of v0 and v1

[SungChiCHIANG]

Currently, the calculation of a reverse motion may get the wrong result when the signs of v0 and v1 are different. For example, consider an input:

    let constraints = SCurveConstraints {
        max_jerk: 3.,
        max_acceleration: 2.0,
        max_velocity: 3.,
    };
    let start_conditions = SCurveStartConditions {
        q0: 0.,
        q1: 10.,
        v0: -1.,
        v1: 2.,
    };
    let input = SCurveInput {
        constraints,
        start_conditions,
    };

And the result profile will be like:

But when a reverse version of the above input is calculated:

    let constraints = SCurveConstraints {
        max_jerk: 3.,
        max_acceleration: 2.0,
        max_velocity: 3.,
    };
    let start_conditions = SCurveStartConditions {
        q0: 0.,
        q1: -10.,
        v0: 1.,
        v1: -2.,
    };
    let input = SCurveInput {
        constraints,
        start_conditions,
    };

The result profile will be like:

After the modification, the result profile will be like the reverse version of the original profile, as expected:

Two test cases are added as well to confirm that two opposite start conditions will get the same time intervals.

[codecov]

Codecov Report

Patch coverage: 79.31% and project coverage change: +1.23% 🎉

Comparison is base (0e7dc6f) 79.37% compared to head (43178d8) 80.60%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #13      +/-   ##
==========================================
+ Coverage   79.37%   80.60%   +1.23%     
==========================================
  Files           1        1              
  Lines         543      593      +50     
  Branches       95      107      +12     
==========================================
+ Hits          431      478      +47     
+ Misses         63       52      -11     
- Partials       49       63      +14     

Files Changed	Coverage Δ
src/lib.rs	80.60% <79.31%> (+1.23%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[SungChiCHIANG]

Hi, should I just add some unit tests to boost up the coverage rate? I can see that SCurveInput::is_trajectory_feasible() is not covered yet.

[marcbone]

First of all, thank you very much for your PR! I am always happy when somebody is opening a PR. I didnt had time yet to look into your PR in detail and you can expect it to take a while. But at a first glimpse it looks like you added a test for the bug you are fixing, so I am more than happy with that. But of course more tests are always appreciated 😅 . Also keep in mind that code coverage for rust based projects is calculated in weird ways. So dont worry about it going down a bit.