servo control: two PID loops or three?

I'm working on a custom BLDC servo controller. I finally got the torque loop rewritten to do the usual park/clarke/pid stuff. Next question: is it better to have separate PID loops for RPM and position, or just have a position PID that feeds the torque loop directly?

djdelorie wrote:

I'm working on a custom BLDC servo controller. I finally got the torque loop rewritten to do the usual park/clarke/pid stuff. Next question: is it better to have separate PID loops for RPM and position, or just have a position PID that feeds the torque loop directly?

Does the drive measure current and make it match the command?
If so, then the torque loop is in the drive, and you don't have to worry about it.
If not, do you have a provision to measure phase current? If not, then you
don't have a torque loop.

If you have separate PID for both velocity and position, then you have a LOT of
parameters to adjust. I'm not sure the velocity loop needs that many.
It may be possible to just have P (gain) and damping (D) for the velocity
loop. Depending on the quality of the velocity signal derived from the encoder,
it may be helpful to use the velocity info, and feed this into the damping term
of the positioning PID, see how this is done in the new PID with the
feedback-deriv pin.

Jon

Perhaps some background is called for... my project is a custom controller/driver board, not a module in linuxcnc. Board here: www.delorie.com/electronics/bldc/ and cnc router here: www.delorie.com/photos/cnc/ . The controller combines a microprocessor and inverter, using a generic step+direction interface to linuxcnc but controlling a BLDC motor instead of a stepper. The motors have a 1000 line (4000 count) encoder and hall sensors, and the mcu has hardware quadrature decoding and RPM measurement (er, valid from 6 to 60,000 RPM or so). I have current measurement on all three phases and plenty of floating point performance (80 MFLOPs with a 20 KHz inner loop). The mcu uses six synchronized PWM signals to drive the three phases.

I had a crude control loop before, but the motors vibrated when "idle" so I'm swapping it out with a more "traditional" control loop. As I said, I have the park/clarke/pid math for the torque/current layer done and can tune it to just short of unstable. The question is, do I put in a separate pid loop for velocity? My pid logic is pretty simple, really it's PI with one FF channel (since I know the position loop needs an RPM feed-forward to make it track properly).

djdelorie wrote:

the mcu has hardware quadrature decoding and RPM measurement (er, valid from 6 to 60,000 RPM or so). I have current measurement on all three phases and plenty of floating point performance (80 MFLOPs with a 20 KHz inner loop). The mcu uses six synchronized PWM signals to drive the three phases.

I had a crude control loop before, but the motors vibrated when "idle" so I'm swapping it out with a more "traditional" control loop. As I said, I have the park/clarke/pid math for the torque/current layer done and can tune it to just short of unstable. The question is, do I put in a separate pid loop for velocity? My pid logic is pretty simple, really it's PI with one FF channel (since I know the position loop needs an RPM feed-forward to make it track properly).

Well, if your velocity can't go below 6 RPM, that may be the problem. In LinuxCNC, the encoder can produce
floating point velocity that goes to quite low values, without arbitrary limits of velocity resolution. (At least
with the timestamped velocity estimation scheme.) Separating the velocity loop may not offer any
improvement (in fact, I can't imagine why it should.) When the encoder dithers, the velocity derived from that
needs to be smooth, or the perceived velocity changes in big jumps, causing the D term of the positioning
loop to overcorrect badly. If you can't timestamp the arrival of the most recent encoder count (which I guess
you might not be able to do if the encoder logic is provided by your MCU) then there are limits to how well
you can discern velocity from periodic sampling of the encoder count. If you can service an interrupt and
timestamp every encoder count, you can do better, but that may be an excessive burden on the MCU.

Jon

The hardware decoder measures the encoder pulse width, I can select arbitrary clock rates to change the range of RPMs I can measure. Below a minimum, it just returns zero, but that's when the clock overflows without seeing any more encoder pulses. There's also a tradoff between waiting longer to see if a pulse comes along, or declaring it to be stopped. Fortunately, RPM measurements become more accurate as the RPM decreases.

But that doesn't help me decide if I should put in a velocity loop and position loop, or just a position loop.

djdelorie wrote:

The hardware decoder measures the encoder pulse width, I can select arbitrary clock rates to change the range of RPMs I can measure.

Well, that is not a terribly reliable way to measure velocity, due to dither and variations in the width
of each state. (Some encoders are better with this than others.) Time stamping the arrival of
counts against a free-running clock has been shown to work quite well, even down to very
low speeds.

Below a minimum, it just returns zero, but that's when the clock overflows without seeing any more encoder pulses. There's also a tradoff between waiting longer to see if a pulse comes along, or declaring it to be stopped. Fortunately, RPM measurements become more accurate as the RPM decreases.

But that doesn't help me decide if I should put in a velocity loop and position loop, or just a position loop.

I think you need to instrument the loop to find out where the instability comes from. I am guessing the
problem may be sudden jumps in perceived velocity when a count come in, such as from encoder/
servo dithering. I have done this in LinuxCNC with Halscope to find out what perturbation came just
before the servo jumped. If you can put in some kind of data logging feature to log several
signals on each servo update cycle, you might be able to unravel why it is unstable.

Jon

The RPM measuring hardware works fine. I can't instrument the loops because I haven't written them yet. Hence this thread. I'm still trying to figure out if I need two loops or three. The old code has been removed.

Am I asking the wrong question? I just want to know if it's better to have a separate velocity loop, or tie the position loop directly to the torque loop. So far you seem to be avoiding that question, and answering all the other questions I didn't ask...

My 2 cents:

Historically they were often done with 2 loops, a velocity mode loop
in the motor drive (perhaps with tachometer feedback) and the position loop in the controller. I think the reason for this is that it keeps the high bandwidth ( a few KHz) part of the control loop in the drive, allowing the PID loop in the controller an easier task (just a few hundred Hz bandwidth position PID loop). Much more suited to the often minicomputer/Z80s under the hoods of 70s to 80s machine tools

Since the velocity part of the loop controls something very close to a first order plant it is mainly a P controller. P in the velocity loop is equivalent to D in a position loop, so I dont really see any great advantage in separate loops, as long as your sample rate is high enough to run the velocity loop (the control bandwidth will be around 1/3 of your sample rate)

However having separate loops can make some things easier, for example in the real world there are various limts, and other nonlinearities that must be dealt
with. These can be easier if the loops are separate amd each have their own
"patches"

is D the differential of the error, or of the control input? RPM is the differential of the position, but if the servo is tracking smoothly, even when moving the differential of the position *error* might be zero.

djdelorie wrote:

is D the differential of the error, or of the control input? RPM is the differential of the position, but if the servo is tracking smoothly, even when moving the differential of the position *error* might be zero.

Yes, D is the differential of error. Well, your RPM reading is NOT the differential of the TRUE
position, due to the position quantization of the encoder, then complicated further by the
time quantization (sampling) of the position. So, at low speeds, the velocity reading
from an encoder is badly corrupted by all this quantization, making it a lot harder to
create a stable control loop. Estimating velocity between position changes using
timestamps seems to help a lot. The only other way to help is to increase the
encoder resolution.

My thinking, not being a controls theory expert, is that the additional velocity loop
will not add much to the system stability. If you had a DC tach that would go
all the way to zero (like an analog velocity servo amp) then it might help.

Jon