Driving a motor with constant torque for any (low) speed

[robca]

I'm thinking of building an exercise machine to see if this works https://onlinelibrary.wiley.com/doi/abs/10.1111/sms.14220. An exercise machine that can provide constant torque when needed for an eccentric movement, then moved back to the starting position with no effort.

Basically, I need a motor that when powered on will exert a constant torque at stall speed, then maintain that same torque while slowly pulling and winding a rope (and the user resisting the force and slowly moving along). Turn it off, move the handle in the starting position again, re-engage the motor to repeat the same movement as above. The amount of torque will depend on the gearing of the machine and various levers, still all TBD.

I have very limited experience driving BLDC motors and stepper motor, none driving AC or DC motors with encoders. I'm assuming I will need some sort of encoder in addition to the motor drivers, and microprocessor controls. I can handle that part without problems, once I get some pointers on where to start.

How can I start building a simple prototype to help me get a sense of the challenge? What kind of motor would work best? Any example or motor driver datasheet I can use a a starting point?

[max_torque]

The torque of an electric motor is directly proportional (within saturation limits) to the phase current

The speed of an electric motor is directly proportional (below base speed) to the back emf phase voltage

The current that is driven through a phase is controlled by the difference between the applied forward voltage and the back emf, divided by the phase impedance (dc resistance + inductance)


What this means is that to maintain a constant torque from zero to "x" rpm requires your motor controller to apply a constant forwards voltage that is just higher (for positive torque ie driving) or just lower (for negative torque ie regeneration) that the backemf as that speed changes.


For example, in easy units to show working

assume your motor has a torque co-efficient of 1Nm per amp
assume you motor has a speed co-efficient of 1volt per rpm
assume your motor has 1ohm impedance

assume we want 1Nm of torque at all speeds:

at zero speed

back emf = (0 rpm x 1V/rpm) = 0
apply 1 v forward voltage, current = (1vfwd - 0vbemf) * 1Nm/A = 1 Nm


at 100 rpm

back emf = (100 rpm x 1V/rpm) = 100v
apply 101 vfwd and current = (101vfwd - 100vbemf) * 1Nm/A = 1Nm



In your case however, you can't just control torque, because if you have a motor controller apply 1Nm, the motor will simply accelerate to max speed when unloaded!
I pretty much all cases motor controllers control torque (phase current) as their primary (inner) control loop and then control velocity and/or position in control loops that sit around the inner torque control loop.

You need to consider exactly what you load looks like to be able to make these descisons.  In any case, simply using some off-the-shellf motor controller, like an "O-drive" is my suggested method to get you up and running as quickly as possible (making your own motor controller is one of those projects that sounds fairly simple but really isn't......)

[Siwastaja]

Torque under your control (with limited accuracy of course) is easy, because the torque produced is directly proportional to current, and current control is what every properly designed motor controller must start with, anyway. Just implement the current control as usual. If you don't need speed regulation, then one less thing to do.

What this "as usual" is? Implementing BLDC FOC from scratch is quite some work, though. It's really simple once you grok the idea, but it takes some time in the rabbit hole of confusing information. If you want it easier, start with brushed DC motor which abstracts away some of the math at mechanical level.

The basics are the same: control the voltage applied to the motor windings with a MOSFET halfbridge(s) (one for unidirectional brushed, two for bidirectional brushed, three for BLDC), allowing you to apply Vcc or GND to each of the wires. Measure motor current (for example, with a shunt resistor in series with the lower leg of the MOSFET, sampled by ADC while the bottom MOSFET is conducting (microcontrollers offer such synchronization possibilities in hardware)), compare to your current setpoint value using a PI feedback loop which outputs the PWM duty cycle. If current is lower than it should be, the control loops increase the duty ratio, applying higher average voltage to the motor, making the current increase. And vice versa. This PI loop is not that critical or difficult to tune. Motor current is a nice triangle wave which increases when the full supply voltage is applied and decreases when the motor is "shorted".

If you use a BLDC (AC permanent magnet motor), all of that applies, but the differences are: instead of one current, you have three, so you would measure two of the phase currents and calculate the third (from the fact that sum is zero). Then you do a bit of extra math: apply 3-axis-to-2-axis transformation to the current measurements (get 2D vector out of 3 values), then apply 2D vector rotation in sync with the measured* rotor position so that you have "stationary" current measurement just like you did with the DC motor, then apply the same PI loop to that stationary value, outputting stationary PWM duty cycle value, which you again make rotate by the opposite 2D vector rotation, 2-axis-to-3-axis transformation, then apply to the MOSFET stages. Basically you have to rotate both the measurement and outputs in software, because you don't have the mechanical brushes which do this on a classic DC machine.

*) approximating it with algorithms instead of measuring makes the problem harder again, and is inferior at low speeds, so measure if at all possible

