Proportional-Integral-Derivative (PID) Controller

PID Intro:

The heart of any real control system has a feedback controller.  When the system’s process is unknown or hard to model, a Proportional-Integral-Derivative (PID) controller is an efficient method for control.  If the system’s process is known, a custom controller will yield higher efficiency.  However, modeling complex systems in attempt to design a custom controller may result in a much higher development time and cost than can be afforded.  In both cases, a PID controller is a very efficient method for controlling all types of systems.

thanks to wikipedia.org for the diagram

PID Theory:

PID controllers can be understood(partially) without an in depth lecture on control theory. PID controllers use 3 sub-controllers combined into 1 controller using a simple sum. The 3 controllers are:

  • Proportional:
    The proportional section of a PID controller is a basic intuitive approach to feedback control. A naive approach to feedback control would say, the farther away from perfect the system is, the more it should work to get perfect. In a perfect world without friction, momentum, etc., this system alone would work great! This is proportional control. However, our world is imperfect and we need to add smarter feedback compensation.
  • Integral:
    The integral section of a PID controller compensates environment imperfections such as friction, wind, and other such imperfections that would resist the system to reach its perfect state. An integral controller works by keeping a sum of all the error the system has seen. In calculus, this is equivalent to the area underneath the curve up to the current point. The controller increases its control signal as the summed error gets larger.
  • Derivative:
    The derivative section of a PID controller compensates environment imperfections such as momentum which causes the system to overshoot its perfect state. The derivative controller lessens its control signal as the speed in which it is achieving its perfect state increases. In calculus, this is the slope of the error signal.

Example:

Let’s consider an example to show how a PID controller could be used. Our example will be an airborne GPS navigation system in a helicopter. The aircraft knows where it is and where it is being told to be. Using basic subtraction, it can figure out the distance to the desired location. This is the error signal. It indicates how far from perfect it is.

Lets say that the PID controller is controlling the forward thrust of the helicopter and that the direction is automatically set by something else (in other words, the helicopter always points the direction it should).

The proportional controller would just set the thrust according to the distance away from the target location. This is a simple approach but most likely will not work by itself. As the helicopter gains momentum, it will become harder to slow down. Using proportional control only, the helicopter will overshoot its target and possibly oscillate around the target location. Another issue is wind. The thrust controller should compensate for wind because a tail wind could cause an positional overshoot and a head wind might cause it to never get there.

The integral controller continues to sum the error it incurs and adjusts appropriately. In the head wind example, the thrust would increase until the aircraft could reach its target destination.

The derivative controller measures the speed in which the error signal is changing, which for the helicopter is simply the relative ground velocity. As the helicopter approaches its destination the derivative controller reduces the thrust allowing the helicopter not to overshoot its target position. In the event of tail wind, it reduces the thurst even more so that it can’t be pushed past the target.

For the helicopter example, all 3 sub-controllers must be used. To use all of them, you just sum the control signals of all 3.

Implementation:

If you think this sounds hard to implement, you are wrong. PID controllers were designed to be generic and easily adapted to all systems. As mentioned before, PID controllers have 3 sub-controllers. Each controller has a parameter that must be tuned, called ‘gain’. To add a PID controller to a system, you just need to attach the generic PID controller and tune the 3 values.

The following C code is an efficient PID controller.

typedef struct {
    double windup_guard;
    double proportional_gain;
    double integral_gain;
    double derivative_gain;
    double prev_error;
    double int_error;
    double control;
} PID;

void pid_zeroize(PID* pid) {
    // set prev and integrated error to zero
    pid->prev_error = 0;
    pid->int_error = 0;
}

void pid_update(PID* pid, double curr_error, double dt) {
    double diff;
    double p_term;
    double i_term;
    double d_term;

    // integration with windup guarding
    pid->int_error += (curr_error * dt);
    if (pid->int_error < -(pid->windup_guard))
        pid->int_error = -(pid->windup_guard);
    else if (pid->int_error > pid->windup_guard)
        pid->int_error = pid->windup_guard;

    // differentiation
    diff = ((curr_error - pid->prev_error) / dt);

    // scaling
    p_term = (pid->proportional_gain * curr_error);
    i_term = (pid->integral_gain     * pid->int_error);
    d_term = (pid->derivative_gain   * diff);

    // summation of terms
    pid->control = p_term + i_term + d_term;

    // save current error as previous error for next iteration
    pid->prev_error = curr_error;
}

Windup Guard:

