The basics of doing PID design: Part 1 - Classical control theory

In each case there is a master plan, and then separate plans for each component. An athlete has a script for each limb, the general for each command, and so forth. All of these plans must be kept in synchronization.

Controlling a robot or other complex intelligent machine requires that it have a plan or model of what it expects to accomplish. Like all such plans, it is quite likely to require modification within moments of the beginning of its execution, but it is still essential.

Like the commander or executive who must modify a plan to allow for changing situations, a robot must also be able to modify its plan smoothly, continuously, and on the fly. If circumstances cause one part of the plan to be modified, then the plans for all other parts must be capable of adjusting to this.

For the plan to have any meaning, physical hardware will need to track to the plan to the best of its ability. Thus we trespass into the fiefdom of Controls. This subject is deep and broad, and engineers spend their entire careers mastering it.

In short, it is a great subject to trample on. The fact is that it is quite possible to create decent controls for most applications using little more than common sense algorithms.

The purpose of a control system is to compare the plan to reality, and to issue commands to the servos or other output devices to make reality follow the plan. The desired position of the robot or one of its servos is often referred to as the rabbit and the position of the actual robot or servo is referred to as the hound.

This terminology comes from the dog racing business, where a mechanical rabbit is driven down the track ahead of the pack of racing canines. A closed loop system is one that measures the error between the rabbit and hound, and attempts to minimize the gap without becoming erratic.

Classical control theory has been in existence for a very long time. Engineering courses have traditionally taught mathematical techniques involving poles and zeros and very abstract mathematics that beautifully describe the conditions under which a control can be designed with optimal performance.

Normally, this involves producing a control system that maintains the fastest possible response to changing input functions without becoming underdamped (getting the jitters).

It is perhaps fortunate that the professor who taught me this discipline has long ago passed from this plane of existence, else he would most probably be induced to cause me to do so were he to read what I am about to say.

Control theory, as it was taught to me, obsessed over the response of a system to a step input. Creating a control that can respond to such an input quickly and without overshooting is indeed difficult.

Looking back, I am reminded of the old joke where the patient lifts his arm over his head and complains to the doctor, "It hurts when I do this, Doc," to which the doctor replies, "Then don't do that."

With software controls, the first rule is never to command a control to move in a way it clearly cannot track.

If you studied calculus, you know that position is the integral of velocity, velocity is the integral of acceleration, and acceleration is the integral of jerk. Calculus involves determining the effect of these parameters upon each other at some future time.

In real-time controls this type of prediction is not generally needed. Instead, we simply divide time into small chunks, accumulating the jerk to provide the acceleration, and accumulating the acceleration to provide the velocity, etc.

This set of calculations moves the rabbit, and if all of these parameters are kept within the capability of the hardware, a control can be produced that will track the rabbit.

Furthermore, the operator who controls the "rabbit" at a dog race makes sure that the hounds cannot pass the rabbit, and that it never gets too far ahead of them. Similarly, our software rabbit should adjust its acceleration if the servo lags too far behind.

A common problem with applying standard control theory is that the required parameters are often either unknown at design time, or are subject to change during operation.

For example, the inertia of a robot as seen at the drive motor has many components. These might include the rotational inertia of the motor's rotor, the inertia of gears and shafts, rotational inertia of its tires, the robot's empty weight, and its payload. Worse yet, there elements between these components, such as bearings, shafts, and belts that may have spring constants and friction loads.

Notwithstanding the wondrous advances in CAD (computer aided design) systems, dynamically modeling such highly complex systems reliably is often impractical because of the many variables and unknowns. For this reason, when most engineers are confronted with such a task, they seek to find simpler techniques.