I am surprised to hear about a PD controller though. In my testing, a PI controller seemed to behave much better than a PD controller. In my research, it seemed a common strategy to drop the D-component completely but I did not see the suggestion to drop the I-component.
In terms of the theoretical guarantees, a PD controller is (nearly) always stable and pretty easy to critically damp. However, if the set point is moving with a nonzero velocity or there is some load, then the PD controller will not converge. A PI and a PID controller can converge even if the target is moving.
Practically speaking, I would recommend encoding as much model information as possible before pulling out the I term: for instance, if you know the velocity of your tracked object and assume an intertidal model, you can just include some of that data in your feed forward rather than the controller, which simplifies things greatly.
You can use your intuition in the sense that if what you measure just has a constant error without an integrator in the loop that error will never be closed. Think about a motion control system with a proportional gain where you are pushing the actuator with your hand away from the current position. The proportional gain will apply a force against your push but generally that will leave some residual error in steady state. This is where the integrator comes in. And I agree with the parent that I've mostly seen the D term dropped from controllers, definitely with motion control, though sometimes there are other weird components or multiple loops which may end up having a similar effect.
One thing that I think is often confused the matter is that P, I, and D all relate to what you measure and what you're controlling. E.g. you might measure velocity or position in a motion control system, and generally your output is going to be current. In a temperature control system your measurement would be temperature and your output is likely going to be current (which influences acceleration, not position or velocity). Ofcourse velocity being the derivative of position means that the meaning of "P" is different. I haven't done PID in a long while but I've always used to ground myself in motion control systems to get a sense what I want to put the loop over.
EDIT: E.g. IIRC it's common in motion control to have a PI loop over the position error and an additional proportional controller over the velocity (and then filters, feed-forward and a bunch of other components ;) ).
> Practically speaking, I would recommend encoding as much model information as possible before pulling out the I term
I was referring to that part. Ie: if I know more abouty system, how do I include that in my control loop.
E.g. if I want to control the temperature of a room, I might have an idea how much energy is lost due to the gradient between inside and outside temperatures.
I would assume that a PID controller is still suitable for that, but I have never seen novice level resources on that.
I think the parent is saying something along the lines of "if you can look at your problem and determine there's no need for an integrator, or you can take the need out using feed forward, then you can remove the integrator" (or set your integral gain to zero). Keep in mind though the integral gain isn't simply acting to take out constant error, it changes the transfer function of the loop.
If you have a mathematical model for the thing you're controlling you can derive the PID parameters using that model. That's very rarely the case though and even with a model reality almost always differs.
The PID controller doesn't "care" about your knowledge. What it does "care" about is how the system responds to the control signal, specifically with linear systems the gain and phase for the different frequencies. If you're tuning a PID using some heuristics then the process of tuning includes the response of the system you're controlling. So at least intuitively I don't see an easy way to take some partial knowledge of the system and incorporate it into the tuning process. Maybe someone with experience can say something like "using less proportional gain and more integral gain results in better <something> for temperature control systems where there's a lot of energy loss due to gradient" but otherwise there's no easy way to tell IMO. If the integrator doesn't help you're probably going to discover that in the process of tuning anyways.
I think this knowledge is more useful in the context of a feed forward, i.e. if you have a good model of how your system behaves and you incorporate it into the feed forward part of your control loop then the residual error is going to be much smaller and you'll get better performance.
I used a PD controller for a specific application where we were trying to maintain a specific temperature in the future, and cared more about the trajectory of the temperature over time to reach the goal. We didn’t much care for the integration of that temperature since that wasn’t important in this particular case. An integration factor would actually wind up the rate of temperature change too much!
Integral windup is the term for this issue, there's a few ways to deal with the windup if you need to keep the integral component (e.g. for tracking a moving set point, or to overcome a stable error).
https://en.wikipedia.org/wiki/Integral_windup
I am surprised to hear about a PD controller though. In my testing, a PI controller seemed to behave much better than a PD controller. In my research, it seemed a common strategy to drop the D-component completely but I did not see the suggestion to drop the I-component.