Help with PID for motorised fader - Page 1
Forum section: electronics / beginners

author: tobeyg
author_rank: Newbie
timestamp: June 19, 2024, 02:43:03 pm
content: I've been fiddling a bit with this Adafruit DC motorised fader (https://www.adafruit.com/product/5466) paired with a L9110S H-bridge module as the motor driver. I provide 9V to the fader motor, although it also works at 5V.I can get it to run in both directions and I can set the destination using a regular potentiometer. The problems I experience are that it’s quite harsh in its movement since I’m running it at full speed at all times. So it’s quite noisy, jumpy and sometimes either gives off a high pitch sound or a crackling sound when setting the target value with the other potentiometer slowly.I’m looking for best practices when driving the fader motor as smoothly (motion wise) and as quite (sound wise) as possible.My research around this problem led me to the concept of PID. I've looked at this tutorial:...for using PID and just adapted it for the L9110S, since the H-bridge being used in the video has a different setup with one pin for direction and one for speed, while the L9110 has one speed pin per direction. I'm also using a potentiometer for setting the target, replacing the encoder in the video.But the code is not working 100% for me. The motor is overall moving with a kind of eased movement, which is good. But there are other problems:It never reaches the target value exactly. It's usually a few 100 points below the target value.Because of this and potentially other things, the motor is constantly running, since I only tell it to stop when it's exactly the target value. This causes it to constantly output sound from the motor. I would assume that the sound wouldn't be as "in your face" if it was only appearing when the fader was moving, but now it is there even in its (somewhat) idle state.It oscillates quite a bit (I think I'm using the word correctly), i. e. the fader is contantly moving short distances back and forth very fast.Here is my code based on the tutorial mentioned above:https://pastebin.com/HNniWmWhWould appreciate any insight into this, what I'm missing etc. The main goal would be to get the fader to movement exactly to the correct target value, while being as smooth and silent as possible.

author: IanB
author_rank: Super Contributor
timestamp: June 19, 2024, 03:04:21 pm
content: PID controllers have tuning parameters (proportional, integral, derivative) that need to be adjusted in each case.It's always advisable to set derivative to zero unless proven to be needed.Then, for servo control, I would suggest reducing proportional action and increasing integral action.Higher proportional action will give a faster and more aggressive response.Higher integral action will help to get to the set point (target position) more quickly.But too much integral action will lead to instability.Tuning controllers is an art. You need to adjust, test, adjust, test, and repeat until the response is satisfactory.

author: tobeyg
author_rank: Newbie
timestamp: June 19, 2024, 03:25:29 pm
content: Thanks for the input! Will try to fine tune it a bit with more purpose than just setting it to random values as I've done so far.Do you think the parameters are causing the motor to never reach the final value as well?

author: IanB
author_rank: Super Contributor
timestamp: June 19, 2024, 03:29:21 pm
content: Integral action is what enables it to reach the final position. With no integral action there will always be an offset.In a "follower" application, I would aim for low proportional action and high integral action. Then if it is too slow, try increasing the proportional action a bit.(Edit: I have changed my advise about this. See my later post below.)

author: tobeyg
author_rank: Newbie
timestamp: June 19, 2024, 03:34:35 pm
content: Nice, I'll try that!The target value of the other potentiometer is a bit unstable in itself. If the value really should be 70 for example, it varies between 70 and 71 and similar. I would imagine that it would be recommended to not chase the exact value but rather have some kind of margin for it, so that +-5 points above or below the target value would be accepted as a valid destination for the fader.Or is it a better idea to use a low-pass filter on the target potentiometer as well as the wiper of the fader? Or how do you usually work around the issue with the target value fluctuating?For reference, the fader is thought to be used with a DAW, so the software would send values of the current volume that the fader should follow. But moving the fader physically with your finger should also set the value in the DAW. So it's kind of a bi-directional thing.

author: pcprogrammer
author_rank: Super Contributor
timestamp: June 19, 2024, 03:55:40 pm
content: Quote from: tobeyg on June 19, 2024, 03:34:35 pmA bandwidth of a couple of bits is normal practice. Another option is to filter the potentiometer reading with averaging or another form of a low pass filter.This applies to both the fader and the target set potentiometer.Quote from: tobeyg on June 19, 2024, 03:34:35 pmFor this it is important that the motor is turned of when the user moves the fader. Constantly read the fader and when the value changes when the motor is off, or not changing in the way you would expect, keep or turn the motor off. Then when the reading is stable for a couple of ms, send the new value to the DAW system.If you are up to speed with C on embedded you could look at thereceiver partof what I made for fischertechnik. It can control two motors with potentiometer feedback and works well with small servos without PID control. It emulates how older analog RC servos do it. More or less just only the proportional part of a PID.Edit: For keeping the code of the OP with the thread added here:Code:#include <CapacitiveSensor.h>#define touchSendPin 14#define touchReceivePin 15//Arduino Pin Assignmentsconst int motorDown = 18; //H-Bridge control to make the motor go downconst int motorUp = 19; //H-Bridge control to make the motor go up//Inputsconst int wiper = 17; //Position of fader relative to GNDconst int pot = 16; //Potentiometer to set position of faderdouble faderMax = 0; //Value read by fader's maximum position (0-1023)double faderMin = 0; //Value read by fader's minimum position (0-1023)CapacitiveSensor touchSensor(touchSendPin, touchReceivePin);volatile bool touched = false; //Is the fader currently being touched?long previousTime = 0;float ePrevious = 0;float eIntegral = 0;int position = analogRead(wiper);void setup() {Serial.begin(9600);pinMode (motorUp, OUTPUT);pinMode (motorDown, OUTPUT);}void loop(){checkTouch();// Setpointint target = analogRead(pot);position = analogRead(wiper);float kp = 2.0;float kd = 0.1;float ki = 0.01;float u = pidController(target, kp, kd, ki);if (!touched) {moveMotor(u);}Serial.print(target);Serial.print(", ");Serial.println(position);}float pidController(int target, float kp, float kd, float ki) {long currentTime = micros();float deltaT = ((float)(currentTime - previousTime)) / 1.0e6;int e = position - target;float eDerivative = (e - ePrevious) / deltaT;eIntegral = eIntegral + e * deltaT;float u = (kp * e) + (kd * eDerivative) + (ki * eIntegral);previousTime = currentTime;ePrevious = e;return u;}void moveMotor(float u) {float speed = fabs(u);if (speed > 255) {speed = 255;}if (u < 0) {analogWrite(motorUp, LOW);analogWrite(motorDown, speed);} else if (u > 0) {analogWrite(motorDown, LOW);analogWrite(motorUp, speed);} else {analogWrite(motorUp, LOW);analogWrite(motorDown, LOW);}}void checkTouch() {touched = touchSensor.capacitiveSensor(30) > 3000;}

author: IanB
author_rank: Super Contributor
timestamp: June 19, 2024, 04:15:47 pm
content: Quote from: IanB on June 19, 2024, 03:29:21 pmOn reflection, I think I am wrong about the above. More likely you will need moderately high proportional action and just enough integral action to remove the offset.

author: tobeyg
author_rank: Newbie
timestamp: June 19, 2024, 05:13:34 pm
content: Quote from: pcprogrammer on June 19, 2024, 03:55:40 pmSorry, how do mean with the bandwidth? As in how often the value is being read?I think at the moment, after setting the parameters of the PID function more carefully, that my main issue is that the readings from the target pot and the fader pot is unstable and that is what's causing the oscillations. I have one 1uF electrolytic capacitor going from the inputs of the Teensy (that I'm using as the MCU currently) to ground. But that doesn't help a lot. What would be the most effective way for stabilising the values as much as possible? I haven't seen this amount of fluctuation before, I wonder if it's the motor that is bringing noise somehow to the readings?Quote from: pcprogrammer on June 19, 2024, 03:55:40 pmYes, the fader has a pin detecting capacitive touch, so whenever I touch it the motor stops. But as you say, there will be additional logic to how the values are being sent, but I'll dig into that as soon as the behavior of the motor is fixed.

