Spark Max PIDF D Filter Parameter

I was looking into the Spark Max Java documentation and saw the ability to set a D filter (http://www.revrobotics.com/content/sw/max/sw-docs/java/com/revrobotics/CANPIDController.html#setDFilter(double))
but have not found any information about what that actually means. Does anybody know what this parameter actually does/what the value of the parameter actually means?

D is the derivative term. It is used to eliminate oscillations induced from an aggressive P term.

Look up PID without a PHD and read it.

I am aware of what the D term in a PID controller is.
I was asking about the “D Filter” parameter (described very vaguely as the “Derivative filter constant”)

Oh. That. Here’s a description of what derivative filtering is. I’m assuming this is what they are shooting for, but the lack of documentation makes it tough.

2.1 Derivative Filtering for PID Control
Two problems with implementing the derivative term Kds (Kde˙) in a PID controller are as follows:

  1. The reference input thetad sometimes has sharp corners (e.g., when it is a square wave) and then
    Kde˙ = Kd(˙
    θd − ˙
    θ) will be large, since ˙
    θd is large, resulting in unreasonable size control inputs to the
    plant if you use a derivative term in the PID controller.
  2. There is noise produced by any real sensor such as the encoder or potentiometer that produces the
    measurement of the output shaft position θ. This noise is typically high frequency noise which implies
    that it has high values of derivatives of that noise. Hence, the sensor noise will result in Kde˙ = Kd(˙
    θd− ˙
    θ)
    being large, since ˙
    θ is large, so that the plant input can be too large if a derivative term is used in the
    PID controller.
    These two reasons often lead to complications in practical applications and hence in actual industrial control
    systems the “D term” (derivative term) is often “turned off” (i.e., Kd = 0). Other times, however, it is not
    turned off due to the benefits it can offer, especially its “predictive capability” (why is this term appropriate?)
    that typically allows you to overcome problems with overshoot in the closed-loop system. Why?
    So, if you turn on the derivative term, how do you solve the above two problems? The typical industrial
    solution to the first problem is to change the form of the derivative term. How? Note that in many
    applications θd is constant for long periods of time so often ˙
    θd = 0; hence it is reasonable to implement the
    derivative term as
    −Kd ˙
    θ
    and hence to avoid having the derivative of θd enter into the Vin control input, yet still make it possible to
    give the controller a predictive capability.
    The practical solution to the second problem above is to put a first order filter on the derivative term
    and tune its pole so that the chattering due to the noise does not occur since it attenuates high frequency
    noise (smooths it out) so that the derivative will not amplify the high frequency noise.

You can find that if you Google it.

I got this from REV a while back when I asked a similar question:

The filtering is a basic IIR filter that can be used to smoother the derivative response. The default is disabled. Here is the actual implementation (this is added to the implementation listed here):

float d = (error - pid->prev_err) * constants->kD; pid->prev_err = error; if (constants->kDFilter > 0 && constants->kDFilter <= 1) { d = (1.0f-constants->kDFilter)*pid->dState + constants->kDFilter*d; pid->dState = d; }

The high the D filter constant is the less noise comes in via encoders. We have experimented with it a bit. 0.3 seems to work best for us but we’ve done very limited testing.

We had used it to attempt to remove chatter when in smart motion mode. It was only minimally helpful.

Great, thanks!
Out of curiosity, do you know anything about the filtering they (may or may not) have on the velocity feedback from the integrated encoder? I noticed functions to change the averaging window and dt value (http://www.revrobotics.com/content/sw/max/sw-docs/java/com/revrobotics/CANEncoder.html#setAverageDepth(int)), but the docs say that they don’t apply in brushless mode.
My team has had remarkable success this year turning the SRX velocity averaging down on our flywheel, so I was hoping something similar could happen for spark maxes.

As far as I know REV api does not have that functionality.

Clarify, we have not played around with those functions so I cant say anything intelligent about it.