[robca]

Thanks for the replies. that got me started looking and narrowing down my options, but not enough to actually think about a shopping list.

I definitely don't want to build a driver board, nor develop fully custom software. In the past, i looked at the ST Micro FOC libraries and boards to get a sense of what's available. And I know of https://simplefoc.com/. VESC is frequently mentioned but seems more targeted towards e-bikes, scooters, etc.

ST also seems to have a lot of boards with integrated STM32 to drive BLDC using their software (that includes a GUI) https://www.st.com/en/evaluation-tools/steval-spin3202.html, or https://www.st.com/en/evaluation-tools/steval-spin3201.html and lots more https://www.st.com/en/evaluation-tools/3-phase-motors-pmsm-bldc-acim/products.html

Pretty much any way I go, though, it's going to be an investment in time and money. And before starting to spend money, I'd like to know that what I want to do is at least feasible with what I buy. I now that I might discover I need a more powerful driver and invest more, but that might also be solved in my case with more gears

Would something like one of the ST boards allow me to drive a motor at near stall speeds with constant torque? Any other board worth buying? I have plenty of Arduino, STM32, ESP32, etc boards, so even a cheap-ish Aliexpress driver board with the right kind of hardware would do (if I knew what to get, that is ). I also have a few brushless motors of different kV and sizes I can start playing with.

I'm getting lost in all the options even just for BDLC controllers: 6 step vs FOC, 1 vs 3 shunt resistors, etc... and what type of motor to use. If I had a starting point (driver board, BLDC motor, for example), I'd feel a lot better

Right now, some of the best options seem to be one of the ST eval boards that piggyback on the Nucleo connector, or a ~$30 DRV8302 from Aliexpress plus one of my existing motors.

Am I on the right track?

[geggi1]

If you are goibg to use off the shelfe components you could look into VFD and an industrial 3 phase motor.
In some VFDs it is possible to set constant tourque parameters.

[Siwastaja]

You want FOC, not "6-step" although those usually come with some kinds of current limiting, too. But FOC, when correctly implemented, has well-defined current you can exactly adjust. If you pick an existing FOC library/solution, then you just set Id=0 and Iq to your desired torque.

Just the BLDC FOC itself is very simple. Any complexity is in additional things like speed regulation control loop and maybe automagic parameter tuning. Or phase angle estimation algorithms. You don't need any of that.

Note that when you want well defined constant torque at low speeds, then rotor angle approximation algorithms go out of window. You need real, physical position sensing! Now many/most BLDC motors come with hall sensors, which give you 6 steps per electrical rotation, i.e. 60 electrical-degree angular resolution. This means, if you use hall sensors to rotate the vectors in FOC, you have an error which varies between -30 .. +30 degrees (and suddenly jumps between +30/-30). This results in some quite significant torque ripple. You would need to test in practice to decide if it's too much for you. If it is, you need a higher resolution position encoder attached to the motor. (I have had decent results using hall sensors and interpolating sub-position in software, but this obviously cannot work at very low speeds or varying mechanical loads.)

[robca]

