Autonomous Blimp

Project Design Report

Design Team 02

Jason Banaska Marcus Horning

Sagar Patel Mike Wallen

Faculty Advisor: Dr. Jay Adams

29 November 2011

i

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  

ii

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  

iii

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  

iv

Figure 46 - PWM Duty Cycle Motor Control Relationship ............................................. 56  

v

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  

vi

1

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

2

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.

3

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

Intuitive, Responsive User Remote Control

Light Weight

Avoid Obstacles

Self-stabilizing in All Directions

Direction and Position Awareness

Displays Video and Other Data Back to User

Self Stabilize When Idle

Inform User When Battery Level is Critical

Safe to Use and Fly Around People

Figure 1- Objective Tree

4

2. Design Requirements Specification

Below is the design requirements specification for the blimp system.

Table 1- Design Requirement Specification

Marketing Requirements

Engineering Requirements Justification

6 The airship should have an average flight duration of twenty minutes.

Based on the 5000mAh rating on the battery and the average current draw.

6 Display warning message on graphical user interface (GUI) on computer when battery voltage level reaches the critically low voltage level.

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.

7 The gondola, sensors, motors, and additional hardware should be detachable from the blimp envelope in less than 5 minutes.

The blimp must be transportable for indoor and outdoor use. The envelope will also be used independently by a second party.

8 The airship must make one full rotation in the yaw direction in under 60 seconds.

This value is determined by user specifications.

1,2,9 The maximum allowable drift during autonomous flight in any direction is 1 m when wind gusts are below 3 m/s.

The amount drift is based on the control system compensation.

3 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 user needs to be able to have full control of the craft's flight trajectory, with ease of use.

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

This value is based on the maximum drift of the airship and the value of the ultrasonic range finder.

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

This value is user specified and is dependent on the thrust that the motors can produce.

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

This is a model aircraft operating standard in the Advisory Circular 91-57.

4 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 maximum range of transmission of the XBee Pro transceiver is 1.609 km.

4 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

The accuracy of the data is based on the constraints of the sensors quality.

5

-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

6

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.

7

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 lighter-than-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.

!!"#$= - D!

!

!!= −!!!

!! = !!!

!!= −!!!

!!"#$= !!"#$  !

W= -mg!

Figure 4 - Applied Forces on Free Form Body

8

Table 2 - Parts List with Estimated Weights

Part Estimated Mass (g) Ultrasonic Sensor (2) 13 Gyroscope 1 Barometer 1 GPS Chip 3 XBee Receiver 3 Camera (Not required) 21 Back-up Battery 15 Accelerometer 1 Microcontroller 3 Motor Electronic Speed Controllers(4)

80 (20 g each)

Motors (4) 440 (110 g each) Propellers (4) 32 (8 g each) Battery 332 g Gondola and attachment materials

1250

Electronic Release Valve 45

Envelope including fins (4) 3629 Mass of Helium 1517 PCB (10"x4") 50 Additional Hardware/Wire (Resistors, Caps, etc)

40

Total Estimated Mass 7476 with 10% added 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

!!"#$%! =  !!"#$ +!!  . 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

(1)

9

!!"#$ =!! ∗ ! ∗ ! ∗ ! ∗ !

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

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.

0  

1  

2  

3  

4  

5  

0   1   2   3   4   5   6  

Drag  Force  (N

)  

Rela/ve  Velocity  (m/s)  

Rela/ve  Velocity  vs.  Drag  Force  

Series1  

(2)

Figure 5 - Relative Velocity vs. Drag Force

10

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

!!"#$%! =  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 double-bladed 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.

0  

5  

10  

15  

20  

25  

0   0.5   1   1.5   2   2.5  

Drag  Force  (N

ewtons)  

Effec/ve  Velocity  (m/s)  

Rela/ve  Velocity  vs.  Drag  Force  

Series1  

Figure 6 - Relative Velocity vs. Drag Force

(3)

11

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

!!"#$%! =  !.!"#  !  !"!!!!. 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 ! = !

! .

Whereas the power developed by the propeller is defined as

!!"#! = !! ∗!!!. 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 ! = !!

!.

0  

5  

10  

15  

20  

25  

0   2000   4000   6000   8000   10000   12000   14000  

Thrust,  in  New

tons  

RPM  

