There is a form  of control equation which is often referred to as PID type.  The name refers to the use of Proportional, Integral and Derivative terms in the equations.

There is also a "classic" PID equation format which is show 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.

While many people have used this classic PID block diagram to perform control functions in robotics, it is seldom a very good solution to the control problem.  And 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 like the classic PID layout; and I don't believe the classic layout could have provided good performance in most cases.

I think that the classic PID layout is a good analytical set of equations.  It works well for Linear systems which control to a relatively stable setpoint (or command).  It does not work well for nonlinear systems including non-linear 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 three 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, the 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).  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.

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 inertial 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)

Since we seldom actually 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 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 value.

Note that the curve does not intersect the Y axis at zero when X is zero.  This is due to the fact that 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 10% + 3 times the desired speed ( e.g. 10 + 3 * 30 ips = 100%, which is what the figure shows is required for 30 ips).

This equation can be implemented in a block diagram as:   (draw Block diagam)

and as code:

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

PWMcommand = 10 + 3 * 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 you try to calculate distance traveled by multiplying the command by time, you will get errors even if your gain was perfect.  And the reason can be seen in figure xx which was the first data you measured of a constant PWM going to a constant speed;  the actual speed is not the same as the commanded speed until some time has passed and the acceleration has gone to zero.