P UAV Telemetry Detailed Design Review Documents February 18, 2010

Transcription

1 P UAV Telemetry Detailed Design Review Documents February 18, 2010 Chris Barrett Gregg Golembeski Alvaro Prieto Cameron Bosnic Daron Bell Project Manager Interface Manager Radio Concepts Software Concepts Power Concepts Mission Statement The goal of this project is to create an open source, multi platform, bidirectional telemetry system to be used in an unmanned aerial platform for an aerial imaging system. The telemetry system must be able to be carried on UAV airframe C and interface with the control system (P10236) for the UAV. The system must be able to send flight data/hardware and software diagnostics to be displayed in real time to a computer on the ground.q Contents: Customer Needs Engineering Specifications System Architecture Abstraction Bill of Materials Software Architecture Data Protocol Specification Radio System Architecture Power System Architecture Mounting System Architecture Risk Assessment MSD P10231 UAV Telemetry Detailed Design Review Document 1

2 P UAV Telemetry Detailed Design Review Documents Customer Needs MSD P10231 UAV Telemetry Detailed Design Review Document 2

3 P UAV Telemetry Detailed Design Review Documents Engineering Specifications MSD P10231 UAV Telemetry Detailed Design Review Document 3

4 P UAV Telemetry Detailed Design Review Documents System Architecture Abstraction MSD P10231 UAV Telemetry Detailed Design Review Document 4

5 P UAV Telemetry Detailed Design Review Documents Bill of Materials MSD P10231 UAV Telemetry Detailed Design Review Document 5

6 P UAV Telemetry Detailed Design Review Documents Software Architecture Packet Type The packet type is the basis of all transactions. The packet type consists of a header and packet payload. The packet structure is described in more detail in the UAV Data Protocol Specification. Packetizer The Packetizer class is on its own thread. This constantly checks for bytes on the serial input buffer. If bytes are available, the Packetizer runs through a state machine which tries to compile a packet based on the UAV Data Packet Protocol. If a packet is compiled, it is checked for validity using a rolling addition checksum. If the packet passes, it is placed in the Incoming Packet Queue to be serviced on another thread in the Packet Handler. The Packetizer can also compile outgoing command packets. This is called from the GUI Action Handler class. MSD P10231 UAV Telemetry Detailed Design Review Document 6

7 Incoming Packet Queue Once the Packetizer has received and decoded an incoming packet, it is placed in the Incoming Packet Queue. This is a standard queue that allows the packet actions and updates to take place in another thread. This queue must be thread-safe. Outgoing Packet Queue Once the Packetizer has created an outgoing packet, it is placed in the Outgoing Packet Queue. This is a standard queue that allows the outgoing packets to have a buffer if the outgoing serial port is full. This ensures that the Packetizer will not block when the outgoing port is full, allowing for incoming packets to be processed. While the queue is not empty it accesses the outgoing port and places the bytes in the outgoing stream. This queue must be thread-safe. Packet Handler The Packet Handler is it's own thread which pops packets off the Incoming Packet Queue. The Packet Handler takes the data in the packet and updates the corresponding values in the GUI. This class also writes the valid data to disk for logging with proper formatting. Furthermore, the Packet Handler takes the GUI input and translates that into a outgoing packet type. This is then translated to a standard Packet by the Packetizer who places it on the Outgoing Packet Queue. MSD P10231 UAV Telemetry Detailed Design Review Document 7

8 Graphical User Interface Flight Info Pane MSD P10231 UAV Telemetry Detailed Design Review Document 8

9 Flight Plan Pane MSD P10231 UAV Telemetry Detailed Design Review Document 9

10 Raw Data Pane Software Feasibility The software design presented is based off a previously functioning system that was implemented for another project. The software will be feasible because we are using proven software concepts. A Model View Control patten will be used for the GUI functionality to ensure that the GUI remains responsive. The use of multithreaded processes will prevent data buffers and queues from loosing data. Selecting QT as a language will help make code maintainable, expandable, and extensible. The modularity of the code will allow easy maintanibility; each component may be rewritten or reused in future revisions. Modular code will also allow simpler testing, as each component may be sand-boxed and tested individually. QT is built for rapid development by integrating the GUI design with code authoring, abstracting the connections between the GUI and variable data. QT/C++ has advantages over the other languages explored due to its speed, compatibility, and licensing. Another advantage of QT/C++ is that it is embeddable, so if the project moves to an embedded platform in the future, such as a PDA or cell phone, code will not have to be modified. Lastly, the three team members implementing the software portion of this project have also created similar designs and meet comparable software goals. MSD P10231 UAV Telemetry Detailed Design Review Document 10