Propeller  RPM  vs.  Sta/c  Thrust  

Series1  

(4)

(5)

(6)

(7)

12

The second method requires knowledge of the efficiency of the motor, the operating voltage, and the delivered propeller power. These properties are related by

! = !!"#!!"

. 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   910  RPM/V  Maximum  Input  Wattage   250  W  Internal  Resistance,   0.08  Ohm  No  Load  Current,   0.85  A  Maximum  Continuous  Current   20  A  Maximum  Burst  Current   25  A  Motor  Torque  Constant,Kt   0.015449  Nm/A  

Table 4-Motor Properties

Diameter   9  inches  Pitch   6  inches  Thrust  Coefficient   !.!"#!  !"!! Number of blades 2 Power Constant, Pc 0.822 Power Factor, pf 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.

(8)

13

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

14

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

!!(!)!(!)

= !!!!!!"

. 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

!!(!)!(!)

= !!!!!!"

.

(9)

(10)

15

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

!(!)!(!)

= !!!!!!!"

. 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

!(!)!(!)

= !!!!!!!"

. Since all the equations of motion are now obtained, they are represented in matrix form given as

(11)

(12)

16

!!"

!!!!!!!!!!!!

   =    !

!!!!!!!!!!!!

+ !

! ! ! !! ! ! !! ! ! !! ! ! !! ! ! !! ! ! !! ! ! !!!! !!! !!! !!!! ! ! !! ! ! !! ! ! !!!! !" ! !

!!!!!!!"

 

Where the matrices A and B are given as  

A=  

! ! ! ! ! ! ! ! ! ! ! !! !/! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! ! !/! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! !/! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! !/!! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! !/!! ! !! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !/!!

 and

 

B=

! ! ! !!/! !/! ! !! ! ! !! ! ! !! ! ! !! ! !/! !/!! ! ! !

!/!! !/!! !/!! !/!!! ! ! !! ! ! !! ! ! !

!/!! !/!! !/!! !/!!

  .  

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

17

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

!!! = [!!"#!!!!!

!+!!"#(!"!)!]+ [

!!"#$ !!!!!

!"].

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.

(13)

(14)

(15)

18

Table 5 - Damping Coefficients

Damping  Coefficients  

a   0.74  b   5  c   5  d   1  e   0  f   1  

Moments  of  inertia  Jp   6.65  rad/sec  Jr   2.97  rad/sec  

Jyaw   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

!!!

!!!!"!!!!!!! .

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

!! =!!!!!!

.

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

(16)

(17)

(18)

19

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.

Ux

Uyaw

Desired Velocity in x-direction

Desired Yaw Velocity

Transformation

M1

M3M2

M4

Up

Z Controller

Uz

Desired Velocity in z-direction

Aircraft Dynamics

YawController

Pitch Controller

XController

Desired Pitch Angle x

pitch

yaw

z

-

-

-

-

Aircraft System

Dynamics

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)

20

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

M1=(Uyaw + Ux*dy’)/(2*dy’), M2=-(Uyaw - Ux*dy’)/(2*dy’), M3=(Uz*dx’ - Upitch + Ux*dz’)/(2*dx’), and M4=(Upitch + Uz*dx’ - Ux*dz’)/(2*dx’).

(20) (21)

(22)

(23)

21

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 14-15 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 z-domain 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.

Yaw Model

Yaw Controller

UyawDesired angular velocity in yaw direction

Z Model

Z Controller

UzDesired velocity in z direction

Pitch Model

Pitch Controller

UpitchDesired pitch angle

X ModelX Controller

UxDesired velocity in

x-direction

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

22

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

