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

[krisRaba]

Hi!
I hope that we have at least one expert in motion control here

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

[jbb]

Depending on how you feel about horrible mathematics, you can do as much or as little as you like.  Are you looking for good enough or maximum speed or maximum smoothness? Will your payload weight change during operation?

To throw my not-very-informed opinion into the ring... I would look at doing the S curve generation purely on the position reference side.

Some things I’d be concerned about:

- with finite encoder resolution, I suspect you’ll get a little bit of vibration (eg limit cycle oscilllations) when the platform is stationary. If you need something dead steady, I suggest a mechanical brake.

- look out for integrator wind-up

- in the faster loops (especially current control), Derivative gain can pass high frequency noise through the system, so if you’ve got lots of bitter happening, try setting D gain to 0

- when lowering load, you may well be generating electricity. Have you checked for this and designed appropriate countermeasures (an external braking resistor is absolutely classic)

- if the DC link voltage changes more than a few %, the PWM reference to equivalent motor voltage rail will change. In general, I suggest including DC link measurement and compensation when generating the PWM duty cycle

- different payloads will change the plant gain, so PID settings would need to be a compromise that works OK with varying loads

- the current sensor arrangement you describe isn’t ideal. Could you rearrange your system so that you have a bipolar current sensor on the true motor current?

- I suggest running current sense ADCs at twice the PWM switching frequency so that the switching frequency is at the top of the Nyquist band and can be filtered out effectively. I have tried sampling at the PWM frequency in the past, and found that small variations in the plant generated some frequencies very close to the switching frequency (thus close to the sampling frequency) which then aliased down to near DC where I could t filter them out. It was disturbing to see my current waveforms ‘gallop’ across the oscilloscope... and moving to double frequency sampling fixed it totally

- it’s possible to develop an observer for the total platform mass (difficult maths)

- it’s possible to develop an observer for the platform speed and position that will provide smooth, continuous position output even at low speed (difficult maths)

[krisRaba]

Depending on how you feel about horrible mathematics, you can do as much or as little as you like.  Are you looking for good enough or maximum speed or maximum smoothness? Will your payload weight change during operation?

I am not sure how much of horrible math I can handle  I have noticed that usually all these horrible descriptions and equations become more eatable when used in discrete form as algorithm examples
Generally during single move payload is constant but I have to take into account that someone will change it without changing any parameters so system should handle that or adjust/autotune.

To throw my not-very-informed opinion into the ring... I would look at doing the S curve generation purely on the position reference side.

I will try that, I think.

Some things I’d be concerned about:

- with finite encoder resolution, I suspect you’ll get a little bit of vibration (eg limit cycle oscilllations) when the platform is stationary. If you need something dead steady, I suggest a mechanical brake.

It is interesting. I have noticed such behavior. When speed PI setpoint is set to 0 it bounces around pulse from time to time. I thought that position controller does that because 0,01mm is quite high resolution for position keeping.. but it turns out it is a matter of speed PI And what is more interesting - I can easily directly set PWM duty at which position is kept and everthing is steady.
Maybe with higher resolution (encoder on motor shaft) it will also behave better on PI

- look out for integrator wind-up

It is limited in my PID implementation AFAIK

- in the faster loops (especially current control), Derivative gain can pass high frequency noise through the system, so if you’ve got lots of bitter happening, try setting D gain to 0

At the moment I don't have current loop. I use hardware to limit max current (OCref clear functionality in STM32) and trim PWM duty. My lowest control loop is speed and it is PI type.

- when lowering load, you may well be generating electricity. Have you checked for this and designed appropriate countermeasures (an external braking resistor is absolutely classic)

At the moment I use PSU that can handle that because other cheaper PSUs were not so happy and were shutting down because of OVP In the future I plan to implement some resistor+NMOS+opamp to protect DC rail and use standard PSU.

- if the DC link voltage changes more than a few %, the PWM reference to equivalent motor voltage rail will change. In general, I suggest including DC link measurement and compensation when generating the PWM duty cycle

Speed control loop handles that, I think.

- different payloads will change the plant gain, so PID settings would need to be a compromise that works OK with varying loads

That's true. I have noticed that parameters tuned for one setup not always fit another setup 

