Help with PID for motorised fader

[tobeyg]

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/HNniWmWh

Would 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.

[IanB]

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.

[tobeyg]

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?

[IanB]

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.)

[tobeyg]

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.

[pcprogrammer]

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 how do you usually work around the issue with the target value fluctuating?

A 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.

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.

For 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 the receiver part of 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: [Select]

#include <CapacitiveSensor.h>
 
#define touchSendPin 14
#define touchReceivePin 15
 
//Arduino Pin Assignments
const int motorDown    = 18;   //H-Bridge control to make the motor go down
const int motorUp      = 19;   //H-Bridge control to make the motor go up
 
//Inputs
const int wiper        = 17;   //Position of fader relative to GND
const int pot          = 16;   //Potentiometer to set position of fader
 
double 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();
 
  // Setpoint
  int 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;
}


[IanB]

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.

On 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.

[tobeyg]

A 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.

Sorry, 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?

For 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.

Yes, 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.

[pcprogrammer]

Sorry, how do mean with the bandwidth? As in how often the value is being read?

With 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.

Yes, 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.

That is a handy feature. Makes detecting a bit easier. Does that work well with a big plastic knob on the fader?

[tobeyg]

On 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.

Yeah, 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 with analogWriteFrequency()) or anything else?

With 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.

I see! Will try it and see.

That is a handy feature. Makes detecting a bit easier. Does that work well with a big plastic knob on the fader?

Yeah, there are caps that are made from conductive materials. Either metal or plastic caps with some kind of metal foil within them (I think).

[IanB]

Yeah, 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 with analogWriteFrequency()) or anything else?

The 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.

[AussieBruce]

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.

[tobeyg]

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.

Hmmm, 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.

[pcprogrammer]

Hmmm, 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.

A 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.

[mikerj]

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.  Y

You 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.

[AussieBruce]

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.

[tobeyg]

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 the ^VILIM be based on the voltage I supply?

[pcprogrammer]

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.

[tobeyg]

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.

Thank 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?

[pcprogrammer]

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.

[MrAl]

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.

[tobeyg]

This is the code I'm running currently: https://pastebin.com/EzhSXZK3
You can see a video of it in action here: https://streamable.com/z5l99a

Current PID values are:

Code: [Select]

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?

[MrAl]

This is the code I'm running currently: https://pastebin.com/EzhSXZK3
You can see a video of it in action here: https://streamable.com/z5l99a

Current PID values are:

Code: [Select]

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?

Hi,

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.

[Siwastaja]

It's always advisable to set derivative to zero unless proven to be needed.

I 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 term

Very 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).

[Infraviolet]

"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.