0
\$\begingroup\$

I have a actuator capable of measuring motor current and position via an encoder on the output shaft. The motor is a brushed DC motor running through a gearbox.

My questions is in regards to the use of a cascaded controller model where by the output of the velocity controller sets the setpoint of the current controller. What I do not understand about this is when velocity tracking and a disturbance torque is encountered the current controller aims to reduce the output voltage to maintain the current and the velocity controller aims to increase the output voltage (via the current controller) to maintain speed. Due the response of the system this causes an exaggerated tracking error when compared to direct velocity control (Voltage Control). A feedforward term does slightly increase tracking performance but not significantly.

enter image description here

Is there something I am missing here? It would make more sense for the current controller to increase the current setpoint when the current measurement is increased. The reason for requiring a current control loop is to be able to set variable max current limits. Switching between "voltage control" & "Current Control" at the limits does not have a smooth response.

A example of this is shown in the image below. The first half of the graph shows the current controller being switch off and the second half shows it being turned on. The Oscillations are from a disturbance torque. It is clear that the tracking error is increased due to the current controller trying to maintain constant torque.

enter image description here

Any guidance would be much appreciated.

\$\endgroup\$
  • \$\begingroup\$ What is actually doing your processing in this case? \$\endgroup\$ – K H Aug 13 '18 at 0:28
  • \$\begingroup\$ A microcontroller \$\endgroup\$ – Paul Phillips Aug 13 '18 at 0:31
  • \$\begingroup\$ Ok. Wasn't sure if it was actually 2 microcontrollers. \$\endgroup\$ – K H Aug 13 '18 at 0:45
  • \$\begingroup\$ Gave you a starter answer, I'm just reading your post some more to evaluate what it should be trying to do. \$\endgroup\$ – K H Aug 13 '18 at 0:48
  • \$\begingroup\$ What are the nature of your disturbance torques? RC car driving over rocks or gusts of wind hitting a fan for instance and how do you wish the motor to perform when it receives countertorque? \$\endgroup\$ – K H Aug 13 '18 at 0:50
1
\$\begingroup\$

You should split the loop in two. Lock the rotor and then tune the inner PI controller (current controller). You should get a neat response. Then connect both controllers and then tune the speed controller.

The inner is a slave controller, it takes the setpoint value from outer controller. Usually the inner has to be faster, usually the current loop is executed with higher frequency than velocity loop, but it does not matter.

This is a speed controller: Speed controller

You can notice the lowpass filter on the begining. It's purpose is to delay the action in order to wait that current loop corrects the error before the speed loop takes an action. Makes sense that it takes time for the controller to correct the error, so you have to wait for a while in the outer loop. Notice also the units:

  • speed: radians
  • dynamic torque (M_dinam): Nm - ommit it for now
  • friction torque (M_frikcije): Nm - forget about it
  • dead weight (M_teze) - forget it
  • speed controller: Kp - Nms/rad
  • the output is torque setpoint Nm

Let's go further to the pre-current loop:

enter image description here

It's a set of limitators, power, torque, current. But then a very important thing, a current constant. The torque setpoint becomes a current setpoint by multiplying ki. The other boxes are notch filters and low pass filter to elimenate the system self-resonance, but skip this.

Finnaly, the current loop:

enter image description here

Note the units of Kp: V/A. It means that output is voltage setpoint, that can be translated to PWM duty cycle.

What you should change in your model:

Add a low pass filter on speed loop. You have seen that you can't switch on/off the current loop unless you multiply the output of the speed loop with some constant. Which turns that your approach to simply turn off/on changes also the total loop gain and you should have two parameter sets.

\$\endgroup\$
  • \$\begingroup\$ From what I can make out this is exactly what I have got. My example graph is not a direct comparison but the difference in velocity error is still apparent no matter on tuning. The issue is still the delay caused when tracking a velocity as the current controller does not "correct the error" in velocity it actually decreases the velocity making it worse. Current controller is tuned independently and runs 4x faster than velocity. \$\endgroup\$ – Paul Phillips Aug 14 '18 at 7:53
  • \$\begingroup\$ The cascaded loop makes the whole system more dynamic a faster response. The current controller regulates the current, without it the sytem response time should be larger. IMO the whole loop isn't properly tuned. Or the implementation of the PI isn't good,...I can't say more, since I don't know how you did it. There is no flaw in the concept, all industrial drives works like that, something in your work doesn't work well. Try to increase gain of the velocity controller, show some tunning results, I can't help without your further work and tries. \$\endgroup\$ – Marko Buršič Aug 14 '18 at 9:30
  • \$\begingroup\$ "It's purpose is to delay the action in order to wait that current loop corrects the error before the speed loop takes an action" The action taken by the current loop to correct the error reduces the velocity and therefore before the velocity loop corrects it we have already experienced a velocity tracking error. Very much appreciate your help and I will try and get some examples to post today. \$\endgroup\$ – Paul Phillips Aug 14 '18 at 22:53
0
\$\begingroup\$

By putting a current loop in, effectively you've built yourself a constant torque, variable speed motor, so the nature of the device is to allow speed to change in order to keep torque the same.

The second loop attempts to use this constant torque variable speed arrangement to control speed, so if just the second loop was controlling the motor, it would be a (variable) constant speed variable torque motor.

I believe the complications in your control mechanism stem from using these two directly conflicting control arrangements. I would suggest that attempting to combine the control mechanisms in the correct way will solve the problem. Keeping them in their opposing separate forms and trying to counter their nature would be much more difficult.

\$\endgroup\$
  • \$\begingroup\$ Thanks for this response. This is what I suspect but just find it interesting that it is such a common topology. It does provide a very elegant way of setting current/torque limits which is desirable in this application. \$\endgroup\$ – Paul Phillips Aug 13 '18 at 0:55
  • \$\begingroup\$ @PaulPhillips Nothing is conflicting in your arrangement, you're on the right way. Peehaps the controllers are not correctly tuned or they are not correctly writen/executed. The major issue could be the implementation of integrator anti-windup an then recovery from saturation. You can post the PI implemetation and show outputs in % of both controllers. Your trend is not very clear. The current measurement has also some weird measurement spikes of values 0. \$\endgroup\$ – Marko Buršič Aug 13 '18 at 6:17
  • \$\begingroup\$ @MarkoBuršič Would you be able to explain then why it makes sense that current aims to decrease voltage where velocity aims to increase it when encountering a disturbance? \$\endgroup\$ – Paul Phillips Aug 13 '18 at 7:14
  • \$\begingroup\$ @PaulPhillips It's the nature of the setup. At the obsatcle the current rises and the current controller tends to lower the voltage, but the speed loop tends to increse the current. The speed loop will be the winner, because it is higher priority. Again: your comparison between off/on current control is not good. Because you probably bypassed the current controller, in this case yo should also multiply the ouptut value with the same Kp of current controller, to compare. \$\endgroup\$ – Marko Buršič Aug 13 '18 at 7:53
  • \$\begingroup\$ I tend to agree with K H here from an experimental standpoint. \$\endgroup\$ – Paul Phillips Aug 14 '18 at 7:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.