! ! = !(!!!.!!"#)!!!

.

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.

Figure 13 - Step Response of X Translational

Figure 14 - Step Response of Compensator

0 1 2 3 4 5 6 7 8 90

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2Step Response

Time (sec)

Ampl

itude

0 1 2 3 4 5 6 7 8 9 101

2

3

4

5

6

7

8

9Step Response

Time (sec)

Ampl

itude

(24)

23

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

! ! = !"(!!!.!"#)!!!

.

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.

0 1 2 3 4 5 6 7 8 9 100

5000

10000Motor rpms for Desired Step Response

0 1 2 3 4 5 6 7 8 9 10-10000

-5000

0

Mot

or rp

m

0 1 2 3 4 5 6 7 8 9 100

5000

0 1 2 3 4 5 6 7 8 9 100

5000

Time, in seconds

(25)

24

Figure 16 - Step Response of Z Translational

Figure 17 - Step Response of Compensator

0 2 4 6 8 10 12 140

0.1

0.2

0.3

0.4

0.5

0.6

0.7Step Response

Time (sec)

Ampl

itude

0 1 2 3 4 5 61.6

1.8

2

2.2

2.4

2.6

2.8

3

3.2

3.4

3.6Step Response

Time (sec)

Ampl

itude

25

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

! ! = !"(!!!.!!"#)!!!

.

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.

0 1 2 3 4 5 6-101

Motor rpms for Desired Step Response

0 1 2 3 4 5 6-101

Mot

or rp

m

0 1 2 3 4 5 6300040005000

0 1 2 3 4 5 6-5000-4000-3000

Time, in seconds

(26)

26

Figure 19 - Step Response due to Pitch

Figure 20 - Step Response of Compensator

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35 0.40

2

4

6

8

10

12

14Step Response

Time (sec)

Ampl

itude

0 10 20 30 40 50 600

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

0.45Step Response

Time (sec)

Ampl

itude

27

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

! ! = !"(!!!.!!")!!!

.

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.

0 5 10 15 20 25-101

Motor rpms for Desired Step Response

0 5 10 15 20 25-101

Mot

or rp

m

0 5 10 15 20 25-4000-2000

0

0 5 10 15 20 25-4000-2000

0

Time, in seconds

(27)

28

Figure 22 –Step Response Due to Yaw

Figure 23 - Step Response of Compensator

0 0.5 1 1.5 2 2.50

0.5

1

1.5

2

2.5Step Response

Time (sec)

Ampl

itude

0 5 10 150

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16Step Response

Time (sec)

Ampl

itude

29

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 low-dropout 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.

0 20 40 60 80 100 1200

20004000

Motor rpms for Desired Step Response

0 20 40 60 80 100 1200

20004000

Mot

or rp

m

0 20 40 60 80 100 120-101

0 20 40 60 80 100 120-101

Time, in seconds

30

MicroController

Low-Dropout Regulator

Battery 1

Xbee Pro PCXbox 360 Controller

Motor 1 Motor

Controller 1

Motor 2 Motor

Controller 2

Motor 3 Motor

Controller 3

Battery Voltage %

Desired Speed M1

Desired Speed M3

Desired Speed M2

Thrust

Thrust

Thrust

Vin

Xbee Pro

Battery Monitor

Desired x-translation

Desired Yaw

Desired Pitch

Monitor

Xbee Adaptor

Transmitter

Televison

Camera Receiver

Accelero-meter

Gyroscope

Barometer

Ultrasonic Proximity Sensors

Camera

Motor 4 Motor

Controller 4

Desired Speed M4 Thrust

Desired z-translation

GPS Sensor

Battery 2

Backup GPS

Battery

Figure 25-Level 2 Hardware Block Diagram

Table 6- Level 2 Hardware Functional Requirements

Module Low-Dropout Regulator (LT1963A) Inputs Power In: 11.1V Battery input Outputs Power Out: 3.3V Output to Microcontroller, Ultrasonic Sensors,

Barometer, Accelerometer, Gyroscope, Xbee Pro, and GPS Sensor.

Functionality Provide regulated voltage and current to several inputs of sensors and the microcontroller.

Module Microcontroller (PIC24FJ256GB106) Inputs Power In: 3.3V In from LDO

Ultrasonic Sensor Data: Distance (m) of objects Xbee Input: Desired positioning of system

31

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

Outputs Desired Speeds: Send desired speeds to motor controllers. Xbee Output: Collected data needing to be sent to ground

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

Module Xbee Pro Inputs Data In: Data to be transmitted wirelessly

Power In: 3.3V In from LDO Outputs Data Out: Data sent out wirelessly Functionality Transmits data wirelessly from Xbee transmitter to Xbee receiver. Module Xbox 360 Controller Inputs Desired Positioning: Desired x-translation, z-translation, pitch,

and yaw Outputs Control to PC: Send signals to the PC Functionality Desired inputs are directed using the Xbox 360 controller and sent to the