As you may have noticed, the code has a feature called windup guard. This is a critical feature that must be used in most control systems. Windup guarding is simply just setting a cap on the maximum value that the integrated error can be. This is typically most needed for startup conditions and situations for switching in and out of control. Let’s look at our helicopter example again. Consider the situation where the helicopter can be piloted by a person or the PID autonomous controller. If the human operator had a target destination only a few feet away from the current position but held the helicopter still, the integral portion of the PID controller would continue to sum the error seen. Eventually this error would grow very large. If the pilot then switched to autonomous mode, the controller’s output thrust signal would be huge, most likely causing a wreck. There are two solutions to this problem. The first is using a cap for the maximum absolute value of the integrated value. This is the windup guard. Another solution would be to call the pid_zeroize function each time the GPS target is set and each time the autonomous control system is enabled. In either case, setting a safe maximum value using a windup guard is good practice.

Optimization:

This code can be optimized if the pid_update function is called at the exact same rate every time. In this case, all references to ‘dt’ can be removed. This will change the optimal values for the integral and derivative gains but once tuned, will respond the same way. In this code, this optimization only removes one multiplication operation and one division operation.
It is possible to change this code to run on fixed-point arithmetic rather than floating-point. This dramatically increases the efficiency but system limits and precision may be compromised. Only use fixed-point if you are sure that you are using enough precision.

EDIT: fixed bug on line 31. changed multiply to divide.

Advertisements

Quadcopter Frame Design

My first quadrotor frame design is simple, sturdy, reliable, and a bit ugly.  I have made no attempt to make it cute, flashy, or visually desirable in any way.  If and when I determine that the structural design performs well, I’ll use some better tools to make a more flashy design.  Until then, I’ll be flying on my raw cut aluminum frame.

My basic design is two 24 inch(610 mm) X 1/2 inch(13 mm) X 1/2 inch(13 mm) square aluminum arms.  I knotched both in the center so that they can cross each other.  There are two 5 1/4 inch(133 mm) alumimum plates holding everything strong and square.  The frame is very strong, rigid, and relatively low weight.

RC Receiver Interface

There are numerous RC Receiver interfacing techniques published on the web.  My quadcopter design is using only one processor for all its computation.  For this reason, I spent extra time designing the interfaces to be as efficient as possible.  Even though RC Receiver interfaces aren’t super complicated, they can cause real-time scheduling issues because of the number of interrupts and the time spent inside these interrupt routines.

Typical RC Receivers output the channel values in a given sequence of pulse width modulated (PWM) signals.  The transmitters and receivers I have tested are Spektrum made.  All Spektrum models seem to have the same design style.  After a small bit of testing, I found that the several channels of signals are output in the same order everytime and have a small time separation.  Since the standard for RC PWM is 50Hz, each pulse comes every 20 milliseconds.  The top 5 lines of the picture above show an example output of a 5 channel Spektrum made receiver.

In a microcontroller, the most accurate way to measure incoming pulses is to use an input capture with a timer.  Measurement occurs when a free running timer value is latched into a register when an event occurs.  Obviously, a higher frequency timer yields a more precise pulse measuring system.  Since most microcontrollers only have a few input capture pins, some special circuitry must be used to measure several pulses.  Since the Spektrum systems do not overlap their output pulses, a simple OR gate structure can be used to combine all the signals into one signal.

Since my quadcopter will be using the Spektrum DX5e and AR500, I’m using a quad 2-input OR gate IC (MC14071BCP), to create this combined signal.  As shown in the timing diagram at the top, there are still 2 voltage transistions per pulse.  This results in 10 interrupts for this design style.  For synchronization purposes, there is always a time between the last pulse and the beginning of the first pulse that is longer than the longest possible pulse.  To capture the values sent by the transmitter, the software is setup for an interrupt to occur on every transition of the signal.  All of the interrupts, except the last one, have a very small amount of time to process.  The last interrupt copies out the five pulse width values and triggers an availability flag so that the rest of the software can have access to it.

An interesting thing that I noticed while testing is that Spektrum has a constant delay of 60 microseconds between each pulse.  To make the system even more efficient, turning off the falling edge interrupts for the first four pulses then back on for the last interrupt results in 4 less interrupts.  For the first 4 pulse width values, 60 microseconds would just be subtracted off.

For my system, this OR gate structure serves another purpose.  The AR500 receiver runs on 5 volts, however, the microcontroller (LPC1768) runs on 3.3 volts.  Of course there are many ways for converting one to another but the MC14071BCP IC has a wide voltage range and is tolerant to 5 volt inputs when running at 3.3 volts.  Without extra circuitry, it will convert the five 5 volt signals from the AR500 into one 3.3 volt signal that represents all five channels.

In conclusion, I’ve found that using a simple OR gate IC is very efficient for pin usage, timer utilization, voltage translation, and interrupt time efficiency.