author: pcprogrammer
author_rank: Super Contributor
timestamp: June 19, 2024, 06:02:01 pm
content: Quote from: tobeyg on June 19, 2024, 05:13:34 pmWith that I don't mean bandwidth as in frequency related, but like what you wrote a range of plus or minus 5, and only react when the difference between the previous reading and the new reading is bigger then that bandwidth or gap if you like. A better term probably is a dead zone or dead band.Quote from: tobeyg on June 19, 2024, 05:13:34 pmThat is a handy feature. Makes detecting a bit easier. Does that work well with a big plastic knob on the fader?

author: tobeyg
author_rank: Newbie
timestamp: June 19, 2024, 09:06:52 pm
content: Quote from: IanB on June 19, 2024, 04:15:47 pmYeah, it felt like high proportional and smaller integral was working better. Still quite unstable though and I'm a bit unsure if it's the PID function or if its the fact that both readings of the target pot and the fader pot are fluctuating too much for the motor to settle properly. Do you know if there are any other aspects to take into account? I'm thinking like the frequency of the analog write (that can be set withanalogWriteFrequency()) or anything else?Quote from: pcprogrammer on June 19, 2024, 06:02:01 pmI see! Will try it and see.Quote from: pcprogrammer on June 19, 2024, 06:02:01 pmYeah, there are caps that are made from conductive materials. Either metal or plastic caps with some kind of metal foil within them (I think).

