scurve trajectory planner

@DauntlessA

I think your method of fixing this by applying a tiny offset worked because it meant that the the loop was no longer complete so its signed area was a lot larger. Although likewise, adding this offset could technically break a curve which would have worked without it?

The offset is not breaking the curve, and the curve is valid without this offset.
The 1e-12 offset was made to get the curve out off a singularity.
The 4-clothoid constrain formula has this result in rare cases where local clothoid plane alignes with global world plane.

We have input xy angle, input z angle for the clothoid fit.

The abstract could also use vector rotation as input, wich can be used to set the
torsion in and out rotations. Technically you can create clothoid helixes using this torsion turn value. But the abstract does not
use this oppertunity.

@Arciera,
Thanks for your contribution!

Hello,

I tested the S-curve feature on the following system:
PC: HP with Intel i3 3rd Gen, 2x4GB RAM (latency < 20k)
OS: Debian 12
LinuxCNC: 2.10 pre-release
I created an XYZ mill configuration using StepConf and ran the same G-code with and without tpmod_scurve.
The results can be seen in the attached videos.
Observations:
Without the S-curve, the feed rate remains continuous.
With the S-curve enabled, the feed fluctuates significantly—at times dropping to 1/10 of the programmed feed rate.
It also noticeably increases the overall program execution time (2,5x slower with scurve in this situation).
I tried increasing VECTOR_BUFFER_SIZE to 100, but it didn’t help much. (Just for testing, I also set VECTOR_BUFFER_SIZE = 2, which made the behavior even worse.)
Maximum velocity and acceleration settings are visible in the video (they’re not particularly high, and are the same in both cases).
Question:
Do you think it's possible to achieve a continuous feed rate using the S-curve?

Files: 
drive.google.com/drive/folders/1uR1LfCv_...4-w6Daf8?usp=sharing

 

Hi Halas,

There is added a hal param for inertia wich can be set to from 0 up to 1 to run at programmed feed.
This results in less feed fluctiations at corners.

See the param section :  readme.

Also program execution time should be faster. As i reverted the acc max change.

Do you mean the hal_inertia_factor parameter?
Sorry, but I can't find this parameter (neither in halshow nor in the source code).

"Also, the program execution time should be faster."
Are you suggesting lowering this value: SERVO_PERIOD = 1000000,
or this one:
[TASK]
TASK = milltask
CYCLE_TIME = 0.001
I performed the above-mentioned tests with these settings.
 

Hi,

i think you need to update local git clone first. It needs latest updates.

Then build_cmake.

S curves. I neeeds it.

So how stable is this at this point for "real work"? I have not been paying attention the last 2-3 months much.