Electronics > Projects, Designs, and Technical Stuff

Motion control, S-curves and other stuff >> controlling lift with DC motor

(1/14) > >>

krisRaba:
Hi!
I hope that we have at least one expert in motion control here 8)

First of all - the object (or plant ;) )
I have about 6kg lift (so vertical direction of move) driven by geared DC motor and what I need is smooth movement from position A to position B with controlled speed in the same time. At the moment I have available:
position feedback -  0.01mm resolution linear magnetic encoder
current feedback - unipolar ACS723 current sensor in V+ above H-bridge.

Current solution
For velocity feedback I use tracking loop that compares actual position from encoder with estimated position calculated from estimated velocity. It works better than raw calculation based on pulses count per deltaT or moving window average from raw results (lag). But still on very slow speeds it is not so great because of low pulse count per encoder reading period. I am thinking about additional encoder on motor shaft (so before /27 gearing) which will give much higher resolution but maybe it can be improved by better algorithms?

I have implemented cascade of regulators:
PD position -> [linear speed limiter a.k.a ramping] -> PI speed -> PWMs for DC motor
 
Positioning works but probably could be tuned a little bit better. One thing I don't like is the shape of velocity curve. Velocity change is limited so setpoint best case is a trapezoid which produces nice S-shape on position curve. But if you put position loop above that you get shapes like "bannana up" on acceleration and inversed "bannana down" on deceleration ;) And of course there are still 2 sharp edges: at the beginning and when changing from constant speed to deceleration phase.

S-curves - how to?
I would like to implement S-curve to velocity curve for smooth movement.
My first idea was to linearly control current by adding additional current control loop and linear limiter. As far as I know current in DC motor is proportional to torque so also proportional to acceleration. Linear acceleration should give S-curve for velocity. Bad news here is that current measurement in this object/plant is not as I expected. I thought that with unidirectional current sensor in V+ above H-bridge I will be able to measure current regardless of DC motor rotation direction. It is true in steady state. When my cascade of regulators keeps position current increases every time force is applied up or down to keep it in place. But because of BEMF during normal operation and going down current reverses most of the time and tries to flow in unexpected direction ;) Regenerative braking is its name, I think ;)
So such current control would work during going up but I think it won't work when going down. But maybe I am wrong?

Another way to get S-curve on velocity is to get rid of linear speed limited and calculate velocity setpoints that will form S-curve and track it with speed regulator. But it seems to be complicated especially when position setpoint is changed before previous setpoint is reached, so previous s-curve is not finished. With linear acceleration it would be smooth by definition, without advanced motion recalculation on the fly. But maybe it is done that way in motion controllers?

Additional problem is with final position estimation. To know "landing point" whole motion has to be calculated before even starting the move, I think. Because other way it would be hard to know when to start deceleration...

Any ideas how it should be done better? ;)
 

IanB:
My first thought is "less is more".

You seem to have a fairly complicated cascade of layers in your control scheme. It seems that each time you don't quite get the result you want you are adding more layers? Now it seems you may be contemplating feed-forward elements with predictive control...

Maybe it is time to try taking things away instead of adding? Have you tried doing simple PID control on position and tuning the P, I and D terms carefully? Your I term should be able to give you some ramping behavior to reduce jolt, and your D term should be able to give you some feed-forward prediction to slow down when you are approach the target position. Perhaps this is where you started, but it still seems to me to be a rational approach.

I haven't implemented control on a system like this, so the above thoughts are just guesses. However, I do think there comes a time when adding more complexity to a system doesn't help.

krisRaba:
Hi!
Thank you for your response.

I have tried with single PID ;) And this is not proper way to do it, I think.

When you separate controllers you have more control over particular elements. First of all you have velocity control itself that isolates any object/plant nonlinearity from higher layers. When you set 10mm/s it keeps it regardless of anything - load change, friction change, supply voltage rail fluctuations etc. It uses all it can use (full range of PWM) to keep your velocity setpoint.

When you use single PID like [position input / PWM output] - what is your speed between positions? Hard to tell ;) If you have PID with limited output you can set limits for max PWM duty and min PWM duty... it doesn't talk in "limited velocity language" ;) It is very important in vertical movement. In horizontal movements it is a little bit easier because it is almost sure that 50% PWM duty LEFT will give the same velocity but opposite sign to 50% PWM duty RIGHT..
But in vertical direction result of 50% PWM duty UP is far away from 50% PWM duty DOWN. Gravity is your enemy here ;)
So you can isolate that nonlinearity by additional layer. You have PI velocity controller that handles all that stuff and higher layers don't have to care about it.

Now on top of that you have position controller. It takes position setpoint and outputs... yes! Velocity! So you have a point where you can control speed. You can set your max and min velocity, and you can say: OK, take me from point A to point B but maximum velocity is 200mm/s or 600mm/s. You can't do that with single PID and asymmetric object.


So cascade of controllers is not a stupid solution here ;) I have seen many examples with even longer cascades of controllers ;) But usually general description and math in these documents looks a little bit overwhelming for me ;) It is a little bit easier to learn from examples instead of PhD elaborations  |O
And in such moments I am not sure if I should add another layer with S-curve somewhere between controllers or replace position PD controller and calculate position changes on the fly with S-curves formulas.

And you are right, I was thinking of some kind of feed-forward  :-DD Just because I have read somewhere that it limits the role of PID itself, it has to handle only the error instead of full value change. But I haven't investigated that topic yet ;)

capt bullshot:
The common way in servo controllers is a cascade of three control loops:

Inner loop: motor current (aka motor torque) controls motor voltage
Middle loop: speed controls torque (current)
Outer loop: position controls speed

As far as I can see, this looks like your control scheme, so I think you've done that part right. For smooth acceleration / deceleration various schemes exist, depending on the requirements. One of them looks similar to your approach and you've successfully found its limits. I'm not deeply into this stuff, so can't help with details of how to implement, but I vaguely remember there's some kind of math (like spline interpolation or up to fifth order curve fitting) required to generate smooth transitions from stopped system to movement and vice versa - quite demanding e.g. for real elevators.

To increase encoder resolution at slow speed with a limited amount of pulses per revolution - do a time measurement from one pulse to the next pulse and calculate raw speed from that in addition to counting pulses per unit of time. Using a tracking loop (observer structure, or some kind of prediction) to get better results is also common technique, but as I said, I'm not deeply enough into that stuff to help with details.

Edit: Having a second encoder for speed, directly at the motor output before the gearbox, should help for smoother velocity control.
And yes, to "land on the spot" you should be able to predict the deceleration curve or supply the position controller with the S-curve matching you mechanical system (expressed in position).  At least some industrial servo controllers work this way - these can be quite complex beasts, not just a simple VFD.

krisRaba:
Thanks for your input :-)
I have read some documents about speed feedback and both delta position and delta time methods have their drawbacks. Sometimes it is useful to mix them so some of the drawbacks are mitigated but generally tracking loops and observers are recommended.
Lack of pulses at low speeds is generally hard to manage. You can measure time between edges and additionally estimate at each sampling period that because there was no pulse and timer is still counting your speed is not higher than X but it works better with ideal encoders with ideal edge positions and spacing.. but AFAIK such encoders doesn't exist ;-)
So my tracking loop works well but unfortunately can't overcome physical limits where in sampling period there is no pulse or double pulse is counted because real speed is not synchronized with sampling time. There are some techniques for such synchronization but I don't understand what they were talking about :-D

Maybe you are right with position S-curve generating for position controller. It would have to be higher order to produce another S-curve on speed but it may work :-)

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod