Electronics > Projects, Designs, and Technical Stuff
Motion control, S-curves and other stuff >> controlling lift with DC motor
<< < (3/14) > >>
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:

--- Quote from: krisRaba on September 30, 2019, 08:51:09 pm ---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 :-)

--- End quote ---
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:

--- Quote from: jbb on September 30, 2019, 11:21:30 pm ---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??

--- End quote ---
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 ;)


--- Quote from: jbb on September 30, 2019, 11:21:30 pm ---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?

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


--- Quote from: jbb on September 30, 2019, 11:21:30 pm ---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.

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



--- Quote from: Mechatrommer on September 30, 2019, 11:39:31 pm ---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.

--- End quote ---
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


--- Quote from: Mechatrommer on September 30, 2019, 11:39:31 pm ---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.

--- End quote ---
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 ;)


--- Quote from: Someone on September 30, 2019, 11:48:21 pm ---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.

--- End quote ---
Solution already found!  :-+ Link to the formula added above.



--- Quote from: rstofer on October 01, 2019, 02:50:02 am ---'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

--- End quote ---

--- Quote from: Mechatrommer on October 01, 2019, 04:47:37 am ---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.

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

 

--- Quote from: capt bullshot on October 01, 2019, 05:38:46 am ---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()

--- End quote ---
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!  :-+

--- Quote from: capt bullshot on October 01, 2019, 05:38:46 am ---- 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.

--- End quote ---
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  :--


--- Quote from: capt bullshot on October 01, 2019, 05:38:46 am ---Anyway, from my limitied knowledge, having an additional speed encoder, especially when your main encoder is a linear position scale, is rather common.

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


--- Quote from: capt bullshot on October 01, 2019, 05:38:46 am ---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.

--- End quote ---
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 ;)


--- Quote from: capt bullshot on October 01, 2019, 05:38:46 am ---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.

--- End quote ---
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?



--- Quote from: filssavi on October 01, 2019, 05:39:04 am ---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.

--- End quote ---
I will :)

--- Quote from: filssavi on October 01, 2019, 05:39:04 am ---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

--- End quote ---
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?


--- Quote from: filssavi on October 01, 2019, 05:39:04 am ---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),

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

--- Quote from: filssavi on October 01, 2019, 05:39:04 am ---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

--- End quote ---
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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod