New Trajectory Planner - Testers/programs wanted

wow - rob, as aways, very impressive. (I am someone that keeps checking you experimental branch to see if you have added any commits.. )

thanks for all your hard work!

sam

rellenberg wrote:

Rick G wrote: The new TP runs the arcs and the circle at the same steady speed, so the first portion runs smoother and faster. This speed is somewhat slower than the current TP did the full circle.

I ran your test file, and I think slowdown you're seeing was fixed in the experimental branch. I'm working on an update to push out to the beta branch that will fix this and a few other minor issues.

Rick G wrote: Where the current TP blends on exiting the circle to the straight the new TP appears not to and prepares for a stop even thought there is a extra lead out move.

I'm seeing this too, and I think it's because Naive CAM is turned on (Q0.001), which combines the lead-out move into a single segment. Since this new single segment is the last move in the program, there is still that pesky exact stop. I'm looking into ways to get around this limitation, but it's surprisingly tricky. There isn't currently a way for the motion module to know that a program is complete. Falling back to a parabolic blend on-the-fly is tricky because parabolic blends have a lower max acceleration. One thing that could work for this is reducing the acceleration that the optimizer sees for the last segment, so that we can safely fall back to parabolic blends on the fly. If that works, I should have a fix out today.

I am also looking into line-arc and arc-arc blends. The good news is, I've managed to get line-arc blends working in some circumstances (see attached). Unfortunately, I'm still working some bugs out, and the line-arc code is rather messier than line-line. The trade-off with circular arc blends is that line-line stuff is mathematically easy, but anything more complicated has to be handled case-by-case. Luckily, as you said, line-line intersections are the most common.

-Rob

skunkworks wrote: wow - rob, as aways, very impressive. (I am someone that keeps checking you experimental branch to see if you have added any commits.. )

Glad to hear it! It's been a little quiet lately because I've got a few features in development, but they aren't quite ready for testing. I'm trying to get at least one out today, and also push the stable fixes to the beta branch.

I noticed that your screenshots have offsets displayed in the preview pane.. If you turn them off in the view menu - it then displays the velocity. (it is a bug - there is a bug tracker on it)

ie

rellenberg wrote:

skunkworks wrote: wow - rob, as aways, very impressive. (I am someone that keeps checking you experimental branch to see if you have added any commits.. )

Glad to hear it! It's been a little quiet lately because I've got a few features in development, but they aren't quite ready for testing. I'm trying to get at least one out today, and also push the stable fixes to the beta branch.

Thanks for the tip! That certainly cleans up the screen a bit.

In other news, I think I've found a fix for the slowdown problem on the experimental branch. Here's how it works:

1. If we get within two segments of the end, force the last segment to be "finalized", i.e. we can't change it's length
2. Re-run the optimization over the last 2 segments
3. If we're not actually at the end (queue starvation), then the next blend arc will fall back to parabolic, so we won't have acceleration violations

There are a few other under-the-hood changes in the experimental branch, but nothing that should have a huge effect on performance yet.

I just pulled the experimental branch. The last segment now runs smooth.

just goofing around - I ran steve.ngc - it had huge acceleration constraint viloations. Maybe part of your arc-line work?

rellenberg wrote: Thanks for the tip! That certainly cleans up the screen a bit.

In other news, I think I've found a fix for the slowdown problem on the experimental branch. Here's how it works:

1. If we get within two segments of the end, force the last segment to be "finalized", i.e. we can't change it's length
2. Re-run the optimization over the last 2 segments
3. If we're not actually at the end (queue starvation), then the next blend arc will fall back to parabolic, so we won't have acceleration violations

There are a few other under-the-hood changes in the experimental branch, but nothing that should have a huge effect on performance yet.

That's strange, steve.ngc seems to run fine in my simulation and RT builds. However, I ran a big batch of tests and found a small overage on arc-parabolic-blend.ngc (attached). Is it consistently going over at a particular spot?