PC to be analyzed. Module Camera Receiver Inputs Images: Images sent wirelessly from camera on blimp to receiver

on ground Outputs RCA output: RCA output to connects to a television. Functionality Images are taken by the camera and sent to the camera receiver and then

displayed on a television. Module Battery Monitor Inputs Power In: 0V-11.1V Battery input Outputs Power Out: 0V-5V to microcontroller. Functionality 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.

Module Motor Controllers 1,2, 3, and 4 Inputs Power In: Battery input

Desired Motor Speed: Input of desired motor speed Outputs Motor Control: Sends a command to control the speed of the

motors. Functionality Receives desired positioning of the motors and sends commands to motor

to control the speeds.

32

Module Ultrasonic Sensors (LV-MaxSonar-EZ4) Inputs Power In: 3.3V Battery input Outputs Data Out: Sensor data to microcontroller. Functionality Sends sensed data to microcontroller via a pulse width signal. Module Barometer (MPL115A1) Inputs Power In: 3.3V Battery input Outputs Data Out: Thermal Data to microcontroller. Functionality Provide thermal data to microcontroller. Module Accelerometer (ADXL345) Inputs Power In: 3.3V Battery input Outputs Data Out: Translational motion data to microcontroller. Functionality Provide translational motion data to microcontroller Module Gyroscope (L3G4200D) Inputs Power In: 3.3V Battery input Outputs Data Out: Rotational motion data to microcontroller. Functionality Provide angular rate data to microcontroller. Module GPS Sensor (RXM-GPS-SR) Inputs Power In: 3.3V Battery input Outputs Data Out: Altitude and Coordinates to microcontroller. Functionality 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.

33

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

!!"# = !!"# ∗ !+!"!" + !!"# (!")

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.

R12.05k

R21.2kC1

10uF

C210uF

LT1963A

U1A

In1

SHDN2

Out5

3

GND

ADJ4

00

00

3.3V11.1V

1.21V

(28)

34

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.

U3A

74ACT109

VDD_IO1

GND2

Res3

GND4

GND5

VS6

CS

7

INT18

INT29

NC10

Res11

SDO12

SDA13

SCL

14

C51uF

C60.1uF

0

0

Vin

µC

µC

µC

µC

NC

NC

NC

NCNC

3.3V

3.3V

35

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.

U2A

L3G4200D

VDD_IO1

SCL2

SDA3

SAO4

CS

5

DRDY/INT2

6

INT1

7

Res

8

Res9

Res10

Res11

Res12G

ND

13

PLLFILT

14

Res

15

VDD

16

C3

10nFC4100nF R3

10k

0

C7

470nF

C810uF

uC

uC

uC

uC

3.0V

NC

NC

NC

NC

NCNC

36

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:

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

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 3-

U4B

MPL115A1

VDD

CAP

GND

SHDN CS

DOUT

DIN

SCLK

C9

1uF C10

1uF

0

µC

µC

µC

µC

3.3V

U4A

RXM-GPS-SR

GND1

VBACKUP2

TX3

RX4

LED5

BS6

EN7

VCC8

GND

9

GND

10

V23.3Vdc

µC

µC

µC

NC

NC

3.3V

37

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

38

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.

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.

U7B

XBEE Pro

VCC

DIN

DO8

RESET

PWM0

PWM1

Res

DTR/Sleep-RQ/D18

GND DIO4

DIO7

ON/Sleep

VRef

Associate/ DIO5

DIO6

DIO3

DIO2

DIO1

DIO0

DOUT

µC

µC

µC

µC

µC

µC

µC

µC

µC

NC

NC

NC

NC

NC

NC

NC

NC

NC

0

3.3V

39

Table 7- List of IO Pins

Component  #  of  IO  Pins  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.

40

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.

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:

R4100k

R581.9k

V311.1Vdc

0 0

µC-

+

U91

23

41

(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

Hose Line

Air Release

Electric Release ValveMotor 3 Motor 4

Air Valve

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

42

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.

MicroController

Camera

Proximity Sensor

Power Management

Battery Voltage

Motor Controller

WirelessCommunication

Module

3-phase Motors and Servomotor

Inertial Sensor Unit

GPS Unit

DisplayModuleRemote Control

User Input Control (Multidirectional)

Figure 36 – Hardware Level 1 Block Diagram

43

Table 8 – Hardware Level 1 Functional Requirements

Module Power Management Inputs Power In: Battery input Outputs Power Out: To motors, motor controller, and microcontroller Functionality Provide regulated voltage to motors, motor controller, and

microcontroller. Module Microcontroller Inputs 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)

