New Trajectory Planner - Testers/programs wanted

Great!!! How is the motion? What does it sound like?

awes wrote: OK, changed and tested again.

From 17 min with standard distribution of LunixCNC to 14 min with the beta.

About 18% faster. Cool.

I made some changes to the config settings, which I'll try to explain here. I may tweak or replace these if there's a better way to represent them.

ARC_BLEND_ENABLE = 1 : self-explanatory, disable the new TP method entirely.

ARC_BLEND_FALLBACK_ENABLE = 0 (Optionally fall back to parabolic blends if the estimated speed is faster. However, this estimate is rough, and it seems that just disabling it gives better performance.)

ARC_BLEND_OPTIMIZATION_DEPTH = 50 (Lookahead depth in number of segments)

ARC_BLEND_GAP_CYCLES = 4 (How short the previous segment must be before the trajectory planner "consumes" it)

Often, a circular arc blend will leave short line segments in between the blends. Since the geometry has to be circular, we can't blend over all of a line if the next one is a little shorter. Since the trajectory planner has to touch each segment at least once, it means that very tiny segments will slow things down significantly. My fix to this way to "consume" the short segment by making it a part of the blend arc. Since the line+blend is one segment, we don't have to slow down to hit the very short segment. Likely, you won't need to touch this setting.

ARC_BLEND_RAMP_FREQ = 20 (This is a "cutoff" frequency for using ramped velocity)

"Ramped velocity" in this case just means constant acceleration over the whole segment. This is less optimal than a trapezoidal velocity profile, since the acceleration is not maximized. However, if the segment is short enough, there isn't enough time to accelerate much before we hit the next segment. Recall the short line segments from the previous example. Since they're lines, there's no cornering acceleration, so we're free to accelerate up to the requested speed. However, if this line is between two arcs, then it will have to quickly decelerate again to be within the maximum speed of the next segment. This means that we have a spike of acceleration, then a spike of deceleration, causing a large jerk, for very little performance gain. This setting is a way to eliminate this jerk for short segments.

Basically, if a segment will complete in less time than 1 / ARC_BLEND_RAMP_FREQ, we don't bother with a trapezoidal velocity profile on that segment, and use constant acceleration. (Setting ARC_BLEND_RAMP_FREQ = 1000 is equivalent to always using trapezoidal acceleration, if the servo loop is 1kHz). I had considered making the RAMP_FREQ into a time instead, but it seems like the idea of a cutoff frequency is more intuitive, at least to a controls engineer.

I can also express it in terms of the "peak" velocity. In other words, what maximum velocity would a segment hit with trapezoidal vs ramp velocity? If the difference is less than some value, or some percentage, then use ramped velocity for smoothness. Let me know if you think one way makes more sense over the other.

Hi Sam,

Thanks for the hint, that solved my issue with git.
I was able to compile and I have now working new TP. Great!

I wanted to test your pyvcp panel with peak acc/velocity display.
I put the check_constraints.hal and postgui.hal in the appropriate directory,modified the INI file accordingly, the panel appears in the right place, but the axis Acc/Vel values are not updated, all remain zero.
The cycle time works.

What else do I need to modify to get the numbers updated?

Best regards:
James

Sam,

Thanks for keeping us up to date. Have the instructions at the beginning of this post been changed to reflect the new branch instructions?

Rob,

Thanks for the information on the settings, it answers a lot of questions.

Rick G

Maybe post your hal and ini files? there is some dirivative calculaters in the main hal file...

ie (this is a sample - you cannot just copy and past this in - have to make it work in your hal..)
I bolded what I think should be added...


# load 6 differentiators (for velocity and accel signals
loadrt ddt names=ddt_x,ddt_xv,ddt_y,ddt_yv,ddt_z,ddt_zv
# load additional blocks
loadrt hypot names=vel_xy,vel_xyz

# add motion controller functions to servo thread
addf motion-command-handler servo-thread
addf motion-controller servo-thread
# link the differentiator functions into the code
addf ddt_x servo-thread
addf ddt_xv servo-thread
addf ddt_y servo-thread
addf ddt_yv servo-thread
addf ddt_z servo-thread
addf ddt_zv servo-thread
addf vel_xy servo-thread
addf vel_xyz servo-thread

