Posts Tagged ‘ quadcopter ’

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

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

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

Past:
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!

Future:
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