- the current sensor arrangement you describe isn’t ideal. Could you rearrange your system so that you have a bipolar current sensor on the true motor current?

It is possible in future PCB release. You mean putting sensor in series with motor, inside H-bridge?
Will it bring any improvements to control system?

- I suggest running current sense ADCs at twice the PWM switching frequency so that the switching frequency is at the top of the Nyquist band and can be filtered out effectively. I have tried sampling at the PWM frequency in the past, and found that small variations in the plant generated some frequencies very close to the switching frequency (thus close to the sampling frequency) which then aliased down to near DC where I could t filter them out. It was disturbing to see my current waveforms ‘gallop’ across the oscilloscope... and moving to double frequency sampling fixed it totally

Thanks for advice. I will keep it in mind. It will be helpfull, I think.

- it’s possible to develop an observer for the total platform mass (difficult maths)

- it’s possible to develop an observer for the platform speed and position that will provide smooth, continuous position output even at low speed (difficult maths)

Any examples of that maths?

[jbb]

Sorry for messy reply - writing on phone at lunch.

Re jumping around at low speed: I think a higher resolution encoder would just make the bitter smaller, rather than getting rid of it. One possibility would be to set a deadband on the position controller that’s a little bigger than the resolution of the encoder. But this could just make things worse... There may be someone on the forum who’s grappled with these issues??

Re current sense: yes, I mean put it inside the H Bridge directly in series with the motor. For a brushed DC motor the torque is directly proportional to the current.  Controlling current equals controlling torque which is great because it then determines the lifting force (plus gearbox and capstan, of course), which is I prtant for your system dynamics. Also limits motor current to prevent firey death. Have you fitted some ferrite beads and EMI caps to the motor?

Re DC rail compensation: if the rail doesn’t move much, you can probably ignore it. But if you’re having trouble with all the system gains moving around, getting 1 unknown term compensated might be helpful.

Re observers: I’ve totally forgotten the maths, sorry.

[Mechatrommer]

you may try implementing Fig 3.22 (cascaded loop) for this kind of multivariable (acceleration/velocity and position) control system in https://www.sciencedirect.com/topics/engineering/position-loop thats the mainstream way in control academic, or... you can try preplanned/precalculated S-curve and do single loop PID control based on that calculated values, ymmv.

- it’s possible to develop an observer for the total platform mass (difficult maths)
- it’s possible to develop an observer for the platform speed and position that will provide smooth, continuous position output even at low speed (difficult maths)

Any examples of that maths?

any control book i know will start with plant modelling, and then to control loop or feedback schematics with gain parm, and then transfer function is derived, and then transformed to Laplace domain to find zeros and poles to determine stability. i never took them seriously esp the Laplace part. you may download some free control book online. and you can see some math example in link i provided above. any control related discussion/text will follow this mode, mind boggling mode  you can go further if you like to "adaptive" or "robust" control for even more mind boggling math, and meet the observer, disturbance and the like in the form of abstract mathematics. ymmv.

[Someone]

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

This is the entire problem of smooth motion, predicting the future position. If you only have a few simple movements possible (not arbitrary positions) just throw a predefined path at it.

[rstofer]

'grbl' is a motion control system running on an Arduino to drive CNC machines.  What is important is that the firmware looks ahead in the G-Code and uses that to control speed and acceleration such that it can cut into a corner without breaking the cutter.  I don't know for sure but it seems like this control of overshoot is just what is desired.  Controlled acceleration and deceleration.

It also has motor current limit which might come in handy.

Might be worth a read:

https://jtechphotonics.com/Downloads/GRBL_Controller/Instruction_Manual_GRBL_Controller_V1_2.pdf

[Mechatrommer]

Using stepper motor as in gbrl or 3d printer is easy, no need pid control, all you need to do is preplanned/predefined motion. You send stepper pulses, it will go exactly to that position, no undershoot, no overshoot not even ringing (given no slip)  thats why most engineers and hobbiests love stepper motor when it comes to position control, not even need close loop feedback. But for bigger lift/torque it will need tons of metal to build the matching stepper motor and hence costs an arm, not to mention rig and cement to support it. thats its drawback, poor torque/weight spec. Ymmv.

[capt bullshot]

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

