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