There is a form  of control equation which is often referred to as PID .  The name refers to the use of Proportional, Integral and Derivative terms in the equations.  And there is a "classic" PID equation block diagram which is shown in the figure below.   This set of equations applies the three PID terms to control of a system using only the error between the system command and a feedback from the systems actual position as an input

.

While many people have used this classic PID block diagram to perform control functions in robotics, it is often not, by itself,  a very good solution to a control problem.  Usually, the user finds it necessary to make some changes to the classic block diagram to get acceptable performance.

In 30 years of working in autopilot design, I never saw a set of control equations that  looked just like the classic PID equations..  

I think that the classic PID equations are a good analytical set of equations.  They work well for linear systems which control to a relatively stable setpoint (or command).  They do not work well for non-linear systems including non-linear input commands such as might be applied to a robot.   I don't think anyone claims that the classic PID layout is an "optimal" solution to any real world problem.

Hence, I'd like to suggest that the three PID terms are tools which you may use (or not use) as necessary to perform control.  

The classic PID terms are designed to do error correction.  Hence, their best use is often to improve the error characteristics of a non-PID system.   

Usually, equations to provide good responsive control to a dynamic command will start out as open-loop equations which make a best estimate of the control necessary to achieve the reference value.  

As an example,  let's design equations to control the speed of a wheel driven robot.   The system will consist of a speed command signal (provided by some navigation software which won't be described here), the control equations,  the motor/robot hardware, and a sensor which measures the actual speed of the robot.  The sensor may be derived from an encoder or a tachometer. 

Drawing of  speed control system.

There are various characteristics of these components which will have to be accommodated by the control equations.

The speed command reference itself has various static and dynamic qualities.  The reference may be able to vary over a limited range (i.e. between zero speed and a maximum speed, or from a maximum reverse speed to a maximum forward speed).   The speed reference may be able to jump directly from one reference value to another (a "step" function...draw examples of each) or the speed reference may have rate limiting on it such that it ramps from one speed to another at a commanded acceleration which may be a constant or a computed variable.  Or, it may have both: normal acceleration and deceleration and "emergency" stop.

The motor and robot will have physical characteristics that the equations will have to deal with.   The motor will have a maximum power which it can provide (represented by a maximum speed and a maximum torque and a varying amount of torque as a function of speed in between.).  The motor and robot combination will have inertia which will determine the acceleration of the motor as torque is applied.  Usually, the power will be applied to the robot with a Pulse Width Modulation system (PWM).  In this case, maximum power will be commanded when the PWM duty cycle reaches 100%.  Hence, this is the power limit.

In a system where all the parts work mathematically perfect, it is possible to compute a duty cycle to achieve any level of speed and acceleration up to the capability of the motor (that is, to a maximum of 100% duty cycle)

Although we seldom know all the mathematically perfect characteristics of our system, we can usually measure them.  For example, the amount of  PWM required to achieve a speed can be determined by applying fixed amounts of PWM to the motor and measuring the speed which the robot actually achieves.  To make this test useful for actual design, you want to run the robot under "normal" conditions.  Perhaps, a flat floor with a rug.   If you run a number of PWM values from 0 to 100%, you will probably get a curve like the following:

Figure of one speed run with 60% pwm and speed varying from 0 to 20 ips. Family of curves?

Figure showing speed versus PWM

If you measure the robots speed from the time the PWM is applied (at zero robot speed), you will normally see the robot's speed increase rapidly at first and then the acceleration slows as the robot approaches it's top speed for that PWM.  The value you want to record is the final value.   The shape of the speed curve is due to the fact that at low speeds, the motor has lots of torque to put into acceleration, and as it approaches its maximum speed, the torque reduces to zero causing an asymptotic capture of the final speed value. 

Note that the curve does not intersect the Y axis at zero when X is zero.  This is because most motors take a certain amount of PWM before they even start to move. 

However, the curve is pretty linear (straight line) and can be used to calculate a gain value for a control equation.   From the figure above, note that over a range to 30 inches per second, the required PWM is 20% + 2 times the desired speed ( e.g. 20 + 2 * 40 ips = 100%, which is what the figure shows is required for 40 ips). 

This equation can be implemented in a block diagram as:

   (draw Block diagram)

and as code:

speedcommand         ' variable in inches per second
PWMcommand        'variable in percent of duty cycle

PWMcommand = 20 + 2 * speedcommand

Now, already we run into a non-linearity which will require special handling.  The equation is capable of generating a PWMcommand value of over 100%.   Hence, it will probably  be necessary to perform some limiting to ensure that this can't  happen. (unless your particular hardware PWM generation can handle commands of over 100%.  Later improvements to the control equations will have additional terms adding into the total PWMcommand, hence, the best place to put the limiter is at the end, after PWMcommand has been computed as show below.

block dgm with PWM limiter.

This equation is the essence of dead-reckoning.   You put out a command which SHOULD achieve the desired result; and then hope that it does work as expected. 

But, if the command is stepped from zero to 40 ips, it may be a few seconds before the robot is actually going 40 ips.  In the meantime, the robot is traveling at some intermediate speed which is unknown (although you could estimate it from the known acceleration curves).  Also, since a 40 ips command will generate a 100% duty cycle,