1
$\begingroup$

I have here a BLDC motor that is controllable with FOC and I already implemented a position controller. The next step is to implement a velocity controller, but I actually don't see how to control the velocity at very low speeds. The speed is proportional to the reference torque producing current i_d for FOC and so for low speeds, there is only a very low current and so nearly no power. This immediately can be seen, that the motor becomes bumpy for low speeds. The implemented speed controller looks like this and works fine for speeds around 50rpm or higher.

i_q_ref = i_q_ref_old + K_Perr_speed + K_Isum_err_speed

The speed measurement is pretty accurate.

What kind of other control structures can be used to achieve a velocity controller for low speeds with FOC?

$\endgroup$
  • $\begingroup$ Can you identify whether the bumpiness is from the encoder, or from the "cogging" of the rotor? $\endgroup$ – Brian Drummond Jan 30 '17 at 12:30
  • $\begingroup$ It comes from the cogging of the rotor. $\endgroup$ – HansPeterLoft Jan 30 '17 at 13:29
  • $\begingroup$ given a high enough resolution position encoder you can measure the cogging in real time but you may have to brake when the cogging pulls the rotor forwards. You may have to treat it as a stepper motor, and microstep at low speeds. If you have this working for positional control, then see para 1 of jpa's answer. $\endgroup$ – Brian Drummond Jan 30 '17 at 15:15
2
$\begingroup$

If you already have a functional position controller, you can just integrate the target speed to get a target position (which is moving). This should work relatively well for low speeds, but probably not when the motor starts moving a significant fraction of a revolution per control loop iteration.

But I think the underlying problem is probably either latency or inaccuracy in the speed measurement. I assume it comes from some kind of encoder? At low speeds, it can take a long time for the motor to move to the next encoder tick, thus the velocity change is not immediately visible to the controller. And if you don't have any smoothing on the velocity reading, it can render PID D-term quite ineffective; and if you add smoothing, it will increase the latency.

One way to increase the speed of the feedback loop is to form some kind of a feed-forward system. Consider having a Kalman filter with state variables (velocity, inertia, external_torque). Then you can update that Kalman filter by both your velocity measurements when you get them, and more often by torque values that you drive to the motor.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Ok, to calculate trajectories was also what I thought makes the most sence. The speed estimation comes from an encoder and the resolution is actually not bad. So I think I'm gonna use the speed controller for high speeds and the trajectory calculation for low speeds. I think I don't have enough computational resources to use a Kalman filter, but it's actually a good idea. $\endgroup$ – HansPeterLoft Jan 30 '17 at 11:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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