Outputs Sensor Data Out: Provide positioning sensor data to motor controller Wireless Sensor Data Out: Sends video and measurement data to wireless transmitter

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

Module Motor Controller Inputs Power In: Battery input

Positioning Data: Microcontroller positioning sensor data in Outputs Motors: Controls the speed, direction, and stability Functionality 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.

44

Module 3- Phase Motors and Servomotor Inputs Power in: Battery input

Controller Data: Signal from Motor Controller Outputs Motors: Controls the speed and direction of flight Functionality Use battery input to supply motors and according to the input signal from

the motor-controller, adjust the speed of the motors.

Module Remote Control Inputs Power In: ?V Battery

User Input Control: User directional input Outputs Positioning Data: To wireless transceiver Functionality Use a ?V battery to supply power to a transmitter and send user

directional input to a wireless transceiver

Module Wireless Communication Module Inputs Power in: Battery Input

User Positioning Data: From remote control Measurement Sensor Data: Receive data from microcontroller

Outputs User Positioning Data: Transmit positioning data to microcontroller Measurement Sensor Data: Send to user display

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

Module Display Inputs Sensor Data In: Wireless Measurement and Video Data In Outputs 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

Functionality 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

45

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.

Blimp Software System

Sensors

User Input Formatted Display Data

Motor Speed Control

Figure 37 - Software Level 0 Block Diagram

Table 9 - Software Level 0 Functional Requirements

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

Module Blimp Software System Inputs -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.

Outputs -Motor Speed Control: calculated motor speeds to control flight of the blimp. -Formatted Display Data: data to be relayed to the user.

Functionality Read user inputs and sensors to determine how to control the blimp.

46

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.

Proximity Sensor Data

Battery Level Data

Motor Control AlgorithmAttitude Data

GPS Data

User Input Transformation

User Input Control

Motor 1 Control

Sensors Interface

Display Coordinates

Display Altitude

Display Speed

Display Battery Level

Display Software

Motor 2 Control

Motor 3 Control

Wireless Data Transmission

Motor 4 Control

Barometer Data

Ground / PC

Blimp / Microcontroller

Temperature Data

User Command Packet Sensor Data Packet

Blimp Orientation/Movement

Display Air Pressure

Display Temperature

Figure 38 - Software Level 1 Block Diagram

Table 10 - Software Level 1 Functional Requirements

Module Sensors Interface (Blimp) Inputs -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.

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

Functionality Reads sensors, calculates the meaning of the inertial measure unit sensors for motor control, and directs data in the appropriate format.

47

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.

Module Motor Control Algorithm (Blimp) Inputs -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.

Outputs -Motor 1 through 4 Control: Calculated motor speeds for each motor. Functionality Implements the control system for the craft based on current orientation

and movement.

Module User Input Transformation (Ground) Inputs -User Input Control: Data from user control device. Outputs -User Commands: Data sent to the craft to direct speed and direction

based on the user’s input. Functionality Reads user input and sends the commands to the craft wirelessly.

Module Display Software (Ground) Inputs -Sensor Data Packet: Data to be displayed to the user. Outputs -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.

Functionality Reads, formats, and displays data back to the user.

48

Proximity Sensor Data

Battery Level Data

Motor Control AlgorithmAttitude Data

GPS Data

User Input Transformation

User Input Control

Motor 1 through 4 PWM Control

Read Sensors

Display Coordinates

Display Altitude

Display Speed

Display Battery Level

Graphical User

Interface

Wireless Data Transmission

Barometer Data

Ground / PC

Blimp / Microcontroller

Temperature Data

User Command Packet Sensor Data Packet

Display Air Pressure

Display Temperature

Motor PWM Sequencing

Motor 1 through 4 RPM

Format Data

Read Sensor Data

Calculate Velocities

Calculate Pitch Angle

Read User Commands

Package/Send Sensor

Data

Package/Send User Commands

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

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.

Figure 40 - Software Level 2 Functional Requirements (for new or updated Modules)

49

