scurve trajectory planner

Oh, forget about the cpu load. Its to late. I forgot that I tested the axis cycle time.

Hi Julian,

Did some updates.

The scurve is now conversed to c code. I think this is easyer for bug solving.
And it can now be used directly in lcnc components.

I forgot to apply the feed overide to the end velocity's of segments.
Now it's running much faster.

I came accross a new bug. When a new buffer was loaded, the velocity was starting from zero when
using feed overides around 300%. Lower than that the bug was not visible.
This now is solved. During a new buffer load and transition the velocity keeps up.

There was also a endvel=0 error, wich halted motion,  is solved by pushing the motion into a new segment,
depending on rundir.

Extreme feed overides:

Hi Grotius.

Really cool! Tomorrow I will have some time to test around. I also wrote a small ncode with some loops to test P and F values. Will test and provide tomorrow.

The conversion I dont get right now. Of course I know how to use components and so on, but have to look how you mean it.

juliankoenig87 wrote:

Hi Grotius.

Really cool! Tomorrow I will have some time to test around. I also wrote a small ncode with some loops to test P and F values. Will test and provide tomorrow.

The conversion I dont get right now. Of course I know how to use components and so on, but have to look how you mean it.

Julian, can you join the qtpyvcp chat room?

matrix.to/#/#qtpyvcp:matrix.org

Hi,

I was thinking about a algo to smooth trajectory path's. This is just an idea.

1. Create a triangle's & find gravity point off triangle's. Triangle is constructed in a loop by path point's n+0, n+1, n+2.
2. Max deviation point lies on the line n+1 up to the gravity point, but not exceed the gravity point. P=0 up to P=Infinity.
3. Connect the gravity points by a  line. (red).
4. Create half way line points on the line. (blue).
5. Connect half way line points by linestrip. (blue). Second stage.
6. Replace linestrip by a cubic spline.

Properties:
Works in 3d space.
Conversion of arc's to linestrips is required.
The new trajectory tends to move inwards when on a circle.

 

Let me know what you think.

Works in 3d space.
Conversion of arc's to linestrips is required.
The new trajectory tends to move inwards when on a circle.

1. Nice
2. Seems unproblematic as that is what a lot of cam output does anyway and deviation can be easily calculated and adjusted.
3. I think that's the same behavior as the current planner.

Thanks

Hi,

I like the idea also. So you want to go nearer to the points before doing a spline. 

I thought of splitting the resulting red points (limiting by gravity point an P) by half for example if the next angle is also in the same direction. Could be more sophisticated of course. Just a rough idea. This way we are not getting more inside in this situations.

Splitting in half between edgepoint and last point if next angle is the ame direction. And going one step back if the direction will change (not perfectly described of course).

Hi,

Today i thought maybe add a path filter to the planner. This is also just an idea that came up.

It uses no G64 P[x] value.
It uses no path blending and or fillets etc.
It works as backend filter for any path using G64 P[x] values.

It uses a hal_path_filter input parameter between 0 and 3000. Imagine 0 up to 3000 servo-cycles.

This is a simple algoritme that calculates the avarage of toolpath points [bufsize] in real time.

The runtime property is that how lower the speed, how closer it gets to the path. Deviation is small.
How faster the speed, deviation becomes bigger.
If normally the motion stops every gcode line because no G64 P[x] value is given, this algo keeps
up velocity's. In fact it automaticly generates endvelocity's for the trajectory.

In halscope the joint.x velocity and acceleration values, are nice.

hal_path_filter = 500
   

hal_path_filter = 1000
 

hal_path_filter = 2000
 

hal_path_filter = 3000


Show multiple filter values, 500, 750, 1000.
 

Let me know what you think?

 

@Arciera,

Thanks for responce.

3. I think that's the same behavior as the current planner
Yes, looks like so.

@Julian,

Also thanks for responce.

I like the idea also. So you want to go nearer to the points before doing a spline.
The idea is polyline simplyfication. Then i thought maybe use :

Douglas-Peucker

 

Visvalingam-Whyatt

 

However both algo's don't satisfy cnc path smoothing.

Then i tried something on a paper with a pen myself. And came up with the triangles
centroid idea.

In Cgal they use the idea off convex hull for triangles.

 

However,
this idea is not really using a convex hull method, it's more like a forward sweep convex hull or
triangle-fan.

When the resulting line strip looks ok. Then doing a splinify is problably most succesfully.
However, if you use the "filter algo from previous post" then used as the planners back-end,
the result is maybe good enhough, you don't need the splinify.

Splitting in half between edgepoint and last point if next angle is the ame direction. And going one step back if the direction will change (not perfectly described of course).
I don't get it. .  But does'nt matter. Thanks for your help yesterday !


From DeepSeek:
Possible Names or Related Algorithms:

Laplacian Smoothing:
A common technique in mesh and curve smoothing that averages points with their neighbors. Your method is somewhat similar but uses centroids and halfway points instead of direct averaging.
 

Centroidal Voronoi Tessellation (CVT)
While not a direct match, CVT involves optimizing point positions (like centroids) to achieve smoothness in a geometric structure.


It looks like the algo is similar to Laplacian smoothing for the first stage. liqimai.github.io/blog/AAAI-18/
However the Laplacian is not using centrold's. And here it show's only the 2d solution. And algo is
working different as we use it.
Then it has no second stage.

 

... month of study in vision system algorythm ... finally see a real utilizations ....