Download Autonomous Blimp - The University of Akron

Document related concepts

Switched-mode power supply wikipedia , lookup

Control theory wikipedia , lookup

Multidimensional empirical mode decomposition wikipedia , lookup

Control system wikipedia , lookup

Brushless DC electric motor wikipedia , lookup

Resilient control systems wikipedia , lookup

Pulse-width modulation wikipedia , lookup

Hendrik Wade Bode wikipedia , lookup

Induction motor wikipedia , lookup

Rectiverter wikipedia , lookup

Brushed DC electric motor wikipedia , lookup

Opto-isolator wikipedia , lookup

Stepper motor wikipedia , lookup

Variable-frequency drive wikipedia , lookup

Immunity-aware programming wikipedia , lookup

Transcript
Autonomous Blimp
Project Design Report
Design Team 02
Jason Banaska
Marcus Horning
Sagar Patel
Mike Wallen
Faculty Advisor: Dr. Jay Adams
29 November 2011
Table of Contents
List of Figures .................................................................................................................... iii List of Tables ...................................................................................................................... v Abstract ............................................................................................................................... 1 1. Problem Statement ...................................................................................................... 1 Need ................................................................................................................................ 1 Objective ......................................................................................................................... 1 Background ..................................................................................................................... 2 Objective Tree................................................................................................................. 3 2. Design Requirements Specification ............................................................................ 4 3. Accepted Technical Design ............................................................................................ 5 Mechanical Design.......................................................................................................... 5 Coordinates and Directions ........................................................................................... 13 Representation of the Control System .......................................................................... 14 Control System Implementation ................................................................................... 19 Compensator Design ..................................................................................................... 21 Block Diagrams and Theory of Operation .................................................................... 29 Level 2 Hardware ...................................................................................................... 29 Schematics: ................................................................................................................... 32 Level 1 Hardware ...................................................................................................... 42 Software Functional Decomposition (SCP) ...................................................................... 45 Software Design (SCP) ..................................................................................................... 49 Ground/Client System................................................................................................... 49 Overview:.................................................................................................................. 49 Interfacing with the Xbox 360 Controller:................................................................ 50 Interfacing with the XBee Pro Transceiver: ............................................................. 51 Ground System Design: ............................................................................................ 52 On-Board Software System .......................................................................................... 55 Motor Control System: ................................................................................................. 55 Pulse Width Modulation: .......................................................................................... 55 Communication:........................................................................................................ 56 i
Psuedo Code.................................................................................................................. 56 6. Parts List ....................................................................................................................... 60 Table 11 highlights the estimated budget with the corresponding parts for the
Autonomous Blimp project. .............................................................................................. 61 5. Project Schedule............................................................................................................ 62 6. Design Team Information ............................................................................................. 64 7. Conclusion and Recommendations ............................................................................... 64 8. References ..................................................................................................................... 66 ii
List of Figures
Figure 1- Objective Tree ..................................................................................................... 3 Figure 2 - Scaled Drawing of Blimp Envelope................................................................... 5 Figure 3 - Modeled Gondola Design .................................................................................. 6 Figure 4 - Applied Forces on Free Form Body ................................................................... 7 Figure 5 - Relative Velocity vs. Drag Force ...................................................................... 9 Figure 6 - Relative Velocity vs. Drag Force ..................................................................... 10 Figure 7-Propeller RPM vs. Static Thrust......................................................................... 11 Figure 8 - Simulated Motor Response .............................................................................. 13 Figure 9 - 3D Blimp Coordinates...................................................................................... 13 Figure 10 – Linear Trend Lines ........................................................................................ 17 Figure 11 –Control System ............................................................................................... 19 Figure 12-System Models ................................................................................................. 21 Figure 13 - Step Response of X Translational .................................................................. 22 Figure 14 - Step Response of Compensator...................................................................... 22 Figure 15 – Step Response of Motor Speeds Due to X-Translational .............................. 23 Figure 16 - Step Response of Z Translational .................................................................. 24 Figure 17 - Step Response of Compensator...................................................................... 24 Figure 18 - Step Response of Motor Speeds Due to Z-Translational ............................... 25 Figure 19 - Step Response due to Pitch ............................................................................ 26 Figure 20 - Step Response of Compensator...................................................................... 26 Figure 21 - Step Response of Motor Speeds Due to Pitch................................................ 27 Figure 22 –Step Response Due to Yaw ............................................................................ 28 Figure 23 - Step Response of Compensator...................................................................... 28 Figure 24 - Step Response of Motor Speeds Due to Yaw ................................................ 29 Figure 25-Level 2 Hardware Block Diagram ................................................................... 30 Figure 26- LT1963A – Low dropout regulator ................................................................. 33 Figure 27- ADXL345 – 3-axis accelerometer .................................................................. 34 Figure 28-L3G4200D – 3-axis gyroscope ........................................................................ 35 Figure 29-MPL115A1 – Miniature SPI Digital Barometer .............................................. 36 Figure 30-RXM-GPS-SR schematic ................................................................................. 36 Figure 31-The LV-MaxSonar-EZ4internal connections [10]. .......................................... 37 Figure 32-Xbee Pro Pin Layout ........................................................................................ 38 Figure 33-PIC24FJ256GB108 recommended connections. ............................................. 39 Figure 34- Voltage divider to monitor battery voltage ..................................................... 40 Figure 35- Release Valve System ..................................................................................... 41 Figure 36 – Hardware Level 1 Block Diagram ................................................................. 42 Figure 37 - Software Level 0 Block Diagram ................................................................... 45 Figure 38 - Software Level 1 Block Diagram ................................................................... 46 Figure 39 - Software Level 2 Block Diagram ................................................................... 47 Figure 40 - Software Level 2 Functional Requirements ................................................... 48 Figure 41 - Xbox 360 Controller Configuration ............................................................... 50 Figure 42- Xbox 360 Analog Stick Sensitivity ................................................................. 51 Figure 43- Ground System Class Diagram ....................................................................... 52 Figure 44- Blimp Controller Execution Loop Sequence Diagram ................................... 54 Figure 45 - Transmission byte sequence from ground system to blimp ........................... 54 iii
Figure 46 - PWM Duty Cycle Motor Control Relationship ............................................. 56 iv
List of Tables
Table 1- Design Requirement Specification ....................................................................... 4 Table 2 - Parts List with Estimated Weights ...................................................................... 8 Table 3-Motor Properties .................................................................................................. 12 Table 4-Motor Properties .................................................................................................. 12 Table 5 - Damping Coefficients........................................................................................ 18 Table 6- Level 2 Hardware Functional Requirements ...................................................... 30 Table 7- List of IO Pins .................................................................................................... 39 Table 8 – Hardware Level 1 Functional Requirements .................................................... 43 Table 9 - Software Level 0 Functional Requirements ...................................................... 45 Table 10 - Software Level 1 Functional Requirements .................................................... 46 Table 11-Parts List ............................................................................................................ 60 Table 12-Estimated Budget............................................................................................... 61 v
vi
Abstract
Unmanned Aerial Vehicles (UAVs) operate under remote or autonomous control
and are used for surveillance applications, usually when human interaction is not
possible. A blimp UAV with feedback control is of special interest because of their
ability for long flight duration and low power operation. The objective of this project is
to design and construct a remote controlled aerial surveillance blimp that will exhibit
self-stabilization capabilities and safety control at a low cost budget. A motor system
with sensor feedback will need to be constructed in order to create autonomous flight
stability. Along with continuous surveillance video feedback the blimp shall also
provide transmitted data including: craft coordinates, weather measurements, battery
power status, and indication of oncoming obstacles. The craft will have a predefined
envelope and the control compensator will be designed through research findings,
computer simulations, and experimental testing. A model of the control system based on
the flight dynamics of the air-craft is analyzed to design a controller for the system. The
control system features a four motor system that can exhibit vertical and horizontal
translational control, as well as pitch and yaw rotational control. This report summarizes
the preliminary control, communication design, and additional user friendly features of
the remote control blimp.
Key Features:
•
•
•
•
Accurate and stable flight
Intuitive remote control
Feedback of live video and critical sensor data
Supplementary autonomous functions
1. Problem Statement
Need
Aerial video surveillance can be used in many different applications. For instance,
aerial surveillance can aid rescue workers to find a missing person or be used to gather
military intelligence. A live video feed can also be useful in other emergency situations
such as riots, fires, earthquakes, and tsunamis. Chemical companies have expressed
interest in using a UAV craft to monitor corrosion of pipes in places where it would be
difficult for human interaction. Companies can use aerial surveillance to put a set of eyes
where it would be dangerous to send employees. Other companies could use aerial
surveillance to monitor habitats and growth of areas and landscapes. There is a need to
provide a cost effective way to achieve aerial surveillance for informational purposes.
Objective
The goal of this project is to create an easy-to-control, self-stabilizing, airship that
can provide live aerial video feedback to the user. In addition, it will be able to provide
1
the location, speed, and battery level voltage of the airship. The craft will be able to be
flown remotely with an X-Box controller. It will also be able to perform some
autonomous functions such as; self-stabilizing when the user releases control of the
remote or communication is lost, stopping movement in the z-direction when the altitude
limit of 122m is reached, and stopping further movement when obstacles are detected.
For surveillance, a camera will be attached to the craft and it will be capable of relaying
real-time video back to the user, thus allowing the craft to be flown without a direct line
of sight. Along with this video, the battery level, weather information, and other sensor
data previously mentioned will be displayed on a self-made graphical user interface
presented on a computer screen.
Background
Current designs for RC blimps typically have a large, non-rigid helium-filled hull
(balloon) with two to three rotatable propellers attached to provide flight direction and
speed. Below the hull, there is typically a gondola which houses the communication
transceiver, battery, and has the motors attached to the outside. Either combustion
engines or electric motors are typically used. Despite electric systems usually being
heavier, it is the choice more commonly used to allow for very precise throttling and
maneuverability. Tail surfaces and rudders are designed and placed at the rear of the hull
with the intention of providing effective control of the direction of the blimp.
The primary concern with using a blimp is that the volume required to lift a rather
large payload which potentially includes the motors and motor controllers, several
sensors, a microcontroller, a battery supply, and a camera would be quite large. Helium
is typically used for blimps, and can lift approximately 1kg/m3 (0.064lb/ft3) which is
based on the differences in densities of the air and helium. In order to have a manageable
size, the payload would need to be minimized as much as possible.
2
Objective Tree
Below is the objective tree for the project, which represents the marketing requirement
organized into a hierarchy of needs.
Surveillance Aircraft
Easy to Use
Stable and Accurate Flight
Safety
Indoor/Outdoor Use
Avoid Obstacles
Self Stabilize When Idle
Intuitive, Responsive User
Remote Control
Self-stabilizing in All
Directions
Inform User When Battery
Level is Critical
Light Weight
Direction and Position
Awareness
Safe to Use and Fly Around
People
Displays Video and Other
Data Back to User
Figure 1- Objective Tree
3
2. Design Requirements Specification
Below is the design requirements specification for the blimp system.
Table 1- Design Requirement Specification
Marketing
Requirements
6
6
Engineering Requirements
Justification
The airship should have an average flight duration
of twenty minutes.
Display warning message on graphical user
interface (GUI) on computer when battery voltage
level reaches the critically low voltage level.
Based on the 5000mAh rating on the
battery and the average current draw.
This feature is intended for craft and
personnel safety. Critically low
voltage is determined from battery
reading, dependent on the number of
cells and battery type.
The blimp must be transportable for
indoor and outdoor use. The envelope
will also be used independently by a
second party.
This value is determined by user
specifications.
The amount drift is based on the
control system compensation.
7
The gondola, sensors, motors, and additional
hardware should be detachable from the blimp
envelope in less than 5 minutes.
8
The airship must make one full rotation in the yaw
direction in under 60 seconds.
The maximum allowable drift during autonomous
flight in any direction is 1 m when wind gusts are
below 3 m/s.
The user control should allow the operator to
control the pitch and yaw rotational directions, as
well as the x and z translational directions. The
analog joystick on the remote will control the
rotational directions and the buttons will control the
translational movements of the craft.
The craft must come to a stop and warn the user via
the GUI when an obstacle is within 1m and lies in
the direction of the flight path.
The airship’s speed in the vertical direction must be
able to achieve 0.5 m/s in less than 10 seconds.
Also, the airship must obtain a speed of 1.8 m/s in
the horizontal direction in less than 6 seconds.
The airship should not exceed a maximum altitude
of 122 m above ground level and must warn the
user when the craft is approaching this position.
The device must transmit 800 meters line of sight
the craft’s battery voltage level, position, altitude,
aircraft speed, distance to obstacles ,and the air
pressure and temperature of the atmosphere.
The accuracy of the transmitted data must be as
follows:
-Temperature within 1ºC
-Air pressure within 1kPa
-Battery voltage within 5% of actual voltage
-Speed within 5% of actual speed
1,2,9
3
5
8
10
4
4
4
The user needs to be able to have full
control of the craft's flight trajectory,
with ease of use.
This value is based on the maximum
drift of the airship and the value of the
ultrasonic range finder.
This value is user specified and is
dependent on the thrust that the
motors can produce.
This is a model aircraft operating
standard in the Advisory Circular 9157.
The maximum range of transmission
of the XBee Pro transceiver is 1.609
km.
The accuracy of the data is based on
the constraints of the sensors quality.
-GPS position within 5 meters
Marketing Requirements:
1. The craft must be stable in flight in all directions.
2. The craft must self stabilize in the absence of user control or when communication is lost.
3. The craft must be intuitive to control via the remote control.
4. The display unit must provide the user with the craft’s coordinates, altitude, video feed, and battery
voltage.
5. The craft must avoid contact with obstacles during flight.
6. The craft must have battery life that will sustain long periods of flight and the user shall be warned
when the battery power is critically low.
7. The craft must be easy to assemble to provide ease of use and transportation.
8. The craft must respond readily to all user commands.
9. The craft must be able to fly outdoors.
10. The craft must comply with Advisory Circular (AC) 91-57 for Model Aircraft Operating Standards.
3. Accepted Technical Design
Mechanical Design (MW,MH)
At this point in time, the blimp that is being considered for the project is owned
by The University of Akron’s Department of Biology. A scaled drafting of the blimp,
provided by Southern Balloon Works, is shown in Figure 2.
Figure 2 - Scaled Drawing of Blimp Envelope
The design of the blimp’s gondola is an important factor in how the blimp will
operate. The gondola design must be light in weight and yet still be able to firmly house
all of the motors. The current design schematic shown in Figure 3 features an easily
5
adjustable gondola design. The material being used for the gondola consists of PVC pipe
and a thin wood board or sheet of plastic that can securely hold all of the electrical parts.
The length of the board will be approximately 2 meters, or long enough to allow the
vertical motors to be effective for controlling the pitch of the craft. The PVC pipe allows
for the gondola frame to be customizable to ensure that the weight requirements of the
blimp are satisfied. The initial dimensions used for the gondola frame is 1 meters long by
0.3 meters wide by 0.3 meters tall, and the weight of the frame was measured to be
approximately 1.10 kilograms. Additional frame pieces can be added if it is determined
that more weight is needed for the payload capacity. If the frame is determined to be too
heavy, an additional alternative may be CPVC pipe, which is lighter in weight. The
frame was design in such a way that it can easily tied or inserted through several metal
loops at the center of the blimp. In addition to the motors, the gondola will also house the
inertial measurement sensors, the XBEE receiver, battery packs, and wireless camera,
which are not shown in Figure 3.
Figure 3 - Modeled Gondola Design
By examining the external and applied forces on the airship, three parameters of
the mechanical design of the airship can be determined. These include the volume of the
envelope, the resulting weight of the payload, and thrust required for satisfactory
acceleration. The desired accelerations will be chosen to satisfy the respective design
requirements regarding the response of the airship. Once the accelerations and required
thrust are determined, the motor can be chosen based on its electrical performance. A
free-body diagram of the forces that act on the blimp are depicted in Figure 4 where T
represents the magnitude of the thrust. The blimp is assumed to be flying in the -!
direction. Also, the center of mass and center of buoyancy are presumed to both be
located at the same point.
6
!
W= -mg!
!!"#$ = - D!
!! = −!! !
!! = −!! !
!! = !! !
!!"#$ = !!"#$ !
Figure 4 - Applied Forces on Free Form Body
In order to reduce a non-linearity in the control system, the airship will be
neutrally buoyant. Therefore, by examining the forces in the ! direction it is evident that
the force of buoyancy must be equal to the weight of the blimp so that acceleration does
not occur in that direction. The force of buoyancy is an effect of the density of the lighterthan-air (LTA) gas used being less than that of air. Therefore, the magnitude force is
dependent of the volume of the envelope and density of gas used. The most commonly
used LTA gas for blimps and airships is helium, which has a lift capacity of 1kg/m3. The
force due to the effect of gravity, or the weight of the blimp, is dependent on the
combination of the masses of the envelope and the on-board equipment.
The volume and weight of the blimp is 8.5!! (300 cubic feet) and 3.86kg (8.5
lbs) respectively. In order to determine if this envelope will be suitable for the blimp
design, it is necessary to hypothesize a payload based on the parts needed to both operate
the blimp and also meet the marketing requirements. The volume of the blimp must be
large enough such that the buoyant force exceeds or is equal to the total weight of the
system. These forces will later be equalized by either adding mass to the system or the
increasing the density of the containing gas (i.e. an air/helium combination will be used).
A list of potential parts is summarized in Table 2 with estimated system mass.
7
Table 2 - Parts List with Estimated Weights
Part
Ultrasonic Sensor (2)
Gyroscope
Barometer
GPS Chip
XBee Receiver
Camera (Not required)
Back-up Battery
Accelerometer
Microcontroller
Motor Electronic Speed
Controllers(4)
Motors (4)
Propellers (4)
Battery
Gondola and attachment
materials
Electronic Release Valve
Estimated Mass (g)
13
1
1
3
3
21
15
1
3
80 (20 g each)
Envelope including fins (4)
Mass of Helium
PCB (10"x4")
Additional Hardware/Wire
(Resistors, Caps, etc)
Total Estimated Mass
with 10% added
3629
1517
50
40
440 (110 g each)
32 (8 g each)
332 g
1250
45
7476
8224
After reviewing the mass, it is determined that the volume of the blimp is indeed large
enough to produce lift. The weight of the system of 8.22kg was less than the lifting
capacity of 8.5kg. However, a concern we have considered is that the shape of the
envelope was designed for advertising and is not desirable for flying. A better shape for
flying is generally a more slender body such that the air drag is reduced. More air drag
will pose a challenge in the control aspect because a nonlinearity will be introduced and it
will not be modeled in a linear system.
By examining the forces shown above in the Figure 4 the thrust required in !
direction that results in a desired acceleration, !,can be found using Newton’s second
law, and is depicted as
!!"#$%! = !!"#$ + !! .
(1)
An acceleration of 0.4 m/s2 was chosen such that the requirement stating that the airship
must obtain a horizontal speed of 1.8 m/s in less than 6 seconds will safely be satisfied.
The drag of the blimp is determined by force equation for drag given by
8
!!"#$ =
!
∗ ! ∗ ! ∗ ! ∗ !! .
!
(2)
In equation 2, C is a dimensionless drag coefficient that is shape dependent, ρ is
the fluid density of air, S is the cross-sectional area, and v is the velocity of the blimp. It
is assumed the nose of the blimp flies forward, directly into the drag. According to Dr.
Stavros Androulakakis of Lockheed Martin, a drag coefficient of 0.1 is appropriate for
the blimp moving in the ! direction. Likewise, a drag coefficient of 1.2 is appropriate for
the blimp moving in the ! direction [2]. These coefficients are dependent on the shape of
the blimp. The fluid density of air taken at an ideal ambient temperature of 25oC at the
standard atmospheric pressure of 101.325 kPa is 1.1644 kg/m3. The reference area from
the front of the blimp is defined as the area of the circle, πr2. Using the values described
above, the drag force is shown in Figure 5 as the velocity of the blimp, relative to the
velocity of air, is varied.
Rela/ve Velocity vs. Drag Force Drag Force (N) 5 4 3 2 Series1 1 0 0 1 2 3 4 5 6 Rela/ve Velocity (m/s) Figure 5 - Relative Velocity vs. Drag Force
By inspection of the graph, the drag force at a relative velocity of 4.8 m/s is 4.1
Newtons. That relative velocity was chosen because it corresponds to the blimp traveling
at maximum speed into a maximum wind speed. Since the desired acceleration and drag
force are now determined, the force of thrust required for a 8.2 kg system as determined
by Equation 2 is 7.38 N. Since all four motors are identical the thrust required to satisfy
the requirements in the vertical direction will not exceed 7.38 provided that the drag force
is low enough. The drag force for a relative velocity is shown in Figure 6.
9
Rela/ve Velocity vs. Drag Force Drag Force (Newtons) 25 20 15 10 Series1 5 0 0 0.5 1 1.5 2 2.5 Effec/ve Velocity (m/s) Figure 6 - Relative Velocity vs. Drag Force
By inspection of the graph, the drag force at a relative velocity of 1 m/s is 5
Newtons. Although this value is larger than that of the blimp traveling in the i-direction,
the acceleration will be low enough such that the thrust required will be lower than 7.38
Newton. Therefore, the propellers and the resulting motors will be chosen based on 7.38
Newton.
The thrust produced is a property of the propellers used. However, these must be
chosen in conjunction with the motors so that the torque developed by the loading to the
propeller will not exceed the stall torque. In addition, the motor must be able to run at a
high enough rpm such that the necessary thrust is produced. Also, the current draw must
be low enough such that the requirement regarding flight duration is satisfied. Although
the thrust produced by a propeller when in motion, known as dynamic thrust, varies from
that produced under static conditions, dynamic thrust is difficult to calculate. However,
since the airship will be flying at a low velocity it is presumed to be flying under static
thrust. The static thrust is a function of the propeller’s rpm, diameter, CF value, and the
density of air and is given as
(3)
!!"#$%! = 9.459×!"!!" !! !! !(!").
The CF, or coefficient of lift, is a dimensionless value that relates the lift force with the
dynamic pressure and reference area and varies with different propellers. A doublebladed propeller with a 9-inch diameter and a 6-inch pitch was chosen. The static thrust
developed as a function of rpm is shown for that specific propeller in Figure 7.
10
Propeller RPM vs. Sta/c Thrust Thrust, in Newtons 25 20 15 10 Series1 5 0 0 2000 4000 6000 8000 10000 12000 14000 RPM Figure 7-Propeller RPM vs. Static Thrust
By inspection of the graph, the thrust of the propeller is proportional to the square of the
rpm. For this particular propeller the relationship between static thrust and RPM is
(4)
!!"#$%! = !. !"# ! !"!! !! .
As mentioned previously it is also important that the propeller’s torque does not exceed
the stall torque of the motor. The torque of the motor is a function of the power produced
by the propeller and the rpm of the propeller. This relationship is given as
!=
!
!
(5)
.
Whereas the power developed by the propeller is defined as
(6)
!!"#! = !! ∗ !!! .
Both Pc and pf are coefficients that are specific to the propeller. The Pc coefficient is the
power constant of the propeller and pf is the power factor, which is typically equivalent to
three.
Also, mentioned previously was the importance of monitoring the current draw
needed to produce thrust. This is not only to ensure that the current does not exceed the
maximum rating of the motor, but also to design the propeller/motor combination so that
the battery life satisfies the design requirement. There are two ways to calculate the
current. The first requires knowledge of the motor torque constant, kt , and the torque
produce. These properties are related by
!
(7)
! = !! .
11
The second method requires knowledge of the efficiency of the motor, the operating
voltage, and the delivered propeller power. These properties are related by
!=
!!"#!
!"
(8)
.
A computer-aided simulation tool designed by Louis Fourdan of Maxx Products
International LLC was used to choose the appropriate motor and propeller. The final
selection of the motor had the following properties listed in Table 3. The properties of the
selected propeller are shown in Table 4.
Table 3-Motor Properties
Motor Speed Constant,Kv Maximum Input Wattage Internal Resistance, No Load Current, Maximum Continuous Current Maximum Burst Current Motor Torque Constant,Kt 910 RPM/V 250 W 0.08 Ohm 0.85 A 20 A 25 A 0.015449 Nm/A Table 4-Motor Properties
Diameter Pitch Thrust Coefficient Number of blades
9 inches 6 inches Power Constant, Pc
Power Factor, pf
!. !"#! !"!!
2
0.822
3
The simulation for the selected motor and attached propeller is shown in Figure 8.
The dot on the current vs. efficiency chart represents the operating state of the motor at
11V (maximum voltage input). With back-emf taken in to account, the delivered thrust is
855 gram-force (8.39 N) at 8371 rpm. This value of thrust for one motor will result in an
acceleration that will satisfy the design requirements. Additionally, the torque of the
motor is 0.135Nm when the maximum current is 13.73A. The input power is 150W,
which is well below the rated input power.
12
Figure 8 - Simulated Motor Response
Coordinates and Directions (JB)
The coordinates and directions used in remainder of this report when referencing
the blimp is shown in Figure 9. The directions shown by the vectors x, y, and z are
referenced to the frame of the blimp. Therefore, as the blimp rotates, so do the unit
vectors r, u, and v. On the other hand, the rotations have an earth frame reference.
Figure 9 - 3D Blimp Coordinates
13
Representation of the Control System (JB,MH)
Controlling the autonomous airship requires knowledge of all of the forces that appear on
it. The airship has six degrees of freedom that accelerations can occur (!,!, !,!! ,!! ,!! ).
The control model of plant for each of the subsystems can be obtained by the differential
equations that represent the dynamics of the system. The six differential equations
representing the six degrees of freedom are obtained by equating Newton’s second
law[1,14] given by ! = !" in each translation and rotation direction. In the rotational
directions, Newton’s second law suggests that ! = !" where ! is a moment of inertia
about the mass center, ! is a moment, and ! is an angular acceleration.
By analyzing each direction separately the differential equations can be obtained.
In addition, some insights can be developed concerning the general motion of the system.
The transfer functions will also be produced from the differential equations.
X-Translation
Movement in the ! direction is defined as the airship moving directly horizontally
forward. The two motors that affect this movement are M1 and M2. Creating a dynamic
equation for the !-translation arrives at !! = −!! + (!! + !! ).Where m is the mass
of the airship, b is a damping coefficient caused by wind resistance, while M1 and M2 are
the thrust (force) produced by each of the motors. However, if motors 1 and 2 are only
powered, then a pitch is created around the center of buoyancy. To compensate for this
pitch, motors 3 and 4 are needed to compensate for the added pitch. The transfer function
with the output to the system being the velocity of the blimp and the input being the
motor thrust produce only in the ! direction is
!! (!)
!(!)
=
!
!!! !!"
.
(9)
Y-Translation
Movement in the ! direction is not directly controllable from the motors located
on the airship. A dynamic equation for the forces in the! direction is !! = −!!.
Therefore, if there is a gust of wind that pushes the airship in the ! directionadjustments
in the yaw and !-translation directions are needed to control the blimp back to its original
position. Since there is user input in this direction the transfer function has no value.
Z-Translation
The movement in the ! direction is controlled by motors 3 and 4.Since these
motors will be placed at an equal distance from the center of mass no net moment will be
applied to the system. An equation for the forces in the ! direction is !! = −!! +
(!! + !! ).The transfer function with the output of the system being the velocity of the
blimp in the ! direction and the input being the thrust produced by the combination of
motor 3 and 4 is given by
!! (!)
!(!)
=
!
!!! !!"
14
.
(10)
Pitch !
Pitch is very important to be able to control, and the system’s setup has four
motors that will alter the pitch. Each motor will cause an angular acceleration in the pitch
since there is a moment arm directed from the position of the motor to the center of mass.
The differential equation for the pitch is given as !! = !! + !!! !! + !! +
(!"′)(!! − !! ). The transfer function with the input to the system being the moment
produced that causes a roll and the output being the pitch angle is
!(!)
!(!)
=
!
!! !! !!"
.
(11)
Roll !
Roll is the acceleration that occurs around the !-axis. There are no motors on the
airships that can control the roll of the system. Also, there will be no moment resulting
from the thrust produced by the motors that will affect yaw. The differential equation for
roll is described by !! = !!. Since there is no the motor that control this direction once
again the transfer function will have no value.
Yaw !
Yaw is rotation about the !-axis. Direct control the yaw of the craft is influenced
by motors 1 and 2. The motion is represented by the dynamic equation !! = !" +
(!"′) ∗ (!! − !! ). However, if motors 1 and 2 are controlled to produce moments with
the same magnitude but opposite direction then no net yaw is created and the craft only
moves in the !-direction. Motors 1 and 2 must be spinning at different speeds to create a
change in yaw. While creating a change in yaw, once again, the pitch level also needs to
be adjusted because it gets affected when adjusting the yaw. The transfer function with
the angular velocity being the output and the moment produced in the yaw direction as
the input is
!(!)
!(!)
=!
!
!
! ! !!"
.
(12)
Since all the equations of motion are now obtained, they are represented in matrix form
given as
15
!
!"
!
!
!
!
!
!
!
!
!
!
!
!
= !
!
! +!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!!!
!
!
!
!!!
!
!
!
!
!
!
!
!!!
!
!
!
!"
!
!
!
!
!
!
!
!!!
!
!
!
!
!
!
!
!
! !!
! !!
! !!
!!! !"
!
!
!
!
Where the matrices A and B are given as
!
!
!
!
!
!
!
!
! !/! !
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !/! !
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !/! !
!
A= !
!
!
!
!
!
!
!
!
!
!
!
!
!
! !/!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!/!
!
!
!
!
B= !
!/!!
!
!
!
!/!!
!
!/!
!
!
!
!
!
!/!!
!
!
!
!/!!
!
!
!
!
!
!/!
!
!/!!
!
!
!
!/!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! !/!!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
! and
!
!
!
!
!
!
!
!
! !/!!
!
!
!
!
!
!/!
! . !/!!
!
!
!
!/!!
In order to complete the representation of the system, the damping coefficients and
the moments of inertia are calculated. The damping coefficients in the translational
directions can be found by referring back to the slopes of the linearized trend lines added
on Figure 10. Based on the geometry of the blimp the damping coefficients in the z and y
directions are identical. The damping coefficients in the rotational directions are more
difficult to obtain since they rely heavily on the geometry of the envelope and knowledge
16
of the location of the center of mass. Nevertheless, damping coefficients of 1 were
hypothesized as a conservative value in the pitch and yaw-direction. The damping was
neglected in the roll-direction. These values were chosen because a straight-line, uniform
wind would produce a minimal moment.
The moments of inertia were obtained by superposition of the moments of inertia
calculated for an ellipsoid and a thick plate. In addition, the parallel axis theorem was
used to obtain the moments of inertia at an estimated location determined to be the mass
center. This location was closer to the front and the base of the envelope. The geometric
parameters of the
Figure 10 – Linear Trend Lines
With A=0.95m, B=0.95, C=0.95 m, D=0.25m,W=0.25m ,H=0.15 m,
!!"# = !. !"#$ (!"#$%&'( !"#$%&), !"# !!"#$ =4kg, the moments of inertia can be
calculated by
!!! = [!!"#
!!! = [!!"#
!!! = [!!"#
!! !!!
!
!! !!!
!
!! !!!
!
]+[
!
!"#$ !! !!!
!"
+ !!"#$ (!′)! ],
! !
+ !!"# (!" ) ] + [
+ !!"# (!"! )! ] + [
!
!
!"#$ !! !!!
!"
!"#$ !! !!!
!"
], and
(13)
(14)
(15)
].
The values !"! and !"! represent the distances from the originally center of mass to the
anticipated center of mass. However, they were neglected. The calculated values for the
damping coefficients and moments of inertia are shown in Table 5.
17
Table 5 - Damping Coefficients
a b c d e f Jp Jr Jyaw Damping Coefficients Moments of inertia 0.74 5 5 1 0 1 6.65 rad/sec 2.97 rad/sec 5.66 rad/sec The values listed in Table 5 were calculated based on theory. However, the values
of the damping coefficients and moments of inertia will obtain experimentally to obtain a
more accurate model of the system. This procedure requires a method of obtaining a step
response in each direction. In addition, the translational/rotational distance must be
sensed.
Each of the six system models will be obtained separately. A step in the respective
direction will be inputted into the system by powering the appropriate motors. The
distance (angle for rotational directions) will be plotted on the oscilloscope in terms of
the voltage. The transfer function of the system will match the prototypical second order
equation given as
!! !
!
! !!"!! !!!! !
.
(16)
The natural frequency, !! , and damping ratio, !, can be obtained by calculating the time
constant, τ, and damped frequency, !! , from the step response. They can then be
calculated using
!=
and
!! =
!
!!!
!!
!!!!
(17)
.
(18)
The time constant of the model is equivalent to the time it takes to reach 67% of the final
value. The damped frequency is the inverse of the time between consecutive peaks. Once
! and !! are known, the coefficients of the prototypical equation can be related to the
system model to determine the damping coefficients and moments of inertia (for
rotational directions only).
18
Control System Implementation (MH)
In the previous section it was determined that only four directions (!,!, yaw, and
pitch) can be controlled. The implementation of the control system is illustrated in Figure
11.
Desired
Velocity in
x-direction
Ux
X
Controller
Desired Pitch
Angle
Up
Pitch
Controller
Desired Yaw
Velocity
Desired
Velocity in
z-direction
Yaw
Controller
-
Transfor
mation
Uyaw
M1
M2
M3
M4
x
Aircraft
Aircraft
System
Dynamics
Dynamics
pitch
yaw
z
Uz
Z
Controller
Figure 11 –Control System
There are four inputs and four outputs of the system. The goal is to be able to control the
translation velocities in the x and z directions, the rotational velocity in the yaw direction,
and the pitch angle. The designed compensators, which will be discussed in more detail
later, will multiply the respective error to obtain Ux, Up, Uyaw, and Uz. The actual
velocity and angle values will be obtained by the combination of accelerometer,
gyroscope, and GPS sensor data. The values of Ux, Up, Uyaw, and Uz represent the
thrust/moment required in the respective direction. The required thrust/moment is
dependent on the four motors and is represented by the coupled set of equations given as
!!
!
!!
!
!! = !!!
!!
!!!
!
!
!!!
−!!!
19
!
!
−!!!
!
!
!
!!!
!
!!
!!
. !!
!"
(19)
As mentioned previously M1,M2,M3, and M4 represent the thrust produced by
motors 1 through 4 respectively. Also, dz’, dx’, and dy’ are the moment arms depicted in
Figure 9 on Page 13. The coefficient ! represent the effect of the body of the blimp’s
tendency to rotate as a result of the propeller’s inertia. However, this effect was neglected
due to the relatively large mass of the envelope. The motor control algorithm is
implemented to determine the thrust and therefore the resulting speed each motor must
produce. This is done by solving for M1, M2, M3, and M4 in Equation 19 in terms of the
measureable values of Ux, Uz, Up, Uyaw. These result in the four motor thrust equations
given as
(20)
M1=(Uyaw + Ux*dy’)/(2*dy’),
(21)
M2=-(Uyaw - Ux*dy’)/(2*dy’),
M3=(Uz*dx’ - Upitch + Ux*dz’)/(2*dx’), and
(22)
(23)
M4=(Upitch + Uz*dx’ - Ux*dz’)/(2*dx’).
20
The motor rpm is related to the thrust by Equation 4 on page 11. However, motors two
are four were chosen to have counter-pitched propellers to reduce the effects of motors
causing rotation of the body.
Compensator Design The four compensators are designed for increased stability of the system, zero
steady-state error, minimum overshoot, and a settling time that satisfies the design
requirements regarding the motion of the system. The four compensators were designed
separately. The system models are all illustrated by Figure 12. Please refer to pages 1415 for the models of the plant. The compensators were all designed with the gain of the
feedback sensors equal to unity. The system was transformed from the s-domain to the zdomain using a zeroth-order hold and a sampling time of 20ms. Also, the output of the
compensators needed to be monitored to ensure that value does not exceed a thrust that is
not obtainable.
Desired angular velocity
in yaw direction
Desired velocity in
z direction
Desired pitch angle
Desired velocity in
x-direction
Yaw
Controller
Uyaw
Uz
Z
Controller
Pitch
Controller
X
Controller
Upitch
Yaw
Model
Z
Model
Pitch
Model
Ux
X Model
Figure 12-System Models
X-Translational:
The velocity of the system is in inherently stable. However, due to the effect of
damping, a PI controller is necessary to obtain zero steady-state error and reduce the
21
settling time. Please refer to the appendix for the MatLab code used to design the
compensators. The resulting transfer function for the compensator in the x-direction is
! ! =
!(!!!.!!"#)
!!!
(24)
.
The step response of the output of system to 1.8 m/s is shown in Figure 12. The step
response of the output of the compensator is illustrated in Figure 13, where the amplitude
represents the thrust required in the respective direction. These step responses correspond
to the motor speeds illustrated by Figure 14.
Step Response
2
1.8
1.6
1.4
Amplitude
1.2
1
0.8
0.6
0.4
0.2
0
0
1
2
3
4
5
6
7
8
9
Time (sec)
Figure 13 - Step Response of X Translational
Step Response
9
8
7
Amplitude
6
5
4
3
2
1
0
1
2
3
4
5
6
7
8
Time (sec)
Figure 14 - Step Response of Compensator
22
9
10
Motor rpms for Desired Step Response
10000
5000
Motor rpm
0
0
1
2
3
4
5
6
7
8
9
10
0
1
2
3
4
5
6
7
8
9
10
0
1
2
3
4
5
6
7
8
9
10
0
1
2
3
4
5
6
Time, in seconds
7
8
9
10
0
-5000
-10000
5000
0
5000
0
Figure 15 – Step Response of Motor Speeds Due to X-Translational
Z-Translational:
Similar to the x-direction, the velocity of the blimp in the z-direction is stable but
a PI controller is needed to reduce the steady-state error and settling time of the system.
The gain of each compensator was chosen such that the output of the compensator was
less than 40% of the maximum thrust/moment that can be produced in the respective
direction. This was done to account for the instance when two or more directions were
controlled simultaneously. The resulting compensator transfer function in the z-direction
is
(25)
!"(!!!.!"#)
! ! =
.
!!!
The step response of the output of the system for a velocity of 0.5 m/s in the z-direction is
shown in Figure 15. Figure 16 shows the step response of the output of the compensator,
where the amplitude represents the thrust required in the z-direction. Once again, the
motor rpm’s to obtain the step response are shown in Figure 17.
23
Step Response
0.7
0.6
Amplitude
0.5
0.4
0.3
0.2
0.1
0
0
2
4
6
8
10
12
14
Time (sec)
Figure 16 - Step Response of Z Translational
Step Response
3.6
3.4
3.2
3
Amplitude
2.8
2.6
2.4
2.2
2
1.8
1.6
0
1
2
3
4
5
Time (sec)
Figure 17 - Step Response of Compensator
24
6
Motor rpms for Desired Step Response
Motor rpm
1
0
-1
1
0
-1
5000
4000
3000
-3000
-4000
-5000
0
1
2
3
4
5
6
0
1
2
3
4
5
6
0
1
2
3
4
5
6
0
1
2
3
Time, in seconds
4
5
6
Figure 18 - Step Response of Motor Speeds Due to Z-Translational
Pitch:
The pitch of the system is not inherently stable. Therefore, a PD controller was
designed to not only make the system stable, but also to reduce the settling time. No
compensation was needed to reduce the steady-state value because the plant already had a
pole at the origin. The transfer function of the compensator in the pitch direction is given
as
! ! =
!"(!!!.!!"#)
!!!
.
(26)
The step response of the output of the system for a desired angle of 0.4 radians is shown
in Figure 18. The step response of the output of the compensator is shown in Figure 19
where the magnitude represents the required moment. The required rpm of motors for the
desired input is shown in Figure 20.
25
Step Response
14
12
8
6
4
2
0
0
0.05
0.1
0.15
0.2
0.25
0.3
0.35
0.4
Time (sec)
Figure 19 - Step Response due to Pitch
Step Response
0.45
0.4
0.35
0.3
Amplitude
Amplitude
10
0.25
0.2
0.15
0.1
0.05
0
0
10
20
30
40
50
Time (sec)
Figure 20 - Step Response of Compensator
26
60
Motor rpms for Desired Step Response
Motor rpm
1
0
-1
1
0
-1
0
5
10
15
20
25
0
5
10
15
20
25
0
5
10
15
20
25
0
5
10
15
Time, in seconds
20
25
0
-2000
-4000
0
-2000
-4000
Figure 21 - Step Response of Motor Speeds Due to Pitch
Yaw:
The velocity of the blimp in the yaw-direction is also inherently stable.
Depending on the magnitude of the damping coefficient a compensator may be require to
reduce the steady state error. Since the magnitude of the damping coefficient of the real
system likely cannot be neglected, a PI compensator will be needed. The transfer function
of the compensator in the yaw direction is given as
! ! =
!"(!!!.!!")
!!!
.
(27)
The step response of the output of the system for a desired angular velocity of 0.4 radians
is shown in Figure 21. The step response of the output of the compensator is shown in
Figure 22 where the magnitude represents the required moment. The required rpm of the
motors for the desired input is shown in Figure 23.
27
Step Response
2.5
2
Amplitude
1.5
1
0.5
0
0
0.5
1
1.5
2
2.5
Time (sec)
Figure 22 –Step Response Due to Yaw
Step Response
0.16
0.14
0.12
Amplitude
0.1
0.08
0.06
0.04
0.02
0
0
5
10
Time (sec)
Figure 23 - Step Response of Compensator
28
15
Motor rpms for Desired Step Response
Motor rpm
4000
2000
0
4000
2000
0
1
0
-1
1
0
-1
0
20
40
60
80
100
120
0
20
40
60
80
100
120
0
20
40
60
80
100
120
0
20
40
60
Time, in seconds
80
100
120
Figure 24 - Step Response of Motor Speeds Due to Yaw
Block Diagrams and Theory of Operation
(JB)
Level 2 Hardware
The hardware’s operation primarily focuses sending the desired motor speeds to the
motor controllers by reading sensor inputs. The microcontroller is the heart of the
circuitry and communicates with all of the sensors to provide the desired motor controller
speeds. The sensors include a gyroscope, accelerometer, GPS, barometer, and ultrasonic
sensors. The low power circuitry gets all of its power from a primary battery that a lowdropout regulator converts to provide the correct voltage to each component. The higher
power circuitry, such as the motors and motor controllers, get their power from a separate
battery with no low-dropout regulator. Data is generated and transmitting wirelessly
through XBee Pro and is displayed on a monitor for the user.
29
Battery 1
Battery 2
Low-Dropout
Regulator
Battery
Monitor
Vin
Thrust
Motor
Controller
1
Motor 1
Motor
Controller
2
Motor 2
Motor
Controller
3
Motor 3
Motor
Controller
4
Motor 4
Desired Speed
M1
Battery
Voltage %
Desired Speed
M2
Ultrasonic
Proximity
Sensors
Desired Speed
M3
Thrust
Thrust
Barometer
MicroController
Desired Speed
M4
Accelero
-meter
Thrust
Gyroscope
Camera
Backup
GPS
Battery
Transmitter
GPS
Sensor
Xbee Pro
Camera
Receiver
Desired
x-translation
Desired Yaw
Desired Pitch
Televison
Xbox 360
Controller
Xbee
Adaptor
Xbee Pro
PC
Desired
z-translation
Monitor
Figure 25-Level 2 Hardware Block Diagram
Table 6- Level 2 Hardware Functional Requirements
Module
Inputs
Outputs
Functionality
Module
Inputs
Low-Dropout Regulator (LT1963A)
Power In: 11.1V Battery input
Power Out: 3.3V Output to Microcontroller, Ultrasonic Sensors,
Barometer, Accelerometer, Gyroscope, Xbee Pro, and GPS
Sensor.
Provide regulated voltage and current to several inputs of sensors and the
microcontroller.
Microcontroller (PIC24FJ256GB106)
Power In: 3.3V In from LDO
Ultrasonic Sensor Data: Distance (m) of objects
Xbee Input: Desired positioning of system
30
Outputs
Functionality
Module
Inputs
Barometer Input Data: Air temperature measurement
GPS Sensor Data: Altitude and coordinates of blimp
Accelerometer Data: Actual translational measurements
Gyroscope Data: Actual rotational measurements
Battery Monitor: Battery voltage level for critical level
Desired Speeds: Send desired speeds to motor controllers.
Xbee Output: Collected data needing to be sent to ground
Receives, communicates, and processes all data from sensors. Develops
desired motor speeds and also sends desired data to Xbee to be sent to the
ground.
Motor Controllers 1,2, 3, and 4
Power In: Battery input
Desired Motor Speed: Input of desired motor speed
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Motor Control: Sends a command to control the speed of the
motors.
Receives desired positioning of the motors and sends commands to motor
to control the speeds.
Xbee Pro
Data In: Data to be transmitted wirelessly
Power In: 3.3V In from LDO
Data Out: Data sent out wirelessly
Transmits data wirelessly from Xbee transmitter to Xbee receiver.
Xbox 360 Controller
Desired Positioning: Desired x-translation, z-translation, pitch,
and yaw
Control to PC: Send signals to the PC
Desired inputs are directed using the Xbox 360 controller and sent to the
PC to be analyzed.
Camera Receiver
Images: Images sent wirelessly from camera on blimp to receiver
on ground
RCA output: RCA output to connects to a television.
Images are taken by the camera and sent to the camera receiver and then
displayed on a television.
Battery Monitor
Power In: 0V-11.1V Battery input
Power Out: 0V-5V to microcontroller.
Uses a voltage divider to send 0-11.1V from battery to 0V-5V to
microcontroller so it can sense when the battery is getting to a critical
level.
31
Module
Inputs
Outputs
Functionality
Ultrasonic Sensors (LV-MaxSonar-EZ4)
Power In: 3.3V Battery input
Data Out: Sensor data to microcontroller.
Sends sensed data to microcontroller via a pulse width signal.
Module
Inputs
Outputs
Functionality
Barometer (MPL115A1)
Power In: 3.3V Battery input
Data Out: Thermal Data to microcontroller.
Provide thermal data to microcontroller.
Module
Inputs
Outputs
Functionality
Accelerometer (ADXL345)
Power In: 3.3V Battery input
Data Out: Translational motion data to microcontroller.
Provide translational motion data to microcontroller
Module
Inputs
Outputs
Functionality
Gyroscope (L3G4200D)
Power In: 3.3V Battery input
Data Out: Rotational motion data to microcontroller.
Provide angular rate data to microcontroller.
Module
Inputs
Outputs
Functionality
GPS Sensor (RXM-GPS-SR)
Power In: 3.3V Battery input
Data Out: Altitude and Coordinates to microcontroller.
Provide the altitude of aircraft and coordinates to the microcontroller.
Schematics: (JB)
The circuitry required for the autonomous blimp consists mainly of power
management and the interfacing of sensors to the microcontroller. Each sensor has its
own requirements for voltage and current supplied. The battery is fixed at one value so a
low dropout regulator is needed for the sensors. The low dropout regulator needs to
chosen with a high enough current rating so that each of the sensors can get their required
current. The sensors needed include a 3-axis accelerometer, 3-axis gyroscope, barometer,
GPS, and two ultrasonic sensors.
Low Dropout Regulator:
(JB)
To provide the required voltage to all of the sensors, a DC/DC convertor is
needed. To step down the voltage provided from the battery, a low dropout regulator is
chosen. Figure 26 shows the circuit for the LT1963A low voltage dropout.
32
U1A
1
C1
10uF
2
In
3.3V
5
Out
R2
1.2k
4
SHDN ADJ
LT1963A
C2
10uF
0
1.21V
0
GND
R1
2.05k
3
11.1V
0
0
Figure 26- LT1963A – Low dropout regulator
This low voltage dropout is chosen over a standard buck convertor because of its
low cost as it already comes in a packaged IC. The LT1963A is capable of supplying
1.5A of output current and the output voltage has a tunable range from 1.21V to 20V.
The input voltage can also range from 1.21V to 20V. The reason that this model of a
LDO was chosen is because of its ability to provide the 1.5A of current and also because
it has an operating quiescent current of only 1mA. Another advantage of the LT1963A is
that it is optimized for fast transient response. A10µF capacitor is needed on the output to
prevent oscillations and is also used to make the output stable. Low equivalent series
resistance polytantalum capacitors are chosen because of their good transient response
which helps the stability of the regulator. The device maintains an output of 1.21V at the
ADJ pin (reference to ground) and a bias current of 3µA into the ADJ pin through R2. To
set the voltage output, the equation
!!"# = !!"# ∗ ! +
!"
+ !!"# (!")
!"
(28)
is used and the values of R1 and R2 can be set [8]. For our case where all of the sensors
require 3.3V as an input, our resistors are set to 1.2k and 2.05k, both 1% parts. The value
of R1 is made up of a 1.1k and a 1k ohm resistor. The only requirement is that R1 be less
than 4.17k to minimize errors in the output voltage caused by the ADJ pin bias current.
Accelerometer:
(JB)
To sense velocity in the x and z directions a 3-axis accelerometer is used. The
ADXL345 accelerometer shown in Figure 27 below measures the acceleration of gravity
as well as dynamic acceleration resulting from motion. This sensor is being used for the
detection of motion feature so that the velocity can be sensed.
33
C6
0.1uF
2
NC
3
4
5
3.3V
Vin
6
SDA
SDO
GND
Res
Res
74ACT109
GND
NC
GND
INT2
VS
INT1
13
µC
12
µC
11
NC
10
NC
9
NC
8
NC
7
C5
1uF
VDD_IO
CS
1
SCL
U3A
3.3V
0
14
µC
0
µC
Figure 27- ADXL345 – 3-axis accelerometer
The required supply voltage of this accelerometer is between 2-3.6V so it is
within range of the chosen LDO value and the supply current required is 140µA. The
communication with the microcontroller is SPI so it will use the same clock and data
connections as the other SPI sensors. A 1µF ceramic and 0.1µF tantalum capacitor are
placed near the supply voltages to decouple the accelerometer from noise on the power
supply. These capacitors are recommended to be placed as close as possible to the
ADXL345. It is also recommended that VS and VDD_IO be separate supplies to
minimize digital clocking noise on the VS supply. If the same supply is used, additional
filtering such as a 100 Ohm resistor in series with VS will help with decoupling [3]. The
CS pin is the chip select pin needed to communicate with the microcontroller for SPI
interfacing. The SCL, SDA, and SDO pins are all used with the SPI interfacing as the
clock, data in, and data out pins.
Gyroscope:
(JB)
To sense rotation such as roll, pitch, and yaw a 3-axis gyroscope is used. The
gyroscope that is chosen is L3G4200D as shown in Figure 28.
34
C3
C4
C8
100nF 10uF
3.0V
10nF
R3
C7
13
GND
14
15
Res
PLLFILT
Res
L3G4200D
5
NC
Res
NC
11
NC
10
NC
9
NC
Res
SAO
Res
12
8
SDA
INT1
4
10k
Res
CS
uC
3
SCL
7
uC
2
DRDY/INT2
uC
VDD_IO
6
1
VDD
U2A
16
470nF
NC
0
uC
Figure 28-L3G4200D – 3-axis gyroscope
The L3G4200D is a low-power three-axis angular rate sensor and provides the measured
angular rate through SPI. The input command will be the angle from the user as an input
so it is desired to know the angle traveled. For the same reason as the accelerometer,
either 100nF ceramic or 10µF polyester capacitors should be placed at the supply
voltages to for decoupling. These capacitors are to be placed as close to the device as
possible. There is also a need for a second order low-pass filter on the PLLFILT pin
(phase locked loop pin), this pin synchronizes driving and sensing interfaces. The supply
voltage is to be around 3.0V and the supply current required is 6.1mA [12]. For the SPI
interfacing, the SCL, SDA, and SDO pins will all use the same line as the other SPI
sensors. The CS pin however will get its own line with the microcontroller so it can be
used as a chip select.
Barometer:
(JB)
One of the design requirements is to send temperature data back to the user’s
GUI. The miniature SPI digital barometer MPL115A1 as shown in Figure 29 is used for
this requirement.
35
U4B
3.3V
C9
1uF
VDD
SCLK
µC
CAP
DIN
µC
GND
DOUT
µC
CS
µC
C10
1uF
0
SHDN
MPL115A1
Figure 29-MPL115A1 – Miniature SPI Digital Barometer
The MPL115A1 is an absolute pressure sensor with SPI interfacing. This sensor is
capable of a measuring range of 50kPa to 115kPa with a + 1kPa accuracy. It can output
monotonic pressure and temperature outputs via SPI. On the CAP pin of the IC, a 1µF
capacitor is suggested to be connected to ground as an output decoupling capacitor for the
main internal regulator. The SHDN pin is suggested to be connected to VDD for normal
operation. Among the other SPI sensors, a chip select is going to have its own connection
with the microcontroller but the SCLK, DIN, and DOUT pins will share the other lines
with the other SPI interfacing components. The supply voltage required for the barometer
is 3.3V and the required supply current is 5 µA [7]. This current and voltage required are
within the limits of the LDO that was chosen.
GPS:
1
3.3Vdc
2
V2
µC
3
4
µC
9
GND
GND
GND
U4A
10
(JB)
The altitude is desired to be sent back to the user along with the coordinates of the
blimp. To do this, a GPS is used and Figure 30 shows the RXM-GPS-SR receiver that is
used in the design.
VCC
VBACKUP
EN
TX
BS
RX
LED
8
3.3V
7
µC
6
NC
5
NC
RXM-GPS-SR
Figure 30-RXM-GPS-SR schematic
The GPS can also be used to calculate the velocity as a way of double checking or
improving the accuracy of the accelerometer. The SR series receiver can acquire and
track up to 20 satellites simultaneously in just seconds. The reason that this GPS receiver
was selected is because it was donated and the supply current required is on 31mA and
that falls under the regulations of the LDO. The supply voltage required is between 336
4.3V and there is need of a backup battery and have that set within the range of 1.3-3.6V.
The TX and RX pins on the GPS are for the serial data input and output and are to be
connected to the microcontroller. The Boot Mode Select pin is to be left open for normal
operation while the LED pin can be left open as well. The LED pin can also be connected
to a LED so it can be shown that a valid fix has been acquired and data is being received.
Ultrasonic Sensor:
(JB)
To sense objects that may appear around the blimp, ultrasonic sensors are used.
The ultrasonic sensors that are used are the LV-MaxSonar-EZ4. Shown in Figure 31 are
the internal passive components, LM324s, a diode array, and a PIC16F676 which all
make up the functions of the ultrasonic sensor.
Figure 31-The LV-MaxSonar-EZ4internal connections [10].
The LV-MaxSonar-EZ4 ultrasonic sensors can detect objects at a max distance of
6.45m within a 1-inch resolution. The interface output formats include a pulse width
output, analog voltage, and serial digital output. The analog output is not desired when
interfacing with the microcontroller. The pulse width output is where the data will be sent
as a pulse width and the range of an object can be calculated using the scale factor of
147µs per inch. Using the pulse width output means that the only pins needing
connections on the ultrasonic sensor are the GND, VCC, and the PW pins. The VCC pin
can range from 2.5V-5.5V and the PW pin is what outputs a pulse width representation of
the range. The TX pin is responsible for sending out the digital serial data so we can
leave it open. The BW and AN pins can also be left open because the analog data output
37
is not being used. The RX pin is internally held high so it does not need to be externally
connected to anything. The blimp is using two of these ultrasonic sensors, one connected
in front of the blimp so anything directly ahead can be detected. The other is connected
on the bottom of the blimp and facing towards the ground so that when the blimp is near
landing, the ground distance can be known.
XBee:
(JB)
To transmit data between the blimp and the ground, Xbee Pro is used. Xbee Pro is
capable of transmitting data up to 300’ and only requires 63mW of transmit power. The
required transmitting current is 250mA with a 340mA peak value; the required receiving
current is 55mA when at 3.3V. These ratings are within the selected LDO requirements.
UART will be the interfacing environment with Xbee Pro and it will require a data out
and in line with the microcontroller along with several digital input and outputs for
communication. Figure 32 shows the pin layout of the Xbee transmitter and which pins
are inputs and outputs to the microcontroller. The digital input/output pins are excess and
will not be connected to anything.
3.3V
µC
µC
µC
µC
µC
µC
NC
U7B
VCC
DIO0
DOUT
DIO1
DIN
DIO2
DO8
DIO3
RESET
DIO6
PWM0
Associate/ DIO5
PWM1
VRef
Res
µC
ON/Sleep
DTR/Sleep-RQ/D18 DIO7
GND
0
DIO4
NC
NC
NC
NC
NC
NC
µC
µC
NC
NC
XBEE Pro
Figure 32-Xbee Pro Pin Layout
Microcontroller:
(JB)
After selecting all of the sensors needed for the blimp, a microcontroller is chosen
based upon how many general purpose input and output pins needed according to the
components used. Another specification of a microcontroller is that it needs four output
comparator pins for PWMs. SPI, I2C, and UART interfacing is also needed so that there
is a choice in choosing the type of communication to use. Table 7 shows a listing
components and which ones need general purpose IO pins on the IC.
38
Table 7- List of IO Pins
# of IO Pins Component needed Barometer 1 Gyroscope 1 Accelerometer 1 GPS 3 ESC 4 Battery 1 Release Valve 1 Ultrasonic 4 SPI 3 Xbee 4 Total 23 (SPI requires 2 data lines and a clock) With this number of general purpose IO’s required, the PIC24FJ256GB108-I/PT
80-pin microcontroller is chosen. This microcontroller supports SPI interfacing through 3
SPI modules, which is what is being used with communicating with the sensors. There
are sixty-five IO pins available on the microcontroller to go along with five 16-Bit timers
and nine PWM outputs. This microcontroller has more capability than needed but it was
chosen with the idea of expansion if the future. If there are an excess amount of IO pins
that are not needed, a 1k resistor can be used between VDD and the unused pin so that
the pin can be set to a logic low. Shown in Figure 33 are the minimum recommended
connections for the microcontroller
Figure 33-PIC24FJ256GB108 recommended connections.
39
Like other integrated circuits that are being used, decoupling capacitors need to be
added externally on every pair of power supply pins, such as VDD, VSS, AVDD, and
AVSS. The voltage supplies are all connected to a voltage in the range from 2-3.6V,
which falls within the range of the selected LDO voltage. These capacitors should be a
low-ESR device and have a resonance frequency of 200 MHz. The values and type are to
be 0.1uF 10-20V ceramic capacitors. These capacitors are to be placed as close to the
pins of the microcontroller as possible similar to other decoupling capacitors being used.
The MCLR pin of the microcontroller is responsible for a device reset and also device
programming and debugging. To ensure that the device does not reset spontaneously, a
small network of two resistors and a capacitor can be used. This MCLR pin Vin high and
low are met due to the 10k Ohm resistor shown in Figure 33 as R6, the resistor R7 has a
value of 400 Ohms and will limit any current flowing into the MCLR from the external
capacitor. This provides protection against Electrostatic Discharge (ESD) or Electrical
Overstress (EOS). The Vcap/VDDcore pin of the microcontroller is a voltage regulator
and it needs to have a low ESR 10uF capacitor tied from it to ground to maintain the
stability of the regulator.
Battery Monitoring:
(JB)
To monitor the battery charge level, a voltage divider will be used to get the
battery voltage within the range of the microcontroller pins so it can be monitored. This is
desired so that when the battery level is reaching a critical value, the user can be alarmed.
The battery voltage is 11.1V when fully charged and this voltage needs to correspond to
5V, which is the max voltage that a pin on the microcontroller can see. Figure 34 shows
a simple voltage divider that can be implemented to achieve the desired range.
R4
100k
V3
11.1Vdc
R5
81.9k
0
1
2
U9
+
3
µC
-
0
Figure 34- Voltage divider to monitor battery voltage
These values of R4 and R5 will be sufficient to produce a range from 0-5V that is seen by
the microcontroller. R4 is chosen to be a 100k Ohm 1% resistor and R5 is chosen to be an
80.6k, 100, and a 1.02k Ohm resistor, each 1% parts. With the values of these resistors
relatively high, there is not much power dissipated across them. This is a desired effect
because the purpose is only to view the value of the battery voltage. The battery that is
chosen has to have the voltage vs. charge characteristics understood so that the reading
can be accurate. To prevent any loading from the microcontroller on to the resistor, a
voltage buffer is used using a ua741cp.
Electric Release Valve:
40
(MW)
It may also become desirable to bring the blimp down to ground level quickly as
possible. If the blimp has a high lift force, the blimp may become uncontrollable unless
some of the helium inside the blimp is released. It would also be considered a safety
feature to have a release system so that the blimp does not drift into any hazards
situations. Despite proper motor placement, it may be difficult to bring down a blimp in
a short amount of time. One possible method of release Helium from the blimp is to
utilize an electric release valve. The blimp is equipped with several rubber valves in
which a hose barb can be used to connect a ¼ inch hose to an electric release valve. The
solenoid being considered is the EZ-2140-0-243-D Vera Valve. This solenoid runs on a
12 Volt input with a power output of 10.5 Watts. However, the opening of the solenoid is
only ¼ inches wide, but the device is suitable for air pressure up to 700 psi. When it is
become desired to bring the blimp down, the electric release valve can be triggered by a
voltage signal and remain open as long as determined by the user. The possible
configuration for the release system is displayed in Figure 35. The success of operation
of the Versa Valve will depend entirely on creating a sealed connection between the
blimp envelope and the electric solenoid [15]. Final results and design may not be
concluded until testing is executed with a fully inflated envelope.
Blimp
Air Valve
Hose Line
Air Release
Electric Release Valve
Motor 3
Motor 4
Figure 35- Release Valve System
Camera:
(MW)
The camera being considered for surveillances purposes is a mini wireless 2.4 GHz
camera. This small camera has full color capabilities and a range of over 200 feet. The
camera has its own transmission system that will be separate from the XBee transmitter
41
and/or microcontroller, and only requires a 9 volt battery to run. This allows the camera
to run for about 2 hours worth of time. The camera will transmit to a base receiver,
which will connect to a RCA input device. The screen device can be a television screen,
or the RCA signal can be converted to a computer monitor screen. The camera may also
be mounted and a pan and tilt servo motor system that would be attached to the gondola.
The pan and tilt system would allow the user to can full control via the RC controller.
The user would be able to control the rotation of the camera while the blimp is in a stable
and stationary position.
Level 1 Hardware
(JB)
The hardware level 1 block diagram can be found below in Figure 36 along with
functional requirements in Table 5.
Battery Voltage
Power
Management
Proximity Sensor
Inertial Sensor Unit
MicroController
Camera
Motor
Controller
GPS Unit
User Input Control
(Multidirectional)
Remote Control
Wireless
Communication
Module
Figure 36 – Hardware Level 1 Block Diagram
42
Display
Module
3-phase Motors
and Servomotor
Table 8 – Hardware Level 1 Functional Requirements
Module
Inputs
Outputs
Functionality
Power Management
Power In: Battery input
Power Out: To motors, motor controller, and microcontroller
Provide regulated voltage to motors, motor controller, and
microcontroller.
Module
Inputs
Microcontroller
Power In: Battery input
Proximity Sensor: Distance (m) of objects for failsafe
Remote Control: User directional input
Read Camera Data: Gathers live video and sends to transmitter
Read Yaw, Pitch and Roll: Positioning data (X, Y and Z Axis
Data)
Read Sensors: Battery (V), GPS positioning (Latitude, Longitude)
and aircraft speed (m/s)
Sensor Data Out: Provide positioning sensor data to motor
controller
Wireless Sensor Data Out: Sends video and measurement data to
wireless transmitter
Use battery input to supply microcontroller while reading user directional
input data along with inertial data and directing data to motor controller
for autonomous control and compensation. Read proximity data for
failsafe and read measurement sensors and sends the signals to a wireless
transmitter.
Outputs
Functionality
Module
Inputs
Motor Controller
Power In: Battery input
Positioning Data: Microcontroller positioning sensor data in
Outputs
Functionality
Motors: Controls the speed, direction, and stability
Use battery input to supply motor-controller and read positioning sensor
data logic from the microcontroller. Sends a signal to control the motors
speed, direction, and stability.
43
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
3- Phase Motors and Servomotor
Power in: Battery input
Controller Data: Signal from Motor Controller
Motors: Controls the speed and direction of flight
Use battery input to supply motors and according to the input signal from
the motor-controller, adjust the speed of the motors.
Remote Control
Power In: ?V Battery
User Input Control: User directional input
Positioning Data: To wireless transceiver
Use a ?V battery to supply power to a transmitter and send user
directional input to a wireless transceiver
Wireless Communication Module
Power in: Battery Input
User Positioning Data: From remote control
Measurement Sensor Data: Receive data from microcontroller
User Positioning Data: Transmit positioning data to
microcontroller
Measurement Sensor Data: Send to user display
Use battery input to supply wireless transceiver and receives positioning
data from remote control and sends the positioning data to the
microcontroller. Receives measurement data from the microcontroller
and sends that data to the user display.
Display
Sensor Data In: Wireless Measurement and Video Data In
Display Video: Live video signal displayed to user
Display Measured Data: Battery (V), GPS positioning (Latitude,
Longitude) and aircraft speed (m/s) displayed on a screen
Read measurement and sensor data to display to user on a screen such as
battery life, GPS positioning and aircraft speed while also displaying live
video
44
Software Functional Decomposition
(SP)
For the blimp system, the software’s primary function is to calculate how to
control the motors in order to follow the user’s direction or self-stabilize when there is no
user-input. This requires reading sensors for determining the current attitude and
movement of the craft along with the commands from a user input device (remote
control) in order to arrive at new motor speeds. In addition, sensor data needs to be
formatted and relayed back to the user. Figure 37 shows this at the lowest functional
software design level, encapsulating the main functionality of software for the blimp in a
single block.
Motor Speed
Control
Sensors
User Input
Blimp Software System
Formatted
Display Data
Figure 37 - Software Level 0 Block Diagram
Table 9 - Software Level 0 Functional Requirements
Module
Inputs
Outputs
Functionality
Blimp Software System
-Sensors: on-board sensors reading blimp attitude/movement data for
motor control and weather data for display.
-User Input: user-control signals telling the blimp how to move.
-Motor Speed Control: calculated motor speeds to control flight of the
blimp.
-Formatted Display Data: data to be relayed to the user.
Read user inputs and sensors to determine how to control the blimp.
Moving to level 1 of the design, the overall software system architecture can be
seen at a high level in Figure 38. In the diagram, there is a distinction between software
on-board the blimp and software on the ground with the user. The diagram also shows
how data flows in the system (pictured left to right with arrows) for each platform and
what data is needed to be communicated between the two platforms. Both the sensors
and user input are used to control the motors via the motor control algorithm. The motor
control algorithm needs to know the current orientation of the craft and how it is moving
45
to calculate how to adjust the motors to meet the desired movement and orientation of the
craft. This will be heavily based on the control system described previously.
Blimp / Microcontroller
Blimp
Orientation/
Movement
Temperature Data
Barometer Data
Motor 1 Control
Motor 2 Control
Proximity Sensor Data
Attitude Data
Sensors
Interface
Motor 3 Control
Motor Control Algorithm
Motor 4 Control
GPS Data
Battery Level Data
User Command Packet
Sensor Data Packet
Wireless Data Transmission
Ground / PC
Display Coordinates
Display Altitude
User Input Control
User Input
Transformation
Display
Software
Display Air Pressure
Display Temperature
Display Speed
Display Battery Level
Figure 38 - Software Level 1 Block Diagram
Table 10 - Software Level 1 Functional Requirements
Module
Inputs
Outputs
Functionality
Sensors Interface (Blimp)
-Proximity Sensor Data: Proximity sensor reading.
-Attitude Data: Orientation data from inertial measurement unit
(gyroscope and accelerometer).
-Air Pressure Data: Barometer sensor reading.
-Temperature Data: Temperature sensor reading.
-GPS/Position: GPS data from on-board GPS unit.
-Battery Level Data: Voltage level reading from battery.
-Sensor Data Packet: combined sensor readings to be transmitted
wirelessly.
-Blimp Orientation/Movement: Data concerning the attitude of the blimp,
the current speed of the blimp (in all directions), and obstacles in
proximity of the blimp.
Reads sensors, calculates the meaning of the inertial measure unit sensors
for motor control, and directs data in the appropriate format.
46
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Functionality
Motor Control Algorithm (Blimp)
-Blimp Orientation/Movement: Velocity of blimp in x and z directions,
angular velocity for yaw, the current pitch angle, and distance to objects
relative to motion.
-User Command Packet: User commanded controls.
-Motor 1 through 4 Control: Calculated motor speeds for each motor.
Implements the control system for the craft based on current orientation
and movement.
User Input Transformation (Ground)
-User Input Control: Data from user control device.
-User Commands: Data sent to the craft to direct speed and direction
based on the user’s input.
Reads user input and sends the commands to the craft wirelessly.
Display Software (Ground)
-Sensor Data Packet: Data to be displayed to the user.
-Display Coordinates: Coordinates displayed to user on screen.
-Display Altitude: Altitude data displayed to user on screen.
-Display Air Pressure: Air pressure data displayed to user on screen.
-Display Temperature: Temperature data displayed to user on screen.
-Display Speed: Speed data displayed to user on screen.
-Display Battery Level: Battery level data displayed to user on screen.
Reads, formats, and displays data back to the user.
The software design is broken down further in its level 2 block diagram shown
below in Figure 39. The addition of calculating velocities for x and z directions and
calculating the pitch angle are needed as inputs to the motor control system.
Additionally, modules for sending and receiving data have been added along with a
module for converting motor speeds to PWM signals to work with the electronic speed
control (ESC) that are actually driving each motor.
47
Blimp / Microcontroller
Calculate
Velocities
Motor 1 through 4
PWM Control
Motor 1 through 4
RPM
Temperature Data
Barometer Data
Proximity Sensor Data
Attitude Data
Read
Sensors
Calculate
Pitch Angle
Motor Control
Algorithm
Motor PWM
Sequencing
GPS Data
Read User
Commands
Battery Level Data
Package/
Send Sensor
Data
User Command Packet
Ground / PC
User Input Control
Sensor Data Packet
Package/
Send User
Commands
Display Coordinates
Read Sensor
Data
Display Altitude
Graphical
User
Interface
User Input
Transformation
Wireless Data Transmission
Format Data
Display Air Pressure
Display Temperature
Display Speed
Display Battery Level
Figure 39 - Software Level 2 Block Diagram
Order of events on blimp (main loop):
1. Read Sensors
2. Calculate Pitch Angle (from combination of accelerometer and gyroscope
readings)
3. Calculate Velocities
4. Check for and read user commands
5. Execute motor control algorithm
6. Adjust generated PWM signals based on new motor speeds
7. Package/send sensor data if enough time has elapsed since last send
Figure 40 - Software Level 2 Functional Requirements (for new or updated Modules)
Module
Motor PWM Sequencing (Blimp)
Inputs
-Motor 1 through 4 RPM: Desired RPM of motors 1 through 4
Outputs
-Motor 1 through 4 PWM Control: Motor control PWM signal
Functionality Converts RPM to pulse width modulation to work with ESC.
48
Module
Inputs
Outputs
Functionality
Calculate Velocities (Blimp)
-Attitude Data: Accelerometer, gyroscope, and GPS sensor readings
-Pitch Angle: current angle of the pitch
-Calculated velocities: Craft velocity in x direction and in z direction
Calculates craft velocities necessary for control system
Module
Inputs
Outputs
Functionality
Calculate Pitch Angle (Blimp)
-Attitude data: Accelerometer and gyroscope readings
-Pitch angle: Craft pitch angle.
Calculates the craft’s pitch angle (relative to x-axis)
Module
Inputs
Outputs
Functionality
Package/Send Sensor Data (Blimp)
-Sensor Data: Data from sensors and calculations.
-Sensor Data Packet: Sensor data packaged for wireless transmission.
Packages user sensor data for wireless transmission
Module
Inputs
Outputs
Functionality
Read User Commands (Blimp)
-User Command Packet: Packaged data for controlling the craft
-Desired movement: Desired x, z, yaw velocities, and pitch angle.
Parses transmitted user command packet into desired movement.
Module
Inputs
Outputs
Functionality
Read Sensor Data (Ground)
- Sensor Data Packet: On-board sensor and blimp data.
-Sensor Data: On-board sensor data to be displayed to the user
Reads transmitted sensor data.
Module
Inputs
Outputs
Functionality
Format Data (Ground)
- Sensor Data: Unformatted data to be displayed to user.
-Formatted Sensor Data: Data ready to be displayed to user.
Formats data from blimp to be displayed to user.
49
Module
Inputs
Outputs
Functionality
Module
Inputs
Outputs
Package/Send User Commands (Ground)
-User Input: Transformed user input for controlling craft.
-User Command Packet: User control packaged for wireless
transmission.
Packages user commands for wireless transmission
Motor Control Algorithm (Blimp)
-Craft x velocity, z velocity, yaw angular velocity, pitch angle: Current
orientation and movement of the craft.
-Desired x velocity, z velocity, yaw angular velocity, pitch angle (from
user command): Desired orientation and movement of the craft.
-Proximity Sensor Data: Flags for objects in range of proximity sensors
-Motor 1 through 4 RPM: Calculated motor speeds for each motor.
50
Functionality
Start
Set desired
Pitch Angle = 0
Yaw Angular
Velocity = 0
X Velocity = 0
Z Velocity = 0
No
User Input?
Yes
Set desired Pitch
Angle, Yaw
Angular Velocity,
X Velocity, Z
Velocity from
user control
reading
Set desired
value(s)
that are
blocked to 0
Yes
Desired
movement
blocked by
obstacle?
Calculate error between
desired and actual
movement and store it
No
Pass each error through
its associated
compensator (difference
equation) and store the
result
Take compensated result
and solve system of
equations for finding
motor thrusts
Convert thrust to RPM
for each motor
End
Software Design
(SCP)
The software design for the blimp system consists of two computing platforms:
on-board the blimp using a microcontroller (PIC) and at the user via PC (Windows-based
laptop). Wireless communication between the two platforms is made through two XBee
Pro RF modules. Since the modules will be operating in transparent mode,
communication between the two can be thought of a serial line replacement (UART).
51
Ground/Client System
Overview:
The system the user interacts with directly consists of an Xbox360 controller
connected to a PC. The main functionality of the ground system is reading, formatting,
and transmitting user controls to the blimp along with reading, formatting, and displaying
sensor data sent from the blimp to the user. There are many available options for
programming languages and frameworks for completing the tasks required by the ground
system, but Microsoft’s C# .NET may be the simplest to use. It provides frameworks for
communicating through serial ports for the XBee wireless transceiver, reading input
devices such the Xbox 360 controller, and a simple but effective way to create reasonable
looking user interfaces without much hassle. This does limit the ground station laptop to
be Windows-based, but it was likely going to be that way due to the use of the Xbox 360
controller. No team members have non-Windows laptops, either.
Interfacing with the Xbox 360 Controller:
The Xbox 360 controller was chosen for a few main reasons: it’s intuitive to use,
contains all of the sensitive buttons needed for blimp flight control, simple to interface
with on the PC (also powered by USB), and is highly available (team members already
own the controller to use for the project). A detached-from-PC controller could be used
but would require additional hardware, including wireless communication components
attached directly to the controller (rather than reusing the Xbee connected to the PC).
Using the Xbox 360 controller also keeps the communication network as simple possible
with only communication between two nodes. The projected control scheme for the
blimp is shown below in Figure 41.
Left Trigger: Fly
Down (8-bit sensitivity)
Left Stick: Pitch/yaw control
(16-bit sensitivity for each
plane)
Right Trigger: Fly up
(8-bit sensitivity)
Right Stick: Fly forwards/backwards
(16-bit sensitivity for each plane)
Back and Start button combination:
trigger electric release valve (Bool)
Figure 41 - Xbox 360 Controller Configuration
52
The controller has two sensitive trigger buttons (top) that will be used to control
the z-translational movement of the blimp. The other two sensitive controls are the left
analog stick and the right analog stick. Both analog sticks can be thought of as a
coordinate plane with 16-bit signed numbers and the north/east as the positive directions
as shown in Figure 42. When interfacing with the analog sticks, the “dead zone” (also
shown in Figure 42) must be taken into account. This is the region on the plane where
any x-coordinate or y-coordinate within its range should be considered zero since they
cannot be accurately read. Both analog sticks are extremely sensitive and will never be at
true zero, resulting in the need for taking the dead zone into account. (This is done is
software, described later.) The left stick will be used to control the pitch along the y-axis
and the yaw along the x-axis. The right stick will only be used to control x-translational
movement via the y-axis. In the future blimp weight, team member time, and project
funding allowing, the right stick x-axis and/or additional unused buttons may be used to
control a pan-and-tilt mechanism for the on-board video camera.
y
“Dead Zone”
32767
32767
x
-32768
-32768
Figure 42- Xbox 360 Analog Stick Sensitivity
In order to interface with the Xbox 360 controller, Microsoft’s XInput (part of
DirectX) application programming interface (API) will be used. XInput is an API that
allows applications to receive input from the Xbox 360 controller for modern Windows
operating systems. There is no current direct Microsoft support built into the .NET
framework for XInput in a managed environment such as C#, but there is an external
library called XInput.NET which provides a simple wrapper to the XInput API. There
are other options besides, XInput.NET (including other simple wrappers) for interfacing
with XInput, such as Microsoft’s XNA framework used for game development with
.NET or another framework called SlimDX (an open source framework for DirectX).
Both provide full support for anything you would want to do with the XInput API,
however, adding a dependency on an additional framework just for controller support that
can be used natively is not ideal. Using XInput.NET will limit the project’s dependencies
on external frameworks, and in turn, limit the number of components needed to be
installed on a machine in order to run the ground system program. Besides the .NET
framework, there will be no external dependencies to install for the PC software, and it
should run out of the box on any Windows-based computer with (Windows XP or
newer).
53
Interfacing with the XBee Pro Transceiver: The XBee transceiver will be connected to the PC running the ground software
through a USB port, which comes from an FTDI (Future Technology Devices
International) chip used to convert the serial output of the XBee to USB. The PC will see
the connected USB port as a virtual serial communication port, allowing for serial
communication to and from the XBee module. (This is due to a software driver for
talking to FTDI chips that comes preinstalled on operating systems like Windows.)
To communicate with the serial ports, .NET provides a namespace called
“System.IO.Ports” which contains the functionality required to communicate with any
connected serial port through a simple interface. Namely, what will be used is a class
within the namespace called “SerialPort,” which can be set up to read and write to a serial
port with the specified baud rate, data bits, stop bits, and parity.
Ground System Design:
The software for the ground will utilize the object oriented paradigm. The
complete UML class diagram for the system can be seen in Figure 43 showing each
dependency and association.
XBee
-­‐port : SerialPort
+recievedDataBuffer : List<sbyte>
+XBee(in portName : string, in buadRate : int, in parity : Parity, in stopBits : int, in dataBits : int, in handshake : HandShake, in threshold : ReceivedBytesThreshold)
+dataRecievedHandler()
+transmit(in data : List<sbyte>)
BlimpMain
+main()
BlimpController
System.IO.Ports
Provides framework for
synchronous and event driven I/O
+execute()
-­‐formatAnalogStickAxis(in stickValue : short) : sbyte
-­‐formatTriggers(in leftTrigger : byte, in rightTrigger : byte) : sbyte
GUI
BlimpSensorData
XBox360Controller
+velocityX
+velocityZ
+altitude
+airPressure
+distanceFront
+distanceBottom
+temperature
+batteryLevel
+BlimpSensorData(in data : List<sbyte>)
+leftThumbX : short
+leftThumbY : short
+rightThumbX : short
+rightThumbY : short
+leftTrigger : byte
+rightTrigger : byte
+start : bool
+back : bool
+update()
+vibrate(in leftMotor : float, in rightMotor : float)
XInput
Provides interface to raw game controller state
Figure 43- Ground System Class Diagram
Note on C# data types: short represents signed 16-bit integer, byte represents an unsigned
8-bit integer, and sbyte represents an 8-bit signed integer.
54
There are distinct classes for interfacing with the Xbox 360 controller and
interfacing with XBee. As mentioned previously, the input from the Xbox 360 controller
will be read using XInput API. The class Xbox360Controller will read the raw controller
data from XInput every time its update() method is invoked and update its fields
(properties with public accessors/get and private mutators/set in C#). Additionally,
XInput provides a way to vibrate the controller which will be used in critical situations
such as low battery levels on blimp.
The XBee class will serve as a wrapper for a System.IO.Ports.SerialPort object,
and will initialize the desired settings in its constructor involving the serial
communication. The two functions of the XBee class are to read and write to the serial
port for communication with the USB-connected XBee. Reading from the serial port will
be event based. That is, when data is ready to be read from the port, the dataRecieved()
event handler will be called and the data packet will be handled. The XBee class allows
for the specification of when the data received handler will be called via the
RecievedBytesThreshold (wrapper for 32-bit integer) parameter in the constructor. This
will be used to know when all of the data from the blimp has been received and is ready
to be processed. The XBee constructor also allows for specification handshaking in the
communication. For this application, the hardware handshakes will be used: request to
send and clear to send.
The BlimpController is used to work with the XBee and Xbox360Controller
classes to control the blimp and process blimp data. The execute method() creates new
Xbox360Controller instance and a new XBee instance and then enters an endless loop.
The loop execution sequence can be seen in the sequence diagram in Figure 44. The
BlimpController uses its formatting methods to transform the data from the Xbox360
controller into 8-bit signed (two’s complement) representation for each control (x, z, yaw,
pitch). This formatted data can then be transmitted serially with the XBee class to the
blimp. When sensor data is available from the blimp, the BlimpController will construct
a new BlimpSensorData object and the user interface (UI) will be notified via an event
that a new data source is available. The UI will then bind to the new created
BlimpSensorData and update its display.
55
BlimpController
XBox360Controller
XBee
BlimpSensorData
update
updated control keys
check recieved data buffer
raw recieved sensor data
create
compute blimp controls (pitch, yaw, x, z)
UI notified of sensor data creation event
to update display
transmit blimp controls
Delay between repeating loop
(based on experimentation)
Figure 44- Blimp Controller Execution Loop Sequence Diagram
The byte sequence for wireless transmission to the blimp is shown below in
Figure 45. The XBee will be operating in transparent mode (since it is only a simple two
node network), so this is raw serial data that the blimp will receive. The first byte
contains a command instruction followed by four 8-bit signed values representing user
control (from the controller). The only command at this point is to trigger the electric
release valve in case of emergency, but others could be added in the future. There is a
tradeoff in sending the raw scaled controller data instead a pre-calculated control system
input (i.e., desired x-velocity) because that calculation will now need to be done on the
microcontroller, but it reduces the amount of data needed to be transmitted due to
requiring additional bits for fixed or floating-point representation.
Command
Pitch
Yaw
X
Z
Figure 45 - Transmission byte sequence from ground system to blimp
The BlimpMain class serves as the entry point to the program. Within the main
method, a new BlimpController is created on a new thread and its endless loop execute()
method is started. Following that, BlimpMain sets up the graphical user interface. This
application requires multithreading to allow for concurrent reading of the user input and
blimp-control functions, while simultaneously displaying a responsive user interface.
56
The only communication to the GUI from the blimp control thread will be an event
triggering the GUI to update its display with newly received data.
On-Board Software System
The functionality of the on-board software system includes reading sensors to
calculate the orientation and velocities of the blimp, reading and interpreting user
commands, controlling the motors of the blimp (via interpreted commands, current
orientation, and velocity), and transmitting sensor data back to the user through UART
communication with the on-board XBee Pro.
Motor Control System:
Motor control involves the implementation of the control system described in the
Controlling the Blimp section. To do this, the velocity in the x-direction, velocity in the
z-direction, angular yaw velocity, and pitch angle must be calculated. To calculate pitch
angle, both the accelerometer and gyroscope need to be used. An accelerometer alone
cannot tell the difference between static acceleration due to gravity from acceleration due
to movement and integrating a gyroscope reading over time will be unstable with any
amount of drift. Combining the two sensors for the accelerometer’s usefulness over a
longer time scale and the gyroscope’s usefulness over short periods can result in usable
angle measurements for pitch. Calculating the pitch of an object in motion is a very
common problem (such as in the two-wheeled self-balancing robot), and the solution is
typically a Kalman filter to get the best estimation of the angle amidst noise and
undesired motion. There is an optimized C program to estimate pitch angle from xacceleration, z-acceleration, and pitch rate available under GNU General Public Release
that could be utilized for the project (available at
http://www.rotomotion.com/downloads/tilt.c). Kalman filters are complex and difficult
to understand, but could be useful when implementing the software for calculating pitch
angle.
Velocities in the x and z directions will need to be calculated with the
accelerometer and gyroscope as well, and compared with previous readings to exclude
extraneous data. GPS readings could also be incorporated to ensure accuracy. The
sensors will need to be tested to determine how well sampling and summing values will
be for integrating acceleration.
Pulse Width Modulation:
In order to control the motors, a pulse width modulated (PWM) signal for each
electronic speed control (ESC) needs to be generated. Being fed a PWM signal with a
duty cycle of 50%, with a certain tolerance (dead zone), the ESC will instruct the motor
to halt any rotation. With a duty cycle longer than the dead zone cutoff, the motor will
drive forward. Above the cutoff, increasing the duty cycle will increase the motor speed
until it reaches the zone where it is at full speed forward. Similarly, with a duty cycle
less than 50%, the motor will go in reverse. The PWM signal to motor control
relationship is shown in Figure 46.
57
Proportional Reverse
Full Reverse
50% Duty Cycle
Motor Off
Proportional Forward
Full Forward
Period
Figure 46 - PWM Duty Cycle Motor Control Relationship
To generate this signal for each of the four ESCs, a timer with a fixed period and
four output compare modules (one for each ESC) on the PIC will be used. By using the
calculated motor speeds from the motor control algorithm, the duty cycles required for
controlling each of the ESCs can be calculated.
Communication: Communication with the ground system will involve interfacing with XBee
through the UART protocol. Receiving control data from the user is a critical operation
and will be handled through an interrupt service routine triggered whenever there is new
data available for in the receive buffer. Sending data back to the user will be triggered
when the XBee is free to send and an elapsed time has passed, through the use of a timer.
Hardware handshakes clear to send and ready to send will be used to control the flow the
data.
Pseudo Code Initialize system:
Initialize Timer1 for PWM generation
Initialize Output Compare 1-4 for PWM generation
Initialize SPI Registers and set Chip Select High for each SPI Device
Initialize UART1 Registers for XBee communication
Initialize UART2 Registers for Ping Sensor Communication (baud rate is
9600, 8 bits, no parity, with one stop bit)
Initialize Timer2 for sending sensor data to ground system
Variables:
dataReceivedBuffer [] - storage for data received by UART 1 (XBee) data received
interrupt
currentPacket [] - container for the most recent complete packet
Initialize difference equation variables to 0: previous x, z, yaw, and pitch values and
previous x, z, yaw, and pitch error values
58
Movement constants: MAX_YAWRATE, MAX_XRATE, MAX_ZRATE,
MAX_PITCH_ANGLE
Data size constant: MAX_SIZE = 127
Scaling constants :
PITCH_SCALE = MAX_PITCH_ANGLE/ MAX_SIZE
YAW_SCALE = MAX_YAWRATE / MAX_SIZE
X_SCALE = MAX_XRATE / MAX_SIZE
Z_SCALE= MAX_ZRATE/ MAX_SIZE
Control constants: MAX_HEIGHT = 400
Motor Constants:
THRUST-RPM_PROPORTIONALITY = 8354218.88 (inverse of 1.197e-7)
MAX_RPM (possibly for each motor)
Physical system constants: MOTOR_DISTANCE_X, MOTOR_DISTANCE_Y,
MOTOR_DISTANCE_Z
Main Loop:
Set Gyroscope Chip Select Low
Request Pitch Angular Velocity
Read Pitch Angular Velocity and store it
Request Yaw Angular Velocity
Read Yaw Angular Velocity and store it
Set Gyroscope Chip Select High
Set Accelerometer Chip Select Low
Request X Acceleration
Read X Acceleration and store it
Request Z Rate
Read Yaw Rate and store it
Set Accelerometer Chip Select High
Set GPS EN High
Read serial National Marine Electronics Association (NMEA) message string and store it
Parse NMEA message for longitude, latitude, and heading and store the result
Set GPS EN Low
Set Accelerometer Chip Select Low
Request X Acceleration
Read X Acceleration and store it
Request Z Acceleration
Read Z Acceleration and store it
Set Accelerometer Chip Select High
Set Barometer Chip Select Low
Request Air Pressure Data
Read Air Pressure Data and store it
Request Temperature Data
59
Read Temperature Data and store it
Set Barometer Chip Select High
Calculate altitude (barometer and GPS)
Calculate Pitch Angle
Calculate X Velocity
Calculate Z Velocity
Check currentPacket [] for user-control packet
if currentPacket [] has complete packet
{
Parse the packet:
if currentPacket [0] signals to, enable electronic release valve
scale received user input to match desired
set desired pitch angle = currentPacket [1] * PITCH_SCALE
set desired yaw-velocity = currentPacket [2] * YAW_SCALE
set desired x-velocity = currentPacket [3] * X_SCALE
set desired z-velocity = currentPacket [4] * Z_SCALE
Perform obstacle detection:
Enable serial communication with front ping sensor
Read front-of-blimp ping sensor serial data (UART)
if desired x-velocity greater than 0 and obstacle detected,
set desired x-velocity to 0
Enable serial communication with bottom ping sensor
Read bottom-of-blimp ping sensor serial data (UART)
if desired z-velocity less than 0 and obstacle detected,
set desired z-velocity to 0
Handle FAA 400 ft. ceiling:
if altitude approaching MAX_HEIGHT,
if desired z-velocity greater than 0,
set desired z-velocity to 0
if desired pitch angle greater than 0 and desired x-velocity greater than 0,
set desired pitch angle to 0 and desired x-velocity to 0
clear currentPacket[]
}
else
{
set desired pitch angle = 0
set desired yaw-velocity = 0
60
set desired x-velocity = 0
set desired z-velocity = 0
}
Error calculations (desired - actual):
Calculate x-velocity error and store it
Calculate z-velocity error and store it
Calculate yaw-velocity error and store it
Calculate pitch angle error and store it
Difference equations (compensators from current model) to find Ux, Uz, Uyaw, Upitch:
set Ux to previous_Ux + 5* x-velocity_error -4.989*previous_ x-velocity_error
set previous_Ux to Ux and previous_ x-velocity_error to x-velocity_error
set Uz to previous_Uz + 10* z-velocity_error -9.85*previous_ z-velocity_error
set previous_Uz to Uz and previous_ z-velocity_error to z-velocity_error
set Uyaw to previous_Uyaw + 15* yaw-velocity_error -14.925*previous_ yawvelocity_error
set previous_ Uyaw to Uyaw and previous_ yaw-velocity_error to yaw-velocity_error
set Upitch to 35*pitch-angle_error + 34.8075*previous_ pitch-angle_error
set previous_pitch-angle_error to pitch-angle_error
Solve system equations to find motor thrusts (M1..M4):
set M1 to (Uyaw + Ux*MOTOR_DISTANCE_Y)/(2* MOTOR_DISTANCE_Y)
set M2 to -(Uyaw - Ux* MOTOR_DISTANCE_Y)/(2* MOTOR_DISTANCE_Y)
set M3 to (Uz*MOTOR_DISTANCE_X - Upitch + Ux*MOTOR_DISTANCE_X)/(2*
MOTOR_DISTANCE_X)
set M4 to (Upitch + Uz* MOTOR_DISTANCE_X - Ux* MOTOR_DISTANCE_Z)/(2*
MOTOR_DISTANCE_X)
Compute motor speeds and directions (RPM):
for each motor thrust (M1..M4)
set value RPM for motor to sqrt(abs(motor thrust*THRUSTRPM_PROPORTIONALITY))
if motor thrust < 0, set value RPM for motor to its negated value
Convert signed RPM to PWM signal for each motor:
set scaledRPM to RPM for motor/MAX_RPM for motor
set duty cycle for motor to PWM timer period * RPM for motor/MAX_RPM for motor
if scaledRPM is less than 0
calculate for negative rotation:
set duty cycle for motor to PWM timer period * (0.5 + scaledRPM/2)
otherwise
61
calculate for positive rotation:
set duty cycle for motor to PWM timer period * (1 - scaledRPM /2)
if transmission timer has elapsed far enough,
package most recent sensor data write it XBee UART
Repeat loop
End pseudo code.
6. Parts List (MW)
Table 10 displays the required parts list with some optional parts that may be
considered to enhance the project design.
Table 11-Parts List
Qty.
2
1
1
2
1
1
1
1
1
4
4
1
1
1
4
Refdes
U3A
U2A
U7B
U4A
U4B
2
1
2
1
2
1
1
2
1
1
C1, C2
R2
R1
Part Num.
MB1040 LV-MaxSonarEZ4
ADXL345BCCZ-RL
L3G4200DTR
XBP24-AWI-001
32400
32403
RMS-GPS-SR
MPL115A1T1
LT1963AES8#PBF
Optima 480 3010-910kv
jDrones AC20-1.0
HB125-100
EZ-2140-0-243-D
PIC24FJ256GB108-I/PT
LP0906P
A1038SFP
N/A
77P-SL5000-3S1P-20C3333
dfc1133
0-HRC31055S
N/A
N/A
TCJY106M035R0070
ERJ-3EKF1201V
ERJ-3EKF2051V
Description
Ultrasonic Sensor
Accelerometer
Gyroscope
RF Transceiver
XBEE USB Adapter
XBEE Adapter Board
GPS Reciever
Barometer
Low Drop Out Regulator
Brushless DC Motors
Electronic Speed Controller (ESC)
Hose connection for the electric release valve
Electronic Solenoid, Release Valve (donated)
Microcontroller
APC 9x6 Pusher Propeller
APC 10x3.8 Slow Flyer Counter Rotating Propeller
Set
Camera (optional)
Battery
Pan and Tilt (optional)
Servo Motors for Pan and Tilt (optional)
Blimp Envelope (donated)
Gondola (donated)
10 uF Poly Tantalum Capacitors
1.2 Kohms Resistor, 1% tolerance
0.1 Kohm Power Resistor
62
1
1
7
1
1
1
1
2
1
1
1
1
1
1
1
1
1
4
4
2
2
16
C6
C5
C4, C11C16
C8
C7
C3
R3, R6
C9, C10
R4
R5
R5
R5
C17
R6
0306ZC104KAT2A
TAJA105K016RNJ
0.1 uF Ceramic Capacitor
1 uF Tantalum Capacitor
0603YC104KAT2A
08056D106KAT2A
04026D474KAT2A
0402YC103KAT2A
ERJ-8GEYJ103V
478-2583-1-ND
1-1614881-2
2-1879216-0
4-1879214-7
4-1614884-1
GRM21BF50J106ZE01K
ERJ-3GEYJ431V
PG164130
ATO20
UA741
22-23-2021
22-01-2037
22-01-2027
22-23-2021
08-50-0114
0.1 uF Ceramic Capacitor, 10% Tolerance
10 uF Ceramic Capacitor, 10% Tolerance
0.47 uF Cermanic Capacitor, 10% Tolerance
10000 pF Ceramic Capacitor, 10% Tolerance
10 Kohm Resistor, 5% Tolerance
1 uF Ceramic Capacitor, 10% Tolerance
100 Kohm Resistor, 1% Tolerance
80.6 Kohm Resistor, 1% Tolerance
1.02 Kohm Resistor, 1% Tolerance
100 Ohm Resistor, 1% Tolerance
10 uF Capacitor, 6.3V Tantalum
400 ohm Resistor, 5% Tolerance
PICkit 3 In-Circuit Debugger(donated)
ATO Fuses 5/pack, 20 Amp
OP AMP, general purpose, DIP-8
Conn Header 3POS .100 VERT
CONN HOUSING 3 POS .100 W/RAMP
CONN HOUSING 2POS .100 W/RAMP
Conn Header 2POS .100 VERT
CRIMP PIN
Table 11 highlights the estimated budget with the corresponding parts for the
Autonomous Blimp project.
Table 12-Estimated Budget
Qty.
2
1
1
2
1
1
1
1
1
4
4
1
1
1
4
2
Part Num.
MB1040 LV-MaxSonar-EZ4
ADXL345BCCZ-RL
L3G4200DTR
XBP24-AWI-001
32400
32403
RMS-GPS-SR
MPL115A1T1
LT1963AES8#PBF
Optima 480 3010-910kv
jDrones AC20-1.0
HB125-100
EZ-2140-0-243-D
PIC24FJ256GB108-I/PT
LP0906P
A1038SFP
Description
Ultrasonic Sensor
Accelerometer
Gyroscope
RF Transceiver
XBEE USB Adapter
XBEE Adapter Board
GPS Reciever
Barometer
Low Drop Out Regulator
Brushless DC Motors
Electronic Speed Controller (ESC)
Hose connection for the electric release valve
Electronic Solenoid, Release Valve (donated)
Microcontroller
APC 9x6 Pusher Propeller
APC 10x3.8 Slow Flyer Counter Rotating
63
Unit
Cost
$29.95
7.79
12.95
32.00
19.99
3.19
Total
Cost
$59.90
7.79
12.95
64.00
19.99
3.19
2.21
4.50
19.05
18.00
1.94
0
7.88
3.95
9.59
2.21
4.50
76.20
72.00
1.94
0
7.88
15.80
19.18
1
2
1
2
1
1
2
1
1
1
1
7
1
1
1
1
2
1
1
1
1
1
1
1
1
1
4
4
16
2
2
N/A
77P-SL5000-3S1P-20C3333
dfc1133
0-HRC31055S
N/A
N/A
TCJY106M035R0070
ERJ-3EKF1201V
ERJ-3EKF2051V
0306ZC104KAT2A
TAJA105K016RNJ
0603YC104KAT2A
08056D106KAT2A
04026D474KAT2A
0402YC103KAT2A
ERJ-8GEYJ103V
478-2583-1-ND
1-1614881-2
2-1879216-0
4-1879214-7
4-1614884-1
GRM21BF50J106ZE01K
ERJ-3GEYJ431V
PG164130
ATO20
UA741
22-23-2021
22-01-2037
08-50-0114
22-01-2027
22-23-2021
Propeller Set
Camera (optional)
Battery
Pan and Tilt (optional)
Servo Motors for Pan and Tilt (optional)
Blimp Envelope (donated)
Gondola (donated)
10 uF Poly Tantalum Capacitors
1.2 Kohms Resistor, 1% tolerance
0.1 KOhm Power Resistor
0.1 uF Ceramic Capacitor
1 uF Tantalum Capacitor
0.1 uF Ceramic Capacitor, 10% Tolerance
10 uF Ceramic Capacitor, 10% Tolerance
0.47 uF Cermanic Capacitor, 10% Tolerance
10000 pF Ceramic Capacitor, 10% Tolerance
10 Kohm Resistor, 5% Tolerance
1 uF Ceramic Capacitor, 10% Tolerance
100 Kohm Resistor, 1% Tolerance
80.6 Kohm Resistor, 1% Tolerance
1.02 Kohm Resistor, 1% Tolerance
100 Ohm Resistor, 1% Tolerance
10 uF Capacitor, 6.3V Tantalum
400 ohm Resistor, 5% Tolerance
PICkit 3 In-Circuit Debugger (donated)
ATO Fuses 5/pack, 20 Amp
OP AMP, general purpose, DIP-8
Conn Header 3POS .100 VERT
CONN HOUSING 3POS .100 W/RAMP
CRIMP PIN
CONN HOUSING 2POS .100 W/RAMP
Conn Header 2POS .100 VERT
5. Project Schedule
Final Design Gantt Chart
64
29.92
29.92
29.00
2.99
9.99
0
0
3.94
0.04
0.04
1.38
0.70
0.07
0.35
0.36
0.05
0.06
0.24
0.71
0.78
0.78
0.71
0.17
0.02
0
1.00
0
0
0
0
0
0
Total
58.00
2.99
19.98
0
0
7.88
0.04
0.04
1.38
0.70
0.49
0.35
0.36
0.05
0.06
0.48
0.71
0.78
0.78
0.71
0.17
0.02
0
1.00
0
0
0
0
0
0
$492.42
65
6. Design Team Information
Project Leader: Marcus Horning, EE
Archivist: MichaelWallen, EE
Hardware Manager: Jason Banaska, EE
Software Manager: Sagar Patel, CpE
7. Conclusion and Recommendations
The dynamics of the system were utilized to produce the models of the system.
However, only the four transfer functions of the systems were created for the controllable
!, !, pitch, and yaw directions. From these, PI and PD compensators were designed to
reduce steady state error, increase stability, minimize the overshoot, and decrease the
settling time of the step responses. The compensators were designed back on theoretical
values. Therefore, they will need to be re-designed when the actual system models are
experimental obtained. The actual system models will be obtained through measurements
made by a series of sensors which include an accelerometer and a gyroscope. These
sensors will be able to provide accurate data about the forces experienced on the aircraft
and thus an accurate model can be made.
66
Some testing needs to be done to determine the accuracy of the sensor feedback
data. In particular, the velocities and tilt angle need to be analyzed since their accuracy is
vital to the control system. Since, the accelerations obtained by a combination of the
accelerometer and gyroscope data are integrated to obtain velocity, error can become
accumulated. The Kalman Filter needs to be researched in more detail and possibly
implemented as a means of reducing this error. Several PID controllers will then be built
to improve the performance and robustness of the system.
67
8. References
[1] Adams, Dr. Jay. Office Meeting, Akron. 10 Oct 2011. In Person.
[2] Androulakakis, Dr. Stavros. Office Meeting, Akron. In Person.
[3] Analog Devices, Inc. “ADXL345 Datasheet”, Rev C, 2011.
http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf
[4] Coultas, Charlie, Rebecca Craswell, Nicole Ericwson, Anders Kukuk, and Cory
Schwarzmiller. "Autonomous Blimp Project." charliecoultas.com.Ed. Charlie
Coultas.N.p., 13 June 2008. Web. 11 Oct. 2011.
<http://charliecoultas.com/files/ABP.pdf>.
[5] Digi International, “XBee®/XBee-PRO® RF Modules”, Product Manual v1.xEx 802.15.4 Protocol, 2009.
http://ftp1.digi.com/support/documentation/90000982_B.pdf
[6]Ford, Ralph M., and Chris S. Coulston.Design for Electrical and Computer Engineers:
Theory, Concepts, and Practice. New York: McGraw Hill, 2008. 55-56. Print.
[7] Freescale Semiconductor. “MPL115A1 Datasheet”, Rev 6, 2011.
http://www.freescale.com/files/sensors/doc/data_sheet/MPL115A1.pdf
[8] Linear Technology Corporation. “LT1963A Series Datasheet”, 1963afe, 2005.
http://cds.linear.com/docs/Datasheet/1963afe.pdf
[9] Linx Technologies. “RXM-GPS-SR Datasheet”, 2009.
http://www.linxtechnologies.com/resources/data-guides/rxm-gps-sr.pdf
[10] MaxBotix, Inc. “LV-MaxSonar-EZ4 Datasheet”, PD10009c, 2005.
http://www.maxbotix.com/products/MB1040.htm
[11] Microchip Technology, “PIC24FJ256GB110 Family Data Sheet”, Revision B,
December 2009.
http://ww1.microchip.com/downloads/en/DeviceDoc/39897c.pdf
[12] ST Microelectronics, “L3G4200D Datasheet”, 17116 Rev 3, 2010.
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LIT
ERATURE/DATASHEET/CD00265057.pdf
[13] Suay, Halit, TakehisaYairi, and Kazuo Machida. "A Self-modeling Autonomous
Airship." The University of Tokyo, 21 Aug 2009. Web. 9 Oct 2011.
<http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5335305&tag=1>.
[14] Veillette, Dr. Robert. Office Meeting, Akron. 9 Oct 2011. In Person.
68
[15] Versa Valve. “Series E Type Valves”, Bulletin E-2006. http://www.versavalves.com/65680_VERSA_WEB.PDF
69
Appendix:
Matlab simulation for x-direction
T=0.020;
m=19/2.2;
c=0.74;
num=[1 0];
den=[m*1 c 0 ];
sys=tf(num,den);
% figure (1);rlocus(sys)
% figure(2);bode(sys);
Gz=c2d(sys,T,'zoh')
% Transfer function:
% 0.00547
% ---------% z - 0.9891
%
% Sampling time: 0.025
% figure(3);rlocus(Gz);
% figure(4);bode(Gz);
D_num=5*[1 -0.9978];
D_den=[1 -1 ];
D=tf(D_num,D_den,T);
Gc=Gz*D;
% figure (5); rlocus(Gc);
% figure (6); bode(Gc);
system_output=feedback(Gc,1);
figure (7); step(1.8*system_output);
system_input=feedback(D,Gz);
Ux=step(1.8*system_input);
Uz=0;
Upitch=0;
Uyaw=0;
a=1.197e-7;
x=1.4;
y=.8;
z=0.6;
% figure (8); step(1.8*system_input);
W = zeros(4,length(Ux));
70
for k=1:length(Ux)
% motor thrust 1..4
M = [(Uyaw+Ux(k)*y)/(2*a*y), (Uyaw-Ux(k)*y)/(2*a*y), (Uz*xUpitch+Ux(k)*z)/(2*a*x), -(Upitch+Uz*x-Ux(k)*z)/(2*a*x)];
for n=1:4
if (M(n) < 0)
W(n,k) = -sqrt(abs(M(n)));
else
W(n,k) = sqrt(abs(M(n)));
end
end
end
time = ones(length(Ux));
for k=1:length(Ux)
time(k) = k*T;
end
figure (9); subplot(4,1,1); plot(time, W(1,:));title('Motor rpms for
Desired Step Response');
subplot(4,1,2); plot(time, W(2,:)); ylabel('Motor rpm');
subplot(4,1,3); plot(time, W(3,:));
subplot(4,1,4); plot(time, W(4,:));xlabel('Time, in seconds');
Matlab simulation for pitch
clear all
close all
T=0.020;
J=5.2;
d=1;
num=1;
den=[J*1 d 0 ];
sys=tf(num,den);
% figure (1);rlocus(sys)
% figure(2);bode(sys);
Gz=c2d(sys,T,'zoh')
% 3.207e-005 z + 3.203e-005
% ------------------------% z^2 - 1.997 z + 0.9968
% figure (2);rlocus(Gz);
K=15;
a=0.99;
D_num=K*[1 -a];
D_den=[1 0];
D=tf(D_num,D_den,T);
Gcnum=conv(D_num,[0.00003207 0.00003203]);
71
Gcden=conv([1 -1.997 0.997],[1 0]);
Gc=tf(Gcnum,Gcden,T);
Gc=D*Gz;
figure (5); rlocus(Gc);
% figure (6); bode(Gc);
system_output=feedback(Gc,1);
figure (7); step(0.4*system_output);
system_input=feedback(D,Gz);
Ux=0;
Uz=0;
Upitch=step(0.4*system_input);
Uyaw=0;
a=1.197e-7;
x=1.4;
y=.8;
z=0.6;
figure (8); step(0.4*system_input);
W = zeros(4,length(Upitch));
for k=1:length(Upitch)
% motor thrust 1..4
M = [(Uyaw+Ux*y)/(2*a*y), (Uyaw-Ux*y)/(2*a*y), (Uz*xUpitch(k)+Ux*z)/(2*a*x), -(Upitch(k)+Uz*x-Ux*z)/(2*a*x)];
for n=1:4
if (M(n) < 0)
W(n,k) = -sqrt(abs(M(n)));
else
W(n,k) = sqrt(abs(M(n)));
end
end
end
figure (9); subplot(4,1,1); plot(W(1,:));title('Motor rpms for Desired
Step Response');
subplot(4,1,2); plot(W(2,:)); ylabel('Motor rpm');
subplot(4,1,3); plot(W(3,:));
subplot(4,1,4); plot(W(4,:));xlabel('Time, in seconds');
Matlab simulation for yaw
T=0.020;
J=6.23;
f=1;
72
num=[1 0];
den=[J*1 f 0 ];
sys=tf(num,den);
% figure (1);rlocus(sys)
% figure(2);bode(sys);
Gz=c2d(sys,T,'zoh')
% Transfer function:
% 0.00547
% ---------% z - 0.9891
%
% Sampling time: 0.025
figure(3);rlocus(Gz);
% figure(4);bode(Gz);
K=15;
a=0.995;
D_num=K*[1 -a];
D_den=[1 -1];
D=tf(D_num,D_den,T);
Gc=Gz*D;
% figure (5); rlocus(Gc);
% figure (6); bode(Gc);
system_output=feedback(Gc,1);
figure (7); step(0.15*system_output);
system_input=feedback(D,Gz);
Ux=0;
Uz=0;
Upitch=0;
Uyaw=step(0.15*system_input);
a=1.197e-7;
x=1.4;
y=.8;
z=0.6;
figure (8); step(0.15*system_input);
W = zeros(4,length(Uyaw));
for k=1:length(Uyaw)
% motor thrust 1..4
M = [(Uyaw(k)+Ux*y)/(2*a*y), (Uyaw(k)-Ux*y)/(2*a*y), (Uz*xUpitch+Ux*z)/(2*a*x), -(Upitch+Uz*x-Ux*z)/(2*a*x)];
for n=1:4
73
if (M(n) < 0)
W(n,k) = -sqrt(abs(M(n)));
else
W(n,k) = sqrt(abs(M(n)));
end
end
end
figure (9); subplot(4,1,1); plot(W(1,:));title('Motor rpms for Desired
Step Response');
subplot(4,1,2); plot(W(2,:));ylabel('Motor rpm');
subplot(4,1,3); plot(W(3,:));
subplot(4,1,4); plot(W(4,:));xlabel('Time, in seconds');
Matlab simulation for z-direction
T=0.020;
m=19/2.2;
c=5;
num=[1 0];
den=[m*1 c 0 ];
sys=tf(num,den);
% figure (1);rlocus(sys)
% figure(2);bode(sys);
Gz=c2d(sys,T,'zoh')
% Transfer function:
% 0.00547
% ---------% z - 0.9891
%
% Sampling time: 0.025
% figure(3);rlocus(Gz);
% figure(4);bode(Gz);
D_num=10*[1 -0.985];
D_den=[1 -1 ];
D=tf(D_num,D_den,T);
Gc=Gz*D;
% figure (5); rlocus(Gc);
figure (6); bode(Gc);
system_output=feedback(Gc,1);
figure (7); step(0.5*system_output);
system_input=feedback(D,Gz);
74
Ux=0;
Uz=step(0.5*system_input);
Upitch=0;
Uyaw=0;
a=1.197e-7;
x=1.4;
y=.8;
z=0.6;
figure (8); step(0.35*system_input);
W = zeros(4,length(Uz));
for k=1:length(Uz)
% motor thrust 1..4
M = [(Uyaw+Ux*y)/(2*a*y), (Uyaw-Ux*y)/(2*a*y), (Uz(k)*xUpitch+Ux*z)/(2*a*x), -(Upitch+Uz(k)*x-Ux*z)/(2*a*x)];
for n=1:4
if (M(n) < 0)
W(n,k) = -sqrt(abs(M(n)));
else
W(n,k) = sqrt(abs(M(n)));
end
end
end
time = ones(length(Uz));
for k=1:length(Uz)
time(k) = k*T;
end
figure (9); subplot(4,1,1); plot(time,W(1,:));title('Motor rpms for
Desired Step Response');
subplot(4,1,2); plot(time,W(2,:));ylabel('Motor rpm');
subplot(4,1,3); plot(time,W(3,:));
subplot(4,1,4); plot(time,W(4,:));xlabel('Time, in seconds');
75