11 Software Test Plan The software will undergo functional validation (FVT) and usability testing (UT). Usability testing will be determined by running the UI and having 5 random people perform scripted actions to make sure that the GUI layer was designed well. Dr. Kolodziej will also perform a usability test to determine that the design meets his needs. An FVT script will also be created after all of the software methods have been created to test the functional value of the code. The FVT will be performed by other members of the team. Unit tests will be used throughout the build process to insure that methods behave correctly. Testing will initially be done with 2 computers connected via a serial cable for initial testing, and then the radio will be dropped in once the packet structure is verified. A test file consisting of simulated UAV control system output data will allow for verification of the packet translation functions without having to integrate with the UAV control system until later. This allows for greater flexibility and removes a dependency on another team. Testing afterwords will consist of setting up a static base station, and another moving rig. The data loss at a distance can be tested with this setup. MSD P10231 UAV Telemetry Detailed Design Review Document 11

12 P UAV Telemetry Detailed Design Review Documents Data Protocol Specification Abstract In order for the UAV control system to report its current sensor and other flight parameters to the ground, a telemetry system is to be designed. The ground base station application must know how to bidirectional communicate with the UAV. The P10231 project aims to fulfill this need through a system of radios, software and a data protocol. This specification explains the data structure that will allow the UAV and base station to communicate. General Packet Structure All packets in the UAV data protocol follow a set structure to ensure uniformity, data integrity, radio efficiency and simple software design. The general packet structure is described in Table 1. The escape character (0x0A) is used to preface any payload byte with a value of 0x55. Index Value Description Details 0 0x55 Start of Packet (SOP) This is the directive that shows this is a new packet. 1 0x## Packet Type Identification byte that describes what kind of packet this is. The payload structure can be referenced using this byte. 2 0x## Length byte 1 The length of the packet is two bytes. This is the length of the packet payload.* The length does not include the SOP, ID, any escape characters, checksum or length bytes. 3 0x## Length byte N 0x## Payload This is the packet data that is being transferred. N+1 0x## Checksum The checksum is the summation of all bytes in the packet, rolling over 0xFF. Table 1: General Packet Structure MSD P10231 UAV Telemetry Detailed Design Review Document 12

13 Packet Types and Payload Descriptions This section focuses on the Packet Payload and its corresponding type byte. The following tables are descriptions of bytes 4...N in the general packet structure shown in Table 1. Packet Type 0x00: Instrumentation & Flight Data Packet Index Value Description Details 4 0x## Parameter 1 This is the first parameter in the packet payload. 5 0x## Parameter 1 6 0x## Parameter 2 7 0x## Parameter 2 8..N 0x## Parameter 3... Packet Type 0x01 Picture Command Packet Index Value Description Details 4 0x## Command* This byte instructs the UAV to take a picture. 0xFF: Take Picture * Purpose of picture command type allows for expandability of camera functionality. **This packet type requires an ACK response packet. If an ACK is not received within 1 second of initial command it must be resent. Packet Type 0x02: General Command Packet Index Value Description Details 4 0x## Device Address 1 Selects the device for corresponding value. 5 0x## Value 1 Value to be applied to the selected device. 6 0x## Device Address 2 7 0x## Value 2 8..N 0x## Device Address N 9..N 0x## Value N Packet Type 0x03: GPS Waypoint Packet MSD P10231 UAV Telemetry Detailed Design Review Document 13

14 Index Value Description Details 4 0x## Latitude 1 High byte of Latitude coordinate 5 0x## Latitude 0 Low byte of Latitude coordinate 6 0x## Longitude 1 High byte of Longitude coordinate 7 0x## Longitude 0 Low byte of Longitude coordinate 8 0x## Altitude 1 High byte of Altitude coordinate 9 0x## Altitude 0 Low byte of Altitude coordinate 10 0x## Speed Desired Speed to travel to coordinate Packet Type 0x04: ACK Packet Index Value Description Details 4 0x## Command Being Acknowledged This byte confirms the transaction of the command being returned Throughput Feasibility At a minimum, 20 variables must be sent from the UAV to the ground at a refresh rate of 10Hz. The following calculation explicitly shows that we are well within the radio s throughput. ((20 variables * 2 bytes each) + 5 byte header)*10 times /sec = 450bytes/sec 450 bytes/sec * 8 bits per byte = 3600 bps The radio can operate at either 9600 bps or bps which is much greater than our minimum of 3600 bps, therefore we are well within our data throughput constraints. MSD P10231 UAV Telemetry Detailed Design Review Document 14

