@Arciera,
The abstract proposes forward transformation (projection) to the xz plane.
Indeed the problem does not arise when there is no z value.
And yes we are directly fitting in 3d space.
The problem isn't there, when you do a plane fit. This is in fact a 2d fit solution in 3d space,
including forward & inverse transformation steps. We did this using the 2d clothoid lib in our
previous planners.
Maybe we can think about this problem and how to solve it using a 3d space fit.
You can state that this is a clothoid wich makes a full torsion turn, wich has no reason to do so.
- I think the ceres is giving it a initial torsion value, and goes on with the torsion during fit iterations until a endpoint fit is found.
- Why does it use this full torsion only in certain space corner directions? Is there a reason we don't know yet?
-
@Mennil,
The clothoid3d uses a non-linear solver to find the xyz endpos for the clothoid fit.
The solver will iterate to the desired endpoint in shortest way, naturally.
It's very unlikely for the ceres solver to give us a self intersecting result as shown in your picture,
unless we give incorrect input angles.
And it's unlikely we have
infinite solutions regarding the 4-clothoid-spline fit.
The codebase ruled out self intersecting clohoids by making improvements to the abstract:
Abstract bug fixes
- In eq45, page 7, the Delta Theta is calculated by: Thetai4 - Thetai0.
The clothoid Delta Theta produced by this substraction, is not alway's correct.
When the incorrect value is used, it shows a self intersecting clothoid.
Eq.45 input Angles are in the range [0,-2pi], [0,2pi]. Substraction can lead to a incorrect
Delta Theta.
To solve this issue, we convert back the thetai[x] into a xy vector.
From here the signed angle between 2 vectors is calculated.
This ensures a correct Delta Theta value.
Problably this is also the reason why in the abstract forward & inverse transformations are used.
In this codebase forward & inverse transformations are obsolet
