Hi… Are there any news on Back-EMF based Simple-FOC develoment? Will it be available some day? Or it’s not in the roadmap?
User @Anthony_Douglas have been trying to achieve that… and it seems it’s difficult to implement…
Regards, Rodrigo
Hi,
It’s on the roadmap 
but since BEMF based commutation is not actually FOC, it isn’t the main priority for the library. So there are other things to do with FOC based control that we are working on first.
An intermediate step might be to implement 6-step commutation based on Hall Sensor inputs, and then extend this to use a “BEMF detector” as input instead.
The challenge is more in the pumbing (low level code), since there are different ways to implement this BEMF detection in hardware, and the solution could look quite different depending on, for example, if you are using comparators or the MCUs ADC.
Keep in mind that unlike FOC, where solutions tend to be harder to find and expensive, BEMF-based ESCs are cheap and easy to find from the RC drone world. There are open source variants (BL-Heli, SimonK, and probably others) and so the community is already quite well served with these products…
I know… but sadly for my case none of them works… I need 30-40V as Input, lower current (3-5A output) . Don’t need the bells and whistles that drone escs do… Higher voltage ESCs are really expensive when are rated to more than 30V …
Benjamin’s Vedder ESC also has a limit ERPM, and from what I read, doesn’t allow 40K RPM as max…
If there was one that accepts higher voltage, lower currents, outputs RPM for PID, programmable to work as not being a Drone ESC, I could try!
Yeah, its often hard to find parts when the specifications aren’t in the “sweet spot”…
I have to say though, 40kRPM is really a lot. I doubt very much SimpleFOC can manage it with FOC control. And I think even with BEMF based control you will need a highly optimised system to reach such speeds. That’s a speed for a CNC spindle or dental drill… why do you need to go so fast?
Indeed is my dental driller! I’m trying to recreate it’s driver.
In fact, using the code from Simple-Circuit, and the DRV8302 aliexpress board, I managed to run the motor to 47KRPM at 33V (it’s rated to 36V-50KRPM), using an external comparator (arduino’s internal MUX ADC didn’t work so well in my case…) just like in the diagram from Simple-Circuit, to read Back-EMF.
I just changed his code to Fast_PWM at 61.5KHz on an arduino Nano, instead of the 31Khz.
The board performs really well, and the motor runs silent, no vibration at all, no heating. But I’m struggling to get to lower speeds than 5K… (I need 5% of the PWM)… I need to go to as low as stable 2K RPM and perform speed PID. I wanted Simple-FOC to deal with the low speeds only…
Ah, I understand now…
Well, this makes sense, although 2K-5K RPM still isn’t so slow for SimpleFOC but I think this will be possible.
The faster your MCU, the faster you’ll be able to turn the motor in this kind of setup, so I would advise looking at one of the faster 32bit Arduinos like the Nano33s, or even a Nucleo 32 board if you like the Nano form-factor.
But I think your core problem will remain: having to work with <5% duty cycle makes the control more difficult, all the more so if PWM frequency is 61kHz… so you could experiment with adaptive PWM (its a thing ) where you lower the PWM frequency to give yourself more range to work with on the low duty cycles.
Another idea to try is an adjustable PSU - using a switch mode DC-DC converter on the VS input path would allow you to regulate the voltage. I don’t know how much power your motor draws, but you can buy or implement reasonably sized switch mode power supplies up to 10A or so. If you have space, they can do a lot more, of course
Using an adjustable DC-DC converter and a digital potentiometer or something like this you could implement a variable DC supply scheme to reduce the motor voltage at low RPMs, allowing you to use higher duty cycles.
These are just some ideas.
Probably better to just try it on a fast MCU first, and see how it goes. You may not even need any special extras.
1 Like
I have read up quite a bit on this subject. BEMF is a specific term that is used as Runger is using it, it applies to 6 step commutation, in which one of the phases is actually not even used for part of the rotation. This is distinct and not FOC.
The exact definition of FOC is apparently significantly slippery, as you learn more you see there is a whole spectrum. However continuously powering the device with a waveform that affects all 3 phases is definitely part of the picture.
There are quite a number of approaches to do true FOC based sensorless commutation, but mostly you watch the current waveform, which is affected by the back emf, but not the same thing. Fundamentally, you are modelling the system and going backwards from the drive voltage waveform, and the current waveform, to compute the adjusted voltage waveform. As you can see, they interact significantly.
There is also an approach called IPD in which short pulses are used and the waveform watched, which can work even if the motor isn’t even moving.
It does in a way seem difficult to implement, but again I would like to say that once the math and programming is understood, I think it will be considered totally doable. Luenberg observers appear to be the most common and standard approach. I think that’s the first one that should be investigated by anyone trying to make a system that fits in with the simpleFOC picture.
To be fair, even the pros clearly have difficulty with this as I have tried 9 different pre-made sensorless drives, and they all couldn’t hack it for one reason or another. I did a consultation with one of the guys from texas instruments to try to figure out why their relatively good MCF8316A driver couldn’t hack it. The bottom line is they haven’t figure the whole business out yet. So yes it is difficult.
After my experiments, I do believe that current optimization has hope, but the hardware has to be designed for it, to give a clean, responsive current signal. It should work relatively well at high speed, at least. However the stalling issue I have no answer for at present, I believe the system could be combined with the luenberg observer as it basically models the motor physics and track things. You dont have to be able to handle any situation, you only have to respond as fast as the motor speed changes, which is limited by inertia.
1 Like
Great!
I’ve got no problem in turning the motor, even at 47K RPM in the Nano… but, if a better CPU is needed, could than an ESP32 be used then?
I’m reading about lowering the frequency at the lower end… Do you have any info, or direction on where to look for adaptive PWM?
I did exactly this, but in a ready-made chinese driver. I managed to go lower than 5K by lowering the Voltage from 33V to 18V. But as the internal code (in the chinese driver) was not done to fast speed transitions, I coundn’t mantain high torque at low speeds even with PID.
But in my dev DRV8302 board I’m not being able so far to do it. I lower the voltage but in the end, I get to the same min speed, but with higher duty cycle… So far… Have to try more…
Thanks!