# create HAL signals for position commands from motion module
# loop position commands back to motion module feedback
net Xpos axis.0.motor-pos-cmd => axis.0.motor-pos-fb ddt_x.in
net Ypos axis.1.motor-pos-cmd => axis.1.motor-pos-fb ddt_y.in
net Zpos axis.2.motor-pos-cmd => axis.2.motor-pos-fb ddt_z.in

# send the position commands thru differentiators to
# generate velocity and accel signals
net Xvel ddt_x.out => ddt_xv.in vel_xy.in0
net Xacc <= ddt_xv.out
net Yvel ddt_y.out => ddt_yv.in vel_xy.in1
net Yacc <= ddt_yv.out
net Zvel ddt_z.out => ddt_zv.in vel_xyz.in0
net Zacc <= ddt_zv.out

# Cartesian 2- and 3-axis velocities
net XYvel vel_xy.out => vel_xyz.in1
net XYZvel <= vel_xyz.out

bjames28 wrote: Hi Sam,

Thanks for the hint, that solved my issue with git.
I was able to compile and I have now working new TP. Great!

I wanted to test your pyvcp panel with peak acc/velocity display.
I put the check_constraints.hal and postgui.hal in the appropriate directory,modified the INI file accordingly, the panel appears in the right place, but the axis Acc/Vel values are not updated, all remain zero.
The cycle time works.

What else do I need to modify to get the numbers updated?

Best regards:
James

rellenberg wrote: ARC_BLEND_OPTIMIZATION_DEPTH = 50 (Lookahead depth in number of segments)

To expand on this a bit, you can choose this value somewhat arbitrarily. Here's a formula to estimate how much "depth" you need for a particular config:

# n = v_max / (2.0 * a_max * t_c)
# where:
# n = optimization depth
# v_max = max axis velocity (UU / sec)
# a_max = max axis acceleration (UU / sec)
# t_c = servo period (seconds)

So, a machine with a maximum axis velocity of 10 IPS, a max acceleration of 100 IPS^2, and a servo period of 0.001 sec would need:

10 / (2.0 * 100 * 0.001) = 50 segments to always reach maximum velocity along the fastest axis.

In practice, this number isn't that important to tune, since the lookahead rarely needs the full depth unless you have lots of very short segments. If during testing, you notice strange slowdowns and can't figure out where they come from, first try increasing this depth using the formula above.

If you still see strange slowdowns, it may be because you have short segments in the program. If this is the case, try adding a small tolerance for Naive CAM detection. A good rule of thumb is this:

# min_length ~= v_req * t_c
# where:
# v_req = desired velocity in UU / sec
# t_c = servo period (seconds)

If you want to travel along a path at 1 IPS = 60 IPM, and your servo period is 0.001 sec, then any segments shorter than min_length will slow the path down. If you set Naive CAM tolerance to around this min length, overly short segments will be combined together to eliminate this bottleneck. Of course, setting the tolerance too high means big path deviations, so you have to play with it a bit to find a good value. I'd start at 1/2 of the min_length, then work up as needed.

rellenberg wrote: ARC_BLEND_RAMP_FREQ = 20

Another trade-off between smoothness and speed is controlled by this cutoff frequency. The benefits in terms of smoothness are explained in the prev. post, but it wasn't clear what this costs you in terms of performance. You can characterize the worst-case loss of performance by comparing the velocity that a trapezoidal profile reaches vs. the ramp:

# v_ripple = a_max / (4.0 * f)
# where:
# v_ripple = average velocity "loss" due to ramping
# a_max = max axis acceleration
# f = cutoff frequency from INI

For the aforementioned machine, the ripple for a 20Hz cutoff frequency is 100 / (4 * 20) = 1.25 IPS. This seems high, but keep in mind that it is only a worst-case estimate. In reality , the trapezoidal motion profile is limited by other factors, such as normal acceleration or requested velocity, and so the actual performance loss should be much smaller. Increasing the cutoff frequency can squeeze out more performance, but make the motion rougher due to acceleration discontinuities. A value in the range 20Hz to 200Hz should be reasonable to start.

Finally, no amount of tweaking will speed up a toolpath with lots of small, tight corners, since you're limited by cornering acceleration. Still, if you see a slowdown that you think shouldn't be there, post the example here. There's always the chance that there's a bottleneck that we missed.