derivative filter

[Stapelzeiger]

It would be useful to be able to filter the derivative term of the PID. I suggest a simple moving average, since it can be implemented very efficiently.

[antoinealb]

What is it used for ? What kind of parameters do we add to it ?

[antoinealb]

Oh and also it is easier to implement an IIR filter than a sliding window average because you don't need to store every samples, you just do : value = tau * input + (1 - tau) * value;

[Stapelzeiger]

What is it used for ?

Noise in the measurement can create high spikes when you derive them.

What kind of parameters do we add to it ?

A time constant or cutoff frequency.

For the IIR vs FIR sliding average, I'm not sure what the implications of using one or the other are. The sliding average has a linear phase which is apparently a good thing, but don't (yet) know enough about the subject to choose one over the other.

[pierluca]

Here I can be of assistance, filtering is basically my field.

IIR are easier to implement but the phase response is not linear and the filter has to be carefully designed in order to be stable. They can be quite sharp in terms of frequency response but the response itself might be "bumpy" (unless you're designing a Butterworth filter). What Antoine mentioned is partially wrong though. Except for first-order IIR filters, you still do need some memory, but much less than for a FIR filter.

A moving average is essentially a FIR, it is inherently stable and linear phase but it does require both more memory and more computation.

However, do realize that if you integrate a filter on the derivative term of the PID, you're de facto changing the transfer function of the PID. In your experience, is it really needed to smooth the D term? From my shaky, theoretical understanding of PIDs, I don't see why it should be needed.

[antoinealb]

Discrete PIDs may benefit from low-pass, first order filters, since numerical derivation tends to be a high pass filter (which is not present in a theoretical PID). And I agree that my example was only valid for first order filters.

[Stapelzeiger]

Using a low-pass on the derivative term is quite common, I think. One of the problems is, that the output saturates quickly if there is (quantization or other) noise on the input of the derivative.

[Stapelzeiger]

A moving average is essentially a FIR, it is inherently stable and linear phase but it does require both more memory and more computation.

More memory, yes, but not more computation. You can keep an accumulator so you don't have to iterate over the buffered input values.

[pierluca]

You can keep an accumulator so you don't have to iterate over the buffered input values.

Well, I was assuming it was a weighted moving average (or generic FIR filter), in which case you can't because the parameters are different for different points in time.

If you use an accumulator, it might actually be cheaper than a 2+ order filter.

[froj]

@Stapelzeiger shouldn't quantization noise best be filtered out before it enters the PID? Then you'd still have the edge when you change the set-point.

[pierluca]

OT: guys, please, either use "consigne" or the proper, English term .. which is setpoint :-)

[antoinealb]

Oh, assumed consign = consigne. Patching my mental vocabulary now.

[Stapelzeiger]

@froj: implementations that I've seen so far filter the error term input of the derivative term, but not the proportional & integral terms. I'm not sure if the low pass on the setpoint for the derivative term is a problem for the filter. It might even be a good thing: if you make a step on the input, the derivative will be a high pulse of one sample-period duration. This pulse will immediately be truncated because the output saturates. But if you have a low-pass filter, the response of the derivative+low-pass will be longer and less high which means that the effect after truncation is bigger.

[Stapelzeiger]

BTW since in last year's codebase the pid was not the only place we needed a low-pass filter, it might be a good idea to place it in a filter module. This module could also contain filters for saturation, overflow to a defined interval & something like the quadramp of last year's codebase.

[antoinealb]

+1 for filter module.

[pierluca]

OT: ok, I finally got the full reasoning behind the first order filter. Not just sampling noise, but also jitter and saturation, the combined effect of which can be disastrous. Thanks for the brainwave ! You're officially more useful than 2 semesters of control theory (with Longchamps) :-D

[antoinealb]

Longchamp is not really useful indeed (working on exam right now).

We should probably try to stick with a filter that doesn't change phase (or not too much), to avoid killing the phase margin of our system.