PID output does not reach setpoint precisely enough

Question

I'm developing/tuning a software PID for a quadcopter. For now I'm only trying to stabilise the pitch angle using the front and back motors, and I'm only looking at Kp. The motors have a control resolution: input variations need to reach a threeshold to have any effect at all.

The process output does reach the setpoint, but not precisely enough for my requirements. There is no steady-state error (aka droop), the hunting range is centered on the setpoint, just too wide for my requirements. Also the instability is not an oscillation, but more of a random drift which needs to be large enough before the PID attempts to correct it.

• With a lower Kp the output needs to diverge from the setpoint significantly before the error is big enough for the PID to attempt to correct it.
• With a higher Kp the PID oscillates.

I could not find a reasonable compromise.

I'm thinking about applying the cuberoot function (or similar) to the error before feeding it to the PID: that way small errors should be significant enough for the PID to attempt to correct them, and large errors would be reduced and might not trigger oscillations. I suppose someone must have been through this before: is this a good solution? Are there any better alternatives?

This is not a steady-state error (aka droop) or oscillation issue as far as I can tell: please don't suggest using Ki or Kd

EDIT: I have clarified the problem description and suggested using cuberoot rather than logarithm which was a bad idea indeed.

Thanks, Marc.

Answer 1

Since posting the question I tried to tune the 3 PID parameters a lot but I never reached any acceptable result. I didn't try to modify the error curve as I suggested in the question, but I found an alternative solution which works reasonably well. There might be other good solutions.

I was using a PID as follows:

• process setpoint: angle
• process output: difference between motors speed (used in motor mix equation)

While in theory this might very well work, I could not find good values for Kp, Ki, and Kd to obtain satisfying results. I changed my program to use 2 cascaded PIDs as follows:

Outer PID:

• process setpoint: angle
• process output: angular rate

Inner PID:

• process setpoint: angular rate
• process output: difference between motors speed (used in motor mix equation)

I first tuned the inner PID so as to get no oscillation but a slight resistance against angular change when the target angular rate is zero. I then tuned the outer PID so as to get no oscillation but a reasonably responsive attitude matching the stick inputs. Even with a very basic tuning the results are acceptable.

Thanks again to all the participants, your input encouraged me to learn more about PIDs and avoided me some errors.

Answer 2

It sounds like the problem stems from your motors. The motors are fine, but they have a threshold that prevents you from setting their speed to exactly the value you want. This is a problem because you are attempting to map your PID directly to their output, which has a minimum value.

You need to alter your motor control code so that if the desired thrust is below the motor's threshold, you pulse the motor so that its average over time is the thrust you need. There are several ways of accomplishing this, depending on how your control loop works.

Answer 3

I am unsure of why you said "please don't suggest using Ki or Kd" and will suggest them anyway. From the comments from the original post I understood that it is not the problem that you settle near the setpoint but that you oscillate around it.

If that is the case then you need to add Kd to dampen the oscillations.

If your problem is in fact that you settle near the setpoint then you need to add Ki to compensate that error.

This is the reason why there are all three terms in the PID regulator and not just one. Such behavior from using proportional term only is expected. Introducing nonlinearity such that you suggested is not something you should generally do.

Regards

Answer 4

I'm going to suggest it anyways. Add an integrator.

What you've described is a textbook description of how a proportional only controller would work. If your output is stable, you will never reach your setpoint. From Wikipedia:

Because a non-zero error is required to drive it, a proportional controller generally operates with a steady-state error, referred to as droop. Droop is proportional to the process gain and inversely proportional to proportional gain. Droop may be mitigated by adding a compensating bias term to the setpoint or output, or corrected dynamically by adding an integral term.

Biasing is typically a static value added to the output based on some known quantity. If the droop is a know stable constant, you can do this. But my personal feeling is that it is usually a hack that requires constant adjustment.

You're attempting to achieve dynamic biasing by using the logarithm of the error. Don't mess with the input to the controller. It will only cause you headaches down the line. You will achieve much better results if you use an integrator.

The alternative is to use a lead-lag filter:

A lead compensator can increase the stability or speed of reponse[sic] of a system; a lag compensator can reduce (but not eliminate) the steady-state error.

But you will achieve the same thing with a lot less math if you manually tune using an integrator.