author: IanB
author_rank: Super Contributor
timestamp: June 19, 2024, 09:51:46 pm
content: Quote from: tobeyg on June 19, 2024, 09:06:52 pmThe only thing I could suggest is that in the real world, PID controllers often have some kind of filtering on the measured value (a simple first order filter is enough). Noisy or jittery signals can be a problem with PID controllers as input noise tends to get amplified by the gain of the controller.

author: AussieBruce
author_rank: Regular Contributor
timestamp: June 20, 2024, 01:37:13 am
content: Pid not getting to the target can be caused by insufficient numeric precision, particularly if the scan rate of the algorithm is high. The problem is that the P term will never get you right there, and the I term will stall if the increment during the time delta is less than the minimum calculation increment. If you're using floating point this should never be a problem, but if it's integer with less than 32 bits this could well be a contributor. Also try running the algorithm slower, although too slow can also cause problems.

author: tobeyg
author_rank: Newbie
timestamp: June 21, 2024, 06:05:17 am
content: Quote from: AussieBruce on June 20, 2024, 01:37:13 amHmmm, yeah. One observation right now is that the edges (max and min position) if the fader is not possible to reach. It’s closest to the target value the closer the position gets to the center. So if I set the target to 1023, I get like 980 or similar with the fader. At 512 the fader is very close, basically around +-5. And at 0 it’s like 8.

author: pcprogrammer
author_rank: Super Contributor
timestamp: June 21, 2024, 06:15:55 am
content: Quote from: tobeyg on June 21, 2024, 06:05:17 amA very simple way to filter a bit of noise is to just drop the lowest bits of your analog to digital conversion. Going back to 8 bits won't be that noticeable on your fader position.

author: mikerj
author_rank: Super Contributor
timestamp: June 21, 2024, 12:21:04 pm
content: Static friction (aka stick slip) can also cause stability problems with PID loops. The motor will require some minimum output to create sufficient torque to start turning the pot, but once the pot starts moving the friction drops and so does that minimum drive level, so overshoots can occur. There have been a bunch of papers written on this, and possible solutions, but the most common for industiral control e.g. motorised valves, is to add a relatively high frequency (compared to loop bandwidth) dither to the drive signal, which may not be desirable for your application. YYou could also look at a discontinuous output control e.g. don't allow the motor drive level go lower than some minimum value until the error is small enough, which will prevent the motor stopping prematurely and then the integrator winding up until and starting it again, potentially causing overshoot. It can be complex to get this work reliably over life though, as friction often changes e.g. grease drying out, or physical wear in bearings etc.

author: AussieBruce
author_rank: Regular Contributor
timestamp: June 22, 2024, 06:51:23 am
content: OK. Well if your PID calc is done in integer, from 0 to 1023, then lack of precision could well be part of your problem. Also, the I term needs to move outside the active output range, either way at times. Setting appropriate values for ranging and limits with PID is essential, and it turns what looks like a simple algorithm into a bit of a brain teaser. There are many traps for the beginner.A typical setup in integer arithmetic (floating point preferred) would be to have the PID calc going from -7FFFFFFF to 7FFFFFFFH (32 bit signed), with the input scaled to maybe a half of that. So you have a significant overrange band at each end. Then scale the calculated output back to your D/A range, or wherever else your real world output goes.Floating point makes scaling easier, but there are other potential gotchas, for example 'integral windup'. Google that for info.

