scurve trajectory planner
19 Mar 2025 08:54 #324271
by Grotius
Replied by Grotius on topic linuxcnc scurve motion planner
Hi,
Here is the so called overfit. To show it better i made a cube.ngc test file.
closup cube corner:
Here is the so called overfit. To show it better i made a cube.ngc test file.
- The problem is clearly visible.
- Its a full torsion turn of 2*M_PI over the clothoid fit.
- It looks for the clothoid lib the solution is valid but unwanted for us.
closup cube corner:
Attachments:
Please Log in or Create an account to join the conversation.
19 Mar 2025 09:53 #324274
by MennilTossFlykune
Replied by MennilTossFlykune on topic scurve trajectory planner
Attachments:
Please Log in or Create an account to join the conversation.
19 Mar 2025 10:24 #324275
by meister
Replied by meister on topic scurve trajectory planner
WTF
the installer script from the first post have removed all user writable files on my system
the installer script from the first post have removed all user writable files on my system
git clone https://codeberg.org/skynet/linuxcnc_scurve_compact
cd linuxcnc_scurve_compact/cmake
./installer
....
rm: cannot remove 'src/python3.11/Parser/Python.asdl': Permission denied
rm: cannot remove 'src/python3.11/Grammar/python.gram': Permission denied
rm: cannot remove 'src/kugel.scad': Permission denied
rm: cannot remove 'src/MXM': Permission denied
CMake Warning:
Ignoring extra path from command line:
".."
CMake Error: The source directory "/" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.
Current directory after build_cmake: /usr/src/MXM/linuxcnc_scurve_compact/cmake
./installer: line 9: cd: configs: No such file or directory
./installer: line 10: ./run_axis_9: No such file or directory
Current directory after run_lcnc: /usr/src/MXM/linuxcnc_scurve_compact/cmake
installer finished.
odippel@odippel:/usr/src/MXM/linuxcnc_scurve_compact/cmake$
odippel@odippel:/usr/src/MXM/linuxcnc_scurve_compact/cmake/../.$ cd /usr/src/MXM/
odippel@odippel:/usr/src/MXM$ ls -l
total 0
Please Log in or Create an account to join the conversation.
19 Mar 2025 10:31 #324280
by Grotius
Replied by Grotius on topic scurve trajectory planner
@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.
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
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?
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
Attachments:
Please Log in or Create an account to join the conversation.
19 Mar 2025 13:28 - 19 Mar 2025 13:32 #324293
by Grotius
Replied by Grotius on topic scurve trajectory planner
@Arciera,
Attached a gcode sample. A cw and a ccw square. That contains the problem.
Extra torsion turn:
No extra torsion turn:
The investegation, i printed the clothoid result and take a look at the theta values, and compared them :
** where != means is not.
If clothoid output is like this, fit is ok:
you can introduce a tiny error to get the fit off-plane. A off plane fit seems to solves this issue.
So when you add 1e-6 (ultra tiny error) to one off the trimmed line's z-position, it goes off plane. Problem is solved.
So when lines have no intersection, there is no extra torsion turn.
Now i did not test any further. So i hope this is it.
Attached a gcode sample. A cw and a ccw square. That contains the problem.
Extra torsion turn:
No extra torsion turn:
The investegation, i printed the clothoid result and take a look at the theta values, and compared them :
** where != means is not.
If clothoid output is like this, fit is ok:
- theta10 Z != 0
- theta 20 XY = 0
- theta 14 Z = 0
- theta 24 XY = 0
- theta10 Z != 0
- theta 20 XY = 0
- theta 14 Z = 0
- theta 24 XY != 0
you can introduce a tiny error to get the fit off-plane. A off plane fit seems to solves this issue.
So when you add 1e-6 (ultra tiny error) to one off the trimmed line's z-position, it goes off plane. Problem is solved.
So when lines have no intersection, there is no extra torsion turn.
Now i did not test any further. So i hope this is it.
Attachments:
Please Log in or Create an account to join the conversation.
Time to create page: 0.341 seconds