Module Calculate Velocities (Blimp) Inputs -Attitude Data: Accelerometer, gyroscope, and GPS sensor readings

-Pitch Angle: current angle of the pitch Outputs -Calculated velocities: Craft velocity in x direction and in z direction Functionality Calculates craft velocities necessary for control system

Module Calculate Pitch Angle (Blimp) Inputs -Attitude data: Accelerometer and gyroscope readings Outputs -Pitch angle: Craft pitch angle. Functionality Calculates the craft’s pitch angle (relative to x-axis)

Module Package/Send Sensor Data (Blimp) Inputs -Sensor Data: Data from sensors and calculations. Outputs -Sensor Data Packet: Sensor data packaged for wireless transmission. Functionality Packages user sensor data for wireless transmission

Module Read User Commands (Blimp) Inputs -User Command Packet: Packaged data for controlling the craft Outputs -Desired movement: Desired x, z, yaw velocities, and pitch angle. Functionality Parses transmitted user command packet into desired movement.

Module Read Sensor Data (Ground) Inputs - Sensor Data Packet: On-board sensor and blimp data. Outputs -Sensor Data: On-board sensor data to be displayed to the user Functionality Reads transmitted sensor data.

Module Format Data (Ground) Inputs - Sensor Data: Unformatted data to be displayed to user. Outputs -Formatted Sensor Data: Data ready to be displayed to user. Functionality Formats data from blimp to be displayed to user.

50

Module Package/Send User Commands (Ground) Inputs

-User Input: Transformed user input for controlling craft.

Outputs -User Command Packet: User control packaged for wireless transmission.

Functionality Packages user commands for wireless transmission

Module Motor Control Algorithm (Blimp) Inputs -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

Outputs -Motor 1 through 4 RPM: Calculated motor speeds for each motor.

51

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

Functionality Start

User Input?

Calculate error between desired and actual

movement and store it

Pass each error through its associated

compensator (difference equation) and store the

result

Yes

Take compensated result and solve system of equations for finding

motor thrusts

Convert thrust to RPM for each motor

End

Set desiredPitch Angle = 0Yaw Angular Velocity = 0

X Velocity = 0Z Velocity = 0

No

Set desired Pitch Angle, Yaw

Angular Velocity, X Velocity, Z Velocity from user control

reading

Desired movement blocked by obstacle?

Set desired value(s) that are

blocked to 0

Yes

NoCalculate error between

desired and actual movement and store it

52

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.

Figure 41 - Xbox 360 Controller Configuration

Right Trigger: Fly up (8-bit sensitivity)

Left Trigger: Fly Down (8-bit sensitivity)

Right Stick: Fly forwards/backwards (16-bit sensitivity for each plane) Left Stick: Pitch/yaw control

(16-bit sensitivity for each plane)

Back and Start button combination: trigger electric release valve (Bool)

53

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.

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

32767

32767 -32768

-32768

x

y “Dead Zone”

54

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.

+update()+vibrate(in  leftMotor  :  float,  in  rightMotor  :  float)

+leftThumbX  :  short+leftThumbY  :  short+rightThumbX  :  short+rightThumbY  :  short+leftTrigger  :  byte+rightTrigger  :  byte+start  :  bool+back  :  bool

XBox360Controller

XInput

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

-­‐port  :  SerialPort+recievedDataBuffer  :  List<sbyte>

XBee

System.IO.Ports Provides  framework  for  synchronous  and  event  driven  I/O

Provides  interface  to  raw  game  controller  state

+execute()-­‐formatAnalogStickAxis(in  stickValue  :  short)  :  sbyte-­‐formatTriggers(in  leftTrigger  :  byte,  in  rightTrigger  :  byte)  :  sbyte

BlimpController

GUI

+main()

BlimpMain

+BlimpSensorData(in  data  :  List<sbyte>)

+velocityX+velocityZ+altitude+airPressure+distanceFront+distanceBottom+temperature+batteryLevel

BlimpSensorData

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.

55

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.

56

BlimpController XBox360Controller XBee

update

check  recieved  data  buffer

transmit  blimp  controls

updated  control  keys

BlimpSensorData

raw  recieved  sensor  data

create

UI  notified  of  sensor  data  creation  eventto  update  display

compute  blimp    controls  (pitch,  yaw,  x,  z)

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.

57

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 x-acceleration, 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.

