c2 smooth velocity profile

Hi

I hacked a c2-smooth velocity profile generator into the current trajectory planner. Screenshots of HAL-Scope of the difference are attached. Blending with "circular arcs" etc... is not affected, just constant acceleration is replaced with smooth quintic Bezier interpolation, control points set so acceleration and jerk is zero at beginning and end of segment.

Feedoverride and pausing does not work ATM and will lead to unexpected und unwanted things.

Some larger jerkiness remains when entering and exiting arc segments and the code is just a proof of concept, if somebody is interested it is here: github.com/rmu75/linuxcnc/tree/rs_6otp.

I would welcome comments if this approach is at all feasible or if there is something inherently wrong.

Next steps would be to actually introduce a jerk limit (just now it only limits acceleration to machine limits and "distributes" resulting jerk a bit more), figure out how to deal with feed override and clean up a little bit.

watching excitedly...

This is from Rob E (both Andy and I emailed him )

It looks like both of you guys had the same idea when you saw this post . I'm glad someone is trying out new things for the motion planner. This looks like a clever way to get finite jerk motions. I've actually worked with this kind of motion planning outside of LinuxCNC, and it has some pros and cons. The big advantage is that the motion profile is a single polynomial (or 3 if you want a constant velocity portion), instead of the 7 phases of an S curve motion. It's also straightforward to do blending this way, since you can just start the next motion early (like how we do parabolic blending). There's some checking required to make sure the derivatives are within limits, of course.

As they've already seen, the downside of this approach is that it's hard to do responsive online changes like feed override and pause / resume, since the motion profile is fixed (once you start the motion). To make it work, you essentially have to break up the trajectory into many short motions (but not so short that you can't reach the requested speed). Then, if the user requests a feed override (or stop), you can do so by changing the end velocity of the next segment.

I'm hand-waving away some details here, but the tradeoff is that planning is a lot simpler if user overrides don't have to be as responsive (i.e. one update per segment instead of continuous control at every interrupt).

I'm curious to see what they do with this! I'd like to try it out myself once I get some time to mess around with it.

-Rob

skunkworks wrote:

This is from Rob E (both Andy and I emailed him )
As they've already seen, the downside of this approach is that it's hard to do responsive online changes like feed override and pause / resume, since the motion profile is fixed (once you start the motion). To make it work, you essentially have to break up the trajectory into many short motions (but not so short that you can't reach the requested speed). Then, if the user requests a feed override (or stop), you can do so by changing the end velocity of the next segment.

Breaking up the curve and continuing it smoothly with some different velocity target should be no problem, but it's a bit tricky and currently distracts only from the real stuff thats not yet working correctly (i.e. proper estimation of maximum acceleration and avoiding limits).

The easy thing would be for short segments to ignore overrides and just insert another acceleration afterwards, long segments probably have a cruise phase with constant velocity, those also can be broken up easily. That should be sufficient for user-controlled overrides, nobody should care about the exact millisecond the feed override kicks in...

Explicit constructions of an S-Curve with constant derivative of jerk followed by constant jerk, constant acceleration, constant velocity phases and at the end the other way back seems to be very messy and have a ton of cases and corners, especially if you want to continue a given velocity/acceleration/jerk.

Hello there,

I've read that you are working on s-curve velocity profile. Is there any chance to help this task done? I wanted to try your's hacked fork, but the pausing function is the thinkg I would rather not resign from.

Regards
Mike

Emergency stop still works, so if you are brave, you could try it. I would verify toolpaths "dry" and look for acceleration violations before running it on a real machine.

I have sort of a plan what to do next, that involves integrating/translating my bezier c++ routines into something suitable for linuxcnc and cleaning up the math stuff. Then some edge-cases remain to be debugged where acceleration limits are exceeded, but ATM i have more pressing things to do.

Pausing and velocity override will of course come back, that branch just now is more or less a proof of concept thing to test whether this approach is feasible and useful.

If you do tests on a real machine I would appreciate feedback of observed effects / differences to stock trajectory planner.

Allright, emergency stop do work, but what about the pause? How the acceleration violation you have mentioned are going to overshoot the limits? I mean if we set arbitrary value for acceleration 'a' how much the algorithm could overshoot this value? 1.2*a, 2*a or 100*a?

Of course I can test your's code on the machine, however some specification for benchmark would be a good thing to discuss.

Regards

hi, any update?

Still very busy with other stuff. But I will continue work on this RSN, there have been some changes to the TP recently that I need to examine. However, real progress will not happen before end of year (probably).

NIce, I have been talking with a friend of me he is a mechanical Phd, he is interested in the test of some trajectory models, but I not sure how to begin I really appreciate if you can point me.

I think this is a very important feature for LinuxCNC, (and of course for the user) and looking at how to create a working team for this task,