Archive for the ‘ Quadcopter ’ Category

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.


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


Due to popular request, here is the code I used on the LPC1768 (right-click download, then change the “.pdf” extension to “.zip”):

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

Turnigy ESC

Plush 30amp
4 $48.76

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


12 x 3.8″ Slow Flyer
2 $7.90


12 x 3.8″ Slow Flyer Pusher
2 $11.84

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


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

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

Initial Quadrotor Design


I have been researching a variety of multi-rotor helicopter setups for some time.  I’ve been trying to identify the strengths and weaknesses of each design type.  I have come up with an initial design for my quad-rotor helicopter.  In attempts to create a very aggressive aircraft, I have designed the propellers to be a close as possible, as large as possible, and the motors to have a high power to weight ratio.  All of my assumptions about quadcopter design are very spectulative since I haven’t ever built one before. 

My first matter of design is a powerful CPU.  My fly-by-wire T-Rex 600 project used 4 Arduinos and they left a sour taste in my mouth.  Arduinos are great for quick prototyping but anything with substance needs a better processor.  Besides, I’m a Computer Engineer so I can’t justify using someone else’s poorly designed microcontroller libraries.  My microcontroller of choice for this project is the LPC1768 ARM Cortex-M3 by NXP Semiconductors.  It is a powerhouse!  I’ve written most of the low-level hardware drivers and a few of the higher level routines, such as PID controllers and Collective Cyclic Throttle Mixing (CCTM).  The combination of the ARM’s Cortex-M3 core with NXP’s hardware peripherials makes this as amazingly powerful design.  ARM+NXP=Happiness!

For aircraft attitude measurement, I’m planning on using the 9DOF Sensor Stick from Sparkfun.  Version 2 is still under design so I’ll have to wait on that.  I’m going to implement 3 different types of sensor fusion algorithms and see which type works the best.  The 3 algorithms are:

  • Complimentary Filter
  • Direction Cosine Matrix
  • Extended Kalman Filter

In the animation above, the two circles representing the propellers show the two sizes I will test.  The inner circles are a 12×3.8″ APCprop and the outer circles are a 14×4.7″ APCprop.  I haven’t seen another helicopter use the 14″ props before so I’ll get the 12″ props working first.

This is an explanation of the animation per level:

Level One (bottom):

  • LiPo battery
  • Receiver

Level Two (between the two metal plates):

  • 4x Electronic Speed Controllers

Level Three (top):

  • CPU
  • 3-Axis of Gyroscopes, Accelerometers, and Magnemeters

Outer Arms:

  • 4x Motors
  • 4x Props

I know that having the props close together makes the attitude harder to stabilize.  On the other hand, having the props close together will (I hope) induce much more torque on the frame from the motors.  This will help me overcome the lame yaw response of most quadrotor helicopters.  I’m banking on the fact that my CPU will be running at 100 MHz and I’ll hopefully have the sensor fusion filters and PID controller running at 400+Hz.  This should allow me to precisely adjust each axis of stabilization.  For better discrete calculus computations (integration and differentation) I’ll try running the sensor fusion algorithms above 1kHz and only commanding the ESCs at their maximum speed (50Hz-400Hz).  This will make the computations more accurate because each time step will produce less error.

Starting a quad-rotor helicopter project

I recently graduated from the University of Utah in Computer Engineering. My senior project was a fly-by-wire system for an unmanned helicopter. We used an Align T-Rex 600 ESP helicopter for the project. Designing a stabilization system for this size of helicopter presents many problems. Given that the tips of the blades travel at 350 mph, physical danger was obviously the biggest concern. We successfully implemented our design.

Even though we felt moderate success, we didn’t feel that our system performed as well as it could have. All the supporting hardware and software was implemented but the time needed to calibrate the many features of stabilization caused us to end the project before all features could be utilized. The excessive calibration time is a result of calibrating a 53 inch helicopter during flight. Any changes in the system had to be modified very slowly.

This project gave me a lot of experience with inertial measurement and feedback control. It also gave me a HUGE desire to make something better!

Now I begin a multi-rotor helicopter project. I aim to fix all the faults in the previous design while overcoming many of the short comings of current multi-rotor designs. I will start by designing a 4 rotor system because it is the cheapest. Once I master the quadcopter, I’ll try a hexacopter or an octocopter. I have been impressed by many multicopter designs. Some are:

  • HexaKopter by MikroKopter
    This design shows a lot of intelligent software engineering. The GPS capabilities of this system are phenomenal. The supporting stabilization system is also very intelligent (see the oscillating coke bottle).
  • GRASP Labs Quadrotor
    Having the entire room and obstacles marked with position sensors is kind of cheating for autonomous vehicles, but I must admit that these helicopters are amazing! Recovering from severe initial conditions is very impressive.

My goals are to:

  • overcome the inheritly slow yaw response of current quad-rotor designs.
  • design an extremely aggressive stabilization system.
  • find a good balance between size and payload capability.
  • make the chassis rigid enough to survive moderately severe crashes.
  • create a quadcopter that is ridiculously fun to drive!

My initial design will be very minimal. I will start off with only a basic quad-rotor design controlled by a transmitter/receiver pair. No other communication will be used. I’m designing this to be minimal so that I can focus on the inertial measurements and feedback control. Once these are mastered, I’ll add fluffy features like:

  • software ground station
  • GPS hold and navigation
  • video downlink