Online calculator for jerk-limited time-optimal trajectories

[Peter Nachtwey]

Cheeco, I have many more test cases I will get to tomorrow but if your target generator works you can make money by selling the target generator to companies that want to make a motion controller. This would be like Codesys selling the PLC ladder logic program to companies that want to have a PLC but don't have the resources to create their own ladder logic software.

I am impressed that you are doing this out of a passion just to know or to do it. Few have this passion. Passion is what separates the best from the very very good.

BTW, I used Mathcad to generate most of my formulas. Mathcad is old and obsolete but I have been using it for over 25 years so it is the devil I know, The example I provided above used wxMaxima. I also used Mathematica for the most difficult problems. What software did you use to generate the formulas?

[Peter Nachtwey]

I have test a few more cases including the toughest one with 6 equations and 6 unknowns that was used by Robert Lewis. We get the same answers.
Solving this last problem the way I did provides an explicit solution. It works but it is very complicated. You have opened my eyes a bit. I am going to try an iterative just to see if it works. The problem with iterative solutions is that they take time that I don't have in a motion controller where the calculation time must be relatively deterministic.

What could be improved?

What I realize is that I need to change my HMI. I need to add a time in the column for the cursor values. I had to go back to my Mathcad worksheet to do accurate comparisons because my HMI doesn't display time. I also need a way of placing the cursor at a specific time because my cursor resolution is pixel limited.


Cheeco should allow for different acceleration and deceleration rates. Often people want to decelerate slower than they accelerate.




Excellent Job!!!!

[tandempace]

Peter, thanks for your useful formulas. They are easy to follow and very useful for an automation project we are working on.


I also want to be able to calculate the acceleration time when I know the initial velocity, given acceleration and Jerk and the distance traveled over this motion.


Thanks
Michael

[jast.313]

Originally Posted by Peter Nachtwey

Meanwhile, just so the people here know what it takes to do this will provide this link.https://deltamotion.com/peter/Maxima/Seg1234567.html
Even the simple case requires solving 17 equations for 17 unknowns! Try solving that in a PLC!

Good job!

Peter, I tried this link and see it requires a sign in. I would love to see the 17 equations. Any possibility to open this up?

Thanks,
Jas
directmotion.com

[Peter Nachtwey]

I will have my IT guy check into it tomorrow.


BTW, we entered the same move into a S7-1500. The S7-1500 does not provide a jerk limited time optimal motion trajectory. I bet few motion controllers provide the optimal motion trajectory.

[userbeware]

Originally Posted by jast.313

Peter, I tried this link and see it requires a sign in. I would love to see the 17 equations. Any possibility to open this up?

Thanks,
Jas
directmotion.com

Also interested in having a look at those EQ's if possible. Impressive work Cheeco, fair play.

Thanks!

[Peter Nachtwey]

You should be able to click on the link and see the equations. There is nothing that fancy for a normal move. The problem is much more complicated if the move is so short that the commanded velocity and acceleration are not reached.


Normally there are 7 motion segments/states 1 to 7. Segment 0 is the stopped state.

[drbitboy]

Hi Peter,


So the input parameters are

• ||j||, the maximum jerk magnitude
• ||a||, the maximum acceleration/deceleration magnitude
• ||v||, the maximum speed
• x7, x0, (or x7 = distance to cover, and assume x0 is zero)
• v0, v7 (sometimes*, but not necessarily, both zero?)
• a0, a7 (same case re: zero as v0, v7?)

And it solves for time (or times) and/or distance as a function of time.


Is that about right?


Thanks


* I changed the "usually" to "sometimes" - the [v0=v7=0] case, or not, is going to be application-dependent, I suspect.

[jast.313]

Peter, really great work you have done...

CNC requires an interesting feature "feed rate override" where the operator changes the programmed "v" at runtime, often in the middle of a move... this means "v" & "t0-t7" are not constant throughout the move (which changes x1,x2,x3,etc...)...
I believe this can also result in the segment state to 'go backwards' (ie: if t3<t<t4 and the operator doubles the "v", this could now mean t2<t<t3 or t1<t<t3)...

Very complicated. Have you have worked in situations like this?

[Peter Nachtwey]

Originally Posted by drbitboy

Hi Peter,


So the input parameters are

• ||j||, the maximum jerk magnitude
• ||a||, the maximum acceleration/deceleration magnitude
• ||v||, the maximum speed
• x7, x0, (or x7 = distance to cover, and assume x0 is zero)
• v0, v7 (sometimes*, but not necessarily, both zero?)
• a0, a7 (same case re: zero as v0, v7?)

And it solves for time (or times) and/or distance as a function of time.


Is that about right?


Thanks


* I changed the "usually" to "sometimes" - the [v0=v7=0] case, or not, is going to be application-dependent, I suspect.

You are right. Usually v0=v7=a0=a7 for a point to point move but many times the user need to change something on-the-fly. In sawmill applications it it often necessary to change the final position , x7, while ramping down.


Any case that may arise must be handled correctly. My graphical program in post #6 is great for testing but I have another version without an interface that has tested 200 trillion, yes trillion, combinations of moves. At work we call this any PVA to any PVA. PVA = position, velocity and acceleration.

[Peter Nachtwey]

Originally Posted by jast.313

Peter, really great work you have done...

CNC requires an interesting feature "feed rate override" where the operator changes the programmed "v" at runtime, often in the middle of a move... this means "v" & "t0-t7" are not constant throughout the move (which changes x1,x2,x3,etc...)...
I believe this can also result in the segment state to 'go backwards' (ie: if t3<t<t4 and the operator doubles the "v", this could now mean t2<t<t3 or t1<t<t3)...