Note that when you want well defined constant torque at low speeds, then rotor angle approximation algorithms go out of window. You need real, physical position sensing! Now many/most BLDC motors come with hall sensors, which give you 6 steps per electrical rotation, i.e. 60 electrical-degree angular resolution. This means, if you use hall sensors to rotate the vectors in FOC, you have an error which varies between -30 .. +30 degrees (and suddenly jumps between +30/-30). This results in some quite significant torque ripple. You would need to test in practice to decide if it's too much for you. If it is, you need a higher resolution position encoder attached to the motor. (I have had decent results using hall sensors and interpolating sub-position in software, but this obviously cannot work at very low speeds or varying mechanical loads.)

Thanks again. Yes, I'm familiar with the issues you mention (from the gimbal experiments), and I plan to use either an optical or hall sensor encoder with high enough resolution (>1000 steps/rotation). SimpleFOC and the ST solutions all include support for multiple types of encoders

I also got the documentation and schematic for the cheap DRV8302 Aliexpress boards, which I'm including here just in case (I did not see it anywhere else), in case someone else bumps into this thread

[max_torque]

If you just want it "to work" with minimum effort then these are my go-to solution these days:

https://odriverobotics.com/


certainly not the cheapest, but ime they work, are robust, are pretty easy to set up and abstract away a lot of the more complex details if you are not interested whilst remaining flexible enough to implement realitively clever control architectures in all primary domains (torque, velocity & position)

They will drive a range of different motors and plenty of web info (inc you-tube for you visual learners... ;-)  is out there!

[robca]

Yes, I have looked at odrive, based on another suggestion earlier in the thread. Definitely an ideal solution for a turnkey solution.

But it's closed source and a black box. I looked at their configuration GUI and it's rather convoluted and will have a learning curve, no matter what. For roughly $180 I would have almost everything I need, minus the motor.

Part of me wonders, though, if I should take the time to learn about FOC and use one of the existing open source solutions like SimpleFOC or the ST framework which, even if not open source, it makes the source code available and modifiable. Definitely this latter option would never pay off if I valued my time at more than 0

[Siwastaja]

Part of me wonders, though, if I should take the time to learn about FOC and use one of the existing open source solutions like SimpleFOC or the ST framework which, even if not open source, it makes the source code available and modifiable. Definitely this latter option would never pay off if I valued my time at more than 0

For the FOC alone - yes you can learn it pretty easily. Or lets' say, you will spend some time in a rabbit hole, and in retrospect laugh at the stupid simplicity of it. Probably easier if you don't look at any source code or frameworks, as they deal a lot with setting up the framework, hardware abstraction and support for different hardware, other algorithmic stuff (like rotor angle estimators, speed control loops, autotuning of feedback loops, communication, etc.), and a lot of boilerplate and bloat which is inevitable when trying to write a generic solution.

FOC alone is nothing more than this: calculate the third phase current, Clarke transform the currents (from weird 3-axis 2D to more understandable 2-axis 2D), 2D vector rotation to always make the measured current appear in the same direction regardless of rotor position, two PI control loops for the two currents (x and y axis), 2D vector rotation of PWM outputs in the opposite direction to what we did earlier, then inverse Clarke transform to that weird 3-axis 2D thing again, producing 3 PWM outputs. Rest is hardware details like how to configure the microcontroller PWM timers, how to set up an overcurrent signal to stop the PWM (so that you don't blow up MOSFETs when trying to tune the PI loops) and so on.

I an attempt to demystify all of this, I absolutely refuse to call bog-standard 2D vector rotation (familiar to me since kid from computer graphics) a "Park transform" just because some Park guy thought they can own a well-known formula by introducing it in a specific (motor control) context. Similarly, I won't even mention Space Vector Modulation since no microcontroller I have ever seen come with Space Vector Modulator hardware but do come with good old PWM-generating timers everyone knows how to use. For example, STM32 series comes with Advanced Control Timers marketed specifically for controlling BLDC motors, yet for some reason you should just ignore this and use an FPGA or something to implement some space vector modulation stuff. Rationale for that shit? One does not need to do "computationally heavy" inverse Clarke transform. Maybe this (two multiplications, two additions, two bitshifts) was computationally heavy in 1970's, I don't know, but I don't know how they then dealt with the rest of the math, which is >90%.