Online calculator for jerk-limited time-optimal trajectories

[cheeco]

Dear PLCtalk Forum,

I developed a generator for time-optimal trajectories with jerk limitation. You can access it online to calculate, display and download (XLSX or CSV) trajectories.


https://www.trajectorygenerator.com/ojet-online

The generation of jerk-limited trajectories is often used in automation and for the movement of large and precise machines (i.e. large telescopes), but also in robotics and CNC machines. Usually, a trajectory generator is placed in front of a control loop to generate a setpoint without discontinuities. Even though the topic of jerk-limited trajectories seems simple and there are hundreds of publications on the topic, most proposed solutions are either approximations (so the given motion constraints are either not exactly matched or not time-optimal), or only work for specific sets of parameters. What sets this trajectory generator apart is the possibility to provide a time-optimal solution for any given motion constraint. Another advantage is that arbitrary start and target motion states (hence position, velocity and acceleration) can be chosen.

I put in quite some work and effort to develop this trajectory generator. The problem is way more tricky than it initally looks, as there are many different cases to consider. Finding a stable mathematical solution is also not straightforward.

I hope you'll find the tool useful and I am really happy to listen to your feedback!


Greetings,

Stefan

[Peter Nachtwey]

Originally Posted by cheeco

I put in quite some work and effort to develop this trajectory generator. The problem is way more tricky than it initally looks, as there are many different cases to consider. Finding a stable mathematical solution is also not straightforward.

Wow! People have no idea what it takes to write a good third order target generator. The target generator is the most complicated part of a motion controller.

I have my own version that I will use to compare solutions when I get to work. I wrote a program to test different combinations of starting stoping and limits. I ran it for 200,000,000,000+ combinations to test mine. It took days. It is impossible to be thorough using human testing.

I do not have my test cases because I am home. I will test your target generator over the weekend. Most of the hard cases are short moves where no limit is reached.

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!

[cheeco]

Dear Peter,

thanks for this answer! I think everyone who has programmed such a trajectory generator is very quickly baffled by the complexity of the problem. The link you sent is an excellent example.

You are also right that the problem without any motion constraints (that is jerk limitation only) is hard to solve, both setting up a good set of equations, but also to stabilize the problem numerically.

I am looking forward to your test cases!

Cheeco

[jstolaruk]

You guys are nothing short of amazing.

[Peter Nachtwey]

This is my version. Notice how much they are the same.
I will do testing later.
I can save away the values for a motion profile in a file. I just counted. I found 35 bugs before I was done.



I posted my directory where I computed the formulas for the different cases. There were about 70 although I only showed about 50 on one screen.


There was one case where I wanted to move from one position, velocity and acceleration to another position velocity and acceleration. The setup looked relatively easy because there were 6 equations to solve for 6 unknowns. The solution took pages. On the sci.math.symbolic newsgroup I posted this problem. A professor from Fordham university saw the problem and simplified it some what. There was competition to see who could solve the problem most efficiently. Robert Lewis's Fermat program was best
https://home.bway.net/lewis/
but the solution still too long to solve in a motion controller during a loop time. Robert Lewis used my example problem in a presentation because the problem looked so deceptively simple but was in fact very difficult.


Now you guys have a clue what goes into the best motion controllers. You guys know I am writing a series of articles about doing motion control in PLCs and motion controllers. I know there is no way a PLC can compete unless the motion is extremely simple.


BTW, the target velocities and accelerations are used to multiply by the target velocity and acceleration feed forwards so the target generator is very important in predicting the control output.

[Peter Nachtwey]

I used one of my 35 test cases. The Ojet target generator gave me an out of bounds error.

[willxfmr]

When I have to tune a control loop, I usually poke the P and I buttons a couple three times and wait to see what happens. This seems a little more advanced than that.


Bubba.

[Peter Nachtwey]

Cheeco and I are talking about the target generator not the control loop. The target generator is the most complex part of the motion controller.

Originally Posted by willxfmr

When I have to tune a control loop, I usually poke the P and I buttons a couple three times and wait to see what happens. This seems a little more advanced than that.
Bubba.

Yes, and much much more but we take care of that and hide it from the user. We have auto tuning. Our auto tuning really works. It only takes about two minutes. A lot of companies say they have auto tuning. It is a marketing thing to check off the feature list but their auto tuning is crude.
It really should be called auto tuning though. It should be called computer assisted tuning.

[cheeco]

Dear Peter,

I can confirm that it is indeed a bug. From how it seems now, it should be (hopefully) easy to correct. But even in a corrected version, the trajectory generator might behave different than you might expect.

I introduced 2 flags which signal potential problems. Both are warnings related to leave the absolute motion boundaries.

• The "out of bounds"-error signals the user that the trajectory is already or will leave the motion boundaries (either position, speed or acceleration boundaries) with the given parameters. The simple case is when the start vector is already outside the motion boundaries. Another not so obvious case is when the start vector is still inside the motion boundaries, but will certainly leave them with the given jerk limitation no matter what the trajectory generator does. In this case, the trajectory generator has no choice but to violate one of the constraints. The "out of bounds" warns the user just about that fact.

• The "unreachable"-warning signals when a target vector cannot be reached. This is the case when all the trajectories would violate the motion constraints to get to the target vector. The trajectory generator also prevents you from potentially unintended use. Therefore, an unreachable error will also be raised when a target vector can be reached, but will cause that the following motion cannot be stopped within the boundaries. Before a command is excecuted, the trajectory generator checks first whether the or not the motion from the target vector onwards can be stopped within the boundaries.

To the bug you found: The "out of bounds" error is intentional, as your start vector (speed=12) is already outside the defined bounds (speed=10). In this case, a stop solution should be calculated that stops the motion with the given maxima for jerk and acceleration. This is not implemented correctly, as the speed and acceleration have still not decreased zero. I will have a look what went wrong here.

Regarding the complexity and the calculation speed. I found a way to elegantly formulate the mathematical problem for the general solution with jerk limitation only. This allows an extremely fast solution of the problem. The code is entirely written in C, and on an 8-year old notebook, the software can calculate 100000 complete general solutions every second. I tested it on a Beckhoff PLC with 1ms cycle time, the processor load increased by only 2-3%. I am sure that the code runs sufficiently fast on any modern PLC as long as it has a double-precision FPU.

[Peter Nachtwey]

Cheeco, I don't think you should call the limits parameters. In my example the the target speed is initially 12 and the user gives a command speed of 10. Giving a motion command with a lower speed should be acceptable. Also, you should add a means of incrementing and decrementing numbers with a mouse like my target generator. It makes it easier to do testing.

But even in a corrected version, the trajectory generator might behave different than you might expect.

This is where it gets interesting. Why should there be a difference? If there is a difference then who's solution is best?

As for the speed. It is the initial command that takes most of the time. After that everything is planned out pretty much. I try to defer as much of the calculations as possible because there is no point in calculating everything just to have the user issue a new command where all the previous calculations are useless.

When I get a hold of a competitor's motion controller I test the target generator. It is often hard to do because they usually don't have a nice interface like mine or yours.

I am home now. I will look for another bug on Monday.

[cheeco]

Dear Peter, sometimes the wording I use is a little sloppy. I am also new to web programming, so even the admittedly basic interface took me already ages - I do not plan an update anytime soon.

The question on how to behave outside the motion boundaries is indeed tricky. My philosophy was to set an error and stop the motion with the given jerk/acceleration boundaries. It is clean, it is simple and (hopefully) leads to defined, expected behavior. Other variants, like getting first inside the motion parameters and then continuing the motion would also be possible, but I decided against them.

Regarding the speed: As you know, there are basically 2 different problems. The first one is hard: Decide which trajectory type is the right and calculate the proper switching times. Once this problem is solved, the second problem can be tackled: The evaluation of the trajectory values for arbitrary timesteps. This problem is - compared to the first one - very simple, as it is calculating linear, quadratic and cubic functions over and over again.

The trajectory generator I developed can solve the first, hard problem - deciding which is the best trajectory for the given start and target values and the given motion boundaries, calculate the switching times and finally evaluating the trajectory - at a pace of ~100000/s on a standard PC, which allows for a real-time trajectory generation and evaluation.

One nice feature is to generate trajectories on-the-fly: Instead of calculating a whole trajectory, you can just calculate the next timestep. The calculated vector will be the start vector for the next iteration. Even though technically not absolutely necessary, this iterative approach leads to a very elegant programming style.

But I am also really interested how the problem of jerk-limited trajectories is currently solved in industry. Since I am not directly working in automation, it is really interesting for me how the problem is solved in practice!

[Peter Nachtwey]

Originally Posted by cheeco

Dear Peter, sometimes the wording I use is a little sloppy. I am also new to web programming, so even the admittedly basic interface took me already ages - I do not plan an update anytime soon.

I must admit. I don't do windows. Someone else wrote the interface for me but after a while I had to edit the program to make it do what I want.
The windows part is the main program. My target generator code is a DLL.

The question on how to behave outside the motion boundaries is indeed tricky. My philosophy was to set an error and stop the motion with the given jerk/acceleration boundaries.

Can't do that. A real motion controller must have positive and negative limits but the that is it. What you call limits should be thought of as command parameters that would be provided by the user. You must let the user change his mind at any time and provide new command parameters.

It is clean, it is simple and (hopefully) leads to defined, expected behavior. Other variants, like getting first inside the motion parameters and then continuing the motion would also be possible, but I decided against them.

I don't know what is meant by "getting first inside the motion parameters"

Regarding the speed: As you know, there are basically 2 different problems.

Only 2?

The first one is hard: Decide which trajectory type is the right

I call that a profile. You can see in the directory I posted I have names such as seg1234567
Where
seg 0 is stopped
seg 1 is accelerating with jerk >0
seg 2 is accelerating with jerk =0
seg 3 is accelerating with jerk < 0
seg 4 is constant velocity
seg 5 is decelerating with jerk < 0
seg 6 is decelerating with jerk = 0
seg 7 is decelerating with jerk > 0
I included this info for the rest of the forum.
Cheeco needs to add this cases below.
seg 8 is a special case where current trajectory is higher than the command. That is the case you see in my last picture.
seg 9 is similar to seg 8 except the current trajectory is much more negative than the current command.