So two methods to deal with sampling intervals and pulses:
- use an encoder with analog (sin/cos) output, that gives you theoretically unlimited resolution by calculating atan2()
- use an additional hardware time to yield a high resolution time measurement from one pulse to the next pulse - some uC (maybe Infineon as I vaguely remember) have special internal connections to feed the QEI output to additional timers, not just the up/down counter. You might have to deal with interrupts not synchronized to your sampling / control loop period.

Anyway, from my limitied knowledge, having an additional speed encoder, especially when your main encoder is a linear position scale, is rather common.

For current sensing, in higher power / voltage servo controllers it's common to place the current sensing into the motor lines (up to three sensors for a 3 phase PMSM), so placing the sensor in the motor output (as you already have an isolated solution) might be the way to go. Regarding lower voltage setups, often shunts placed in the lower legs of the brigde are used, but this is for saving the isolation / differential amplification part, not for better performance.
PWM is typically generated using a triangle style modulation (main counter is counting up and down, PWM egdes are placed on up and down ramps and can be updated at top and bottom count, current is sampled at top and bottom of the triagle. Any uC that says "Motor control PWM" in its features should be able to operate at least one timer unit in this mode. With maybe some additional skew adjusted to the inherent propagation delays of the system (H-Bridge and current sensor), this yields the correct average value of the motor current. Harmonics and stuff are filtered by the comb filter nature of this sampling arrangement.

[filssavi]

IMHO before embarking in a horrible journey through observers and model predictive controls, you should close the current loop, it is of vital importance for a smooth operation of a machine drive, as it can mask all the motor nonlinearities from the speed controller, that now it has the much easier job of controlling an ideal machine.

This is fundamental for a good tunability of the outer loops, of course the bandwidths should be decreasing (usually by an order of magnitude or so) as you go from the inner loops out

Also for good operations on the entire load range of the machine you might want to add some adaptive paid parameter changes (easing the parameters when at full load for example),

Hardware wise as job already said that current sensor really needs to be moved to the output, also you need a bipolar sensor as it is not guaranteed that the motor current will always run in the same direction

[krisRaba]

Re jumping around at low speed: I think a higher resolution encoder would just make the bitter smaller, rather than getting rid of it. One possibility would be to set a deadband on the position controller that’s a little bigger than the resolution of the encoder. But this could just make things worse... There may be someone on the forum who’s grappled with these issues??

Yeah, higher resolution should reduce the problem because change in position will be noticed earlier and less correction action will be needed. But on the other hand higher resolution means being more sensitive to vibrations etc. I have noticed that with linear position encoder when changed 0,1mm to 0,01mm version. I have implemented plotting routine that outputs something if positions changes. After increasing resolution it was plotting almost all the time as it is hard to keep so precise position steady. Even stepping on other end of the room causes vibrations that change the position slightly

Re current sense: yes, I mean put it inside the H Bridge directly in series with the motor. For a brushed DC motor the torque is directly proportional to the current.  Controlling current equals controlling torque which is great because it then determines the lifting force (plus gearbox and capstan, of course), which is I prtant for your system dynamics. Also limits motor current to prevent firey death. Have you fitted some ferrite beads and EMI caps to the motor?

I will try to implement current sensing directly on motor. But I am still not sure if current control loop will work properly in vertical as UP and DOWN currents looks way different. But maybe it will handle that just like speed controller handles it without a problem.

Re DC rail compensation: if the rail doesn’t move much, you can probably ignore it. But if you’re having trouble with all the system gains moving around, getting 1 unknown term compensated might be helpful.

At the moment I use top quality PSU which provides bang-on DC rail and even handles overvoltage caused by motor in regenerative breaking. I will consider it later because at cutting cost phase I will try to replace that expensive PSU to something little bit cheaper.

you may try implementing Fig 3.22 (cascaded loop) for this kind of multivariable (acceleration/velocity and position) control system in https://www.sciencedirect.com/topics/engineering/position-loop thats the mainstream way in control academic, or... you can try preplanned/precalculated S-curve and do single loop PID control based on that calculated values, ymmv.

This is almost exaclty what I have. One missing component is the current control loop because I only use hardware comparators to limit current. I have to change current sensing circuit to make it bidirectional etc. as mentioned earlier.
I have also found excellent example for S-curve calculation and it can be used for position point-by-point feeding. It determines initial and final position and additionally total time of movement. In spreadsheet it works very well.
https://robotics.stackexchange.com/a/7503

any control book i know will start with plant modelling, and then to control loop or feedback schematics with gain parm, and then transfer function is derived, and then transformed to Laplace domain to find zeros and poles to determine stability. i never took them seriously esp the Laplace part. you may download some free control book online. and you can see some math example in link i provided above. any control related discussion/text will follow this mode, mind boggling mode  you can go further if you like to "adaptive" or "robust" control for even more mind boggling math, and meet the observer, disturbance and the like in the form of abstract mathematics. ymmv.

Uhm, no thanks I would probably need another guy that loves that part who would model, simulate and prepare algorithms etc. I think it's important part when you want to do it REALLY right because with all that maths you can see traps that can occur in very specific situations. Unfortunately my mind is not so flexible after all these years. I could dive into that but it would take some time and give no pleasure, I think So maybe I will stick to solutions for engineers, not for academic gurus

This is the entire problem of smooth motion, predicting the future position. If you only have a few simple movements possible (not arbitrary positions) just throw a predefined path at it.

Solution already found!  Link to the formula added above.

'grbl' is a motion control system running on an Arduino to drive CNC machines.  What is important is that the firmware looks ahead in the G-Code and uses that to control speed and acceleration such that it can cut into a corner without breaking the cutter.  I don't know for sure but it seems like this control of overshoot is just what is desired.  Controlled acceleration and deceleration.

It also has motor current limit which might come in handy.

Might be worth a read:

https://jtechphotonics.com/Downloads/GRBL_Controller/Instruction_Manual_GRBL_Controller_V1_2.pdf

Using stepper motor as in gbrl or 3d printer is easy, no need pid control, all you need to do is preplanned/predefined motion. You send stepper pulses, it will go exactly to that position, no undershoot, no overshoot not even ringing (given no slip)  thats why most engineers and hobbiests love stepper motor when it comes to position control, not even need close loop feedback. But for bigger lift/torque it will need tons of metal to build the matching stepper motor and hence costs an arm, not to mention rig and cement to support it. thats its drawback, poor torque/weight spec. Ymmv.

I have already tested big stepper motor in that project and it is too slow. Stepper doesn't like high speeds because torque decreases very fast and when you try to go too fast with hugely decreased torque you can loose steps, produce a lot of noise etc
Mentioned controller uses dedicated drivers so it is a little bit easier because you provide command or DIR/STEP and you don't care, driver should follow and keep position. I try to control everything directly from MCU so my code should care about everything
But maybe (if I understand it correctly that GRBL is an Arduino + shield with drivers) there is some open source code that can be used as a reference for movement planning... I assume there is no feedback and it works open-loop by forcing positions on drivers but there could be something interesting anyway.

 

So two methods to deal with sampling intervals and pulses:
- use an encoder with analog (sin/cos) output, that gives you theoretically unlimited resolution by calculating atan2()

It's "resolver", I think. AFAIK it is used in very precise drives. If my additional encoder on motor shaft will not do the job I will investigate that solution. Thanks for a hint! 

- use an additional hardware time to yield a high resolution time measurement from one pulse to the next pulse - some uC (maybe Infineon as I vaguely remember) have special internal connections to feed the QEI output to additional timers, not just the up/down counter. You might have to deal with interrupts not synchronized to your sampling / control loop period.

This is also interesting. At the moment I use another timer as a time-base and it triggers input capture on QEI so I am independent from ISR execution delays in deltaT measurements.
I will have to check if STM32 has some logic to forward edges to other timers. But IIRC it doesn't have anything like that and signals would have to be wired externally to work with two timers. In older MCUs it was a little bit better because you could route your input to more than one peripheral. Nowadays you can select only one Alternative Function and all you can do is to use internal inter-peripheral connections. It is less flexible 

Anyway, from my limitied knowledge, having an additional speed encoder, especially when your main encoder is a linear position scale, is rather common.

I have also seen that in many out-of-the-box controllers. It means it is not so stupid, maybe?

For current sensing, in higher power / voltage servo controllers it's common to place the current sensing into the motor lines (up to three sensors for a 3 phase PMSM), so placing the sensor in the motor output (as you already have an isolated solution) might be the way to go. Regarding lower voltage setups, often shunts placed in the lower legs of the brigde are used, but this is for saving the isolation / differential amplification part, not for better performance.

I can put this current sensor anywhere which is a big advantage. The problem is with its output data acquisition. My MCU is 3.3V and sensor is 5V. Version for unipolar current is easy to adapt because you have small bias voltage, like 0.5V and it increases with current increase (with defined sensitivity) so when you use sensor with higher current range you can measure it directly and only limit the maximum voltage. With bipolar sensor it will be a little bit more complicated because Vbias=Vcc/2 so you have to scale bias and full range... but I will handle it somehow, I think

PWM is typically generated using a triangle style modulation (main counter is counting up and down, PWM egdes are placed on up and down ramps and can be updated at top and bottom count, current is sampled at top and bottom of the triagle. Any uC that says "Motor control PWM" in its features should be able to operate at least one timer unit in this mode. With maybe some additional skew adjusted to the inherent propagation delays of the system (H-Bridge and current sensor), this yields the correct average value of the motor current. Harmonics and stuff are filtered by the comb filter nature of this sampling arrangement.

I have noticed that many exaples use that kind of "phase-correct PWM" and didn't know why. Your explanation about current measurement points put some light and understanding and it corresponds to earlier suggestion that current should be measured twice per PWM period.
But one error that pops up in my head is the current limiting by OCref CLEAR. For Brushed DC it's not so big problem that you will cut the cycle if current exceeds provided limit (comparator with blanking period) but in 3-phase BLDC and sinusoidal driving... but OK, it's not that case now Maybe for BLDC I should use other methods of current control.
So you mean that I should sample current on TOP and BOTTOM, and make an average Ia=(It+Ib)/2?

IMHO before embarking in a horrible journey through observers and model predictive controls, you should close the current loop, it is of vital importance for a smooth operation of a machine drive, as it can mask all the motor nonlinearities from the speed controller, that now it has the much easier job of controlling an ideal machine.

I will

This is fundamental for a good tunability of the outer loops, of course the bandwidths should be decreasing (usually by an order of magnitude or so) as you go from the inner loops out

Yeah, I heard that. From my gathered information outer loop should be at least 2-5 times slower to avoid racing conditions etc. Should it be achieved by parameters tuning / decreasing gains or by varying sampling periods?

Also for good operations on the entire load range of the machine you might want to add some adaptive paid parameter changes (easing the parameters when at full load for example),

I hope that some isolation between layers will able to handle that but we will see...

Hardware wise as job already said that current sensor really needs to be moved to the output, also you need a bipolar sensor as it is not guaranteed that the motor current will always run in the same direction

Yeah, I have already noticed that it wont. For steady state my current sensing works OK (so one direction, from V+ to the motor) but for high speed DOWN movement miracles happen and my current reading tries to go far below Vbias (<0.5V). I think that my unipolar sensor is bipolar in fact but has different bias circuitry that brings Vbias low so only unipolar currents can be seen on output.

[krisRaba]

The problem is with its output data acquisition. My MCU is 3.3V and sensor is 5V. Version for unipolar current is easy to adapt because you have small bias voltage, like 0.5V and it increases with current increase (with defined sensitivity) so when you use sensor with higher current range you can measure it directly and only limit the maximum voltage. With bipolar sensor it will be a little bit more complicated because Vbias=Vcc/2 so you have to scale bias and full range... but I will handle it somehow, I think

Ok, it is not true anymore. I have found new serie of these sensors that is 3.3V compatible  

[IconicPCB]

Trajectory planner is the name of the game.
In absence implement a PID controller with Feed forward path.
Divide the path You wish to traverse into a series od shorter segments.
Treat the overall path as sum of small steps along the path.
This way You can control the profile of the movement by implementing incremental changes in ( PID and Feedforward) positional  SET POINT.

[Siwastaja]

1) Add proper bipolar current sensing. Regenerative braking is still torque ~ current! No need to handle it differently.
2) Sync current sensing to the PWM so you get right average (over the PWM cycle) current reading
3) Tight and fast control loop for current. Typically a PI loop works. Measure the current with scope verifying your loop is stable.

