Feedforward control algorithm help

[Pandiani]

It seems that I still need more help on this....

Hello guys,

Some time ago I asked question about feedforward algorithm. Peter explained and attached the file to help me understand. After first reading I thought, "that's it, it is so simple". Now I need to deeply learn feedforward i.e I need to implement it. Peter was very kind and attached the file. In the first part, there is a small example of servo system. If I understood this correctly, the whole goal is to make Gc transfer function so that represents 1/Ga, where Ga is transfer function of plant. In such case there are no need for closed loop. I extended this example.

Ga = Ka/(s+a). Now we have: Gc =1/Ga=(s+a)/Ka = s/Ka+1/K. Now, in the structure I see that closed loop is still used, and these gains are applied in parallel with clasiccal PID. So I can conclude that this makes whole control loop more robust. Now, one can come to that structure.

If I understood good, first one needs to imagine that no closed loop is used which means that input to the controller is desired response (target generator). In that case Gc = CO/target =>

s*Target/Ka+Target/K = CO.

Now we returned to closed loop control and apply that gains in parallel no matter we assumed control loop will not be used in the first place.

Let's put some real values of parameters:

Transfer function of the plant is G=10/(s+2), so feedforward controller is:Target*s/10+Target/5 = CO????

I don't actaully see how this can work, I mean since we already have PID, will these controller fight each other?

I understand idea behind feedforward, I just don't understand why we assume one structure, calculate gains, then apply that gins on a different structure?

 

[kamenges]

I understood the basic usefulness of feed forward terms well before I really knew what they were called or how to develop them. I think this is a case where my lower level of education may help me a little bit. While I understand the need to mathematically model this problem and how that method makes the problem much easier to handle, when push comes to shove I still see feed forwards in purely physical terms. How do I transfer energy from my actuator to my physical plant?

One thing to keep in mind is that meaningful feed forwards cannot be generated unless the command is profiled. A step change in command will allow you to use a zero order feed forward (proportional only) but none of the higher order feed forwards. This is because, as you know, feed forwards are base solely on the command and its derivatives. The derivative of a step change in command is pretty aggressive.

So let's look at the motor example you listed. You have two feed forward terms shown. One is based on the command value. The second is based on the derivative of the command. As long as the command is at least ramped linearly the derivative term will produce a meaningful output value. Assuming the model is corrct these output values will exactly account for the energy transfer required to make the plant follow the command value. Again, keep in mind that feed forwards don't really work well with step commands. Since I don't do real well with LaPlace transfer functions yet I still calculate my feed forward gains the long way. However, by necessity, come up with the same values.

Assuming the open loop plant is stable, the command generator is not based on the plant state and the command generator doesn't produce a command change that the actuator can't produce, the feed forward terms will produce a stable system. That is one of the things that make feed forwards so attractive. They won't produce instability. However, feed forward values don't directly contribute to system stability. Unlike a PID controller a feed forward value can't help make an unstable system more stable.

I know this was a rambling post but I hope it provides some help.

Keith

 

[Peter Nachtwey]

This takes a new way of thinking

Let's put some real values of parameters:

Transfer function of the plant is G=10/(s+2), so feedforward controller is:Target*s/10+Target/5 = CO????

You are not interpreting the formula correctly.
1. You must reduce the system to a type 0 system. This includes velocity and temperature control systems. Pandiani has already done this but this is an important step.
2. Target is the target velocity. Kv is the gain, 1/5, that is multiplied by the target velocity to get the velocity feed forward term.
3. Target*s is the target acceleration. Ka is the gain, 1/10, is multiplied by the target acceleration to get the acceleration feed forward term.
4. The two terms are added to the PID control output.
5. The motion controller needs to generate motion profiles that have smooth velocities and accelerations.

I don't actaully see how this can work, I mean since we already have PID, will these controller fight each other?

No!!!!! The feed forwards don't fight because they are not dependent on feedback. It is the PID that adjusts.

New think, feed forwards are most important after the proportional gain.
First assume the system is linear and that the controller must output 10 volts for the motor to move 1m/s. I am hoping that you can compute the voltage required to go 0.5 m/s. If the model is exact there will be no error and the PID will output 0. This also means that no error is required to get the correct output.

In general, one relies on the feed forwards first. The PID is just there to correct for non-linearities and changes in the load. This means one doesn't have to be as aggressive on the PID tuning to get close to 0 error.

 

[Pandiani]

