I’m working on a project with a 1-pole-pair BLDC (24V/40Ohm/0.6A max) motor with hall sensors, running at low speeds (<50 rad/s). No matter what I try, I can’t get it to run smoothly in closed-loop. On the other hand, open-loop control runs perfectly smooth, even down to 1 rad/s with much lower noise.
Fortunately, the motor only runs for short periods, so the tradeoff of lower efficiency for smoother control is worth it. That said, I’d still like to reduce the current draw by dynamically adjusting the motor’s voltage limit. My idea is to monitor the hall sensors for a stall and automatically increase the voltage limit until the stall clears. The driver I’m using (DRV8316C) also supports current sensing, although I have not gotten that to work in combination with the STM32G431. But if current sensing makes this implementation much easier/efficient then I’ll spend some more time trying to make it work.
Has anyone tried something similar? If so, how well did it work? Did it cause jitter when a stall happened, since the voltage feedback system might take some time to react?
Yes, here’s a recent thread where @mwinter and I tried and failed https://community.simplefoc.com/t/speed-limit-on-b-g431b-esc1-with-2212-920kv-motor/6488
@Anthony_Douglas has also tried various strategies without success.
Have you tried SmoothingSensor yet? It’s easy to use. Download the drivers repository and #include SimpleFOCDrivers.h and encoders/smoothing/SmoothingSensor.h, declare it like SmoothingSensor smooth(sensor, motor); and then in setup(), do motor.linkSensor(&smooth); instead of linking the HallSensor directly. It used to be you also had to set smooth.phase_correction for hall sensors, but if you use the dev branch version it’s done automatically now with a specialized constructor.
Current sense would allow you to use the sensorless flux observer, which is what mwinter eventually settled on. It’s tedious to tune the parameters for it, but works well when you only need velocity control.
My hunch was that it was the switching that was the problem. We tried a myriad of ways to make it work. However, I was doing it with the flux observer. I had not tried with an actual sensor. So there might be some hope. One day I would like to try with sensors and see if we can get it to work. Another hunch is that it also had to do with the need to switch the torque controller. Each individually worked completely fine. My original need was super accurate velocity control with the ability to recover from a stall. But I now see other benefits to getting such a switch to work in that you can use open loop to overcome environmental factors that temporarily effect velocity. Only with significant deviation do you switch to a closed loop mode to recover. But yeah, its much less efficient.
Thanks! Were the failures due to the switching between open and closed loop? Or just with open loop?
I have not yet tried SmoothingSensor, will definitely give that a shot the coming days.
Edit: just tried SmoothingSensor, the noise is definitely reduced, smoother, and now goes down to 30 rad/s. Below that it still struggles, so open loop is still necessary unfortunately. Very nice piece of code though.
I’ll try to see how well the dynamic voltage limit will work with open loop. Probably will make the stall detection time threshold be dependent on the target velocity to minimize disturbances. Maybe 3-5 times the expected transition between hall sensor steps will be marked as a stall, which increases the voltage limit in steps of 0.1V or so until it runs again. Will keep you guys updated
@Daan87423 have you tried working with an encoder? I found hall sensors very difficult to run smoothly at low speeds, they just don’t have enough resolution