Only after this, start adding on the top.

[krisRaba]

Ok, I have ordered bipolar ACS that outputs 3.3V range signal  so I will be able to use it directly.
My thoughts about current were taken from current configuration which works a little bit weird because there is no headroom in the Vbias to handle reverse currents. Maybe with proper sensor placement it will be obvious ;-)

[capt bullshot]

I have noticed that many exaples use that kind of "phase-correct PWM" and didn't know why. Your explanation about current measurement points put some light and understanding and it corresponds to earlier suggestion that current should be measured twice per PWM period.
But one error that pops up in my head is the current limiting by OCref CLEAR. For Brushed DC it's not so big problem that you will cut the cycle if current exceeds provided limit (comparator with blanking period) but in 3-phase BLDC and sinusoidal driving... but OK, it's not that case now Maybe for BLDC I should use other methods of current control.
So you mean that I should sample current on TOP and BOTTOM, and make an average Ia=(It+Ib)/2?

For 3-phase servos HW overcurrent detection is used for real overload and short circuit detection. Usually such kind of event shuts down the power stage, and some kind of manual restart is required. The current loop keeps the motor current within the operation range normally, there's no cycle-by-cycle current limiting as seen in current mode switchers. I'd expect an DC motor driven by an H-Bridge to operate in a similar way.