author: tobeyg
author_rank: Newbie
timestamp: June 27, 2024, 08:09:40 pm
content: Thank you all for the advice! Some of it is unfortunately a bit too complex for my experience so far, but I appreciate it a lot and will try to digest and implement.One update is that I switched the L9110 for the DRV8871 as the motor driver. I was experiencing the motor just refusing to work when increasing the PWM frequency. There is no specification for frequency limits in the limited amount of data sheets that I could find for the L9110. Although it's mentioned in other sources that it works with PWM, there is no mention of PWM in the data sheets. It seems to be quite an obscure component overall.But with the DRV8871 I can run a way higher PWM frequency (over hearing range) and that gets rid of a lot of the noise I was experiencing before, so that's a plus! It also seems to run a bit smoother in general, but I still have trouble stabilizing the reading of the fader. Before I was setting the target with another pot, but I'm now setting random values in code between 0-1023 at an interval in order to at least have a constant target value. But the fader value is still fluctuating. It's hard to determine if it's caused by the PID or if it's the reading that is unstable in itself and that causes the PID to be unstable.Also, this is the calculation for the Current Regulation of DRV8871, found at 7.3.3 in the data sheet (https://www.ti.com/lit/ds/symlink/drv8871.pdf):Am I understanding it correctly that even if I supply 9V, that the calculation should be done using 64 kV? So if I want to restrict the current to 0.8 A, I would need to have resistance at 80 kΩ? Or should theVILIM be based on the voltage I supply?

author: pcprogrammer
author_rank: Super Contributor
timestamp: June 28, 2024, 06:11:15 am
content: On page 5 of the datasheet it states "Constant for calculating current regulation", so yes you should use this value and not the supply voltage.

author: tobeyg
author_rank: Newbie
timestamp: July 01, 2024, 07:54:11 am
content: Quote from: pcprogrammer on June 28, 2024, 06:11:15 amThank you!I saw a mention either here or somewhere else to try and use twisted pair wiring in order to reduce the noise. Would that be mainly for +9V and GND for the motor or should I try it on other connections as well?

author: pcprogrammer
author_rank: Super Contributor
timestamp: July 01, 2024, 11:52:33 am
content: Wiring can always be a source of noise and care has to be taken to reduce it. For the potentiometer wires a shielded cable could be used for the signal, and twisting the motor wires can help in reducing the emission. Also best to keep them as short as possible.

author: MrAl
author_rank: Super Contributor
timestamp: July 01, 2024, 12:19:11 pm
content: Hello,The integral gain helps to get the set point more accurate.In other words, if you were to set the position with an adjustment that should correspond to 45 degrees, with a low integral gain it may go to 41 degrees and with a higher integral gain it may go to 44 degrees. That's what the integral gain actually does. It's referred to in control theory as the steady state error. Many feedback systems have high integral gain and nothing else. In fact, it could be very high.What this does not mean though is that it will change from 41 degrees to 42 degrees all of a sudden, that's not what the integral gain would cause unless it changed itself.What the derivative gain does is it acts like a predictor of what the position will be in the future. This could help if the position overshoots because if it overshoots then it has to back up, and then it undershoots and then has to go forward again, then backup, then forward, etc., which would mean it would oscillate between two positions constantly. If the system could 'predict' where the final position will be then it can apply less power as the position becomes closer and closer to the predicted value.There are a lot of things involved in a system like this, like rotational velocity, rotational inertia, etc. That stuff can be hard to deal with that's probably why a lot of people use some known technique to adjust the parameters. There are methodical procedures for adjusting the gains but you should probably look that up on the web.There is a boatload of theory on this but it depends on knowing everything about the system like the properties of the motor(s), friction, mass of the load(s), etc. That means it just helps to understand how these things work but not as much as to how to adjust the gains.

author: tobeyg
author_rank: Newbie
timestamp: July 02, 2024, 08:52:37 pm
content: This is the code I'm running currently:https://pastebin.com/EzhSXZK3You can see a video of it in action here:https://streamable.com/z5l99aCurrent PID values are:Code:float kp = 6;float ki = 2;float kd = 0.08;I have twisted the cables going from the H-bridge to the motor, as well as the +3.3V and wiper wire going to the potentiometer pins. I'm getting a fairly stable reading, at least better than before. But I'm still experiencing some jitter and audible noise from the motor (as you can hear in the clip above). Would also like to have a smoother movement, it's quite rapid now and eases very slowly from overshoot to the target value. I would like it to ease smoothly from the old value to the target value, so there is a smooth easing in the start and end of the travel, rather than a rapid start and then very slowly getting adjusting for the target as it does now.What can I expect from the PID when it's optimized? Is it expected to have it stay fixed at the target value without any jitter or do I need to stop the motor manually when it's close enough?

author: MrAl
author_rank: Super Contributor
timestamp: July 03, 2024, 07:22:41 am
content: Quote from: tobeyg on July 02, 2024, 08:52:37 pmHi,As I was saying, there is a lot of theory on this but you need to know a lot about the physics of the system components and that is not always available without testing yourself.The optimization depends a lot on what the components are capable of, and what kind of voltage and power is available.For example, many buck circuits have a finite time that they can respond to a change in load current, but if you had a very high voltage input available you could reduce that to almost nothing. In theory if you had an infinite voltage available you could get the delay down to zero, but nobody has such a thing. That means the response will always depend on what input voltage is available.This is also the case with stepper motors. The speed depends a lot on what voltage is available, but then the motor itself has a limit anyway so you can't use an infinite voltage even if you had that. There is also a limit to the current so you can only get so much force out of one. There's no way to design that kind of thing to be any better once you reach the limits of the components and what is available to driver them.As to the oscillation issue, you can almost always get rid of the oscillation but that may mean making the step response slower. It usually ends up being a compromise between the step response settling time and the oscillatory part and the overshoot. A faster settling time could mean a lot of overshoot. The only way to predict this is to know everything about the components and available drive power source.Unfortunately, there could also be some nonlinear things like sticking friction. That could mean a small oscillation will always be present.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 03, 2024, 05:24:19 pm
content: Quote from: IanB on June 19, 2024, 03:04:21 pmI don't like this kind of grossly incorrect generalizations. When PID controller is used as a generic control component without conversion (e.g. integrating, taking derivatives) of inputs and outputs, what terms are needed depend on what is being measured and what is being controlled. So the roles, mental expectations of what P or I or D do are not actually fixed!Very relevantly in OP's case, for example, if you control say a motorized valve based on water temperature measurement, or a motorized potentiometer based on volume (or reference resistance track) measurement, what terms are needed depend on how the motor is driven:If the motor itself accepts position input, you are correct, D should be initially set as zero; PI controller is the primary method; P gives transient response and I removes offset error. P should be set fairly high, e.g, to oscillation and then halved; and just a little bit of I added to remove offset.BUT:If the motor is given relative movement commands (e.g., pulses of varying length based on PID output value), then the motor becomes a mechanical integrator itself, and the roles of the terms become integrated, too: I term becomes double integral (integral of integral), which is useless. P term becomes an integral, and removes the offset (thus small amount is used). D term becomes P, and provides transient response! So you need a PD controller with quite a lot of D term, and you can't have a responsive and stable feedback without it.I know the whole PID control theory is a huge can of worms, and is best tackled in a iterative hybrid strategy of just building stuff and experimenting + looking at literature. This PD thing I discovered when building a motorized heating shunt valve controller, which mixes hot and cold water, measuring output temperature. Because the motor is just a synchronous AC motor, driven in pulses clock-wise or counter clock-wise, attempts to control it with PI control all failed miserably. The elements for success were:* Backlash removal logic (simple piece of code which detects when direction changes and then lengthens the pulse)* A lot of D term, and removal of I termVery usually just PID alone doesn't give very good results even if you hire infinite number of monkeys for infinite time to generate optimal coefficients. Usually the system needs something else too, like the backlash removal I mentioned, or some physical feedforward (e.g., in a robot, from gyroscope yaw angular rate directly to motor currents).

author: Infraviolet
author_rank: Super Contributor
timestamp: July 03, 2024, 07:51:23 pm
content: "Backlash removal logic (simple piece of code which detects when direction changes and then lengthens the pulse)"Interesting note, thanks. I've had issues myself in the past doing PID with a DC brushed motor, this could be a major part of the reason why. Also, DC motors won't move at all below a certain PWM percentage threshold, where this threshold is will often vary with PWM frequency too. I found I had to have code after the PID that boosted any non-zero value up to that threshold (in whichever directionnwas appropriate), this tended to lead to some oscillation about the stopping position, though it settled to the correct position over time.

author: IanB
author_rank: Super Contributor
timestamp: July 03, 2024, 09:06:21 pm
content: Quote from: Siwastaja on July 03, 2024, 05:24:19 pmThanks for the detailed comments. I was also thinking yesterday that driving a motor speed to achieve a position is indeed an integrating process, since the speed of the motor is integrated to give the position of the output shaft. Controlling an integrating process with a PID controller is challenging and does require a different approach to tuning. I totally agree with you there.Fortunately, not many processes are pure integrators like that. Liquid level in a tank is another one, where the tank level is the integrated value of the flows in and out.That said, you do often need some integral action even on an integrating system, since the accumulated integral action produces an offset or bias on the controller output. Without integral action you need to manually set the bias on the controller output. For example, if your normalized PID output runs from 0 - 100% and you are controlling motor speed on a positioner, then you might bias it so that 50% output corresponds to zero speed, 0% corresponds to max reverse, and 100% corresponds to max forward. Or you would express the PID algorithm in absolute engineering units, where the error is expressed in millimeters of deviation and the controller output is expressed in revolutions per minute (or something). But doing this causes every control loop to have different scaling and it becomes harder to apply rules of thumb to the magnitude of the tuning constants. Consequently PID loops often normalize their inputs and outputs in a range from 0 to 1 (0% to 100%) to fit the range of the associated A to D and D to A converters.Coming back to the opening point about generalizations. I have been tuning process control loops in the chemical process space (flows, levels, pressures, temperatures, etc.) for about 40 years, and I would say in over 90% of cases the D term has been set to zero. If a generalization is something that is true most of the time, then in the process engineering space my comment fits. Where you can take me to task is that there are many other domains where PID control is used, in mechanical and electrical systems, for example. And in those domains, derivative action may be much more relevant.So, you got me. Point taken.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 04, 2024, 12:08:25 pm
content: Quote from: Infraviolet on July 03, 2024, 07:51:23 pmImplementing current feedback and using current as controller parameter (speed PID loop controlscurrent setpoint, not PWM duty directly) will tremendously help.From current setpoint, you go to PWM with another feedback loop (current measurement --> PWM duty%), but that loop can be PI (without D) and tuning it is much more forgiving.

author: MrAl
author_rank: Super Contributor
timestamp: July 04, 2024, 06:29:31 pm
content: Quote from: IanB on July 03, 2024, 09:06:21 pmHi,There is a good rationale for using the D part. It's almost like you are giving the system an advanced look into the future so it knows where it is heading even before it gets there.I am sure you know that a 'slope' is an increase or decrease in some quantity that keeps changing over time. That's almost always (maybe always) used in conjunction with a coefficient. For a simplified example:y=m*t+bHere the 'm' is the slope. Having the slope involved with the value of 'y' it gives us a sort of glimpse into the future about where 'y' will be after the next increment of time 't'. That gives the rest of the system a little more knowledge about how the control will work. 'm' is not usually a constant though because it changes over time. Once the system starts to stabilize, 'm' becomes a lower value, and thus has less and less influence on the system final value.I think a really good example, although a little too complicated to discuss here maybe (or maybe not), is a buck circuit where we measure the current in the inductor. That's like measuring the derivative. If we use that information, we can control the output even faster than just measuring the output voltage, which of course is mandatory with a regular buck circuit.The advantage is in a system that would otherwise have objectionable overshoot if we tried to control it faster (a very typical control theory problem). Since the system has a sort of advanced knowledge of what will happen next, it can almost 'foresee' the overshoot before it happens because the derivative is a high value at that point, and if it was already a low value it would 'know' that the overshoot will not be that bad so less dv/dt compensation would be required. That allows it to use that to help to prevent the overshoot from happening or at least not as bad as it would have been.Not all systems are going to need this because a lot of them can be controlled without objectionable overshoot, such as in overdamped systems. There's no problem there so the D part probably would not do anything or would actually cause more overshoot.That's more or less theory of the control of systems which allows us mostly to understand the workings of systems, but a more practical way to adjust the coefficients uses fuzzy logic. There's a good article on it on the web somewhere but I'd have to find it again. A search should turn something good up though. Probably something like, "Using fuzzy logic to adjust a PID control system".

author: IanB
author_rank: Super Contributor
timestamp: July 04, 2024, 06:47:43 pm
content: The reason you don't find derivative action used so much in the process industries is that it common to tune control loops quite slowly and give them a damped response. One reason for this is that the processes being controlled are often quite non-linear, so a tuning which is fast but stable in one region of operation could become unstable in a different region due to the non-linearity. Very often control engineers will be happy if control loops drift slowly to the set point, and there is rarely a need for a super aggressive response. It should remembered that everything comes at a cost, and if you put tight control on the measured variable, you will have a lot more movement of the manipulated variable, and this may have its own consequences. For slow, damped, control action, PI is typically sufficient.There are of course cases where faster and tighter control is needed, and in that case a more analytical approach to tuning will be used, and all three PID terms may be included.Another characteristic of derivative action is that it can react to noise on the measured signal, and process variables can often have noise on the measurement. For this reason, derivative action is almost always combined with a filter in the measurement to remove any high frequency content in the signal.

author: IanB
author_rank: Super Contributor
timestamp: July 05, 2024, 04:11:21 pm
content: Out of curiosity, and to illustrate some of the comments made by various posters to this thread in a more concrete fashion, I made a simulation of a motor-driven positional servo with a PID feedback controller.There is a motor which runs in either forward or reverse direction to move the position of an output actuator, which has a position target set by the controller. The motor is simulated with inertia, so it takes time to respond to changes in speed demand.All model parameters are dimensionless, and only relative magnitudes have any meaning. There is no reference to actual physical dimensions or units of measure.Some results from this simulation are attached:With only proportional action there is a tendency to overshoot and some oscillation around the target position.Reducing the proportional gain can remove the oscillation, but then the control action is slower.Introducing derivative action allows the gain to be increased and leads to a much faster control action without oscillation or overshoot.Introducing integral action leads to gross overshoot and poor control. It should be left at zero.

author: Siwastaja
author_rank: Super Contributor
timestamp: July 05, 2024, 06:05:03 pm
content: Quote from: MrAl on July 04, 2024, 06:29:31 pmWith this line of thinking, let me once more remind everyone of the existence of feedforward. Use it! Super simple. Can be something as simple as a fourth term off the setpoint, so that the whole equation becomes:output = Kff * setpoint + Kp * error + Ki * (accumulated error) + Kd * (error - prev_error)Tune with all P, I, D terms all set to zero, for best possible response from feedforward alone. Then tune the rest as usual.You can also add stuff like feedforward from setpoint change (Kdff * (setpoint - prev_setpoint).These thingstrulylook into the "future" - D term still has delay, it has to go through generating an error before it can react.

author: IanB
author_rank: Super Contributor
timestamp: July 05, 2024, 06:27:31 pm
content: Quote from: Siwastaja on July 05, 2024, 06:05:03 pmSurely if error = (setpoint − value), then Kp * error expands to Kp * setpoint − Kp * value, and the feedforward term is already there?It could also be mentioned that while responding to setpoint changes can be useful in servo (setpoint following) applications, it may be undesirable in regulatory (rejecting disturbances) applications. So many implementations have an option to include or ignore setpoint changes in P and D terms. (In fact, some algorithms may ignore setpoint changes on the D term altogether, since a sudden change in the setpoint would cause a big jump in the output.)

author: MrAl
author_rank: Super Contributor
timestamp: July 05, 2024, 10:13:00 pm
content: Quote from: Siwastaja on July 05, 2024, 06:05:03 pmHi,It's interesting that you should bring this up, then add PID back into it.I say this because feedforward control if often used by itself so that might be an interesting topic too.There are disadvantages though, such as system modeling accuracy.I might agree that is probably the most future predicter control.The topic of control theory is rather wide and encompasses a lot of knowledge so there would be many different ways to do this kind of thing.

author: MrAl
author_rank: Super Contributor
timestamp: July 05, 2024, 10:16:59 pm
content: Quote from: IanB on July 04, 2024, 06:47:43 pmHi,Yes, I had hinted on this with the lines:"Not all systems are going to need this because a lot of them can be controlled without objectionable overshoot, such as in overdamped systems. There's no problem there so the D part probably would not do anything or would actually cause more overshoot."There are so many areas in control theory that could be discussed I doubt we could cover all of them here, thus every reply will be like a microcosm of what can really be done. I think we've all touched on some of the good ones.