One thing to keep in mind is that meaningful feed forwards cannot be generated unless the command is profiled. A step change in command will allow you to use a zero order feed forward (proportional only) but none of the higher order feed forwards. This is because, as you know, feed forwards are base solely on the command and its derivatives. The derivative of a step change in command is pretty aggressive.

Keith, I agree. Derivation of sudden changes or sharp edges couse pulses with very high peaks. I learned that feedforward can be useful in cases when there is reference tracking problem especially when reference is a smooth continous curve.

In general, one relies on the feed forwards first. The PID is just there to correct for non-linearities and changes in the load. This means one doesn't have to be as aggressive on the PID tuning to get close to 0 error.

My main motivation for this question is that I find in one textbook more about feedforward that increase confusion. In that example, there is clasicall closed loop system. Plant has trasnfer function of Km/s(Tms+1) (position servo system). PI controller is used: Gpid=Kp(1+sTp)/s. Now the story goes something like this: while PI can provide good response and good disturbance rejection, there can be problems when reference tracking is desired. In that case one can use feedforward algorithm in the following way:
Thr(s)=( 1 + s^2(1+sTm)/(KmKp(1+sTp)) )Th(s)

In this example Gpid*Gplant is used together in closed loop tran. function, and yet derivation of reference is added after PID block, in front of the plant block.
Now I have one example where only plant transfer function is used, just PID added in parallel and other example in which equivalent transfer function is used (closed loop with PID) to obtain feedforward....

 

[Peter Nachtwey]

In that case one can use feedforward algorithm in the following way:
Thr(s)=( 1 + s^2(1+sTm)/(KmKp(1+sTp)) )Th(s)

Pandiani, I am not sure what all the variables above stand for.
Could you define them?
What is Thr, Th, Tm KmKp ( is this Km*Kp) and Tp?

 

[Pandiani]

Pandiani, I am not sure what all the variables above stand for.
Could you define them?
What is Thr, Th, Tm KmKp ( is this Km*Kp) and Tp?

I wasn't precise enough, I'm sorry. I hope attached file will clearify things a little.

The whole story is that equivalent transfer function of the closed loop system together with PI controller is calculated (little bit different form of PI), and then it is inversed (1/G(s)) in order to obtain feedforward gains. I don't believe this is the right way. In your example only plant's transfer function is inversed...

 

[Peter Nachtwey]

Your diagram isn't right.

Feed forwards are NOT inside the feed back path. They are called feed forwards because they by passed to the control output.

ftp://ftp.deltacompsys.com/public/NG/Mathcad%20-%20FeedForward%20and%20the%20RMC.pdf


You can see that if the PID was removed there would still be a parallel control output from the feed forwards. The goal is to pick feed forwards gains that will estimate the required control output exactly so there will be no error so no PID output is required.

 

[Pandiani]

We don't understand each other

Peter,

Attached .pdf file in my previous post represents closed loop system with PI controller. Problem is to design feedforward for such system. If I understand whole story , then I would implement feedforward system as shown on the picture below.

Is this correct?

Now my question is: what is mathematically correct way in design feedforward. In the textboox I found that for the closed loop system, equivalent transfer function is first calculated:
Geq=Gpid*Gplant/(1+Gpid*Gplant). Now that can be considered open loop system with Geq transfer function. Now, feedforward can be obtained Gff=1/Geq.

In your files I saw this approach: Gff=1/Gplant

 

[kamenges]

It looks to me like the diagram is correct. The feed forwards are added in parallel with the PI controller output.

It also looks to me like the feed forward gains, as you have them shown are correct.

I disagree with the last paragraph, though. You DO NOT want to base your feed forward on the CLTF. The feed forward values should only account for what is required by the plant to achieve the desired target profile. As Peter has said, in a perfect world feed forward would be all this is required to keep the plant tracking the target. You don't need the PI controller at all.

The feed forward values should not be based on the dynamics of the PI controller. As stated, ideally the PI output would be zero so it would have no effect on the feed forward values anyway. Always keep in mind that feed forward values are there to account for physical requirements of the plant. Since these requirements exist apart from the controller, whatever its form, the controller doesn't need to be considered in their development.

Keith

 

[Pandiani]

I finally got it!

I disagree with the last paragraph, though. You DO NOT want to base your feed forward on the CLTF. The feed forward values should only account for what is required by the plant to achieve the desired target profile. As Peter has said, in a perfect world feed forward would be all this is required to keep the plant tracking the target. You don't need the PI controller at all.