58

Period

50%  Duty  Cycle

Proportional  Reverse

Proportional  Forward

Motor  Off

Full  Forward

Full  Reverse

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

59

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

60

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

61

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_ yaw-velocity_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*THRUST-RPM_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

62

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. Refdes Part Num. Description

2 MB1040 LV-MaxSonar-EZ4 Ultrasonic Sensor

1 U3A ADXL345BCCZ-RL Accelerometer 1 U2A L3G4200DTR Gyroscope 2 U7B XBP24-AWI-001 RF Transceiver 1 32400 XBEE USB Adapter 1 32403 XBEE Adapter Board 1 U4A RMS-GPS-SR GPS Reciever 1 U4B MPL115A1T1 Barometer 1 LT1963AES8#PBF Low Drop Out Regulator 4 Optima 480 3010-910kv Brushless DC Motors 4 jDrones AC20-1.0 Electronic Speed Controller (ESC) 1 HB125-100 Hose connection for the electric release valve 1

EZ-2140-0-243-D Electronic Solenoid, Release Valve (donated)

1 PIC24FJ256GB108-I/PT Microcontroller 4 LP0906P APC 9x6 Pusher Propeller

2

A1038SFP APC 10x3.8 Slow Flyer Counter Rotating Propeller Set

1 N/A Camera (optional)

2 77P-SL5000-3S1P-20C-3333 Battery

1 dfc1133 Pan and Tilt (optional) 2 0-HRC31055S Servo Motors for Pan and Tilt (optional) 1 N/A Blimp Envelope (donated) 1 N/A Gondola (donated) 2 C1, C2 TCJY106M035R0070 10 uF Poly Tantalum Capacitors 1 R2 ERJ-3EKF1201V 1.2 Kohms Resistor, 1% tolerance 1 R1 ERJ-3EKF2051V 0.1 Kohm Power Resistor

63

1 C6 0306ZC104KAT2A 0.1 uF Ceramic Capacitor 1 C5 TAJA105K016RNJ 1 uF Tantalum Capacitor

7 C4, C11-C16 0603YC104KAT2A 0.1 uF Ceramic Capacitor, 10% Tolerance

1 C8 08056D106KAT2A 10 uF Ceramic Capacitor, 10% Tolerance 1 C7 04026D474KAT2A 0.47 uF Cermanic Capacitor, 10% Tolerance 1 C3 0402YC103KAT2A 10000 pF Ceramic Capacitor, 10% Tolerance 1 R3, R6 ERJ-8GEYJ103V 10 Kohm Resistor, 5% Tolerance 2 C9, C10 478-2583-1-ND 1 uF Ceramic Capacitor, 10% Tolerance 1 R4 1-1614881-2 100 Kohm Resistor, 1% Tolerance 1 R5 2-1879216-0 80.6 Kohm Resistor, 1% Tolerance 1 R5 4-1879214-7 1.02 Kohm Resistor, 1% Tolerance 1 R5 4-1614884-1 100 Ohm Resistor, 1% Tolerance 1 C17 GRM21BF50J106ZE01K 10 uF Capacitor, 6.3V Tantalum 1 R6 ERJ-3GEYJ431V 400 ohm Resistor, 5% Tolerance 1

PG164130 PICkit 3 In-Circuit Debugger(donated)

1

ATO20 ATO Fuses 5/pack, 20 Amp 1

UA741 OP AMP, general purpose, DIP-8

4 22-23-2021 Conn Header 3POS .100 VERT 4

22-01-2037 CONN HOUSING 3 POS .100 W/RAMP

2

22-01-2027 CONN HOUSING 2POS .100 W/RAMP 2

22-23-2021 Conn Header 2POS .100 VERT

16 08-50-0114 CRIMP PIN

Table 11 highlights the estimated budget with the corresponding parts for the Autonomous Blimp project.

Table 12-Estimated Budget

Unit Total

