New Trajectory Planner - Testers/programs wanted

No, I had the "old" once.

ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 1
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_SMOOTHING_THRESHOLD = 0.4

Will change and try again

That should have worked.. (I just notice that rob had changed the ini setting..) I don't exactly know what some of them do

ARC_BLEND_ENABLE = 1 (obviously enables arc blending)
ARC_BLEND_FALLBACK_ENABLE = 0 (If enabled - this says fall back to parabolic blending if faster)
ARC_BLEND_OPTIMIZATION_DEPTH = 50 (look ahead)
ARC_BLEND_GAP_CYCLES = 4 (don't know)
ARC_BLEND_RAMP_FREQ = 20 (don't know)

awes wrote:

No, I had the "old" once.

ARC_BLEND_ENABLE = 1
ARC_BLEND_FALLBACK_ENABLE = 1
ARC_BLEND_OPTIMIZATION_DEPTH = 50
ARC_BLEND_SMOOTHING_THRESHOLD = 0.4

Will change and try again

OK, changed and tested again.

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

About 18% faster. Cool.

Hi Sam.

I tried to follow your instructions:

cd whateveryourlinuxcncRIPdirectoryis
git fetch origin
git branch --track circular-blend-arc-rc1 origin/circular-blend-arc-rc1




but I got the error message like this:

bj@bj-cr:~$ cd linuxcnc-rtos/
bj@bj-cr:~/linuxcnc-rtos$ git fetch origin
remote: Counting objects: 872, done.
remote: Compressing objects: 100% (328/328), done.
remote: Total 510 (delta 389), reused 217 (delta 167)
Receiving objects: 100% (510/510), 1.19 MiB | 1.11 MiB/s, done.
Resolving deltas: 100% (389/389), completed with 150 local objects.
From git://git.mah.priv.at/emc2-dev
* [new branch] arm-read-tsc -> origin/arm-read-tsc
* [new branch] float-compare -> origin/float-compare
3b3fdf1..47ac165 gmoccapy_1_0 -> origin/gmoccapy_1_0
* [new branch] zultron-ubc-merged-into-mhaberle-ubc -> origin/zultron-ubc-merged-into-mhaberle-ubc
bj@bj-cr:~/linuxcnc-rtos$ git branch --track circular-blend-arc-rc1 origin/circular-blend-arc-rc1
fatal: Not a valid object name: 'origin/circular-blend-arc-rc1'.

Could you help me what did I wrong?

it looks like you are tracking git://git.mah.priv.at/emc2-dev not git.linuxcnc.org.. (and it doesn't seem to be up-to-date with master)

Lets see - how do you fix that.. You have to add the linuxcnc repository.

Well - I don't know off the top of my head... It might be easier for you to create a new rip following the updated directions in the first post...

If I find it - I will post the directions for your issue.

sam

ok bjames28 - In you git directory try this...

git remote add linuxcnc git://git.linuxcnc.org/git/linuxcnc.git
git fetch linuxcnc
git branch --track circular-blend-arc-rc1 linuxcnc/circular-blend-arc-rc1
git checkout circular-blend-arc-rc1
cd src
make clean
./autogen.sh
./configure
make
sudo make setuid
cd ..
. ./scripts/rip-environment
linuxcnc

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