The feed forward values should not be based on the dynamics of the PI controller. As stated, ideally the PI output would be zero so it would have no effect on the feed forward values anyway. Always keep in mind that feed forward values are there to account for physical requirements of the plant. Since these requirements exist apart from the controller, whatever its form, the controller doesn't need to be considered in their development.
Keith

Keith, it is very same obstacle I hit when trying to understand this. It all comes to same result. In attached file you can see step by step approach.

 

[kamenges]

Now I understand why you were so confused. I just assumed that your book showwed the feed forward signal added BETWEEN the PI controller and the plant (in parallel with the controller, as you were saying). Your latest diagram shows the feed forward as an input to the PI controller. Now the equation you were showing makes some kind of sense.

I just don't understand why it would be done that way. They are basically modifying the feed forward signals to account for gains to account for what the PI controller is going to do to the feed forward signal on it's why through the controller to the output actuator. Why not just bypass the controller and not have to worry about how it affects the feed forward. With the method shown in your book the feed forward gains would need to be recalculated every time the PI gains are recalculated just to keep the same feed forward signal. That seems a little odd to me.

Keith

 

[Peter Nachtwey]

The command ff or Gff as Pandiani shows is another way of doing feed forwards. This method is more like exaggerating the motion profile so the actual path with follow the desired path. This is kind of like leading a donkey around by using a carrot on the stick. One would need to exxagerate the motion of the carrot to get the donkey to follow the desired path.

I am just taking a quick break. Nice work there Pandiani. Here is something for you to think about. If you tune the PID so the closed loop transfer function ( CLTF ) is critically damped, there will be three poles at -p. The command feed forward terms have gains 1 3/p 3/p^2 and 1/p^3 for a third order system. The coefficients follow a binomial pattern and the poles increase by one for each order of the system. This means Pandiani must generate a position, velocity, acceleration and jerk for his motion profile. A second order system would require a 'snap' term for the forth order feed forward gain.

 

[Pandiani]

In conclusion, for this particular example of position servo system, feedforward can be useful for reference input tracking only if input (desired trajectory) has second derivation. For example if input is step signal or even ramp feed forward is good solution.

 

[kamenges]

Originally posted by Pandiani:

In conclusion, for this particular example of position servo system, feedforward can be useful for reference input tracking only if input (desired trajectory) has second derivation.

While I agree that a complete solution would require that the tragectory generator be an order higher than the plant transfer fucntion, I also feel that something is better than nothing. Use what you have available. If all you have is the position and velocity commands and you can't do a reasonable differential to get acceleration, just use the veolcity command as a feed forward. Don't just give up on feed forward because you can't implement a complete solution.

Peter, when you are talking about the order of the profile generator, are you referring to Pandiani's 'serial' feedforward implementation, the parallel implementation or both? I would think the trajectory generator just needs to be one order higher than the plant transfer function so you don't have a step input to any of the gains. This would infer that a second order plant would require a third order trajectory generator.

Keith

 

[Peter Nachtwey]

While I agree that a complete solution would require that the tragectory generator be an order higher than the plant transfer fucntion, I also feel that something is better than nothing.

Yes

Use what you have available. If all you have is the position and velocity commands and you can't do a reasonable differential to get acceleration, just use the veolcity command as a feed forward.

A couple of weeks ago Norm derived a 7th order motion profile. This will do the trick. You must remember that it is easy to calculate derivatives just by differentiating the position polynomial as many time as is necessary. Obviously a 3rd order positioin polynomial will only give provide constant jerks that change in steps. This can be OK for some systems. For serverly under damped second order systems this will not do.

Peter, when you are talking about the order of the profile generator, are you referring to Pandiani's 'serial' feedforward implementation, the parallel implementation or both? I would think the trajectory generator just needs to be one order higher than the plant transfer function so you don't have a step input to any of the gains. This would infer that a second order plant would require a third order trajectory generator.

You must remember that the Command or serial feed forward is for the whole closed loop transfer function. A type 0 second order system will have 3 poles. One for the integrator and two for the system. The minimum order for the motion profile generater should be equal to the number of closed loop poles. However, this means the jerk will change in steps for a 3 order closed loop transfer function. Ideally it would be best of the jerk didn't change in steps so possibly a higher order motion profile is required for smooth jerks.

A lot depends on the nature of the second order system. An underdamped one will respond to step wise changes in the jerk much more readily than the one that is bare under damped, or over damped.