15 P UAV Telemetry Detailed Design Review Documents Radio Specification Feasibility Analysis The radio selected is the Digi XTend-PKG 900 MHz. The XTend radios send serial data seamlessly from one point to the other. The radios operate on the 900MHz ISM (Industrial, Scientific, and Medical) band. The radios conform to the Federal Communications Commission's (FCC) Part 15 rules in order to operate without a license. The rule states that ``For systems using digitalmodulation in the MHz...'' up to 1 Watt of transmit power is allowed. The antenna selection depends on where the radio will be used. The UAV will have a smaller omnidirectional antenna and the base station will have a large, higher gain, omnidirectional one. In the rare case that the system is not able to meet the range requirements, a high gain directional antenna can be used on the ground. While a directional antenna is not ideal due to the narrow range of operation, it increases the range significantly. Table: Friis Equation Speed of Light Wavelength Frequency Power Received Power Transmitted Receiving Antenna Gain Transmitting Antenna Gain Distance Between Antennas MSD P10231 UAV Telemetry Detailed Design Review Document 15

16 In order to calculate the maximum range between the two radios, the basic form of the Friis transmission equation (2) is used. The simplified equation ignores the effects of mismatched impedance and polarization. Both antennas will be aligned most of the time, while the airplane is in level flight, the polarization will be equal. The radios are designed to drive a load, and both antennas are designed for. By using cables, or connecting the antenna directly to the radio, the mismatch in impedance is greatly reduced. The selected base antenna is 65" and dbi gain. The UAV antenna is 6" and dbi gain. In order to convert the gain from dbi to Watts, equation (4) is used. Equation (2) is rearranged to solve for the maximum range (3). The radio transmit power(pt), along with both antenna gains (Gr, Gt) are known. The wavelength can be calculated using equation. The final parameter needed is the received power. From the radio documentation, a minimum received power of -100dBm is needed to operate at full speed (115,200 bps). The radio can continue to operate with received power of -110dBm at a reduced data rate (9,600 bps). MSD P10231 UAV Telemetry Detailed Design Review Document 16

17 In order to convert the -100dBm power to Watts, equation is used. The calculation results in a range of about 1400 meters at full speed, with a reduced-speed range of about 4600 meters. Test Plan There are two main methods of testing the radios. The first method consists in confirming the transfer of serial data seamlessly. This can be done by connecting a computer to each radio and transmitting data using a simple terminal program. Characters will be sent from one computer to the other. The tester will confirm that the data is accurate. The radios will be tested at both available baud rates to confirm proper operation. The range testing is slightly more difficult. The test consists of setting one radio in a high place (hill or building) and a second radio on a mobile platform, such as a car. An automated program will send data continuously back and forth between the two devices while the vehicle moves away. This test will give us a better idea of the actual range of the radios. A more accurate, but much harder to perform, test consists of taking one of the radios on a small airplane and testing the range that way. This, while possible, could be expensive. MSD P10231 UAV Telemetry Detailed Design Review Document 17

18 P UAV Telemetry Detailed Design Review Documents Power Supply Specification Feasibility Analysis From our customer needs, we found that the entire flight time of the Airframe was to be at most forty minutes. It quickly became apparent that the limiting factor to meet this spec would be the operating current of our Radio unit. Looking over the documentation of the radio, it consumes the most current when in a transmission state at the one Watt operating mode. This maximum is.9 A or 900mA. In order to allow for the worst case scenario, it was assumed that the radio would be constantly transmitting, sustaining 900mA for the entirety of flight time. The time was then rounded up to sixty minutes in order allow more room for error and unknowns. The full calculation for the current requirements of the radio is shown below. Battery Current ma x Time hours=mah 900 ma x 1 Hour=900 mah This engineering specification dictates that our battery selection is limited to those that can supply at least 900mAH capacity. After considering a number of other desirable characteristics such as multiple flight times between recharges and ease of charging, a Lithium Polymer (LiPo) battery with 5500 mah capacity was selected. This battery can supply over six hours of flight time, as shown by the equation below mah/900 ma=6.11 hours This 6.11 hour time frame should allow for eight to nine flights of forty minutes before the battery needs to be recharged. The desired battery can be found at the following web address: Test Plan Looking at the specification sheet for the radio, it shows that the radio will take in 9V at 900 ma, which using ohm's law comes to 10 Ohms, shown below. 9V/900mA=10 ohms As a result of this an apparent test plan reveals itself. We could simply connect the battery across a ten ohm resistor and monitor its output voltage until it drops below the level that is accepted by the radio. This time duration would give us an approximate running time for the battery. If this time was under forty minutes, it would fail the test, but over forty minutes it would pass. MSD P10231 UAV Telemetry Detailed Design Review Document 18

