Limiting Jerk in lookahead mode

I am experimenting with using lookahead mode to get sharper corners during high speed moves. The problem I am having is that the jerk becomes excessive.

 

Our existing application doesn't use lookahead and calculates the minimum TA and TS between each move to keep the acceleration and jerk limits within machine configuration settings. I thought I would be able to just turn lookahead on and then reduce the blend times to get sharper corners. This works to some degree, the corners are sharper and I can limit acceleration with Ixx17, but the Jerk goes through the roof. Even if I leave the TS value alone and just make TA = 2*TS, the Jerk goes up by a factor of 3. (Without lookahead, TA 95 and TS=41 and Jerk was 14000 in/sec³, with lookahead turned on, TA=82, TS=41 and the Jerk went up to over 40000).

 

Is there any way to limit the jerk when using lookahead? I noticed in the PowerPmac manual that Motor[x].InvJmax is used to set the maximum jerk for a motor and it says that the legacy I-Variable alias for this is Ixx18, but there is no mention of Ixx18 in the Turbo PMAC SRM. Does Ixx18 exist in the Turbo PMAC?

 

I appreciate any insight or advice.

 

Scott

I am not directly answering your question, but S-curve acceleration is "constant-jerk" acceleration. If you set TA=0 and hence control accel with pure TS, then you control jerk by controlling TS. Sound reasonable?

The issue of jerk control in lookahead is a thorny one. The algorithms for acceleration control in lookahead are by far the most complex we have ever done, and are very computationally intensive to execute. As we have evaluated jerk control lookahead algorithms, they look to be at least 5 times more complex and 5 times more computationally intensive. It also is not clear that they could be done in real time at all -- with acceleration control, as long as you are looking ahead your stopping distance, you will be fine, but there does not appear to be any hard and fast rule when you add jerk control to the mix.

 

(Note that the jerk control that Power PMAC does with the InvJmax term is not part of lookahead. It works only on the initial move calculation. For basic LINEAR moves, it can extend the TS time if the time you specified creates a jerk that exceeds this limit.)

 

What lookahead gives you that you like is the ability to separate out your corner size from your acceleration magnitude. You can set a small corner with a small TA time (the corner blending starts and ends F*Ta/2 distance from the programmed corner point) but control your rate of acceleration with Ixx17 in lookahead. This allows you to slow down before you start cornering, take the corner slowly within limits, and accelerate after you come out of the corner. (This is the way you take a sharp corner in your car.) Unfortunately, this is done without good jerk control, as you have noticed.

 

So what to do? The short answer is that the best strategy presently is to control acceleration with lookahead, then add a low-pass filter to the resulting trajectory with Ixx40 in Turbo PMAC, or the higher-order trajectory pre-filter in Power PMAC. Several Turbo PMAC users with similar concerns have achieved what they consider satisfactory results with this combination.

 

Some background: Turbo PMAC's Ixx40 filter and Power PMAC's trajectory pre-filter are, in signal-processing jargon, "causal" filters, because they do not have access to any future information. By contrast, PMAC's blending acceleration control (TA and TS) and buffered lookahead algorithms are "non-causal" filters, because they do have access to future information in the trajectory -- the simple blending looks one move ahead, and the buffered lookahead can look many moves ahead. (They are also technically mathematically non-linear filters, but that is not of concern here.)

 

In general, non-causal filters will have superior performance characteristics because they can "know" more. (Digital audio generally uses time-symmetric non-causal filters and just delays the output by the time required to complete these filters.) In the case of motion trajectories, the non-causal filters disturb the path much less than the causal filters.

 

Adding acceleration control to your trajectory does two important things. First, by limiting the magnitude of acceleration, you are respecting the physical limits (torque, force, current) of your system. But second, it is a low pass filter, reducing the high-frequency energy in the trajectory, so it will not stimulate the high-frequency dynamics of your machine. However, to do this with a causal filter requires a long time constant, and so a low-cutoff frequency, and gross path distortions.

 

