# PID control loop exit condition

I'm helping programming a FLL LEGO robot (two motorized wheels and a ballpoint in the back are the contacts with the ground), experimenting with a PID control to make it turn. It may seem overkill, but everything else, including a pure proportional control can't account well for the "not so precise" motors and sensors.

That said, what is a good exiting condition for a PID algorithm? Of course just waiting some time until the oscillation becomes imperceptible is good, but I wonder what the literature has to say, since in my application I need control back to the main program asap to do other things.

My guesses:

• fine tune the number of iterations with the derivative and proportional therms arbitrarily close to the setpoint
• a parallel control loop that "pulls the brake" after the setpoint has been reached a certain number of times (and fine tune it too)

If this is not the right place to ask this question feel free to move it wherever you want.

• Why would you exit PID? In my world it always works. Any higher level algorithm may be built above it.
– user76844
Commented Sep 18, 2017 at 12:30
• You mean to actually keep it working behind, in parallel to everything else the robot is doing? I didn't think about it. Maybe, but our interaction with the motors is pretty high level, so that would mean that, for any other movement the output of this control should be added to every other output needed which adds a lot of complexity but should definitely work. Commented Sep 18, 2017 at 12:33
• Not in parallel. Higher level algorithm produces a command, which is the PID input. PID output is probably voltage or something
– user76844
Commented Sep 18, 2017 at 12:37
• Do you know how a PID is usually implemented in real time systems?
– user76844
Commented Sep 18, 2017 at 12:37
• I think you might not grasp the integral part. This is the sum of all errors over time, which is continuously updated, to have the regulator compensate for errors and lower the oscillation caused by the proportional. For this to work, the regulator has to update on regular basis - it should never "exit". The longer it runs, the better the "I part" becomes. And suppose the regulator error nature changes after running for a while - you'll want the PID to compensate. Commented Sep 18, 2017 at 14:24

A PID algorithm corrects a control signal based on an error, and its goal is to reduce the error to zero.

By 'turning' I understand that you want your robot to move to a required position or to a certain distance. In that case, the error is the distance that the robot has yet to cover, and the control signal could be the PWM duty cycle that power the motorized wheels.

Consider this pseudo-code:

requiredPosition = obtainRequiredPosition();
error = requiredPosition - currentPosition;
while(error <> 0) {
correction = PID(error);
averagePower += correction;
applyPower(averagePower);

// Wait a little: either with a waiting loop
// or, better, implement the whole thing in iterrupts.
wait();

currentPosition = captureCurrentPosition();
error = requiredPosition - position;
};


I don't think you need the integral part of the PID. You don't need your robot to spend an equal amount of time with positive and negative error.

As an example, you would need the integral part to control the helm of a boat: When the boat is heading in a specific direction, you want to compensate the time going too much to the left with an equal time going too much to the right.

• During my robotic course at the university me and my classmates made small cars that used PID regulators to keep the cars in the center of a labyrinth. The integral part was not necessary since there was no constant error pushing the car around in a particular direction. If the labyrinth would have been tilted, say 30 degrees, then the integral part would've been needed. - So you're right. Commented Oct 23, 2017 at 12:54