Sampling at TOP and BOTTOM provides the average current for each (if done correctly), no need to average them. Usually it's used to virtually double the carrier frequency, since the control loop is executed once at TOP and once at BOTTOM and updates the PWM each time. This is useful for higher voltage / power application where you typically use switching (PWM) frequencies from 2kHz to 16kHz. If your PWM frequency is higher, you should be fine with one update per complete period or less.

STM32 doesn't have internal routing from the QEI decoder to other timers afair, I'd propose to route the encoder signals to additional timer inputs running in edge capture mode.

[Siwastaja]

Motors typically have such high inductance compared to the high switching frequency and high current measurement bandwidth, that current ripple is very small, and it's trivial to tune the current PI loop to react fast and not overshoot. If done like that, "pulse by pulse" limiting is only a safeguard measure against problems during initial PI controller tuning at early stage of development; and a safeguard against some strange edge cases that still slips through the PI loop control; or a short circuit.

Though, even the "pulse by pulse" limit may be too slow to react to the actual short circuit, because the inductance is now bypassed and the protection should be really fast (microsecond range). For cost-cutting, it may make sense to decide not to support safe shorting of the output.

[krisRaba]

STM32 doesn't have internal routing from the QEI decoder to other timers afair, I'd propose to route the encoder signals to additional timer inputs running in edge capture mode.