Very complicated. Have you have worked in situations like this?

Yes, a good controller can move from any PVA to any PVA efficiently. Look at post #6. In this example a command is issued to stop but the command decel limits the deceleration so the motion must overshoot and come back. This motion is NOT optimized. Look at time 1.32 seconds. At this time the motion has stopped and then starts accelerating back to the set point at 0,0,0. This is not optimal because the acceleration went to 0 too. This wastes time. You can see the gray line ( acceleration ) is negative until about time 1.23 and then the acceleration become less negative until it becomes zero at 1.32. We call this a ramp reverse. An optimal ramp reverse would keep the acceleration -100 during the slow down then continue back to down to -200 at about time 1.5 seconds. This would save perhaps a tenth of a second.


No one caught this. We I examine other controllers I have a few tests to I use to find non optimal movement.


So why does this matter? Say for instance you have a flying shear or cut off machine. After the cut is made the cutter needs to retract quickly get get read for the next cut. Saving a tenth of a second can mean a lot to production. On top of that, decelerating through 0 velocity reduces the distance traveled and saves energy.


Details, details.


For CNC type of motion we can change the feed speed on the fly. We can do this in 2 or 3 dimensions.

I have an example but I don't change the feed speed but that is the easy part.

https://deltamotion.com/peter/Maxima/feedspeed.html
A little calculus for those stuck at home like me.

[jeffersonhui]

Originally Posted by Peter Nachtwey

Yes, a good controller can move from any PVA to any PVA efficiently. Look at post #6. In this example a command is issued to stop but the command decel limits the deceleration so the motion must overshoot and come back. This motion is NOT optimized. Look at time 1.32 seconds. At this time the motion has stopped and then starts accelerating back to the set point at 0,0,0. This is not optimal because the acceleration went to 0 too. This wastes time. You can see the gray line ( acceleration ) is negative until about time 1.23 and then the acceleration become less negative until it becomes zero at 1.32. We call this a ramp reverse. An optimal ramp reverse would keep the acceleration -100 during the slow down then continue back to down to -200 at about time 1.5 seconds. This would save perhaps a tenth of a second.


No one caught this. We I examine other controllers I have a few tests to I use to find non optimal movement.


So why does this matter? Say for instance you have a flying shear or cut off machine. After the cut is made the cutter needs to retract quickly get get read for the next cut. Saving a tenth of a second can mean a lot to production. On top of that, decelerating through 0 velocity reduces the distance traveled and saves energy.


Details, details.


For CNC type of motion we can change the feed speed on the fly. We can do this in 2 or 3 dimensions.

I have an example but I don't change the feed speed but that is the easy part.

https://deltamotion.com/peter/Maxima/feedspeed.html
A little calculus for those stuck at home like me.

Hi, Peter,

Sorry to revive a 2-year old thread, but it looks like your Delta Motion links are broken now. Would you be able to fix them? I am having a hard time solving the 3rd order equations for jerk as well. I would like to see the equations that you solved for the S-curve motion profile, including this link:
https://deltamotion.com/peter/Maxima/Seg1234567.html

[Peter Nachtwey]

Originally Posted by jeffersonhui

Hi, Peter,

Sorry to revive a 2-year old thread, but it looks like your Delta Motion links are broken now. Would you be able to fix them? I am having a hard time solving the 3rd order equations for jerk as well. I would like to see the equations that you solved for the S-curve motion profile, including this link:
https://deltamotion.com/peter/Maxima/Seg1234567.html

I renamed the directory
https://deltamotion.com/peter/wxMaxima/Seg1234567.html
However, that link does have much to do with 3rd order motion profiles. This one is better.
https://deltamotion.com/peter/wxMaxima/Seg1234567.html
Also, this thread covers a very difficult case. My example assumes that the acceleration and velocity limits are reached. The calculations get to be MUCH more difficult if the limits are not reached. As far as I know, Cheeco and I are the only ones that have solved it in a way that can be implemented in a motion controller. Solutions generated by Mathcad, Mathematica, and wxMaxima are too long to be useful.
Generating 3rd order motion profiles is not easy if trying to be optimal. I haven't seen another motion controller, that can solve the problem Cheeco presented, optimally.

[jeffersonhui]

Hi, Peter,

Thanks for such a fast response.

I am trying to implement jerk control on a Codesys PLC, but don't know if it's even possible. I am currently getting an issue where the acceleration and velocity reach 0 together, but the position falls short of the setpoint due to rounding issues.

I don't think Codesys is equipped to handle matrices or solving many equations together so don't even know if I can implement your method...

[Peter Nachtwey]

Originally Posted by jeffersonhui

Hi, Peter,

Thanks for such a fast response.

I am trying to implement jerk control on a Codesys PLC, but don't know if it's even possible.

What do you mean by jerk control? The jerk is usually specified by the user. Codesys should implement the PLC Open motion libraries so you don't need to re-invent the wheel.

I am currently getting an issue where the acceleration and velocity reach 0 together, but the position falls short of the setpoint due to rounding issues.

Yes, this can be a huge problem, but there are tricks.

I don't think Codesys is equipped to handle matrices or solving many equations together so don't even know if I can implement your method...

You don't do this inside Codesys. I used Mathcad to figure out the formulas much like what you see in my link. I then implemented them in C so they could be made part of the firmware. You should try making a C library for Codesys if the PLC Open motion commands don't do what you want.



This is not an easy task.