and calculate the proper switching times.
Once this problem is solved, the second problem can be tackled: The evaluation of the trajectory values for arbitrary timesteps. This problem is - compared to the first one - very simple, as it is calculating linear, quadratic and cubic functions over and over again.

There are a lot of things that must be solved all at once.

The trajectory generator I developed can solve the first, hard problem - deciding which is the best trajectory for the given start and target values and the given motion boundaries, calculate the switching times and finally evaluating the trajectory - at a pace of ~100000/s on a standard PC, which allows for a real-time trajectory generation and evaluation.

This is how I did my testing but a standard PC is a power hog and requires massive amounts of cooling. The code must run efficiently on something less like a ARM processor.

One nice feature is to generate trajectories on-the-fly: Instead of calculating a whole trajectory, you can just calculate the next timestep.

This is what we do. We have since that 1980s. The user must be able to change his mind. More likely it will be a master computer that computes new positions to go to while still moving.

The calculated vector will be the start vector for the next iteration. Even though technically not absolutely necessary, this iterative approach leads to a very elegant programming style.

It is necessary for a real motion control product. It is important to do the minimum necessary each iteration for two reasons. You can't spend too much time when the command is given and you don't want to compute a whole motion profile in the first iteration when the user or master computer will change its the command parameters.

But I am also really interested how the problem of jerk-limited trajectories is currently solved in industry. Since I am not directly working in automation, it is really interesting for me how the problem is solved in practice!

I sell motion controllers.
[/quote]
I have shown and told you a lot. you are on the right track. Now you must decide how far you want to go.

I may make a video about this. It is interesting to see how the motion profiles changes as command parameters change.

[cheeco]

Its true that the segments 8 and 9 are not implemented in a way you implemented them.

I had also a look at your GUI and found it really appealing. It is interesting how many common elements our solutions share, despite different development paths!

When taking a closer look at your posts, I realized that I missed a lot of information you wrote on the first time (maybe because I was busy looking for the bug).

You mentioned that you are writing articles about motion controller. Are these articles available online or in a journal? I would be very interested to read some expert views on the topic!

What I also realized from your posts is that a motion controller and a PLC are actually two different devices (ok, now that I read it again it's kind of obvious). But what I do still not quite understand how your setup looks like. I understood that the motion controller runs the target generator (hence the*.dll). Are the calculated trajectory points then passed to the PLC which executes the actual control loop? Where and how does the Windows software come into play?

It is also clear that the performance results I obtained will look very differently on an embedded device. When you talk about an ARM class processor, are you referring to the computational power of a common PLC or a common Motion Controller? I am currently planning to port my code to a STM32 to see where I get in terms of performance.

I am still very interested in your test cases. Today, I found the root cause for the bug you discovered, but I will need some days to implement a fix and thoroughly test the new version.

Thanks for the support!

[Peter Nachtwey]

Originally Posted by cheeco

It is interesting how many common elements our solutions share, despite different development paths!

I think it is only logical.

You mentioned that you are writing articles about motion controller. Are these articles available online or in a journal? I would be very interested to read some expert views on the topic!

Mostly about hydraulic motion control. There are some significant differences between electric servo and hydraulic servo control.
Mostly I write about the closed loop algorithms.

What I also realized from your posts is that a motion controller and a PLC are actually two different devices (ok, now that I read it again it's kind of obvious).

Yes, we see the differences because we know what it takes to generate the target position, velocity and acceleration. We get asked all the time why should they buy a motion controller? "Can't I do it in a PLC?"

But what I do still not quite understand how your setup looks like. I understood that the motion controller runs the target generator (hence the*.dll). Are the calculated trajectory points then passed to the PLC which executes the actual control loop? Where and how does the Windows software come into play?

The motion controller runs on a real time operating system from a company called Green Hills.
https://www.ghs.com/
The code is in a flash memory but gets copied to ram for faster execution. The fastest PLCs do the same.

It is also clear that the performance results I obtained will look very differently on an embedded device. When you talk about an ARM class processor, are you referring to the computational power of a common PLC or a common Motion Controller? I am currently planning to port my code to a STM32 to see where I get in terms of performance.

The difference between PLCs and motion controllers is blurred. The main difference software and what is given priority. Our controllers and have been used as PLCs or as the only controlling device in the machine. However, a motion controller must largely stick to motion control. PLCs do not need to be deterministic and must support a wider range of I/O devices and much larger amount of I/O.

I am still very interested in your test cases. Today, I found the root cause for the bug you discovered, but I will need some days to implement a fix and thoroughly test the new version.

Thanks for the support!

You will see more next week when I am back at the office.

I sent you a private message with more information.

[cheeco]

Dear Peter,

I uploaded a bugfixed version of the trajectory generator. The first part of the trajectory looks now identical to your test case. As stated previously, in my implementation, a violation of the boundary conditions (or parameters) leads to a motion stop.

OJET-online Testcase