Today I have found that in F3 serie it is possible in SYSCFG to select ENCODER_MODE bits which will connect TIM15_CH1 and TIM15_CH2 to inputs on TIM2, TIM3 or TIM4. Maybe they are connected in parallel thenand both timers can use them? It would be great. But it has to be tested because I haven't found any information about that option and it is very poorly described in datasheet.
I can't see any related signal input on TIM2/3/4 diagrams so it will be something outside these blocks, I think.

Motors typically have such high inductance compared to the high switching frequency and high current measurement bandwidth, that current ripple is very small, and it's trivial to tune the current PI loop to react fast and not overshoot. If done like that, "pulse by pulse" limiting is only a safeguard measure against problems during initial PI controller tuning at early stage of development; and a safeguard against some strange edge cases that still slips through the PI loop control; or a short circuit.

Though, even the "pulse by pulse" limit may be too slow to react to the actual short circuit, because the inductance is now bypassed and the protection should be really fast (microsecond range). For cost-cutting, it may make sense to decide not to support safe shorting of the output.

I usually use it like that - to limit current when something goes really wrong. But I was also thinking of some kind of hardware regulation where you can write 0xFFFF to OCRx and it will be trimmed by OCrefCLEAR when current reaches setpoint and comparator changes its state. Maybe it is not the best solution But if I recall properly it was used in some document about BLDC 6-step control to limit phase current to desired level. It used external circuitry to filter out noise and after comparator was routed to TIMx_ETR pin. Then ETR was selected as OCrefCLEAR source...
But actually almost everything you need for that is inside the MCU

[jbb]

From past experience with PV inverters, an ‘oh crap’ hardware overcurrent trip is good.

