So will my solution, and it won't require modifying the PID library. It's just not the correct solution.Īnd it will also allow the PID to be smart enough to take the shortest path, knowing that sometimes going CCW will be shorter than CW, and vice-versa. I'm not saying your solution is wrong, because it's not. Nothing you wrote in the previous section supports this assertion, since the problem of step change response is completely different than the problem of wrap-around discontinuity, and will have a completely different solution. It is perhaps the worst possible solution.įixing the PID Compute function to correctly handle the encoder wrap-around is not terribly difficult, and is the only correct solution, If you are already close to the setpoint, you want it to move smoothly to the setpoint, and not suddenly go foot-to-the-floor, which will cause it to over-shoot, and most likely oscillate wildly, back and forth over the point where you inject that step change. If you really WANT it to move quickly to a new position far away, that is the correct thing to do. Fixing the PID Compute function to correctly handle the encoder wrap-around is not terribly difficult, and is the only correct solution, and it will also allow the PID to be smart enough to take the shortest path, knowing that sometimes going CCW will be shorter than CW, and vice-versa.Īnd what happens when you give a PID a large step change in setpoint? It reacts STRONGLY, commanding a maximum-effort move. It is perhaps the worst possible solution.

At worst, the D term will provide an extra, very brief pulse of output with my solution, unless there's something extra in the standard PID library that handles setpoint changes that I'm not aware of.Īnd what happens when you give a PID a large step change in setpoint? It reacts STRONGLY, commanding a maximum-effort move.

Mostly the same as a step change in setpoint, I would think. Therefore, even 1 degree overshoot cause the error value is -359 (set point - now position) and the motor rotate again to reach the desired position. Motor rotation is slowing down as its 'now' position approaching 0 degree, but the system is not overshoot free. I know the problem is due to a little position overshoot cause the encoder to read a very large error.įor instance, if the setpoint is 0 degree, the motor rotate to reach it. But when it is not, the motor never stop rotating. When the set point is a value between 10 - 350 the sytem worked well. FOR READING ENCODER POSITION, GIVING 0-359 OUTPUT CORRESPOND TO THE ENCODER POSITION PID myPID(&input, &output, &setpoint, kp, ki, kd, DIRECT) ĪnalogWrite(RPWM, out) //Sets speed variable via PWMĪnalogWrite(LPWM, abs(out)) //Sets speed variable via PWM The used code: #include īyte input_pin = ĭouble input = 0, output = 0, setpoint = 0 The motor cannot stop at set point value near 0 degree (350 - 359, 0 - 10 degree).

The system contain a dc motor, absolute encoder, and a motor driver.Įverything work as expected, but one thing. I'm doing a control engineering project, implementing a PID motor position control for automatic antenna tracking system.

Position control of a dc motor arduino