Update:

I implemented this RC receiver interface on the LPC1768 connected to a AR500.  My results are accurate to about 60-70ns.  This leads me to believe that the AR500 is running on the typical ATmega8 (or 168 or 328) microcontroller running at 16MHz (1/16MHz = 62.5 ns).

Update:

Due to popular request, here is the code I used on the LPC1768 (right-click download, then change the “.pdf” extension to “.zip”):
https://nicisdigital.files.wordpress.com/2013/09/rc_receiver_interface-zip.pdf

Quadcopter Software Design

Before I begin discussing the quadcopter design, here is a diagram that shows the high-level software structure for my design:

All future software design posts will reference to this diagram.  Here is a short explanation of the necessity and function of each block:

PWM Decoder Driver:
In order to interpret flight commands from a standard RC Transmitter/Receiver, any multi-rotor design must have some sort of PWM decoder.  My decoder will be expecting a single signal containing all PWM channels (details here).  The decoder driver will translate the several channels of pulse widths into values to be interpreted by the command translator.

Command Translator:
Depending on the flight mode, the PWM values given by the transmitter are interpreted differently.  The command translator determines which mode the user is flying in and translates the commands accordingly.

I2C Master:
The inertial sensors I’ve chosen to use all run on the I2C protocol.  This high-speed protocol will be a great interface to use because of its addressing scheme and its interrupt time efficiency.  The I2C protocol is more complicated that most serial protocols but the LPC1768 has built-in hardware to handle the physical layer.  The I2C interrupt scheme for this hardware is very efficient with each interrupt needing only a few lines of code.

Sensor Fusion:
As mentioned in an earlier post, I will be implementing several sensor fusion algorithms to find out which has the best performance.  The first one I will implement is the Extended Kalman Filter (EKF).  The EKF algorithm is widely known to be one of the best methods for state (in my case aircraft attitude) estimation.  This filter will take the sensor readings from the various sensors and output an estimation of the current aircraft attitude.  For my initial design it will be important to measure:

  • Roll – Side to side angle relative to the horizon
  • Pitch – Front to back angle relative to the horizon
  • Roll Rate – Side to side rotational rate relative to the horizon
  • Pitch Rate – Front to back rotational rate relative to the horizon
  • Yaw Rate – Horizontal rotational rate relative to magnetic heading
  • Magnetic Heading – Direction relative to magnetic north

Proportional-Integral-Derivative (PID) Stabilization:
Once the desired aircraft attitude is determined from the transmitter commands and the actual aircraft attitude is determined from the sensor fusion algorithm, PID controllers are used to determine the fastest way to make the desired attitude become the actual attitude.  PID controllers are very efficient for control of a system in which an accurate physical model is unknown.  Using calculus to determine error slopes and areas, PID controllers compensate for environmental noise and disturbances while overcoming steady state error and oscillations.  PID controllers are VERY simple to design and code but are VERY hard to tune and calibrate.  (see this post)

Multi-Rotor Throttle Mixing (MRTM):
Standard helicopters use Cyclic Collective Pitch Mixing (CCPM) to adjust the aircraft attitude.  It works by adjusting the pitch of the blades depending on their current angular position.  I came up with term MRTM, as I haven’t found a term defined for multi-rotor helicopters.  MRTM works by adjusting the speed of several propellers in such a way that results in the same aircraft control and a typical helicopter (a post will soon follow that explains this in detail).  MRTM can be used to control the attitude of many styles of multi-rotor helicopters.

PWM Encoder Driver:
Once everything has been computed, the PWM Encoder takes the control values and generates a pulse width modulated (PWM) output for each motor.  This is the exact opposite process of the PWM Decoder.  The LPC1768 has good support for PWM output.  I’ll be able to output all channels of PWM without using any interrupts or processing time.  Can’t beat that!

Impressive Multi-rotor Designs

Fast Agile Quadcopter

MikroKopter HexaKopter (6 Propellers)

GRASP Lab (University of Pennsylvania)

ETH Flying Machine Arena (Quadcopter Ping Pong)

Shrediquette (FPV Flying in Africa)

Quadcopter Doing Flips (KapteinKUK)

Quadrotor Parts List

Here is the initial parts list for my quadcopter design:

Product Description Quantity Price


Turnigy Brushless Outrunner

2217 20turn 860kv 22A
4 $53.12
($13.28ea)


Turnigy ESC

Plush 30amp
4 $48.76
($12.19ea)


Turnigy LiPo

5000mAh 3S 25C Lipo
1 $27.43


XT60 Connectors