19 P UAV Telemetry Detailed Design Review Documents Mounting System Architecture The housing must securely mount the system in UAV C and provide protection against shock caused by the planes landing. Specifications Engineering Specifications Marginal Value Ideal Value size (cm) 17.75x17.75x x15.25x15.25 Weight (kg) Max acceleration (m/s 2 ) Flight time (minutes) Design Specifications Associated spec Max Stress (kpa) 2.82E+05 Max acceleration Based on Ultimate stress of PCB Max tempradio (Celsius) 80 Flight time size (cm) 17.75x17.75x17.75 size weight (kg) 2.27 weight Based on operating conditions of radio Based on space allotted for system in UAV C Based on weight allotted for system in UAV C Feasibility Analysis In order to estimate the stress on the radio caused by landing the system was modeled as a mass spring system with some initial velocity in free vibration. MSD P10231 UAV Telemetry Detailed Design Review Document 19

20 For Springs in series: k1e=11310 N/mm; k2e=592 N/mm Equations of motion in matrix form: Initial Conditions: MSD P10231 UAV Telemetry Detailed Design Review Document 20

21 From here I decoupled the system and found the displacement of x1 using modal coordinates in Matlab. Matlab Code function [x1,x2]=displacement(m1,m2,k1,k2,x0,xd0) %setting up matrices from EOM M=[m1 0;0 m2]; K=[k1 -k1;-k1 (k1+k2)]; %Decoupling system Kt=M^-0.5*K*M^-0.5; %finding eigen values and eigen vectors [v,d]=eig(kt); %natural frequencies for two masses w2=d(1,1); w1=d(2,2); w=[w1 w2]; %setting up eigen vector matrix P=[v(1,1) v(2,1);v(1,2) v(2,2)]; %intial conditions of modal cordinates r0=p'*m^(-0.5)*x0 rd0=p'*m^(-0.5)*xd0 %displacement of modal coordinates for t=1:10001 for i=1:2 r(i,1)=sqrt(w(i)^2*r0(i,1)^2+rd0(i,1)^2)/w(i)*sin(w(i)*((t-1)/10000)+atan(w (i)*r0(i,1)/rd0(i,1))); end x=m^(0.5)*p*r; global x1 x2 x1(t)=x(1,1); x2(t)=x(2,1); end MSD P10231 UAV Telemetry Detailed Design Review Document 21

22 (displacement at the radio determined by above function) Relating the displacement back to the stress on the radio caused by the UAV landing we can see that this design provides more than enough cushioning to prevent damage to the system during landings. Overheating The heat generated by the system in 45 minutes = 2700 joules Mass of the radio = 0.2 kg Assuming a very hot day (100 F/37.8C) the temperature in the radio would have to rise about 42 degrees C in order to overheat. For the radio to overheat in a perfectly insulated system it would need to have a specific heat less than 320 J/kg-K. So our radio should not have a problem with overheating for the desired flight time. Size The planned dimensions of our system are 15.25x15.25x12.4 so we are well within our size constraints. MSD P10231 UAV Telemetry Detailed Design Review Document 22

23 Weight The estimated weight of the system is 1.13 kg. Test plan To ensure the radio will not overheat while inside of the housing we will run the radio and battery we plan on using in a situation that is more insolated than the housing and monitor the temperature closely if in this worst case scenario the radio does not overheat we can be pretty certain the radio will not overheat in our system. Mounting System Engineering Drawings (Side view) MSD P10231 UAV Telemetry Detailed Design Review Document 23

24 (top view) MSD P10231 UAV Telemetry Detailed Design Review Document 24

25 MSD P10231 UAV Telemetry Detailed Design Review Document 25