In terms of control rate, it’s easiest from a SW perspective to run everything at the same sample rate. However, you might run out of execution time. So maybe group things together: run the current ADC at twice the PWM frequency, the current (aka torque) and speed loops at the PWM frequency, and the position loop at a lower frequency (maybe 10x lower?).

In the interests of not going crazy, I’d suggest aiming for current bandwidth = PWM frequency / 10, and speed bandwidth = PWM frequency / 100 and position bandwidth <= PWM frequency / 1000.

I’ve found it very handy in the past to set and clear some GPIO pins as the processor makes its way though the code. You can then directly measure execution times with a scope.

Regarding gravity: obviously it’s an issue. You need torque to compensate for gravity, and it will vary with the mechanical load. The Integral part of the speed controller will soak this up. You may find it beneficial to have different +ve and -ve limits. So you don’t accelerate the stage into the floor :-)

[krisRaba]

From past experience with PV inverters, an ‘oh crap’ hardware overcurrent trip is good.

In terms of control rate, it’s easiest from a SW perspective to run everything at the same sample rate. However, you might run out of execution time. So maybe group things together: run the current ADC at twice the PWM frequency, the current (aka torque) and speed loops at the PWM frequency, and the position loop at a lower frequency (maybe 10x lower?).

In the interests of not going crazy, I’d suggest aiming for current bandwidth = PWM frequency / 10, and speed bandwidth = PWM frequency / 100 and position bandwidth <= PWM frequency / 1000.

Thanks for these tips. I will close my current loop soon and then I will try to tweak everything above...

I’ve found it very handy in the past to set and clear some GPIO pins as the processor makes its way though the code. You can then directly measure execution times with a scope.

I use that method too

Regarding gravity: obviously it’s an issue. You need torque to compensate for gravity, and it will vary with the mechanical load. The Integral part of the speed controller will soak this up. You may find it beneficial to have different +ve and -ve limits. So you don’t accelerate the stage into the floor :-)

In new cascade with current loop I hope that it will handle that. My currently used speed loop works ok with symmetric output for PWM. It probably doesn't use full range for DOWN direction but who cares if it knows what to do. But maybe you mean tuning phase... yeah.. everything can happen then

[krisRaba]

So far I have added AUX encoder on motor shaft and results are quite promising. It performes better than on linear encoder only, I think, especially at lower speeds where linear encoder's resolution was too small so only few pulses were counted per sampling period + quantization error caused by sampling period not synchronized to speed and incoming pulses.
But I have also noticed that my speed tracking loop based on linear encoder works surprisingly well and it offers similar speed error amplitude from sample to sample to my new measurement based on AUX encoder in more steady regions. Of course error slightly increases at rapid changes before the loop finds out that something is wrong with estimated value And it lags a little bit... but still is better than raw delta time measurement from linear encoder.

With new measurements I have used just discovered functionality, that I can forward signals from timer in QEI mode (delta time method) to other timer that can count time between edges (delta pos method) :] Delta pos method is better for low speeds, delta time for high speeds so basing on setpoint I use "crossover" speed to decide which measurement should be forwarded to speed variable At the moment it works like a switching point but maybe I should use some kind of proportional change in wider range? I don't know

I have also added bipolar current sensor in series with motor windings but so far I haven't enough time to write code that handles it. I hope to do it soon.

One annoying thing that I noticed is that there is some "fighting" at the end of the move when speed is fading out. It reaches very low speeds, probably hard to measure precisely, so measurement reaches near zero but setpoint is a little bit higher so there is a bump on PWM output to increase speed to setpoint level. Nothing noticeable happens on measurement (time between encoder pulses) so it winds up and bang, new pulse arrives - setpoint exceeded so "stop your horses!" occurs And because of that braking is not perfectly smooth at the end.
I wonder if that planned current loop will help with such things. Current loop will be fast, much faster than speed loop, and current measurements are available each cycle so no need to wait for speed pulse to react. As fas as I understand that, between speed loops there will be a constant current setpoint and current loop will try to handle it. Constant current means constant torque... How it will react to changing friction or other disturbance? With constant torque additional friction will probably slow down the lift and it will have to wait for speed loop that will ask for more current/torque to keep speed setpoint...