Adding jerk control to your trajectory also does two things. By limiting the rate of change of your desired acceleration, it also limits the rate of change of your desired motor current, thereby respecting the inductance in your windings. But mainly, it is a low-pass filter that reduces the high-frequency energy in your trajectory. It turns out that if you have done the bulk of your low-pass filtering with a non-causal acceleration filter (TA and/or lookahead), you can add a causal filter on top of this with a short time constant (high cutoff frequency) to further roll off the high-frequency content of your trajectory with minimal distortion to the path. That is what I am recommended.

 

It just so happens that I have been experimenting this week with various combinations of non-causal acceleration filtering and causal filtering added to that. Lots of combinations, and lots of FFT plots. Qualitatively, I have confirmed the results I have just stated above. I hope to get more quantitative results soon.

I appreciate the comprehensive reply. I spent quite a bit of time yesterday trying various values of ixx40 from .01 to .99 and the only values that had any significant effect on the jerk were extremely high values (~0.99) but then the actual path was so far from programmed path, it was not useable.

 

A little more backgound of what I am trying to do may help.

 

Max Acc/Dec = 1.65g Max Jerk = 18,000 in/sec³

 

We have a linear move at a high feedrate (2000IPM) followed by a 0.125” diameter arc at a much lower feedrate (400 IPM) then another long linear move at 2000 IPM. We calculate the TA,TS to keep the above limits and we end up with TA=95, TS =41. The feedrate of the arc is actually slowed to 126IPM to keep the move time of the arc greater than TA. The result is shown in the following plot:

Because of the long blend times, we end up with a tapered slot instead of a slot with nice round ends.

 

To try and fix this, I turned lookahead on and then reduced the blend time between the linear moves and the arc to TA=10, TS=5. This appears to work on paper, because the actual path is very close to the desired path but when it is run on the actual machine, it is noticeable louder, you can feel the machine shake and the following error becomes excessive. The following plots show this motion. The first plot shows Velocity and Acceleration and the second plot shows the jerk. The acceleration is staying within our limits but the max jerk is over 100,000.

 

 

Is there anything I am missing? Using your car analogy, the driver is slowing down in advance of the corner, but he is mashing on the brake and accelerator, not smoothly applying them.

 

If I can’t get lookahead working for me, my next approach will be to split the linear move leading into the arc into 2 pieces with a short “slow down” zone before the arc and do the same thing with the linear move leading out of the arc.

A tangent line/arc blend may intuitively seem smooth, but traversing it certainly is not. You have a sudden change from zero centripetal acceleration (the line) to significant non-zero centripetal acceleration (the arc). Looking at the system in a continuous sense, this requires infinite jerk. For this reason, you never see direct line/arc transitions in modern highway and railway design.

 

In a sampled (digital) sense - per move section or segment - you get a very high jerk at this boundary. The PMAC has some tools for helping here, but you have a very fundamental problem if this is the path you want.

 

The TA/TS blending does soften the acceleration transition at the cost of flattening the path at the blend (the path must change to yield a lower jerk at a given speed). In many cases, this is adequate, but not in yours.

 

The lookahead does slow you down to the needed arc speed before the arc starts, but as you note, it does this without jerk-limiting S-curve along the linear path.

 

So, given all your desires and constraints, I think your proposed strategy of adding a short linear move on each side of the arc to permit you to transition between high linear speed and low arc speed with jerk-limiting S-curve acceleration is the best strategy. You will still need to optimize your TA & TS times in the blends between the slow short linear moves and the arc to limit jerk while keeping a reasonable path.

ScottB, not directly related to the topic, but can you share the thinking used to develop your maximum jerk specification?

Brian,

The jerk limit for this machine was given to me by the director of engineering many years ago and he has since retired. I suspect he arrived at this value empirically but I don't know what process he used.

A couple of further thoughts here. If we did have a jerk-limiting feature in our lookahead algorithm, working the same way for jerk as the present algorithm does for acceleration, it would slow the trajectory to a virtual stop in a direct line/arc blend (i.e. with small TA & TS times that do not flatten the blend), then accelerating back up to even the low speed of the arc, which is limited by the centripetal acceleration. I doubt this is what you want.

 

I do think that adding low-speed linear moves on both sides of the arc move will help a lot. But you will have to accept a trade-off between the jerk at the line/arc junctions and the fidelity of the resulting path to the perfect line and arc.