Fink, Greczanik, Hamblin, Kirkwood
Quadrotor Unmanned Hovering Craft
Senior Project Final Report
Design Team #10
Joel Fink
Vince Greczanik
Kyle Hamblin
James Kirkwood
Dr. Jay Adams
4/22/2011
ii
Fink, Greczanik, Hamblin, Kirkwood
Table of Contents
Abstract ............................................................................................................................... 1 Introduction ......................................................................................................................... 2 Statement of Need ............................................................................................................ 2 Problem Statement ........................................................................................................... 2 1.2.1 – Objective .......................................................................................................... 2 1.2.2 – Background...................................................................................................... 3 Design Requirement Specifications .................................................................................... 4 Accepted Technical Design ................................................................................................ 6 Engineering Calculations ................................................................................................. 6 3.1.1 – Mechanical (Kyle) ........................................................................................ 6 3.1.2 – Power (Kyle, Joel) ...................................................................................... 10 3.1.3 – Computation (James) .................................................................................. 12 3.1.4 - Motor Controller (Joel) ............................................................................... 12 3.1.5 – Control System (James, Kyle, Vince, Joel) ................................................. 13 Block Diagrams Level 1 w/ FR tables & ToO ............................................................... 17 3.2.1 – Inertial Measurement Unit (IMU) (Vince) ................................................. 17 3.2.2 – MCU and Communication (James)............................................................. 21 3.2.3 – Power Management (Kyle) ......................................................................... 22 Design and Schematics .................................................................................................. 23 3.3.1 – Sensors (Vince) ........................................................................................... 23 3.3.2 – Communication (James) ............................................................................. 28 3.3.4 – Motor Controllers (Joel) ............................................................................. 30 3.3.5 – Computation Hardware (James) ................................................................ 33 3.3.4 – Power Management (Kyle) ......................................................................... 34 3.3.5 – Central Microcontroller Software (James).................................................. 36 3.3.6 – PCB Design ................................................................................................... 53 Parts List ........................................................................................................................ 56 Operation, Maintenance, and Repair Instructions............................................................. 59 Charging the Battery ...................................................................................................... 59 i
Fink, Greczanik, Hamblin, Kirkwood
Calibration and Startup .................................................................................................. 59 Data Output .................................................................................................................... 61 Mechanical Maintenance ............................................................................................... 62 Testing Procedure ............................................................................................................. 62 Financial Budget ............................................................................................................... 66 Project Schedule................................................................................................................ 67 Design Team Information ................................................................................................. 68 Conclusions and Recommendations ................................................................................. 68 References ......................................................................................................................... 70 ii
Fink, Greczanik, Hamblin, Kirkwood
List of Figures
Figure 1 - Implemented Quadrotor Design ......................................................................... 7 Figure 2 - Anticipated Quadrotor Design ........................................................................... 7 Figure 3 – Implemented Weight Distribution ..................................................................... 8 Figure 4 - Total Potential Lift vs. Motor Speed ................................................................ 10 Figure 5 - Total Potential Lift vs. Current ........................................................................ 11 Figure 6 - Altitude Step Response .................................................................................... 16 Figure 7 - Pitch Step Response ......................................................................................... 16 Figure 8 - Roll Step Response .......................................................................................... 17 Figure 9 - IMU Module Block Diagram ........................................................................... 17 Figure 10 - Digital Gyroscope Axis Orientation............................................................... 19 Figure 11 - Central Microcontroller and Communication Module Block Diagram ......... 21 Figure 12 - Power Management Module Block Diagram ................................................. 22 Figure 13 - Inertial Measurement Unit (IMU) Schematic ................................................ 24 Figure 14 – Comparison of Roll Measurements ............................................................... 26 Figure 15 - Ping Sensor Schematic ................................................................................... 27 Figure 16 - Ping Sensor Interface Circuit ......................................................................... 27 Figure 17 - Wireless Communication Setup ..................................................................... 29 Figure 18 – HobbyKing Electronic Speed Controller....................................................... 31 Figure 19 – Motor Controller dsPIC Flow Diagram......................................................... 32 Figure 20 – Motor Controller Calibration Curve .............................................................. 32 Figure 21 - Schematic of Microcontroller and Communication Modules ........................ 34 Figure 22 - Battery Monitor Schematic ............................................................................ 36 Figure 23 - Switching Regulator Schematic ..................................................................... 36 Figure 24 - 5V Charge Pump Schematic .......................................................................... 36 Figure 25 - Flow Diagram of Main Application ............................................................... 37 Figure 26 - Sensor Data Ready Interrupts......................................................................... 38 Figure 27 – High Level Flow Diagram of Main Loop...................................................... 39 Figure 28 - Flow Diagram of Takeoff and Landing Algorithm ........................................ 45 Figure 29 - UART Transmission Flow Diagrams............................................................. 50 Figure 30 – PCB Layout – Top Copper ............................................................................ 53 Figure 31 – PCB Layout – Inner Copper 1 ....................................................................... 54 Figure 32 – PCB Layout – Inner Copper 2 ....................................................................... 55 Figure 33 – PCB Layout – Bottom Copper ...................................................................... 56 Figure 34 - Safety Enclosure............................................................................................. 63 Figure 35 - Pitch Data, pre mitigation .............................................................................. 65 Figure 36 - Pitch Data, post mitigation ............................................................................. 65 iii
Fink, Greczanik, Hamblin, Kirkwood
List of Equations
Equation 1 - Propeller Lift (Abbott & Doenhoff, 1959) ..................................................... 9 Equation 2 - Lift for Quadrotor ........................................................................................... 9 Equation 3 - Combined Lift for Quadrotor ......................................................................... 9 Equation 4 - Maximum Angular Velocity .......................................................................... 9 Equation 5 - Battery Capacity ........................................................................................... 11 Equation 6 - System Dynamics, Sum of Angular Velocities ............................................ 13 Equation 7 - System Dynamics, Z-Direction Force .......................................................... 13 Equation 8 - System Dynamics, Pitch Torque .................................................................. 13 Equation 9 - System Dynamics, Roll Torque ................................................................... 13 Equation 10 - System Dynamics, Yaw Torque ................................................................. 13 Equation 11 - East Motor, Angular Velocity .................................................................... 14 Equation 12 - South Motor, Angular Velocity.................................................................. 14 Equation 13 - West Motor, Angular Velocity ................................................................... 14 Equation 14 - North Motor, Angular Velocity.................................................................. 14 Equation 15 - Z-Direction Position ................................................................................... 14 Equation 16 - Pitch Position ............................................................................................. 14 Equation 17 - Roll Position ............................................................................................... 14 Equation 18 - Yaw Position .............................................................................................. 14 Equation 19 – Controller Transfer Function ..................................................................... 15 Equation 20 - Rotation Quaternion ................................................................................... 25 Equation 21 - Quaternion as Function of Euler Angles .................................................... 25 Equation 22 - Quaternion Equivalent of Rotation Matrix ................................................ 25 Equation 23 - Euler Angles as Function of Quaternion .................................................... 25 iv
Fink, Greczanik, Hamblin, Kirkwood
List of Tables
Table 1 - Design Requirements Table ................................................................................ 6 Table 2 - Weight Distribution ............................................................................................. 8 Table 3- IMU Module Functional Requirement Tables ................................................... 18 Table 4 - Central Microcontroller and Communication Module Functional Requirement
Tables ................................................................................................................................ 21 Table 5 - Power Management Module Functional Requirement Tables .......................... 22 Table 6 - Comparison of Digi XBee Modules .................................................................. 28 Table 7 - XBee Module Pinout ......................................................................................... 30 Table 8 - NXP LPC1768 Specifications, .......................................................................... 33 Table 9 - List of Interrupts Used in Application ............................................................... 37 Table 10 - evaluateUserInput Module Summary .............................................................. 40 Table 11 - getIMUData Module Summary ....................................................................... 40 Table 12 - getAttitude Module Summary ......................................................................... 41 Table 13 - runAttitudeControlLoop Moule Description ................................................... 41 Table 14 - updateMotorSpeeds Module Summary ........................................................... 41 Table 15 - turnOffMotors Module Summary.................................................................... 42 Table 16 - resetControlParameters Module Summary...................................................... 42 Table 17 - getPingRanges Module Summary ................................................................... 42 Table 18 - pingStartBursts Module Summary .................................................................. 43 Table 19 - runAltitudeControlLoop Module Summary .................................................... 43 Table 20 - getPowerData Module Summary .................................................................... 44 Table 21 - checkPowerLevels Module Summary ............................................................. 44 Table 22 - beginTakeoffSequence Module Summary ...................................................... 46 Table 23 - beginLandingSequence Module Summary...................................................... 46 Table 24 - List of I2C Devices Used ................................................................................. 47 Table 25 - I2CBegin Module Summary............................................................................ 48 Table 26 - I2CWaitUntilIdle Module Summary ............................................................... 48 Table 27 - ADCLastReading Module Summary .............................................................. 49 Table 28 - UARTPutChar Module Summary ................................................................... 50 Table 29 - UARTSendNextChar Module Summary ......................................................... 50 Table 30 - List of Status Messages ................................................................................... 52 Table 31 - sendUserMessage Module Summary .............................................................. 52 Table 32 - Parts List .......................................................................................................... 56 Table 33 – Quadrotor Commands ..................................................................................... 60 Table 34 - EPROM Parameters......................................................................................... 61 Table 35 – Output Data Description ................................................................................. 61 Table 36 - Expenses .......................................................................................................... 66 Table 37 - Sources of Funding .......................................................................................... 67 v
Fink, Greczanik, Hamblin, Kirkwood
Abstract This document describes the construction, design and implementation of an aircraft
possessing four motors and four propellers mounted in the vertical direction that will be
able to hover stably, herein referred to as a quadrotor. A feedback control system has
been designed to maintain the desired altitude and attitude (orientation of the craft in 3D
space) of the quadrotor by controlling the speed (and consequently lift) of each motorpropeller combination. The altitude of the quadrotor will be determined through the use
of an ultrasonic range finder while the attitude will be determined through the use of an
Inertial Measurement Unit (IMU) which consists of a triple-axis accelerometer and tripleaxis gyroscope. A wireless communication module will allow important information to
be relayed from the quadrotor to a ground station and vice versa. One microprocessor
will act as a central control module, processing sensor data and implementing the control
algorithm, and 4 brushless DC motor controllers will be used to accurately control the
speed of each motor-propeller combination.
1
Fink, Greczanik, Hamblin, Kirkwood
Introduction
Statement of Need
Unmanned Aerial Vehicles (UAVs) have become prevalent in many defense and security
operations today. However, as most UAVs are fixed-wing aircraft they have several
disadvantages such as poor maneuverability and the inability to operate indoors. A new
class of UAV needs to be developed for use in situations where the presence of a UAV
would be beneficial, but where the limitations of fixed-wing aircraft prevent the effective
use of an UAV. Such a vehicle could be used to inspect structures, like factories and
bridges, survey indoor corridors, and even find missing children within a densely wooded
area.
Problem Statement
1.2.1 – Objective
The objective of this project is to design and implement the hardware and software for an
autonomous hovering quadrotor vehicle. A quadrotor vehicle is an aerial craft that has
four propellers located parallel to the ground at the four corners of the craft. The speed of
each propeller can be individually adjusted to steer the craft and to maintain stability.
For this project the quadrotor vehicle will be developed to the point where it can hover at
a predetermined height and orientation. The vehicle will require no human input for
stability and will remain stable despite outside interferences, such as a hand waving
underneath the craft or uneven terrain. This design will set a stable base for future aerial
maneuvering and full blown autonomous intelligence which, while not a part of this
proposal, will be developed further if time permits.
All electrical hardware and software will be the original work of the design team. The
Flight Stability control algorithm will be a primary focus of our design. Flight hardware,
such as propellers, motor controllers, and motors, will be selected based on proven
combinations determined by online communities, significantly reducing the amount of
mechanical design required by this project.
2
Fink, Greczanik, Hamblin, Kirkwood
1.2.2 – Background A quadrotor aircraft is the logical selection for this project. It requires fewer moving parts
than a helicopter and is much more stable. Quadrotors can move without adjusting blade
angle or adjusting rotor tilt.
The basic principles behind this project include simple aerodynamics, ( Lift > weight) ,
control system theory, embedded systems, and sensor and actuator interfacing. Designing
an effective control system is probably the most important aspect of this project. The
control system is responsible for keeping the craft stable despite many disturbances that
may act upon it. Feedback for these types of craft is provided by an IMU, or inertial
measurement unit, which contains accelerometers and/or gyroscopes that measure the
crafts movement and orientation. Most crafts available today use 5 DOF (degrees of
freedom) IMUs which measure X, Y, Z, pitch, and roll. For our craft we wish to add an
additional DOF to measure the yaw of the craft. Magnetometers could be added as well to
eliminate accumulated error in the gyroscope measurements. This will help the craft
maintain a stable orientation.
As with all aerial vehicles, battery life and weight are also serious parameters that must
be taken into account when designing the vehicle.
3
Fink, Greczanik, Hamblin, Kirkwood
Design Requirement Specifications Marketing
Requirements
1
1
1
3
3
3
3
Engineering Requirements
Justification
Mechanical
The total weight of the quadrotor in This ensures enough lift and
un-tethered flight configuration must maximizes battery life.
be less than 3.3 lbs.
The motor-propeller combination
must be able to lift 4lbs.
With a 4lb. minimum rating
the craft will easily fly.
The quadrotor, fully assembled,
must have dimensions less than 3ft.
x 3ft. x 3ft.
For indoor operation, the craft
must be maneuverable.
Power
The craft must be able to maintain
un-tethered flight for a minimum of
20 minutes.
The central microcontroller will
monitor the battery voltage to
provide state of charge feedback to
the operator as a percentage of full
charge.
When the battery voltage is at
approximately 20% charge level, the
user will be alerted. If the user takes
no action before the battery reaches
10% charge, the craft will
automatically land.
The central microcontroller will
monitor the battery current. If an
over current condition is detected
the operator will be alerted, and the
speeds of the motors will be reduced
until a safe operating level is
obtained.
4
This time will reasonably
demonstrate craft operation.
For monitoring purposes to
ensure that the LiPO battery
cells are not damaged.
Preservation of the physical
structure of the craft.
To ensure that the discharge
rate specification of the LiPO
battery cells are not exceeded.
Fink, Greczanik, Hamblin, Kirkwood
3
2
2
2
2
1
1
1
1,2
1,2
A switching DC-DC buck converter
will be used to regulate the battery
voltage down to 3.3VDC for the
onboard electronics. The DC-DC
converter must have efficiency
greater that 85% and be able to
provide a minimum of 1A to the
onboard electronics.
Communication
The system will incorporate two
way wireless communications. The
operator must be able to send
commands to the quadrotor, and the
quadrotor must be able to send status
information to the operator.
Necessary for craft electronic
hardware component power.
The switching regulator
maximizes efficiency and
consequently flight time.
Two way communication will
allow for altitude input and
craft monitoring.
For ease of communication
A prebuilt wireless communication
implementation.
module will be used for simplicity.
The communication range of the
To ensure a reasonably safe
module must be at least 100ft in an
operation range.
indoor environment.
The module must be able to
This rate will guarantee up to
communicate at a data rate of at
date information.
least 9600bps.
Inertial Measurement Unit (IMU)
The IMU will include one triple axis These components will sense
accelerometer and one triple axis
the orientation of the craft in
gyro interfaced with the central
space.
microcontroller.
The triple axis digital accelerometer The accelerometer will
must sense inclination changes of as provide angular acceleration
little as 0.25 degrees. The dynamic
about all three axes.
range of the device will be set to +/2g to optimize resolution.
The triple axis digital gyro must
The gyro will provide rotation
detect yaw, pitch, and roll with
orientation about all three
optimized resolution using a
axes.
digitally programmed low pass filter
and possible analog pre-filtering.
Computation
The processor will have a 32-bit
These specifications will
core.
allow ample configuration for
the I/O and control software.
The processor will have several I/O
capabilities including at least I2C,
UART, and A/D converters.
5
Fink, Greczanik, Hamblin, Kirkwood
The processor will have hardware
multiply and divide capability
Motor Controller
Each of the 4 brushless DC motors
This will allow for specific
1
will be independently controlled by
maneuverablility.
its own motor controller.
Each motor controller will
This protocol is standard for
communicate with the central
the two devices.
1
2
microcontroller over I C as a slave
device.
The central microcontroller will
The commands will move the
1
send speed commands to the motor
craft accordingly.
controller.
Control System
Craft must be able to hover stably in This will allow for operation
four degrees of freedom, yaw, pitch, in an indoor environment with
roll, and z-axis, with no more than
stable movement.
1
24 inches of drift in any direction
and no more than 30 degrees of
rotation on any axis.
Craft must be manually
The craft must have this
2,4
programmable by the user to hover
human input for operation.
at a height of up to 6ft.
Marketing Requirements
1. The craft should be able to hover stably (e.g. maintain a given height and
orientation).
2. The craft should be easily programmed by a user to hover at a specific height.
3. The craft should have a rechargeable battery with acceptable life.
4. The craft should be easy to setup and test.
1,2
Table 1 - Design Requirements Table
Accepted Technical Design Engineering Calculations
3.1.1 – Mechanical
(Kyle)
Structural Considerations:
The quadrotor that was implemented in the project is shown in Figure 1 and the
anticipated design is shown in Figure 2 below. As shown, the designs are very similar.
6
Fink, Greczanik, Hamblin, Kirkwood
The narrower landing rails were the result of a maximum PCB area to keep cost down.
The PCB rotation of 45° helped both in control system design by defining a coordinate
system that was intuitive to work with and PCB design because the software utilized
could not place parts at a 45° angle. Also to keep costs down and speed up design,
aluminum rods were substituted for the carbon fiber rods and a new male interconnect
was fabricated via a CNC mill from scratch, replacing the PVC tubing connector. The
motor-propeller combinations remained the same as did the battery size and dimensions.
Figure 1 - Implemented Quadrotor Design
Figure 2 - Anticipated Quadrotor Design
In order to ensure flight with minimum power consumption the total weight of the
quadrotor in un-tethered flight configuration must be as light as possible. Table 2 shows
the anticipated weight distribution of the various components towards the total weight of
the quadrotor. Figure 3 represents this data graphically as a percentage of total weight.
Hardware in the table refers to the various nuts and bolts required to construct the frame,
not electronic hardware. This weight distribution does not account for the weight of a
7
Fink, Greczanik, Hamblin, Kirkwood
Printed Circuit Board, sensors and electronic components. It is assumed that the weight
of these items will be small in comparison to the listed items below.
Table 2 - Weight Distribution
Category Item/Material Weight (g) Weight (lbs) Motors KDA‐20‐22L
266.0 g
0.59 lbs Tubing Aluminum
126.0 g
0.28 lbs Interconnect Plastic
19.1 g
0.04 lbs Landing Rails Plastic
47.4 g
0.10 lbs Hardware Plastic
87.4 g
0.19 lbs Batteries 10 Ah
621.0 g
1.37 lbs Total Weight
1166.9 g
2.57 lbs Quadrotor Weight Distribution
Motors
23%
Batteries
53%
Tubing
11%
Interconnect
2%
Landing Rails Hardware
4%
7%
Figure 3 – Implemented Weight Distribution
8
Fink, Greczanik, Hamblin, Kirkwood
Motor-Propeller Analysis:
To determine whether or not the motor-propeller combination would generate enough
lift, Equation 1 is used to approximate the amount of lift generated by one propeller of a
specific geometry.
Equation 1 - Propeller Lift (Abbott & Doenhoff, 1959)
.
1000
Where:
L is Lift [ounces]
is Thrust Factor
is the Coefficient of Lift
P is Pitch of the propeller [inches]
D is the Diameter of the Propeller [inches]
is motor angular velocity [RPM]
The thrust factor is a unit-less scalar and is equal to 0.0017 for our propeller geometry.
The coefficient of lift, pitch and diameter of our propeller are 0.04549, 4.7 inches and 10
inches respectively. Substituting these constants into Equation 1 it simplifies to Equation
2.
Equation 2 - Lift for Quadrotor
1.82 10
.
The total lift for the quadrotor will be the sum of the lift generated by the four propellers
and is given by:
Equation 3 - Combined Lift for Quadrotor
7.28 10
The selected motor has a speed rating of
= 840
.
. With an operating voltage of
12VDC the maximum speed of the motor is given by:
Equation 4 - Maximum Angular Velocity
Where:
is maximum angular velocity [RPM]
is motor speed rating
V
is applied voltage [V]
9
Fink, Greczanik, Hamblin, Kirkwood
This yields a maximum angular velocity of 10,080 RPM.
Total Quadrotor Lift
14.00
12.00
Lift (lbs)
10.00
8.00
6.00
4.00
2.00
0.00
0
2000
4000
6000
8000
10000
12000
Rotor Speed (RPM)
Figure 4 - Total Potential Lift vs. Motor Speed
Using
as a limiting factor, lift was plotted from motor speeds of 0 to 10,000RPM.
Figure 3 shows the total amount of lift that could be generated by all four propellers and
shows that the there is the potential to generate an amount of lift that far exceeds the
3.3lbs weight restriction of the quadrotor, as defined in the Design Requirement
Specifications. This indicates that the quad rotor is capable of flight.
3.1.2 – Power (Kyle, Joel) Battery Sizing:
The selected motor lacks a datasheet and very little information can be determined
without experimental data. What is known is that each motor has a maximum operating
current of 13.5A which yields a maximum total current of 54A. It will be assumed for
battery sizing that the angular velocity of the motor will increase linearly with average
current. Therefore, the current-lift graph will follow the shape of the voltage-lift graph
with a maximum value of 54A. This assumption was used to approximate the Lift vs.
Current graph in Figure 5.
10
Fink, Greczanik, Hamblin, Kirkwood
Total Lift vs. Current
7000
6000
5000
Lift [lbs.]
4000
3000
2000
1000
0
0
1000
2000
3000
Current [A]
4000
5000
6000
Figure 5 - Total Potential Lift vs. Current
When lift equals weight the quadrotor will maintain a hover at constant altitude. Using
the maximum weight of 3.3lbs specified under the Design Requirement Specifications
section an average current draw of approximately 30A will achieve hover. 30A is much
greater than the 1A maximum allotted for on board electronics therefore electronic
current draw will be ignored. This yields an average continuous current draw of 30A
from the battery. Since battery capacity is rated in amp hours, it can be deduced that:
Equation 5 - Battery Capacity
Where:
is Battery Capacity [Ah]
is Average Current [A]
is Flight Time [h]
A required flight time of 20 minutes equates to 0.333 hours and yields a minimum battery
capacity of 10Ahr.
10
11
Fink, Greczanik, Hamblin, Kirkwood
To be able to fully utilize our potential lift, this design calls for a 12VDC 10Ah battery
array with a maximum discharging current of approximately 50A.
3.1.3 – Computation (James)
The exact performance requirements of the quadrotor’s processor are difficult to compute
before a complete model of the system is developed. However an attempt is made here to
estimate the requirements of the system.
After researching other implementations of the quadrotor, it seems that most systems
sample their attitude sensors at a rate of about 200Hz or every
1
200Hz
5ms
Assuming a 100MHz clock, consistent with the NXP LPC1768 processor intended to be
used, and an instruction execution speed of 1 MIPS/MHz or 100 MIPS, up to
0.005 sec
100,000,000 instructions
500,000
instructions can be executed per sample period, which should provide enough
computational ability and some additional headroom.
I2C communication will be used to communicate between the sensors, central
microcontroller, and motor controllers in our system. For every I2C byte transmitted, 8
bits of data, and an ACK/NACK bit are sent (A total of 9 bits). A 400kHz
implementation of the protocol will be used in our system. Therefore, the transfer speed
can be found to be
1
9 bits
400000Hz
22.5μs/byte
If an average I2C packet size of 4 bytes is assumed,
0.005
sec
22.5µs 4
55
packets can be sent per sample period. Communication speed should not be a hindrance
to our sampling rate.
3.1.4 - Motor Controller
(Joel)
The selected motor controller will receive a pulse between 700us and 2ms which will
dictate the speed at which it drives the brushless DC motor. Four of these controllers will
be used, one for each motor, and the four pulses necessary to operate these controllers
will be provided by a dsPIC33 microcontroller. The dsPIC33 microcontroller will
transmit a pulse to the motor controller every time an I2C message is received. The I2C
12
Fink, Greczanik, Hamblin, Kirkwood
message will dictate the width of the pulse and thus the motor speed. Though the pulse
width was found to be linearly proportional to the motor speed, the relationship varied
slightly between controllers. Therefore, a hardcoded calibration data was measured and
included in the control algorithm.
3.1.5 – Control System
(James, Kyle, Vince, Joel)
System Dynamics Calculations
In analyzing the physical dynamics of the quad rotor, one needs to consider a control
system with six degrees of freedom that need controlled by adjusting the speed of four
motors. In order to simplify this task and decouple the differential equations, the
assumption will be made that the pitch, yaw, and roll along with their derivatives
approach zero. It will also be assumed that the sum of the angular velocity of all four
motors equals zero as shown Equation 6.
Equation 6 - System Dynamics, Sum of Angular Velocities
ΩE
ΩS
ΩW
ΩN
0
In order to control lift, the relation in Equation 7 is used. Similarly for pitch and
roll Equation 8 and Equation 9 are used respectively. Yaw is controlled by the overall
speed of the motors as shown in Equation 10. The constants b and d will need to be
determined by experimentations as they relate to the dynamics and weight of the actual
Quadrotor. The b constant is a lift constant and corresponds to the amount of lift the
respective motors are generating. The d constant, however, is a drag coefficient in the
yaw direction that depends on the surface area of the tubing and motors.
Equation 7 - System Dynamics, Z-Direction Force
ΩE
ΩS
ΩW
ΩN
Equation 8 - System Dynamics, Pitch Torque
ΩN
ΩS
Equation 9 - System Dynamics, Roll Torque
ΩW
ΩE
Equation 10 - System Dynamics, Yaw Torque
ΩN
ΩS
ΩE
ΩW
Reversing the equations above provides us with parameters for controlling the motor as
shown in Equation 11, Equation 12, Equation 13, and Equation 14 below.
13
Fink, Greczanik, Hamblin, Kirkwood
Equation 11 - East Motor, Angular Velocity
ΩE
1
F
4b
1
T
2b θ
1
T
4d ψ
Equation 12 - South Motor, Angular Velocity
ΩS
1
F
4b
1
T
2b
1
T
4d ψ
Equation 13 - West Motor, Angular Velocity
ΩW
1
F
4b
1
T
2b θ
1
T
4d ψ
Equation 14 - North Motor, Angular Velocity
ΩN
1
F
4b
1
T
2b
1
T
4d ψ
Z-axis position and angular position can be obtained from the forces and torques in the
equations above by applying Newton’s Second Law as shown in Equation 15, Equation
16, Equation 17, and Equation 18 where m represents mass of the quadrotor, g represents
acceleration due to gravity, represents propeller distance from the center of the
Quadrotor, and I represents the moment of inertia in a specific direction.
Equation 15 - Z-Direction Position
1
Equation 16 - Pitch Position
Equation 17 - Roll Position
Equation 18 - Yaw Position
1
14
Fink, Greczanik, Hamblin, Kirkwood
It is important to note that using the decoupled analysis provided here with the given
stated assumptions, x and y movements are uncontrollable.
Control System Design and Simulation
Since our control model has decoupled the individual axes from one another, four
separate controllers were design for the Z, Pitch, Roll and Yaw axes independently.
The controller designs were based on the step response of the system due to a
disturbance. An acceptable settling time was set to be 3 seconds and the controllers from
the design portion of the project worked terribly. This indicated a good deal of
inaccuracies in our system model. In the end we implemented a PID controller for each
values for the individual axes. We used the
axis and tweaked the , and
trapezoidal rule as our integration method and since it is an associative integration
method, we substituted s with the inverse of the trapezoidal rule. The resulting controller
transfer function is as follows:
Equation 19 – Controller Transfer Function
2
2
2
2
1
In implementation, the derivative data was read directly from the sensors. That would
make implementing the above controller equation in the microprocessor problematic, but
the equation was useful to understand how the stability of the system was being affected
as we modified certain gains. The step responses of the systems and their controllers are
shown below in Figure 6, Figure 7, and Figure 8. The measures necessary to obtain a
yaw step response were deemed unsafe and therefore the yaw response was unobtainable.
As the figures show, our longest settling time occurs on the Pitch axis and is
approximately two seconds. The settling time for both Altitude and Roll are
approximately one second. It can also be seen that our controllers do posses a steady
state error; for the Roll and Pitch this error is approximately 0.5°; for Altitude the error is
5cm. These errors are considered negligible for the purposes of this project. All of the
controllers reach a limit cycle where the output oscillates around its set point. This is to
be expected with a system as inherently unstable as the quadrotor.
15
Fink, Greczanik, Hamblin, Kirkwood
Altitude Step from 40cm to 80cm
100
90
Altitude (cm)
80
70
60
50
40
30
0
1
2
3
4
5
Time (seconds)
Figure 6 - Altitude Step Response
Pitch Step Response from 0° to 10°
12°
10°
Roll (Degrees)
8°
6°
4°
2°
0°
‐2°
0
1
2
3
4
Time (seconds)
Figure 7 - Pitch Step Response
16
5
6
7
8
Fink, Greczanik, Hamblin, Kirkwood
Roll Step Response from 0° to 10°
12°
Roll (Degrees)
10°
8°
6°
4°
2°
0°
0
1
2
3
Time (seconds)
Figure 8 - Roll Step Response
Block Diagrams Level 1 w/ FR tables & ToO
3.2.1 – Inertial Measurement Unit (IMU) (Vince)
Figure 9 - IMU Module Block Diagram
17
4
5
6
Fink, Greczanik, Hamblin, Kirkwood
Table 3- IMU Module Functional Requirement Tables
Module
Inputs
Outputs
Functionality
Designer
3-Axis Digital Gyroscope
- Power: 3.3VDC
- Data: Angular rate for all 3 axes
Measures angular velocity for all three axes. Data is sent to microcontroller for
processing.
Vince Greczanik
Designer
3-Axis Digital Accelerometer
- Power: 3.3VDC
- Data: Linear acceleration for all 3 axes
Measures linear acceleration along all 3 axes. Data is sent to the microcontroller
for processing.
Vince Greczanik
Module
Inputs
Outputs
Functionality
Designer
3-Axis Digital Magnetometer
- Power: 3.3VDC
- Data: Magnetic field strength along all 3 axes
Measures the magnetic field strength along all 3 axes. Acts as a digital compass.
Vince Greczanik
Module
Inputs
Outputs
Functionality
Digital Ping Sensor (Total 6)
- Power: 3.3VDC
- Data: Distance from sensor to obstacle
Digital ping sensors will be mounted so that 1 is facing in each direction. One
on the bottom can be used for altitude sensing. The ones on top and on the sides
can be used for obstacle avoidance.
Vince Greczanik
Module
Inputs
Outputs
Functionality
Designer
Theory of Operation
The inertial measurement unit module consists of several sensors that are responsible for
giving the quadrotor a sense of its orientation in space. This information is used as
feedback for the controller’s control loop and helps the craft maintain stable flight. The
sensors provide faculties for the craft to determine its pitch, roll, yaw, and altitude, as
well as the ability for obstacles to be avoided.
One of the sensors used is a 3-axis digital gyroscope. Electronic gyroscopes are sensors
that measure the angular velocity about a given access. Figure 6 shows an example of a
triple-axis digital gyroscope and along what axes rotation can be measured about.
18
Fink, Greczanik, Hamblin, Kirkwood
(STMicroelectronics, 2010)
Figure 10 - Digital Gyroscope Axis Orientation
To measure the pitch and roll of the craft, the data corresponding to the respective
gyroscope axes are used. Because this data represents an angular rate it must be
integrated over time to obtain the craft’s actual angles of rotation. In an ideal world this
process would be flawless, always yielding an accurate angle. In reality, noise before the
integration will create drift in the actual angular reading.
To remedy this problem the data from the gyroscope can be fused with that from a 3-axis
accelerometer. An accelerometer is a sensor that can detect linear acceleration along a
given number of axes. As well as detecting acceleration due to change in the quadrotor’s
velocity (known as dynamic acceleration), an accelerometer can also detect acceleration
due to gravity (static acceleration). By measuring what axes static acceleration is acting
on, the craft’s tilt can be determined. This computation can provide an absolute
measurement of the quadrotor’s pitch and roll.
Using the accelerometer solely to determine pitch and roll works well and long as the
craft experiences no dynamic acceleration. However when linear acceleration is present
the numbers computed from the accelerometer become incorrect. Ultimately the best
solution is to combine the data from both the gyroscope and the accelerometer to get
fairly accurate pitch and roll calculations over all conditions. The gyroscope data is used
when dynamic acceleration is present, and the accelerometer data is used to correct the
gyroscope’s drift.
To obtain the quadrotor’s yaw angle the respective angular velocity data from the
gyroscope is integrated over time. Like for pitch and roll, drift is a big problem with this
reading. Therefore a digital magnetometer, or compass, can be used to correct the drift in
yaw angle measurement. Because magnetometers are relatively slow devices, the yaw
reading from the gyro can be used by the control algorithm, while the magnetometer data
can be used to correct the yaw angle drift when available. In our implementation the
19
Fink, Greczanik, Hamblin, Kirkwood
magnetometer is populated but not used. It was found that electromagnetic noise and
surrounding metal made the compass reading unreliable. In the future filter algorithms
should be investigated so that useful data can be derived from this sensor.
The quadrotor’s altitude is detected by an ultrasonic ping sensor mounted to the bottom
of the craft. Research indicates that ultrasonic sensors are available with ranges of up to
19 feet, more than enough to meet the design requirement stating that the craft must be
able to hover at a height of 6 feet.
Supporting circuitry for 5 additional ping sensors is present as well. These sensors can be
placed so that one is facing above the craft, and four others are facing in each of the four
lateral directions. These additional sensors could be used for obstacle detection and
avoidance.
20
Fink, Greczanik, Hamblin, Kirkwood
3.2.2 – MCU and Communication (James)
Figure 11 - Central Microcontroller and Communication Module Block Diagram
Table 4 - Central Microcontroller and Communication Module Functional Requirement Tables
Module
Inputs
Outputs
Functionality
Designer
Central Microcontroller
- Power: 3.3VDC
- Signal: Analog voltage representing battery voltage
- Signal: Analog voltage representing battery current
- Data: Angular velocity data from gyroscope
- Data: Linear acceleration data from accelerometer
- Data: Readings from magnetometer
- Data: Readings from pressure sensor
- Data: Ping sensor data
- Data: Commands received from wireless receiver
- Data: Data stored in EEPROM
- Data: Status data from motor controllers
- Data: Commands and data to EEPROM
- Data: Status information to be transmitted by wireless transmitter
- Data: Speed commands for motor controllers
The module is the central controller for the quadrotor craft. It processes all
incoming commands, all sensor data, and maintains the stability of the vehicle.
James Kirkwood
21
Fink, Greczanik, Hamblin, Kirkwood
Module
Inputs
Outputs
Functionality
Designer
Module
Inputs
Outputs
Functionality
Designer
Wireless Communication Module
- Power: 3.3VDC
- Data: Status data from the microcontroller that needs to be transmitted to the
user
- Data: Commands received from the user that will be sent to microcontroller
Allows the exchange of status and command information between the quadrotor
and user during operation.
James Kirkwood
Serial EEPROM
- Power: 3.3VDC
- Data: Data from MCU to be stored in EEPROM
- Data: Data requested from MCU that is stored in EEPROM
Stores information such as calibration data, and control coefficients in nonvolatile memory.
James Kirkwood
3.2.3 – Power Management (Kyle)
Figure 12 - Power Management Module Block Diagram
Table 5 - Power Management Module Functional Requirement Tables
Module
Inputs
Outputs
Functionality
Designer
Li-ion Battery Array
- None
- Power: 12VDC
Supply power for the quadrotor’s electronics and motors.
Kyle Hamblin
22
Fink, Greczanik, Hamblin, Kirkwood
Module
Inputs
Outputs
Functionality
Designer
Module
Inputs
Outputs
Functionality
Designer
Module
Inputs
Outputs
Functionality
Designer
Over Current Protection Network
- Power: 12VDC from Li-ion Battery Array
- Power: 12VDC
- Signal: Analog voltage that represents the amount of current being drawn from
the battery
Measures the current being drawn from the battery. Outputs a voltage that will
be interpreted by the main MCU.
Kyle Hamblin
Low Voltage Detection Network
- Power: 12VDC from Li-ion Battery Array
- Power: 12VDC
- Signal: Analog voltages that represents the current voltage of the battery
Divides the battery voltages to a level that can be read by the main MCU’s A/D
converters
Kyle Hamblin
DC/DC Buck Converter
- Power: 12VDC from Protection and Detection Modules
- Power: 3.3VDC
Regulates 12VDC down to 3.3VDC to power Microcontroller, supporting
electronics and sensors.
Kyle Hamblin
Theory of Operation
The batteries used are high-powered Li-Ion cells that do not have front end protective
electronics. Therefore it is of extreme importance that the power management system is
designed to monitor the battery pack carefully and ensure that specifications are not
exceeded. The low voltage detection network will ensure that the battery pack is not
discharged below its minimum specified voltage by obtaining the voltage of each cell
individually and calculating state of charge based on the lowest cell voltage. The over
current protection network ensures that the maximum continuous discharge current for
the battery pack is not exceeded. Under both low voltage and over current conditions, the
quadrotor will initiate the landing sequence. The DC/DC converter uses a MOSFET and
supporting passive electronics to switch the 12VDC rail to 3.3VDC. This increases
overall system efficiency and consequently increases flight time.
Design and Schematics
3.3.1 – Sensors (Vince) The inertial measurement unit (IMU) has been designed and specified for optimal craft
performance. An HMC5843 digital triple axis magnetometer has been included in the
quadrotor design to accurately provide the control system with the craft heading given
23
Fink, Greczanik, Hamblin, Kirkwood
proper filtering takes place. This compass is designed for low-field magnetic sensing
applications. The sensor has a full-scale range of 4 guass and a resolution of up to 7
milli-gauss. This unit will easily interface, via I2C, with the control system. An
ADXL345 digital triple axis accelerometer has been specified to easily meet the design
requirements. This device is well suited for mobile device applications. It measures the
static acceleration of gravity in tilt sensing applications, as well as dynamic acceleration
resulting from motion. Its high resolution (4mg/LSB) enables resolution of inclination
changes of as little as 0.25 degrees. The most important IMU component is the IMU3000. This device was selected because of its embedded 3-axis gyroscope and an internal
digital motion processor. The unit interfaces with the third party accelerometer, via I2C,
to deliver a fusion output with processed acceleration and rotational motion data. The
motion processor couples the 3-axis data from each sensor to produce a 6-axis fusion
output in the form of a quaternion.
SDA0
SCL0
Gyroscope
C?
2.2nF
7
3.3V
IMU-3000
SCL1
18
17
16
15
14
13
U45
3.3V
C?
0.1uF
20
19
18
17
16
SDA
DRDY
AVDD
AGND
VREN
HMC5843
OFFP
OFFN
NC8
SETP
SETN
6
7
8
9
10
DVDD
SETC
C1
DGND
SVDD
SDA1
3.3V
1
2
3
4
5
GND
NC17
NC16
NC15
NC14
VDD
SCL
SDAP
SCLP
TP1
TP0
SDA
SCL
CLKOUT
RESV21
CPOUT
RESV19
24
23
22
21
20
19
Magnetometer
3.3V
15
14
13
12
11
13
12
11
10
9
8
CLKIN
NC2
NC3
NC4
NC5
AUX_DA
7
8
9
10
11
12
VDD
SDA
GND2
SDO
RESV3 RESV11
GND4
NC
GND5
INT2
Vs
INT1
1
2
3
4
5
6
CS
1
2
3
4
5
6
SCL
U19
3.3V
14
Accelerometer
AUX_CL
VLOGIC
AD0
REGOUT
RESV-G
INT
U17
ADXL345
C?
0.01uF
C54
0.1uF
C?
4.7uF
Figure 13 - Inertial Measurement Unit (IMU) Schematic
Quaternions are vectors in four-dimensional space that offer a mathematical notation
allowing the representation of three dimensional rotations of objects. Quaternions also
avoid the problem of gimbal lock and, at the same time, are numerically more efficient
and stable when compared with traditional rotation matrices. Although final
implementation did not incorporate the coupled accelerometer and gyroscope or the use
of quaternions; the following calculations were left for possible future configuration of
the IMU-3000.
A rotation quaternion is defined as:
24
C?
0.22uF
Fink, Greczanik, Hamblin, Kirkwood
Equation 20 - Rotation Quaternion
cos sin
sin
sin
2
2
2
2
where q represents a rotation about a unit vector [ ] through an angle ε. The
expression of the quaternion vector elements as a function of Euler angles yields:
Equation 21 - Quaternion as Function of Euler Angles
cos
cos
cos
sin
sin
sin
cos
cos
cos
sin
sin
sin
cos
sin
cos
sin
cos
sin
sin
cos
cos
cos
sin
sin
.
In order to find the Euler angles from the quaternion differential equations, it is easiest to
find the rotation tensor S first. The quaternion equivalent of the rotation matrix,
Equation 22 - Quaternion Equivalent of Rotation Matrix
2
2
2
2
2
,
2
is used instead of calculating the Euler angles from the quaternion directly.
From Equation 22, the Euler angles are found as:
Equation 23 - Euler Angles as Function of Quaternion
tan
sin
2
.
tan
This matrix provides the craft pitch, roll, and yaw position to be used by the control
system for space orientation.
25
Fink, Greczanik, Hamblin, Kirkwood
When initially planning the project it was intended that the motion processing capabilities
of the IMU3000 would provide sufficiently accurate attitude measurements. However
after attempting to figure out the very convoluted Invensense software libraries (with no
response from the company’s support department) to no avail it was decided that an
alternative means of attitude calculation had to be used. After a little research it was
found that the Kalman filter is an often implemented, well proven method of fusing
sensor readings from gyroscopes and accelerometers. A Kalman filter is an iterative filter
that uses two or more noisy inputs to generate an accurate state measurement. In the
implementation we used, the gyroscope generates a relatively clean pitch reading, but has
drift due to the necessary integration. The accelerometer pitch readings are very noisy
(especially while the motors are running) but the noise is centered about the actual pitch.
The Kalman filter essentially uses the accelerometer data to remove the bias from the
gyroscope data. Because the math and statistics was beyond our learning curve for the
amount of time available we ended up using a Kalman filter library developed by aerial
robotics enthusiast Tom Pycke 1,2.
Overall, the implemented Kalman filter provided very satisfactory results. Figure 14
show the response of the filter. As you can see the accelerometer measurement is very
noisy, but has a bias around the actual roll value. The gyroscope reading on the other
hand is very clean, and follows the change in roll almost flawlessly. However you can see
that the raw gyro reading is offset from the actual roll value reflected in the accelerometer
data. The output of the Kalman filter combines the benefits of both datasets: the
absoluteness of the accelerometer data, and the cleanness of the gyro data to provide an
accurate pitch measurement.
6000
4000
2000
Accel Roll
0
0
500
1000
1500
‐2000
‐6000
‐8000
Figure 14 – Comparison of Roll Measurements
2
Gyro Roll
Kalman Roll
‐4000
1
2000
http://tom.pycke.be/mav/71/kalman-filtering-of-imu-data
http://tom.pycke.be/mav/92/kalman-demo-application
26
Fink, Greczanik, Hamblin, Kirkwood
The SRF02 ultrasonic sensors are a perfect fit for the quadrotor’s altitude sensing
capabilities. The device is a single transducer ultrasonic rangefinder in small footprint
PCB. Although only one sensor was populated on the bottom of the craft, the supporting
circuitry is present for up to 5 additional sensors which can be used for object avoidance.
These sensors communicate through I2C with a limit of sixteen sensors per bus. This is
more than enough for the quadrotor application, for there will only be up to two sensors
per bus. The range finder is able to effectively read from 6 inches to 21 feet. These
specifications will safely allow the craft to hover anywhere from 1 foot to 20 feet and
avoid objects with plenty of time for flight correction.
Top
North
U14
SDA0_5V
SCL0_5V
1
5V 2
3
4
5
VCC
SDA
SCL
MODE
GND
SDA1_5V
SCL1_5V
1
5V 2
3
4
5
SRF02
VCC
SDA
SCL
MODE
GND
Bottom
1
5V 2
3
4
5
SDA1_5V
SCL1_5V
1
5V 2
3
4
5
5V
R164
200k
3.3V
GND
SCL1
SDA1
1
SCL0 3
SDA0 4
VREF2
EN
SCL2
SDA2
VCC
SDA
SCL
MODE
GND
SRF02
Figure 15 - Ping Sensor Schematic
VREF1
1
5V 2
3
4
5
VCC
SDA
SCL
MODE
GND
SRF02
South
VCC
SDA
SCL
MODE
GND
U46
SDA2_5V
SCL2_5V
West
U21
SRF02
2
U16
SRF02
U20
SDA0_5V
SCL0_5V
East
U15
R162
4.75k
7
8
6
5
R163
4.75k
SCL0_5V
SDA0_5V
PCA9306
C63
0.1uF
Figure 16 - Ping Sensor Interface Circuit
27
U22
SDA2_5V
SCL2_5V
1
5V 2
3
4
5
VCC
SDA
SCL
MODE
GND
SRF02
Fink, Greczanik, Hamblin, Kirkwood
3.3.2 – Communication (James) Communication is an important part of the quadrotor’s design, but not a primary design
focus. Therefore it has been decided that a preassembled module will be used to provide
wireless communication capabilities. Experience has confirmed that the XBee modules
offer a good compromise between feature set and ease of use. Table 6 shows a
comparison between four modules that Digi manufactures that meet the design
requirement specifications of this project.
Table 6 - Comparison of Digi XBee Modules 3
Indoor
Range
Outdoor
Range
Transmit
Power
Receive
Power
Price
XBee 1.0 1mW
100ft
300ft
45mA @
3.3V
50mA
@ 3.3V
$22.95
XBee Pro 1.0
60mW
300ft
1 mile
250mA @
3.3V
55mA
@ 3.3V
$37.95
XBee 2mW
Series 2.5
133ft
400ft
45mA @
3.3V
40mA
@ 3.3V
$25.95
XBee Pro 50mW
Series 2.5
300ft
1 mile
295mA @
3.3V
45mA
@ 3.3V
$40.95
Product
Despite slight advantages in range and power consumption for the series 2.5 modules,
one of the series 1.0 modules was used for the quadrotor because their configuration and
interfacing is simpler. The added complexity in the series 2.5 modules comes from their
ability to implement mesh networking, which is unnecessary for this project.
Ultimately the 60mW series 1.0 module was used for the quadrotor because its 300ft
indoor range exceeds the design requirements and will allow the quadrotor to operate
over a larger range in the future.
3
Digi International, Inc., www.digi.com
28
Fink, Greczanik, Hamblin, Kirkwood
Once configured, the XBee modules act simply as a wireless bridge for UART based
communication, supporting data rates of up to 250 kbps. Figure 17 shows a diagram
illustrating how wireless communication was implemented in the quadrotor system. One
of the UART modules on the quadrotor’s microcontroller was configured to output data
to one of the XBee modules. On the ground side another XBee module was connected to
a serial-USB converter, allowing data to be passed to and from the XBee module from a
PC. The user is able to send commands to the quadrotor using any terminal application,
such as HyperTerminal, running on the PC.
Figure 17 - Wireless Communication Setup
Table 7 shows the pin configuration for the XBee modules. Only four of the module’s 20
pins need to be connected for basic communication: DIN, DOUT, VCC, and Ground.
29
Fink, Greczanik, Hamblin, Kirkwood
Table 7 - XBee Module Pinout 4
Pin #
1
2
3
4
5
Name
VCC
DOUT
DIN / CONFIG
D08*
~RESET
Direction
Output
Input
Output
Input
6
PWM0/RSSI
Output
7
8
9
PWM1
[reserved]
DTR / SLEEP_RQ /
DI8
GND
AD4 / DIO4
CTS / DIO7
Output
Input
Output
Input
Either
16
ON/ ~SLEEP
VREF
Associate / AD5 /
DIO5
~RTS / AD6 / DIO6
17
18
19
20
AD3 / DIO3
AD2 / DIO2
AD1 / DIO1
AD0 / DIO0
Either
Either
Either
Either
10
11
12
13
14
15
Description
Power supply
UART Data Out
UART Data In
Digital Output 8
Module Reset (reset pulse must be at least
200 ns)
PWM Output 0 / RX Signal Strength
Indicator
PWM Output 1
Do not connect
Pin Sleep Control Line or Digital Input 8
Ground
Analog Input 4 or Digital I/O 4
Clear-to-Send Flow Control or Digital I/O
7
Module Status Indicator
Voltage Reference for A/D Inputs
Associated Indicator, Analog Input 5 or
Digital I/O 5
Request-to-Send Flow Control, Analog
Input 6 or Digital I/O 6
Analog Input 3 or Digital I/O 3
Analog Input 2 or Digital I/O 2
Analog Input 1 or Digital I/O 1
Analog Input 0 or Digital I/O 0
Either
Either
Either
* Function is not supported at the time of release
3.3.4 – Motor Controllers (Joel) For the quadrotor, four pre-manufactured HobbyKing electronic speed controllers (ESCs)
were used to control the motors we used. (These were used in place of our custom
designed controllers because we were experiencing problems that we could not find an
explanation for. See the future recommendations section for a further discussion on this.)
4
XBee/XBee-PRO RF Modules Product Manual,
http://ftp1.digi.com/support/documentation/90000982_B.pdf
30
Fink, Greczanik, Hamblin, Kirkwood
Figure 18 – HobbyKing Electronic Speed Controller
The HobbyKing ESCs read a signal pulse with a duration between 0.78 and 2.0ms and
translate it to a motor speed which the controller maintains. In our implementation we
have one controller for each brushless DC motor. A dsPIC is used to provide the pulse
signals to the motor controllers. Through experimentation it was found that the ESCs can
be sent new pulses at 200Hz which update the speeds of the motors.
The dsPIC which interfaces to the four ESCs is connected to the central microprocessor
via I2C. The central processor calculates the desired motor speeds and transmits them to
the dsPIC. Figure 19 shows the software flow chart for the dsPIC software. Basically the
processor is constantly waiting for a new I2C command from the central processor. The
instant a new command is sent, pulses are sent to each of the ESCs. Originally the PWM
generator was used to create the pulses, and the duty cycle was updated whenever a new
I2C command was received. The problem with this is that the control algorithm in the
central processor and the updates to the ESCs were out of sync. In our current
implementation the pulses are in sync with the I2C commands which occur at 200Hz.
31
Fink, Greczanik, Hamblin, Kirkwood
Figure 19 – Motor Controller dsPIC Flow Diagram
Our control algorithm outputs desired motor speeds in RPM. In order to be able to
achieve the desired RPM on each motor, the four ESCs were calibrated. In order to
calibrate the controllers the actual motor RPM was plotted versus several speed command
values. A linear approximation (Figure 20) of the data was then derived and implemented
in the software to translate RPM to the proper speed commands.
8000
y = 9.3247x + 2511.4
7000
6000
5000
4000
3000
2000
1000
0
0
200
400
600
Figure 20 – Motor Controller Calibration Curve
32
Fink, Greczanik, Hamblin, Kirkwood
3.3.5 – Computation Hardware (James) The computationally intensive requirements of the quadrotor require that careful attention
be given to the choice of processor. An ARM Cortex-M3 processor was chosen for this
project because of both its familiarity and high performance. The selected part, the NXP
LPC1768, has capabilities including clock frequencies of up to 100MHz, a 32-bit core,
hardware based multiply and divide, and low interrupt latency. A more complete list of
specifications is shown in Table 8.
Table 8 - NXP LPC1768 Specifications 5,6
Program Memory (Flash)
Data Memory (RAM)
Max Clock Speed
Package
Supply Voltage
Notable Peripherals
Performance Features
512kB
32kB
100MHz
LQFP100
3.0-3.6V
4 UART modules
3 I2C modules
1 SPI module
12-bit analog-to-digital converter (8 channels)
4 32-bit timers
70 GPIO pins
Hardware divide (2-12 cycles)
Single cycle (32x32) multiply
12 cycle interrupt latency
A schematic of both the microprocessor and communication modules is shown in Figure
21. The microprocessor is clocked by a 12MHz crystal, which is multiplied up to
100MHz by an internal PLL. The LPC1768’s reset pin is connected through a pull-up
resistor to 3.3V, with an option of grounding it through a jumper. The jumper is used to
hold to processor in reset while the motor controller processors are programmed. LEDs
were populated with the microprocessor to be used for debugging purposes. Four red
LEDs are connected to four of the processor’s GPIO pins, and one yellow, and one green
LED are connected to the processor’s UART pins to give a visible indication of data
communication with the XBee module. The processor’s three I2C busses are used for
interfacing with the serial EEPROM, sensors, and motor controllers, and are configured
to operate at 400kHz. The signals containing the battery voltage and current
measurements are connected to the LPC1768’s analog input pins.
5
6
NXP LPC1768 Datasheet, http://ics.nxp.com/products/lpc1000/all/~LPC1768/
ARM Cortex-M3 website, http://www.arm.com/products/processors/cortex-m/cortex-m3.php
33
Fink, Greczanik, Hamblin, Kirkwood
Figure 21 - Schematic of Microcontroller and Communication Modules
3.3.4 – Power Management (Kyle) The batteries indicated in Figure 22 were chosen due to their high capacity and high
discharge rate. The batteries can handle a maximum discharge rate of 80A continuous
which is significantly more than the 54A the motors can potentially draw. The 10Ah
capacity also meets the specifications for 20 minutes of flight time.
With such large current draws, monitoring of the current flowing from the batteries at any
given moment becomes a concern. Since efficiency is of the utmost importance to
achieve longer flight times, the traditional current monitoring scheme of an operational
amplifier and current sense resistor becomes impractical. The ACS756 is a magnetic
current sensor with an analog output proportional to the current passed between IP+ and
IP-. With 139μΩ between IP+ and IP-, the power losses that would be encountered in a
current sense resistor are drastically reduced and that is why it was used in this design.
The TPS40200 from Texas Instruments shown in Figure 23 was chosen for this design
due to its high efficiency (90%+) at the anticipated electronics current draw of 1A. Since
it is a switching regulator, it minimizes power losses that would be experience with a
34
Fink, Greczanik, Hamblin, Kirkwood
linear regulator or zener diode. The TPS40200 was also chosen because the design team
has extensive experience with this part from previous projects, which will aid in the
troubleshooting process.
The Linear Technology LTC1754 charge pump in - 5V Charge PumpFigure 24 was
selected because of its small package, low power dissipation, and due to the fact that the
selected ping sensors operate on 5V.
35
Fink, Greczanik, Hamblin, Kirkwood
ACS756
4
IP+
3.3V
VCC
3
VIOUT
R49
10.0k
2
C26
0.1uF
GND
U12
1
BT1
3.7V 10Ah
PL-9959156-10C
Vbatt
5
IP-
BATT_CURRENT
BT2
3.7V 10Ah
PL-9959156-10C
R51
36.0k
C28
0.1uF
BATT_VOLTAGE
BT3
3.7V 10Ah
PL-9959156-10C
R53
10.0k
C33
0.1uF
Figure 22 - Battery Monitor Schematic
Vbatt
C24
C25
0.01uF
50V
0.22uF
25V
8
R52
25.5k
SS
ISNS
U13
COMP GDRV
3
6
4
C29
3
1.00k
7
Q7
FDC654P
3.3V
L1
1
2
5
6
C27
R50
VDD
2
RC
FB
1
470pF
R48
0.051
1/4W
470pF
GND
R47
41.2k
5
C23
22uF
25V
4
C22
22uF
25V
TPS40200D
10uH
C30
1000pF
D7
DFLS230L
R55
2.55k
R54
25.5
1/8W
R56
49.9k
C31
C32
47uF
6.3V
0.1uF
10V
C35
C34
330pF
68pF
FB
R57
8.06k
Figure 23 - Switching Regulator Schematic
5V
U44
1
C55
10uF
3.3V
2
3
Vout
C+
GND Vin
nSHDNC-
6
5
C56
1uF
4
3.3V
C57
10uF
LTC1754
Figure 24 - 5V Charge Pump Schematic
3.3.5 – Central Microcontroller Software (James) Figure 25 shows a diagram illustrating the flow of the quadrotor’s main software
application. The software starts in an initialization phase, where the various peripherals,
sensors, and interrupts are configured, and then moves into the application’s main loop,
where the brunt of the system’s calculation is carried out. Throughout the quadrotor’s
36
Fink, Greczanik, Hamblin, Kirkwood
operation various interrupts will be triggered to handle different processes. Table 9 lists
all of the interrupts actively used in this application. These will be covered in more detail
later in the report.
Figure 25 - Flow Diagram of Main Application
Table 9 - List of Interrupts Used in Application
Interrupt
Timer 0
Timer 1
Timer 2
External Interrupt
1
UART 2
I2C 0
I2C 1
I2C 2
Purpose
Regulates timing for landing algorithms (every
100ms)
Indicates when ping sensor data is ready to be read
(every 70ms)
Indicate when power measurements of the battery
should be taken. Also sets rate that data stream is
outputted (every 40ms).
Indicates when IMU data is ready to be read (every
5ms)
Triggers function to process incoming characters.
Loads new character from TX buffer when
transmitter is idle
Used to control I2C data transfer
Used to control I2C data transfer
Used to control I2C data transfer
Priority
(0 highest,
31 lowest)
3
2
3
1
4
0
0
0
Main Loop
Most of the system’s calculation and sensor interfacing is carried out in the application’s
main loop. Before discussing the main loop it is crucial to understand the five interrupt
handlers shown in Figure 26. Each one of these handlers occurs periodically when a
certain sensor should be ready to have its data read, or when a certain action needs to
occur. There is one each for the IMU-3000, the ping sensors, the digital compass, the
power monitoring algorithm, and whenever a character is received on the UART. When
37
Fink, Greczanik, Hamblin, Kirkwood
one of the interrupts occurs, a corresponding flag bit is set indicating that a particular
action is ready to be taken.
Figure 26 - Sensor Data Ready Interrupts
Figure 27 shows a flow diagram of the application’s main loop. Note that there is a check
for each of the five flag bits mentioned in Figure 26 within the loop. If a flag for a
particular action is set, an algorithm will be run to read and process data from the
particular sensor. Otherwise that part of the code will be bypassed for the rest if the
current loop iteration.
38
Fink, Greczanik, Hamblin, Kirkwood
Figure 27 – High Level Flow Diagram of Main Loop
The first check in Figure 27 is of the receivedCharReady flag. This variable is set
whenever the UART received a character from the user. When this flag is set the
evaluateUserInput module is executed. This module is described in Table 10.
39
Fink, Greczanik, Hamblin, Kirkwood
Table 10 - evaluateUserInput Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
evaluateUserInput
c: character received by UART
None
Processes characters received by the UART and checks to see if the
inputted sequence matches a valid command. The user is alerted if
they enter an invalid command. If the user enters a valid sequence
of characters the corresponding command is executed.
beginTakeoffSequence, beginLandingSequence
By main loop when receivedCharReady is set.
Next the IMUDataReady flag is checked. This flag is set whenever the IMU3000 IC has a
new set of accelerometer and gyroscope data available in its buffer. The data is retrieved
using the getIMUData module. The IMU data is then passed to the getAttitude module
where the gyro and accelerometer data is fused via a pair of Kalman filters to get an
accurate measurement of the craft’s pitch and roll angles. If the craft is on the ground
(currentlyGrounded is set) a command is sent to turn off the motors, and all the control
parameters (integtators, setpoints, etc) are reset. If the craft is flying (currentlyGrounded
is cleared) the newly obtained attitude information is passed to the
runAttitudeControlLoop function where PID controllers will determine the motor speeds
necessary to keep the quadrotor stable. The motors are then set to the desired speeds
through the setMotorSpeeds module. Table 11 through Table 16 describe the modules run
when IMUDataReady is set.
Table 11 - getIMUData Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
getIMUData
None
imuData: a structure containing the raw data from the IMU3000 IC.
Sends an I2C command to the IMU IC requesting that all
accelerometer and gyroscope data be sent to the microcontroller.
I2CBegin, I2CWaitUntilIdle
By main loop when IMUDataReady is set (every 5ms)
40
Fink, Greczanik, Hamblin, Kirkwood
Table 12 - getAttitude Module Summary
Module Name
getAttitude
imuData: a structure containing the raw data from the IMU3000 IC.
Input Arguments
Output Arguments attitude: a structure containing the quadrotor’s pitch, roll, and yaw
angles in degrees, and altitude in cm
Merges accelerometer, and gyroscope data to calculate an accurate
Description
measurement of the quadrotor’s pitch and roll angles, as well as it’s
yaw rate.
Modules Invoked None
By main loop when IMUDataReady is set (every 5ms)
How Invoked
Table 13 - runAttitudeControlLoop Moule Description
Module Name
Input Arguments
runAttitudeControlLoop
attitude: a structure containing the quadrotor’s pitch, roll, and yaw
angles in degrees, and altitude in cm
attitudeSetpoint: a structure containing the quadrotor’s desired
pitch, roll, and yaw angles in degrees, and altitude in cm
Output Arguments motorSpeeds: a structure containing desired speeds for each of the 4
motors
Contains the controller for the quadrotor’s attitude (pitch, roll, and
Description
yaw). Processes feedback from the attitude structure to calculate
updated motor speeds which will cause the craft to operate at the
desired setpoints while maintaining stability.
Modules Invoked None
By main loop when IMUDataReady is set (every 5ms)
How Invoked
Table 14 - updateMotorSpeeds Module Summary
Module Name
Input Arguments
setMotorSpeeds
motorSpeeds: a structure containing desired speeds for each of the
4 motors
Output Arguments None
Sends 8 bytes to the motor controller interface processor indicating
Description
the desired speeds for each of the 4 motors.
Modules Invoked I2CBegin, I2CWaitUntilIdle
By main loop when IMUDataReady is set (every 5ms) while craft
How Invoked
is running.
41
Fink, Greczanik, Hamblin, Kirkwood
Table 15 - turnOffMotors Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
turnOffMotors
None
None
Sends a command to the motor controller interface processor to
turn off all 4 motors.
I2CBegin, I2CWaitUntilIdle
By main loop when IMUDataReady is set (every 5ms) while craft
is grounded.
Table 16 - resetControlParameters Module Summary
Module Name
Input Arguments
resetControlParameters
attitudeSetpoint: a structure containing the quadrotor’s desired
pitch, roll, and yaw angles in degrees, and altitude in cm
Output Arguments None
Resets all parameters in the quadrotors control loop (PID
Description
components, setpoints, etc.)
Modules Invoked None
By main loop when IMUDataReady is set (every 5ms) while craft
How Invoked
is grounded.
The pingDataReady flag is set every 70ms, when the ping sensor has completed its latest
reading. When this flag is set the latest reading is fetched from the sensor, and a new ping
burst is triggered. The runAltitudeControlLoop module is then run using the retrieved
data. The motor speeds will reflect the changes from this module the next time the
runAttitudeControl loop function is run. Table 17 through Table 19 describe the modules
invoked when the pingDataReady flag is set.
Table 17 - getPingRanges Module Summary
Module Name
getPingRanges
None
Input Arguments
Output Arguments pingRanges: a structure containing the ranges in cm measured by
each of the 6 ping sensors
Reads the measured ranges from each of the 6 ping sensors over
Description
I2C.
Modules Invoked I2CBegin, I2CWaitUntilIdle
By main loop when pingDataReady is set (every 70ms)
How Invoked
42
Fink, Greczanik, Hamblin, Kirkwood
Table 18 - pingStartBursts Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
pingStartBursts
None
None
Sends an I2C command to each of the 6 ping sensors to initiate an
ultrasonic burst. This begins the measurement process.
I2CBegin, I2CWaitUntilIdle
By main loop when pingDataReady is set (every 70ms)
Table 19 - runAltitudeControlLoop Module Summary
Module Name
Input Arguments
runAltitudeControlLoop
attitude: a structure containing the quadrotor’s pitch, roll, and yaw
angles in degrees, and altitude in cm
setpoints: a structure containing the quadrotor’s desired pitch, roll,
and yaw angles in degrees, and altitude in cm
Output Arguments None
Contains the controller for the quadrotor’s altitude. Processes
Description
feedback from the attitude structure to calculate updated motor
speeds which will cause the craft to operate at the desired altitude
while maintaining stability.
Modules Invoked None
By main loop when pingDataReady is set (every 70ms)
How Invoked
When the powerDataReady flag is set, the battery power information (voltage for each
cell, and current) are read by using the getPowerData module. The power data is then
passed to the checkPowerLevels module which will make sure the voltage is above the
proper minimums, and the current is below the maximum level. If the cell voltage drops
to a low level, the craft will land. If the current limit is exceeded, the altitude setpoint will
be reduced until the current is within compliance. Table 20 and Table 21 detail the
modules called when powerDataReady is set.
43
Fink, Greczanik, Hamblin, Kirkwood
Table 20 - getPowerData Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
getPowerData
None
batteryVoltage: battery’s voltage in mV
batteryPercent: battery’s remaining charge in percent
batteryCurrent: battery’s current in mA
Reads the A/D converter values for the channels connected to the
battery voltage, and current sensors and converts values to mV and
mA respectively. The battery voltage is compared to values in a
lookup table in order to derive the battery’s remaining percent
charge.
ADCLastReading
By main loop when powerDataReady is set (every 40ms)
Table 21 - checkPowerLevels Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
checkPowerLevels
batteryVoltage: battery’s voltage in mV
batteryPercent: battery’s remaining charge in percent
batteryCurrent: battery’s current in mA
None
Checks the battery’s current voltage and current levels. If the
charge falls below 20% the function has a warning message sent to
the user. If the voltage falls below 10 a warning message is sent to
the user and the quadrotor is commanded to land. If the battery
current limit is exceeded, a warning message is sent to the user and
the altitude setpoint is decreased until the limit is no longer
exceeded.
The following global variables are affected by this module
batteryOvercurrent: flag that is set when battery current limit is
exceeded
battery20Pct: flag that is set when battery charge drops below 20%
battery10Pct: flag that is set when battery charge drops below 10%
beginLandingSequence, sendUserMessage
By main loop when powerDataReady is set (every 40ms)
Takeoff and Landing
The takeoff and landing processes are initiated by calls of the modules
beginTakeoffSequence, and beginLandingSequence respectively (Table 22 and Table
23). These modules are simply used to set and clear flag bits which are checked by the
44
Fink, Greczanik, Hamblin, Kirkwood
takeoff and landing algorithm (Figure 28). This algorithm is run in the main loop
whenever takeLandStepReady is set.
Figure 28 - Flow Diagram of Takeoff and Landing Algorithm
When beginTakeoffSequence is called, the global variable currentlyTakingOff is set.
When the Timer 0 interrupt occurs (every 100ms), the state of currentlyTakingOff is
checked. If it is set, the algorithm will increase the altitude setpoint by a certain amount
until its next iteration. If the handler sees that the quadrotor’s altitude is greater than
30cm, it will know that the takeoff process is complete and thus clear the
currentlyTakingOff flag. The same happens in reverse for the landing process; the
algorithm will decrease the quadrotor’s altitude setpoint as long as currentlyLanding is
set. The steady update of the altitude setpoint over time allows the craft to make smooth
ascents and descents.
The landing algorithm is also employed by the checkPowerLevels module. If the
batteryOvercurrent flag is set by the module the craft will smoothly descend until the flag
is cleared by checkPowerLevels.
45
Fink, Greczanik, Hamblin, Kirkwood
Table 22 - beginTakeoffSequence Module Summary
Module Name
Input Arguments
Output Arguments
Description
beginTakeoffSequence
None
None
Begins process that lifts quadrotor off ground. Has message sent to
user that landing takeoff has begun. The actual takeoff process is
handled in the Timer 3 interrupt.
currentlyGrounded must be set in order for this function to work!
Modules Invoked
How Invoked
The following global variables are affected by this module
currentlyTakingOff: this flag is set
currentlyGrounded: this flag is cleared
sendUserMessage
By user command
Table 23 - beginLandingSequence Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
beginLandingSequence
None
None
Begins process that lands quadrotor. Has message sent to user that
landing sequence has begun. The actual landing process is handled
in the Timer 3 interrupt. This module always overrides
beginTakeoffSequence.
The following global variables are affected by this module
currentlyTakingOff: this flag is cleared
currentlyLanding: this flag is set
sendUserMessage
By user command, by checkPowerLevels module
Low Level Modules
A number of the main processor’s peripherals are used in order to for the quadrotor
function effectively. In order to more easily utilize these peripherals a series of low level
modules have been designed to interface with them. Modules have been designed to work
with the UART, the I2C busses, and the analog to digital converter (ADC).
The LPC1768 processor has 3 I2C busses that can be used. To take advantage of this, the
I2C devices have been allocated in order to optimize I2C throughput. Table 24 lists all of
the I2C devices that are available, and the busses they are assigned to. While footprints
46
Fink, Greczanik, Hamblin, Kirkwood
are available on the PCB for each of the devices in Table 24, not all are used in the final
implementation of this project.
Table 24 - List of I2C Devices Used
I2C Bus #
Devices
0
EEPROM
IMU-3000
Ping - Top
Ping - Bottom
1
Digital Compass
Ping - North
Ping - South
Motor Controller North
Motor Controller - East
2
Pressure Sensor
Ping - East
Ping - West
Motor Controller South
Motor Controller - West
Note that the ping sensors have been configured such that two of them are connected to
each bus. This arrangement allows three of the sensors to be read at any given time,
cutting the time required for communication in third compared to if each sensor were on
a single bus. The same concept was in mind when the motor controllers were assigned to
I2C busses.
In order to allow multiple I2C busses to be active at a given time special attention has to
be given to the design of the interface modules. For this application two modules are used
to work with I2C transfers: I2CBegin and I2CWaitUntilIdle (Table 25 and Table 26).
When a transfer needs to be initiated I2CBegin is called. I2CWaitUntilIdle is then called
and the program will pause until the transfer on the selected bus has completed. Calling
I2CBegin for each bus before calling I2CWaitUntilIdle will initiate 3 simultaneous data
transfers.
47
Fink, Greczanik, Hamblin, Kirkwood
Table 25 - I2CBegin Module Summary
Module Name
Input Arguments
I2CBegin
busNum: I2C bus over which to communicate (Can be 0-2)
address: 7-bit I2C slave address
numWrite: number of bytes to write to slave
numRead: number of bytes to read from slave
Output Arguments None
Initiates an I2C transfer over the selected bus. Before an I2C write
Description
begins, the I2CxBuffer[] array must be filled with each data byte
that will be written. When data is read from the slave, the received
data is placed in the I2CXBuffer[] starting at the index after the last
written byte.
Example: To write 2 bytes and to read 2 bytes
I2C0Buffer[0] = firstByteToWrite;
I2C0Buffer[1] = secondByteToWrite;
I2CBegin( 0, slaveAddress, 2, 2);
I2CWaitUntilIdle( 0 );
Modules Invoked
How Invoked
firstReadByte = I2C0Buffer[2];
secondReadByte = I2C0Buffer[3];
None
Anytime I2C communication is necessary
Table 26 - I2CWaitUntilIdle Module Summary
Module Name
I2CWaitUntilIdle
busNum: I2C bus to wait for
Input Arguments
Output Arguments errorCode: a value representing a certain error on the I2C bus.
0 if transfer completes successfully
1 if NACK is received from slave device
2 if I2C bus times out
Waits until selected I2C bus has finished a transfer, or encountered
Description
an error. Must be called after I2CBegin. This function will return
the
Modules Invoked None
Anytime I2C communication is necessary
How Invoked
The LPC1768’s ADC will be configured to operate in burst mode. In burst mode the
ADC constantly cycles through each active input channel, taking samples and storing the
digitized result in the respective register. This mode is advantageous in that it causes the
converter to operate automatically, eliminating most of the processing overhead required
48
Fink, Greczanik, Hamblin, Kirkwood
to run the module. One software module is available to interface with the analog to digital
converter: ADCLastReading (Table 27). This module simply reads the last converted
value for a selected channel.
Table 27 - ADCLastReading Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
ADCLastReading
channel: the ADC channel to retrieve data from
data: digitized value of the voltage read from selected channel
Retrieves value from the last analog-to-digital conversion
performed on the selected channel. Note that the ADC is
configured to constantly run in the background. This function does
not initiate the sample of a channel; it merely retrieves the value
measured from the latest sample.
None
Anytime an analog input needs to be read
For communication to and from the user, one of the LPC1768’s four UARTs peripherals
will be used. When data is transmitted to the user, a string of characters is added to a
circular buffer by the UARTPutChar module (Table 28). The UART interrupt will be
configured such that it will be triggered whenever the UART is idle and ready to transmit
a new byte. When this interrupt occurs, the UARTSendNextChar (Table 29) module is
called and will load the next byte in the buffer into the UART transmit holding register.
This interrupt based configuration is advantageous because it is not necessary for the
processor to sit idle while a byte is being clocked out. Figure 29 shows a flow diagram of
the modules involved in data transmission.
49
Fink, Greczanik, Hamblin, Kirkwood
Figure 29 - UART Transmission Flow Diagrams
Table 28 - UARTPutChar Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
UARTPutChar
c: character to be transmitted by UART
None
Adds a character to the UART circular buffer to be transmitted.
None
Whenever data is sent out through the UART.
Table 29 - UARTSendNextChar Module Summary
Module Name
Input Arguments
Output Arguments
Description
Modules Invoked
How Invoked
UARTSendNextChar
None
None
Adds the next character in the UART circular buffer to the UART
TX register.
None
By the UART TX interrupt handler. (Whenever the UART TX
register is empty)
50
Fink, Greczanik, Hamblin, Kirkwood
User Interaction
The quadrotor’s software facilitates a certain level of interaction between the craft and
the user. The user will be able to set commands to the craft (takeoff, land, change
altitude, etc.) as well as request runtime data (battery voltage, current, etc.). Status
messages will also be sent to the user automatically when certain conditions occur.
Each of the commands has a unique initial character that isused to identify the command.
Additionally some commands require the user to enter a value or parameter that will be
used by the command. To see the comprehensive list of commands available, look in the
operation manual contained in this report.
Table 30 lists all the status messages that the quadrotor can send to the user, and under
what conditions they are sent. When a message is to be sent to the user the module
sendUserMessage (Table 31) is called and passed a unique message ID corresponding to
the desired message type. sendUserMessage is essentially a lookup table that has a
predefined message transmitted based on the input key, in this case “messageID”.
51
Fink, Greczanik, Hamblin, Kirkwood
Table 30 - List of Status Messages
Message
“Battery 20%”
Message ID
MSG_BATT_10PCT
Parameter
When Sent
When battery charges
falls below 20%
“Battery 10%”
MSG_BATT_20PCT
When battery charges
falls below 10%
“Battery
MSG_BATT_OVERCUR When battery
Overcurrent”
maximum current
level is exceeded
“Ping Sensor
MSG_PING_FAIL
Ping sensor When I2C
Failure:
#
communication with
#<parameter>”
ping sensor fails
“Motor I2C Failure: MSG_MOT_I2C_FAIL
Motor
When I2C
#<parameter>”
controller # communication with
motor controller fails
“IMU Failure”
MSG_IMU_FAIL
When I2C
communication with
IMU fails
“Accelerometer
MSG_ACCEL_FAIL
When I2C
Failure”
communication with
Accelerometer fails
“Beginning
MSG_TAKEOFF_BEGIN When quadrotor
Takeoff”
begins takeoff
“Takeoff
MSG_TAKEOFF_DONE When quadrotor
Complete”
completes takeoff
“Beginning
MSG_LAND_BEGIN
When quadrotor
Landing”
begins landing
“Landing
MSG_TAKEOFF_DONE When quadrotor
Complete”
completes landing
Table 31 - sendUserMessage Module Summary
Module Name
Input Arguments
sendUserMessage
messageID: a value representing the desired message to be sent to
user.
parameter: an optional argument that is used with certain messages.
Output Arguments None
This function is called whenever a status message is to be sent to
Description
the user. Sends approproiate message based on messageID.
Modules Invoked UARTPutChar
Whenever a status message is sent to the user.
How Invoked
52
Fink, Greczanik, Hamblin, Kirkwood
3.3.6 – PCB Design Figure 30 – PCB Layout – Top Copper
53
Fink, Greczanik, Hamblin, Kirkwood
Figure 31 – PCB Layout – Inner Copper 1
54
Fink, Greczanik, Hamblin, Kirkwood
Figure 32 – PCB Layout – Inner Copper 2
55
Fink, Greczanik, Hamblin, Kirkwood
Figure 33 – PCB Layout – Bottom Copper
Parts List Table 32 - Parts List
Quantity Part Reference 4
M1,M2,M3,M4
1
-
Part Number Description KDA20-22L
BLDC Motor
19-502-3mx10
Prop mounts
2
P1,P3
10x47SF
10x4.7 Prop - puller
2
P2,P4
10x47SFP
10x4.7 Prop - pusher
PVC U Channel,
5'x0.51"x0.59"x0.06"
100 qty: Nylon 6/6 Acorn Nut
1/4"-20
1
-
85065K33
1
-
94922A029
56
Fink, Greczanik, Hamblin, Kirkwood
1
-
94812A116
1
-
98743A330
100 qty: Nylon 6/6 Hex Nut
1/4"-20
5' Nylon Threaded Rod 1/4"-20
1
-
2882K35
1' Length 3" Wide Nylon Block
6
B1,B2,B3
PL-9959156-10C
3.7V 10Ah High Power Li-Ion
Cells
1 C52 GRM188R71H331KA01D 1 C53 C0805C680J5GACTU 2 C54,C55 EEE‐FP1E471AP 1 C58 GRM188R61A105KA61D 1 C67 GRM188R71H222KA01D 3 C70,C74,C75 GRM188R71C105KA12D 1 C73 GRM188R60J475KE19D 4 C76‐C79 C1608X7R1H104K 5 2 1 D1‐D4,D8 D5,D7 D6 LTST‐C190KRKT LTST‐C190KGKT LTST‐C190KSKT 1 D15 DFLS230L‐7 1 J1 90120‐0763 1 J2 GRPB052VWVN‐RC 3 3 J3,J5,J7 J4,J13,J16 039303035 90120‐0766 1 1 J9 J11 039303035 42820‐4212 1 J12 90120‐0764 1 J14 0702462004 1 J15 90131‐0764 1 L1 LPS6225‐103ML CAP ‐ Ceramic 330pF 50V 10% X7R 0603 CAP ‐ Ceramic 68pF, 5%, 50V, NPO, 0805 CAP ‐ Electrolytic 470uF 25V SMD CAP ‐ Ceramic 1uF 10V 10% X7R 0603 CAP ‐ Ceramic 2200pF 50V 10% X7R 0603 CAP ‐ Ceramic 1uF 16V 10% X7R 0603 CAP ‐ Ceramic 4.7uF 6.3V 10% X5R 0603 CAP ‐ Ceramic 0.1uF 16V 10% X7R 0603 LED ‐ Red Clear Lens SMD 0603 LED ‐ Red Clear Lens SMD 0603 LED ‐ Yellow Clear Lens SMD 0603 Diode ‐ Schottky DFLS230L, 2A, 30V, PowerDI‐123 SMD CONN ‐ 1x3 0.100" Pitch Through Hole CONN ‐ 2x5 0.050" Pitch Through Hole CONN ‐ 1x3 0.100" Pitch Through Hole CONN ‐ 1x4 Mini Fit Sr 50A Through Hole RA CONN ‐ 1x4 0.100" Pitch Through Hole CONN ‐ 2x20 0.100" Pitch Through Hole CONN ‐ 2x4 0.100" Pitch Through Hole Inductor ‐ 10uH, 20%, 2.1A, 0.202 Ohm, LPS6225, SMD 57
Fink, Greczanik, Hamblin, Kirkwood
1 Q25 FDC610PZ 10 R1,R11,R32,R172‐
R178 R2,R12,R21 CRCW060310K0FKEA 3 12 CRCW0603200KFKEA ERJ‐3EKF2610V RES ‐ 261 Ohm 1/10W 1% 0603 SMD 3 R3‐R6,R13‐
R16,R19,R20,R22,R2
3 R7‐
R10,R17,R18,R55,R5
6 R27,R31,R35 CRCW06030000Z0EA 3 R37,R46,R47 CRCW0603200RFKEA 1 R164 CRCW060341K2FKEA 1 R165 MCR10EZHFSR051 1 R166 CRCW06031K00FKEA 1 R167 CRCW060325K5FKEA 1 R168 CRCW06032K55FKEA 1 R169 CRCW080525R5FKEA 1 R170 CRCW060349K9FKEA 1 R171 CRCW06038K06FKEA 1 U1 LPC1768FBD100,551 3 U2,U3,U5 PCA9306DP,118 1 U4 XBP24‐AWI‐001 1 1 U6 U9 24AA256‐I/ST DSPIC33FJ32GP302‐I/MM 1 U27 TPS40200D 1 U28 ACS756 1 U29 LTC1754ES6‐5 RES ‐ 0 Ohm 1/10W 1% 0603 SMD RES ‐ 200 Ohm 1/10W 1% 0603 SMD RES ‐ 41.2k Ohm 1/10W 1% 0603 SMD RES ‐ 0.051 Ohm 1/4W 1% 0805 SMD RES ‐ 1.00k Ohm 1/10W 1% 0603 SMD RES ‐ 25.5k Ohm 1/10W 1% 0603 SMD RES ‐ 2.55k Ohm 1/10W 1% 0603 SMD Res ‐ 25.5 Ohm 1/8W 5% 0805 SMD RES ‐ 49.9k Ohm 1/10W 1% 0603 SMD RES ‐ 8.06k Ohm 1/10W 1% 0603 SMD IC ‐ LPC1768 Cortex‐M3 512KB Flash LQFP‐100 IC ‐ Level Translator Oprn Drain Bidirectional TSSOP8 Module ‐ XBEE Pro 60mW WireAntenna IC ‐ EEPROM I2C 256kb TSSOP8 IC ‐ dsPIC MCU/DSP 32K Flash QFN28 IC ‐ TPS40200D Buck Conv 3A 46V, SOIC8 IC ‐ Magnetic Current Sense ANALOG 5PIN UNIQUE IC ‐ LTC1754 Charge Pump 5.0V 8 CRCW06034K75FKEA MOSFET ‐ FDC654P, P‐CH, 30V, 3.6A, 0.075 Ohm, SuperSOT6 RES ‐ 10.0k Ohm 1/10W 1% 0603 SMD RES ‐ 200k Ohm 1/10W 1% 0603 SMD RES ‐ 4.75k Ohm 1/10W 1% 0603 SMD 58
Fink, Greczanik, Hamblin, Kirkwood
1 U30 IMU‐3000 1 U31 HMC5843 1 U32 ADXL345 6 U33‐U35,U37‐U39 SRF02 1 Y1 ECS‐120‐20‐5PDN‐TR 50mA SOT23‐6 IMU‐3000 Triple Axis Gyroscope With MPU IC ‐ HMC5843 Digital Triple Axis Magnetometer IC ‐ Triple Axis Accelerometer I2C/SPI LGA14 Module ‐ SRF02 Ultrasonic Range Finder Crystal ‐ 12.00MHz 20pF SMD Operation, Maintenance, and Repair Instructions Charging the Battery The 3 cell Lithium Ion battery pack must be charged using three 4.2V floating power
current limited to 3.8A. During initial charge, the batteries should pull current at the
3.8A maximum. When the supplies voltage limit with a current draw of approximately
300mA, the batteries are fully charged. Batteries should always be monitored when they
are charging for overheating or any other signs of fault.
Warning: Ensure the outputs of the power supplies are enabled before connecting
batteries. Because the power supply terminals are at low resistance when the supplies are
off or disabled, failure to do this can short the battery and cause substantial damage!
Calibration and Startup The following steps should be followed when operating the Quadrotor:
1. Ensure the area is clear and proper safety is in place.
2. Connect the XBee wireless unit to the USB port on the computer.
3. Connect to the proper serial port on the computer using a serial terminal program
at 19200 bps.
4. Plug the battery into the Quadrotor. The motors should initialize (a buzzing noise
is heard) and a welcome message will appear in the terminal window.
5. Before flying, ensure the vehicle is stationary and calibrate the gyroscope by
pressing “C” followed by Enter.
6. Use the commands listed in Table 33 to control the Quadrotor.
7. Running a motor test before flight by entering “T 20” is recommended to ensure
all motors are operating properly.
59
Fink, Greczanik, Hamblin, Kirkwood
Table 33 – Quadrotor Commands
Command
Take-Off*
Landing Sequence
Operate at Constant
Uz
Set Altitude Setpoint
Set Motor Speeds
Calibrate
Gyroscope*
Edit EEPROM
Parameters*
Read Altitude
Setpoint
Set Yaw Rate
Setpoint
Read Current Yaw
Rate
Set Pitch Setpoint
Input
‘T’
‘L’
‘T x’
x: value to hold Uz at
-
‘A x’
‘T x’
‘C’
x: altitude in cm
x: motor speed
-
-
‘E’
-
‘a’
-
EEPROM Parameter
Menu
Altitude in cm
‘Y x’
x: yaw angle rate in
1/100 degrees
-
Read Current Pitch
‘p’
Set Roll Setpoint
‘R x’
Read Current Roll
‘r’
x: roll angle in 1/100
degrees
-
Read Battery Voltage
Percent
Read Battery Voltage
Read Battery
Current
Read Motor Speed
Read Ping Sensor
‘q’
-
‘v’
‘i’
-
‘m x’
‘p x’
x: motor #
x: ping sensor #
Enable Data Output
Disabled Data
Output
Clear Command
Buffer
Emergency Stop
‘[‘
‘]’
-
*
‘y’
‘P x’
Parameter(s)
x: pitch angle in 1/100
degrees
-
Returns
Yaw angle rate in
1/100 degrees
Pitch angle in 1/100
degrees
Roll angle in 1/100
degrees
Battery charge in
percent
Battery voltage in mV
Battery current in mA
Motor speed
Ping sensor reading in
cm
-
Backspace -
-
‘!’
-
-
Command is only functional when quadrotor is grounded.
60
Fink, Greczanik, Hamblin, Kirkwood
The EEPROM parameter menu allows an operator to set certain control parameters while
the vehicle is landed and idle. Table 34 describes these parameters.
Table 34 - EPROM Parameters
Option
1
2
3
4
5
6
7
8
9
0
A
B
C
D
E
F
Title
G
Roll Kp
Roll Ki
Roll Kd
Pitch Kp
Pitch Ki
Pitch Kd
Altitude Kp
Altitude Ki
Altitude Kd
Yaw Kp
Yaw Ki
Yaw Kd
Minimum Ping Altitude
Initial Altitude Setpoint
Uz Landing Interval
Landing Altitude
Interval
Uz Landing Cutoff
H
I
J
X
Uz Minimum
Uz Maximum
Uz Null Point
Exit
Description
Roll PID Controller, Proportional Constant
Roll PID Controller, Integral Constant
Roll PID Controller, Derivative Constant
Pitch PID Controller, Proportional Constant
Pitch PID Controller, Integral Constant
Pitch PID Controller, Derivative Constant
Altitude PID Controller, Proportional Constant
Altitude PID Controller, Integral Constant
Altitude PID Controller, Derivative Constant
Yaw PID Controller, Proportional Constant
Yaw PID Controller, Integral Constant
Yaw PID Controller, Derivative Constant
Minimum Altitude for Valid Ping Sensor Data
Initial Altitude setpoint at Takeoff
Decrement Uz by this amount every 100ms during landing
Decrement altitude setpoint by this amount every 100ms
during landing sequence
Turn off motors when Uz is below this value during landing
sequence
Absolute Minimum Uz Value
Absolute Maximum Uz Value
Uz Value at Which Quadrotor will Hover
Data Output When data output is enabled, continuous scrolling data will be outputted to the
terminal. Table 35 describes each column of this data.
Table 35 – Output Data Description
Data
Count
Units
Description
Counts data points, Useful for plotting
data
Uz Control Parameter, Relative Lift
Needed
Current Draw
Battery Voltage
Integer
Uz
Battery Current
Battery Pack Voltage
Roll Angle
Pitch Angle
Amps
100ths of a Volt
100ths of a Degree
100ths of a Degree
61
Fink, Greczanik, Hamblin, Kirkwood
Yaw Rate
North Motor Speed
South Motor Speed
East Motor Speed
West Motor Speed
Altitude
100ths of a Degree / second
Relative Unit, from 1 to 4000
Relative Unit, from 1 to 4000
Relative Unit, from 1 to 4000
Relative Unit, from 1 to 4000
Millimeters
Mechanical Maintenance Checklist:
•
•
•
•
•
•
Tighten all screws and nuts.
Make sure the PCB is securely attached to the device with the positive x-axis
towards the South motor.
Ensure the tether cable is securely connected.
Check for tilted motors, that is, motors not facing directly up.
Check for damaged props. (North and South are pusher props. East and West are
puller props.)
Ensure motors are spinning in the correct direction. Switching two of the wires
going from a motor controller to a motor will reverse motor direction.
Testing Procedure Quadrotor implementation and testing can be divided down into seven logical, though not
necessarily chronological, sections, safety considerations, hardware construction, board
layout, board population and wiring, individual component testing, single axis testing, zaxis and yaw testing. In each of these steps a number of unexpected problems were
solved.
The first step in building and testing the Quadrotor was to consider the safety concerns
associated with having four propellers spinning at high speeds. These precautions
included building a metal screen which was especially important for early testing when
the stability of the Quadrotor was uncertain. Figure 34 shows this structure. In addition,
a strong tether was connected between the Quadrotor and an area cleared around the
Quadrotor to prevent injury to people or damage to the Quadrotor. Also, a sign was put
up warning that high speed blades could be dangerous.
62
Fink, Greczanik, Hamblin, Kirkwood
Figure 34 - Safety Enclosure
Next, the physical frame and landing skids were built with a continuous focus on
lightweight materials, strength, rigidity, and symmetry. This was done in order to
provide a solid base on which to operate the Quadrotor electronics. Symmetry was
important because it takes strain off of the control system, using the natural balance of the
frame and low center of gravity for stability.
FreePCB, a freeware layout program, was used to develop the PCB board. Though
Cadence was considered, it was decided that the learning curve was to steep to warrant
the effort for a single PCB. However, Cadence Orcad Capture was used for schematic
layout. After multiple layout checks, two 4-layer 2oz copper boards were ordered from
Golden Phoenix PCB. Two ounce copper was considered a necessity because of the high
current draw necessary to power the four brushless DC motors.
After the boards were received, it was necessary to populate them and begin
programming and testing. At this point, the necessary wires and connectors were also
built to interface the motors and power source with the PCB board.
Testing proceeded with testing of each component before implementing that component
into the control algorithm. I2C communication, motor controllers, XBee wireless
module, and attitude sensors were all tested independently. Eventually voltage
monitoring, current monitoring, ping sensor data, and a variety of other sub-systems
would be integrated into the main control algorithm.
63
Fink, Greczanik, Hamblin, Kirkwood
The decision was made to test the Quadrotor on a single axis in order to acquire a quick
response with minimum overshoot and oscillation. Initially the control algorithm was
going to be a state space implementation, but the end design consisted of a number of
individual PID controllers. The PID controller was chosen because of design team
members’ familiarity with this controller. In the process of testing and developing the
PID controller on the roll and pitch axes it became evident that our accelerometer was
being adversely affected by vibration from the motors. This was eventually mitigated
through a series of vibration mitigation techniques including mounting the PCB board
with Velcro and putting a layer of vibration absorbent material between each motor and
the Quadrotor frame. Figure 35 shows the accelerometer data converted to pitch data
before these mitigation techniques were employed. Figure 36 shows the corrected data
after mitigation. Note the difference in scale on these two graphs.
64
Fink, Greczanik, Hamblin, Kirkwood
30000
Pitch
(100ths of a Degree)
20000
10000
Series1
0
0
500
1000
1500
2000
2500
1500
2000
2500
Series2
‐10000
‐20000
‐30000
Figure 35 - Pitch Data, pre mitigation
3000
2000
pitch
(100ths of a Degree)
1000
0
‐1000
0
500
1000
Series1
Series2
‐2000
‐3000
‐4000
‐5000
Figure 36 - Pitch Data, post mitigation
Once the pitch and roll axes controllers were independently tuned to the desired response,
z-axis feedback was configured using the downward facing ping sensor. Eventually it
was also decided to use a PID controller for altitude control. Due to some issues with
undesired yaw motion, a PID controller was implemented on the yaw axis and
immediately significantly mitigated yaw motion with very little tuning. Design of the
takeoff algorithm proved a challenge due to the inaccuracy of ping data at short distances
and the drift associated with trying to find altitude by double integrating accelerometer
data. In addition, a slow take off might cause problems on the pitch and roll axis due to
an increasing integral that could not be corrected until the Quadrotor was air born. In
65
Fink, Greczanik, Hamblin, Kirkwood
order to provide a fast enough take off with minimal overshoot and faults, the Quadrotor
was configured to track altitude using accelerometer data up to a certain height where
ping sensor altitude data would prove more accurate.
Final testing involved testing weight carrying capabilities, battery life, voltage and
current monitoring systems and fixing a few software bugs.
Financial Budget Initially it was necessary to approach the design of the Quadrotor with a more limited
budget and hopes of receiving further funding. However, after receiving the $1000
robotics scholarship, it was possible to invest in additional resources such as a secondary
battery pack and 4-layer 2oz copper PCB. Table 36 shows our estimated costs along with
actual costs. Table 37 shows our sources of funding. In the end, we ended this project
with a sum of $370.57 remaining.
Table 36 - Expenses
Expenses Item Initial Estimated Costs Actual Costs PCB $ 438.00 $ 310.00 3.7V 10Ah High Power Li‐Ion Cells $ 319.80 $ 319.80 $ BLDC Motors 51.52 $ 51.52 $ Mechanical Hardware 70.20 $ 114.12 $ Module ‐ XBEE Pro 60mW and USB Adapter 32.00 $ 88.95 $ 147.00 $ 147.00 SRF02 Ultrasonic Range Finder
$ 15.00 $ 15.00 IMU-3000 Triple Axis Gyroscope
$ 20.00 $ 20.00 HMC5843 Digital Triple Axis Magnetometer
$ 22.88 $ 22.88 IC - LPC1768 Cortex-M3 512KB Flash LQFP-100
$ 23.16 $ 23.16 MOSFET P-CH 30V 15.2A POWER56
$ 22.92 $ 22.92 MOSFET N-CH 30V 20A POWER56
$ 19.92 $ 19.92 IC DSPIC MCU/DSP 32K 28-QFN
66
Fink, Greczanik, Hamblin, Kirkwood
$ 201.83 $ 946.23 Miscellaneous Electrical Components
Total:
Table 37 - Sources of Funding
Funding EE Department Funding Honors Department Funding Robotics Scholarship Total: $ 400.00 $ 100.00 $ 1,000.00 $ 1,500.00 Project Schedule 67
$ 284.16 $ 1,129.43 Fink, Greczanik, Hamblin, Kirkwood
Design Team Information Joel Fink, Electrical Engineer
Vince Greczanik, Electrical Engineer
Kyle Hamblin, Electrical Engineer
James Kirkwood, Electrical Engineer
Conclusions and Recommendations As is the case with any design project, even the most well planned and engineered design
will have unexpected problems arise that must be solved or at least mitigated. With the
Quadrotor, mechanical problems proved to be this. In simulating the control system it
was possible to get a good response by implementing a theoretical control algorithm.
However, in reality the control was majorly redesigned to actually function correctly on
the Quadrotor. This was a result of not having particularly effective ways to understand
the precise dynamics of our actual device. While, in general terms, it was possible to
model the Quadrotor, coming up with actual values for moment of inertia and force from
the props was far more challenging. For further development, it is recommended to find
someone with experience in modeling systems like this.
Another challenge that needed solved was the vibration that was being detected by the
accelerometer when the motors were operational. These vibrations caused extremely
noisy pitch and roll measurements, such that the data was unusable. This was solved by
putting vibration absorbent material between the motors and the frame. In addition, the
PCB containing the accelerometer was attached using Velcro to help mitigate vibration
into the board. This combination proved to be the correct combination of mechanical low
pass vibration filtering to allow useable readings but not delay the readings as a spring or
less stiff mounting might have done. In the future, the assistance of mechanical engineers
would be ideal to help further mitigate the effects of vibration on the attitude sensors.
A number of aspects, not in the design requirements, remain to be explored on the now
stable Quadrotor. Use of a magnetometer or GPS might be implemented to provide more
absolute position information. Closely connected with this is the need to control
movement in the X-Y plane. Feedback on this plane is difficult without one of the
absolute sensors mentioned above. Attempts were made to mitigate X-Y plane drift by
finding position information from the accelerometer, but accelerometer data proved to be
overly noisy causing a drift of over 1km in just a few minutes of operation.
68
Fink, Greczanik, Hamblin, Kirkwood
Further improvements could also be made in the operation of the z-axis feedback. The
ping sensors proved to have far lower range around 2 meters as compared to the
advertised range of 6 meters. In addition improved altitude sensing might be provided
by a pressure sensor.
Most brushless DC motor controllers are hobbyist equipment designed to run off a simple
modulated pulse. This design, however, limits the rate at which the motors can be
adjusted. For future improvements, it would be advantageous to have motor controllers
that operate directly off I2C commands. This would allow less delay between
microcontroller speed commands and actual speed updates on the motor.
We did design and attempt to implement such a controller. Since our brushless DC
motors did not have Hall Effect sensors, we were required to implement a sensorless
motor controller consisting of 3 FET drivers, 3 N-Channel FETs and 3 P-Channel FETs.
Our controller worked will in an open loop configuration, but when we implemented the
Back EMF feedback to give closed loop feedback and consequently increase the motor
speed to the point that flight was attainable, the FET drivers failed. The peculiar part of
the failure was that only the FET drivers failed, the MOSFETs themselves remained in
tacked. Originally our driver had a maximum output current of 1.5 amps and an output
resistance of 7 Ω. Since we are running at 12VDC, 12V/7Ω = 1.7A. We then upgraded
our FET driver to a Texas Instrument driver than could handle 4A output and still the
drivers failed while the FETs remained in tacked. Time prohibited further investigation
of this problem, but it would be beneficial if this problem were to be solved in the future.
In addition, for the Quadrotor to be useful load carrying capability should be explored
along with a more in-depth understand of battery life given a specific load.
In summary, the purpose of this project was to take the initial step of platform stability
towards an unmanned hovering vehicle. The Quadrotor in its current state is able to
hover stably on the Z-axis and in pitch, roll, and yaw. It is our hope that others will take
this design and improve upon it implementing some of the suggestions above.
69
Fink, Greczanik, Hamblin, Kirkwood
References Abbott, I. H., & Doenhoff, A. E. (1959). Theory of wing sections: including a summary
of airfoil data. Mineola, NY: Dover Publications, Inc.
Fairchild Semiconductor Corporation. (2009). FDMS6673BZ. Retrieved November 29,
2010, from Fairchild Semiconductor:
http://www.fairchildsemi.com/ds/FD%2FFDMS6673BZ.pdf
Fairchild Semiconductor Corporation. (2009). FDMS8660AS. Retrieved November 29,
2010, from Fairchild Semiconductor:
http://www.fairchildsemi.com/ds/FD%2FFDMS8660AS.pdf
Linear Technology. (1999). LTC1754-3.3/LTC1754-5. Retrieved November 29, 2010,
from Linear Technology: http://cds.linear.com/docs/Datasheet/175435f.pdf
Microchip. (2010, October 20). dsPIC33FJ32GP302. Retrieved November 29, 2010,
from Microchip:
http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en532304#1
Microchip. (2007). MCP1700. Retrieved November 29, 2010, from Microchip:
http://ww1.microchip.com/downloads/en/DeviceDoc/21826b.pdf
Microchip. (2006). TC4426/TC4427/TC4428. Retrieved November 29, 2010, from
Microchip: http://ww1.microchip.com/downloads/en/DeviceDoc/21422d.pdf
STMicroelectronics. (2010, September 3). L3G4200D. Retrieved November 21, 2010,
from STMicroelectronics:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERAT
URE/DATASHEET/CD00265057.pdf
70