I would like to realize a constant acceleration control of BLDC motor so that its speed can rise from zero to target speed in a predefined time period. I understand that the motor should be able to generate enough torque so that J*dw/dt can be satisfied. Let's assume this condition is fulfilled. To implement this control with a MCU, what I can think of is to use a timer to generate fixed time interval deltaT interrupt, say 10ms, and every time the timer interrupts, the next speed target is calculated using next_speedref = current_speedref + acceleration * deltaT.

My questions are

  1. I can give new speed reference value, but how can I make sure the actual speed can settle to the target value within deltaT?
  2. If I have to use a speed closed-loop control, when acceleration*deltaT is small, which means the speed error going into the PI controller will be small, do I need to set Kp and/or Ki to be big enough to make sure the speed can be reach the target within deltaT?
  3. For industrial motion control, normally how would they realize constant acceleration?
  • \$\begingroup\$ I am not sure constant acceleration is desirable or practical. I'd expect to build up the acceleration at the start of the overall velocity change, and taper off the acceleration to 0 acceleration before the end of the velocity change. Going from constant velocity to constant acceleration, then back to constant velocity instantaneously seems like a bad idea. Also, what is the top speed of rotation, and the type of BLDC? Can you include a link to its datasheet or spec? Am I correct to assume you are building the BLDC controller? \$\endgroup\$ – gbulmer May 7 '16 at 3:16
  • \$\begingroup\$ @gbulmer, what I intended to do is to realize constant acceleration from zero speed to target speed. It is not "from constant velocity to constant acceleration, then back to constant velocity". \$\endgroup\$ – David Lin May 7 '16 at 3:21
  • \$\begingroup\$ I think, going from zero speed to a constant acceleration until it reaches the target speed is even harder because there'll be extra forces involved trying to get it to start moving. So, do you mean a continuously changing (in the mathematical sense too) acceleration, ? I.e smoothly changing acceleration and not constant acceleration? Specifically the velocity at every instant should be a function who's derivatives are continuous? I \$\endgroup\$ – gbulmer May 7 '16 at 3:30
  • \$\begingroup\$ IRC, for example cubic splines could define the velocity at any instant, and the performance of the motor and controller would constrain the possible solutions. \$\endgroup\$ – gbulmer May 7 '16 at 3:35
  • \$\begingroup\$ @gbulmer, if I remember correct, S-Curve is quite common in commercial servo drive, which is to use constant jerk (derivative of acceleration) rather than constant acceleration for smoother motion. In S-Curve control, the acceleration is continuously changing until it reaches the maximum acceleration allowed. I guess using constant acceleration should be easier than S-Curve. \$\endgroup\$ – David Lin May 7 '16 at 3:51


simulate this circuit – Schematic created using CircuitLab

The block diagram is simplified industrial drive position control loop. For your app. you can ommit certain stages, you would neeed current controller PI and velocity controller PI. From your open loop trajectory planner you calculate the velocity according to your formula, then you give a velocity setpoint to the velocity controller.


simulate this circuit

Now if you own a functional BLDC FOC kit, this should be no problem since the current loop and velocity is yet implemented. What you might add is the torque (current) feedforward. As you said \$M=J\alpha+M_{load}\$ we can anticipate the dynamic torque setpoint before the velocity lags the setpoint. So there is a torque feedforward path that forwards the torque setpoint "a priori". \$M_{ffwd}=J\alpha=\frac{d\omega}{dt}J;\; I_{ffwd}=M_{ffwd}*k_i;\; k_i[A/Nm]\$

Since the velocity loop "a posteriori" can't immediately follow the dynamic change in speed, there should be introduced a first order LP filter before the the velocity PI controller (it's ommited in the picture), to delay the action until there is a system response due to the feedforward loop action.

The other thing is a simple trajectory calculator, which calculates a ramp. This should be a recursive algorithm that increments the speed and checks limits each itteration loop. This part doesn't have any feedback from real speed or position, it just computes in open loop. It's all up to regulation loops to follow the speed setpoint.

  • \$\begingroup\$ very nice and clear explanation. Thank you very much. I will try to follow the structure and develop the controller. \$\endgroup\$ – David Lin May 8 '16 at 0:55

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.