Male/Female (5 pairs)
1 $3.19


Turnigy Balancer/Charger

Accucel-6 50W 6A w/ accessories
1 $22.99


Pyramid Power Supply

PS12KX 10-amp 13.8-volt
1 $46.99


APCProp

12 x 3.8″ Slow Flyer
2 $7.90
($3.95ea)


APCProp

12 x 3.8″ Slow Flyer Pusher
2 $11.84
($5.92ea)


Spektrum DX5e

5 Channel 2.4 GHz DSM2 Transmitter
1 $59.99


Spektrum AR500

5 Channel 2.4 GHz DSM2 Receiver
1 $39.99


LPCXpresso LPC1768

ARM Cortex-M3 Development Board
1 $28.50


9 DOF Sensor Stick

3-Axis Gyro, Accelerometer, Magnetometer
1 $99.99


OR Gate

CMOS Quad 2-Input
1 $1.00


Buffer

CMOS Quad 2-Input
1 $1.00


Aluminum Tubing

6061 1/2″ x 1/2″ x 72″, 0.063″ Wall
1 $21.14


Aluminum Sheet

6061 12″ x 12″, 0.063″ Thick
1 $10.06


Coleman Wire

16 Gauge 100 Feet
1 $11.24


Bullet Connectors

3.5mm 3 Pairs
4 $19.80
($4.95ea)

The aim of this design is for an extremely aggressive quadcopter. My design goals are for the stabilization system to handle VERY abrupt changes in attitude and able to recover from any acrobatic mishap. I’ll be adding a mode for acrobatics where absolute angles are not used for stabilization. Instead, the stabilzer will hold to a rotational rate. If an acrobatic maneuver goes south, one switch flip will be able to bring the helicopter back to a stabile hover. The only remaining control not adjusted by the stabilizer is the throttle.

I’m sure that there will be additional items I will need but haven’t thought of. I will try to keep this list up to date for those of you using it for your own copter build.

EDIT: added 16-gauge wire and 3.5mm connectors

ARMed with power!

NXP's ARM Cortex-M3

Over the past few years I’ve worked with a number of different microcontrollers.  I was introducted to the microcontroller world during a university class that used Freescale’s 68HC12.  This was a great learning platform because it forced me to constantly dig through the datasheet for register definitions.  I learned on a low-level how microcontrollers operate.  The 68HC12 is a 16-bit CISC architecture.  The class focused on embedded systems hardware.

The second class of the series used Freescale’s 32-bit ColdFire RISC microcontroller.  This class focused on the software side of embedded systems.  The ColdFire design is much more powerful than the 68HC12 microcontroller and much easy to use.  However, both microcontrollers have the same flaw, they are made by Freescale!  Freescale makes some very fine products but from my experience, they have two major flaws:

  1. Their register usage and configuration make the microcontroller hard to use and a pain to configure. 
  2. Their datasheets are impossible to find the information you need, which makes it even harder to configure.

During the summer in between these two classes, I discovered the ultimately easy to use microcontroller, the Arduino.  In case you don’t know, the Arduino is a development platform built around an 8-bit AVR microcontroller.  The AVR alone is a pretty easy to use microcontroller.  It isn’t terribly powerful because it’s only 8-bits.  The Arduino environment adds an easy-to-use IDE with programming software.  It also gives a bootloader and software libraries.  If you want a quick and dirty (VERY dirty) setup, this is the microcontroller for you! 

Once I decided to start a substantial programming project for an unmanned autonomous quad-rotor helicopter, I knew I wanted to find a great microcontroller to be my one and only.  I did a lot of research and decided I should look into a 32-bit ARM solution.  I found the LPC1768 ARM Cortex-M3 microcontroller by NXP Semiconductors.  Of all the microcontrollers I’ve used, this is the only one that I’ve enjoyed every part of.  The ARM Cortex-M3 core is simply amazing.  I heavily doubt that there is a more efficient way to utilize 32-bits!  NXP’s hardware peripherals compliment the ARM core in a perfect way.  Each peripheral seems to have had countless hours of design.  The setup for these complex peripherals is very easy!  This is because the configuration registers are straight forward and the accompanying datasheet is precise and detailed.  The development platform I use is the LPCXpresso LPC1768.  $30 will buy you a tiny microcontroller development board, and a JTAG programming device.  The IDE is Eclipse based easy to use and free.

For all you Arduino users out there, I suggest you give this a try.  The Arduino environment is severely limiting and you’ll never learn efficient embedded system design.  Don’t get me wrong, if I need a quick development test, I’ll use my Arduino, but for any real-time operation, I’ll stick to those who know it best, ARM.