I'm working in a wheeled robot where each BLDC motor is controlled by a driver. These drivers are designed by ourselves and are working fine, they use Hall sensors and encoders for speed feedback loop, and also current sensing for current control, so stalling is not a problem. Despite this, we have find out that when a wheel gets suddenly stuck (most of the time for pressing against a wall) the current in the motor rises and triggers the overcurrent protection. This current peak is so severe that it causes a voltage drop across the robot, causing lots of different problems.

I'm pretty confident that the reason for this problem is that when the wheel gets suddenly stalled, the current rise is too fast for the control loop (a PID implemented in a microcontroller) in our driver because again, if the stalling is not instantaneous the driver correctly lowers the PWM duty cycle and keeps a correct current. This current peak also surpasses our power supply rating, and causes the voltage drop across the system.

I have been searching online and I have not found anyone with the same problem. I believe a solution would be to lower the overcurrent protection threshold, that is currently three times the nominal current, but my superiors don't like this proposal because the overcurrent triggering is too disruptive for the robot operation. Another idea is to increase the size of the driver power input capacitors, and use their accumulated energy for the peak. This wouldn't solve the problem, but would prevent it from causing the voltage drop. Another idea I proposed my superiors was to add some torsion flexibility to the wheels or axis to make the stalling more progressive, but they want it solved without touching the mechanical aspect. Another option is to limit the max current in the firmware so that when the motor stalls it doesn't go so high, but we cannot afford to lower the maximum torque.

I'm completely stuck with this problem. Does my theory of the problem origin make sense? Has anyone found anything like this? Is there anyway that I could solve this without disrupting operation, ideally limiting the motor current?

  • \$\begingroup\$ What's the current control loop iteration time/frequency? What's the PWM frequency? My first instinct is to get oscilloscope traces of the current feedback signal and the PWM waveforms and iterate on the motor drive software. It might be as simple as increasing the current sampling rate by 5x. You might also need to do anomaly detection and immidiate response in the current control loop (IE:check ADC sample isn't too high and immidiately cut PWM if it is). TL:DR expect extra complexity in the motor driver code. \$\endgroup\$ Jun 12, 2023 at 13:59
  • \$\begingroup\$ If a feeble supply can't cope with stalled motor(s), how do you manage to accelerate from a stop without causing similar problems? \$\endgroup\$
    – glen_geek
    Jun 12, 2023 at 14:12
  • \$\begingroup\$ You need to let the motor coast on a flywheel and suddenly brake it to see whether it is overcurrent (stall) or overvoltage (flyback). You can also place RC snubbers to see if it alleviates the issue. \$\endgroup\$
    – DKNguyen
    Jun 12, 2023 at 14:25
  • \$\begingroup\$ You say that "Another option is to limit the max current in the firmware" which implies that firmware is already fast enough to react to over-current. That suggests you just need to improve the PID loop or supplement it to catch and respond to mild over-current events. \$\endgroup\$ Jun 12, 2023 at 14:26
  • \$\begingroup\$ It sounds as if there's some digital filtering going on before the data reaches the PID loop, and the delay from that filtering slows down the response too much, while the overcurrent protection works on raw data with no delay. Solution: have two current limits acting on raw data. One is the safety setting you already have, which has to be high to allow high torque. The other is set by the PID loop, and clamps these sudden spikes. The control loop can take its sweet time deciding where the soft limit should be, as long as that limit acts without delay. \$\endgroup\$
    – Ben Voigt
    Jun 12, 2023 at 15:34

1 Answer 1


I'm pretty confident that the reason for this problem is that when the wheel gets suddenly stalled, the current rise is too fast for the control loop

That is correct. But that also means that your current control loop is way too slow. Typically those control loops are analog and have high bandwidths. The control loop needs to have bandwidth a couple times wider than indicated by the RL time constant of the motor winding.

I have a few fractional hp BLDC servos on my desk. The current control loops run on an FPGA and have 10MHz sample rates. There is no duty cycle control per se: the control loop maintains a set current by turning the switches on and off as the current passes the thresholds set by the set current ripple amplitude. It's a cycle-by-cycle control, and the FPGA is constantly monitoring that the current behaves in expected fashion, i.e. that it is a ramp. The control loop can deal with hard short circuits on the output without overstressing the rest of the circuit. Time from short circuit to load disconnection is about 150ns, a bit more when the short circuit is at the end of long motor power cables, a bit less when it's on the servo power PCB.

I have been searching online and I have not found anyone with the same problem.

That's because the current control loops are usually designed to be fast. How fast is the one you've implemented? What's the sampling rate?

I believe a solution would be to lower the overcurrent protection threshold

Absolutely not. That threshold is only supposed to be hit when there's a short circuit somewhere!

I'd start by ensuring that the current control loop has let's say 50kHz bandwidth. That's a reasonable ballpark without knowing what sort of power levels and winding inductances you're working with.

  • \$\begingroup\$ Thank you for your fast response. I realize now that I left out a lot of important information In my question. We are using a heavily modified version of MCSDK, a SDK for motor control supplied by ST. I followed your advise to increase the frequency of the loop. If anyone has the same problem with slow control in MCSDK: \$\endgroup\$ Jun 16, 2023 at 9:49
  • \$\begingroup\$ [Sorry first time here, sent by mistake] Our feedback loop updates every time the phase current reading conversions end, so the frequency can be increased by reducing the sampling time, and by checking if you are using your ADCs in an efficient way (in our case we were using only one of three). After implementing these changes, the problem has not completely disappeared but is much less frequent, Thank you Kuba and everyone who commented to help me. \$\endgroup\$ Jun 16, 2023 at 9:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.