Qty. Part Num. Description Cost Cost 2 MB1040 LV-MaxSonar-EZ4 Ultrasonic Sensor $29.95 $59.90 1 ADXL345BCCZ-RL Accelerometer 7.79 7.79 1 L3G4200DTR Gyroscope 12.95 12.95 2 XBP24-AWI-001 RF Transceiver 32.00 64.00 1 32400 XBEE USB Adapter 19.99 19.99 1 32403 XBEE Adapter Board 3.19 3.19 1 RMS-GPS-SR GPS Reciever 1 MPL115A1T1 Barometer 2.21 2.21 1 LT1963AES8#PBF Low Drop Out Regulator 4.50 4.50 4 Optima 480 3010-910kv Brushless DC Motors 19.05 76.20 4 jDrones AC20-1.0 Electronic Speed Controller (ESC) 18.00 72.00 1 HB125-100 Hose connection for the electric release valve 1.94 1.94 1 EZ-2140-0-243-D Electronic Solenoid, Release Valve (donated) 0 0 1 PIC24FJ256GB108-I/PT Microcontroller 7.88 7.88 4 LP0906P APC 9x6 Pusher Propeller 3.95 15.80 2 A1038SFP APC 10x3.8 Slow Flyer Counter Rotating 9.59 19.18

64

Propeller Set 1 N/A Camera (optional) 29.92 29.92

2 77P-SL5000-3S1P-20C-3333 Battery 29.00 58.00

1 dfc1133 Pan and Tilt (optional) 2.99 2.99 2 0-HRC31055S Servo Motors for Pan and Tilt (optional) 9.99 19.98 1 N/A Blimp Envelope (donated) 0 0 1 N/A Gondola (donated) 0 0 2 TCJY106M035R0070 10 uF Poly Tantalum Capacitors 3.94 7.88 1 ERJ-3EKF1201V 1.2 Kohms Resistor, 1% tolerance 0.04 0.04 1 ERJ-3EKF2051V 0.1 KOhm Power Resistor 0.04 0.04 1 0306ZC104KAT2A 0.1 uF Ceramic Capacitor 1.38 1.38 1 TAJA105K016RNJ 1 uF Tantalum Capacitor 0.70 0.70 7 0603YC104KAT2A 0.1 uF Ceramic Capacitor, 10% Tolerance 0.07 0.49 1 08056D106KAT2A 10 uF Ceramic Capacitor, 10% Tolerance 0.35 0.35 1 04026D474KAT2A 0.47 uF Cermanic Capacitor, 10% Tolerance 0.36 0.36 1 0402YC103KAT2A 10000 pF Ceramic Capacitor, 10% Tolerance 0.05 0.05 1 ERJ-8GEYJ103V 10 Kohm Resistor, 5% Tolerance 0.06 0.06 2 478-2583-1-ND 1 uF Ceramic Capacitor, 10% Tolerance 0.24 0.48 1 1-1614881-2 100 Kohm Resistor, 1% Tolerance 0.71 0.71 1 2-1879216-0 80.6 Kohm Resistor, 1% Tolerance 0.78 0.78 1 4-1879214-7 1.02 Kohm Resistor, 1% Tolerance 0.78 0.78 1 4-1614884-1 100 Ohm Resistor, 1% Tolerance 0.71 0.71 1 GRM21BF50J106ZE01K 10 uF Capacitor, 6.3V Tantalum 0.17 0.17 1 ERJ-3GEYJ431V 400 ohm Resistor, 5% Tolerance 0.02 0.02 1 PG164130 PICkit 3 In-Circuit Debugger (donated) 0 0 1 ATO20 ATO Fuses 5/pack, 20 Amp 1.00 1.00 1 UA741 OP AMP, general purpose, DIP-8 0 0 4 22-23-2021 Conn Header 3POS .100 VERT 0 0 4 22-01-2037 CONN HOUSING 3POS .100 W/RAMP 0 0

16 08-50-0114 CRIMP PIN 0 0 2 22-01-2027 CONN HOUSING 2POS .100 W/RAMP 0 0 2 22-23-2021 Conn Header 2POS .100 VERT 0 0

Total $492.42

5. Project Schedule Final Design Gantt Chart

65

66

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.

67

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.

68

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_LITERATURE/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.

69

[15] Versa Valve. “Series E Type Valves”, Bulletin E-2006. http://www.versa-

valves.com/65680_VERSA_WEB.PDF

70

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

71

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*x-Upitch+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]);

72

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*x-Upitch(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;

73

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*x-Upitch+Ux*z)/(2*a*x), -(Upitch+Uz*x-Ux*z)/(2*a*x)]; for n=1:4

74

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

75

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)*x-Upitch+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');