The applications of Unmanned Aerial Vehicle (UAV) have grown drastically

90 08 01 91 09 31

GPS

ABSTRACT The applications of Unmanned Aerial Vehicle (UAV) have grown drastically around the world in recent years. More and more universities in particular in aerospace engineering have also established their own UAV programs to investigate some unique missions and to fulfill the education and training purpose as well. Based on the UAV mission of autonomous flight and long endurance, the onboard computer system, including relevant hardware and software, becomes vital equipment to be developed to facilitate this goal. This research therefore emphasizes on the development of an onboard computer platform both on hardware and software. The platform consists of a single board computer, various air data sensors, Global Positioning System (GPS), inertial sensors, and other necessary peripherals. A real-time operating system (RTOS) called QNX is used as its operating system. The developed platform can collect, analysis/compute, control/monitor, store, and transmit the data downward so that the ground station can receive and monitor in real time the status of the UAV. Furthermore, the present system also can be a good platform to accommodate the requirements of various payloads for the UAV missions. II

CONTENTS... I ABSTRACT... II CONTENTS...III LIST OF TABLES...VI LIST OF FIGURES... VII LIST OF FIGURES... VII 1. INTRODUCTION...1 1.1. UAV Developments and Applications...1 1.2. Developments of UAV in Universities...4 1.3. Autonomous UAV Project in RMRL, IAA of NCKU...5 2. SYSTEM OVERVIEW...8 2.1. System Architecture...8 2.2. Onboard System...9 2.2.1. Onboard hardware...9 2.2.2. Onboard software...10 2.3. Vehicle System...10 3. ONBOARD HARDWARE AND SOFTWARE...15 3.1. Onboard Hardware...15 3.1.1. Onboard computer...15 3.1.1.1. CPU module...16 III

3.1.1.2. DAS module...16 3.1.1.3. Serial interface module...17 3.1.2. Sensors...17 3.1.2.1. GPS receiver...17 3.1.2.2. Altimeter...17 3.1.2.3. Air speed sensor...18 3.1.2.4. Inertial measurement unit...19 3.1.3. Wireless modem...20 3.1.4. Servo controller...20 3.1.5. RC switch...20 3.1.6. Power system...22 3.1.7. Case and interface card...24 3.2. Onboard Software...26 3.2.1. Software architecture...27 3.2.2. Programming of processes...28 3.2.2.1. I_GPS and D_GPS...29 3.2.2.2. I_IMU...29 3.2.2.3. I_AD and D_AD...29 3.2.2.4. DB_base...30 3.2.2.5. AL_NAV...30 3.2.2.6. AL_STORE...33 3.2.2.7. AL_DNLK and O_DNLK...33 IV

3.2.2.8. AL_PLO and O_PLO...34 3.2.2.9. M_onitor...35 4. TEST, RESULTS, AND DISCUSSION...36 4.1. Ground Tests...36 4.1.1. Endurance test...37 4.1.2. Wireless data communication on car...40 4.1.3. EMI test...42 4.2. Flight Tests...42 5. CONCLUSION...48 5.1. Concluding Remarks...48 5.2. Future Work...49 REFERENCES...50 APPENDIX A...52 VITA...! V

LIST OF TABLES Table 1-1: Applications in UAV...2 Table 2-1: Basic specification of the 1/5 Cessna 182...11 Table 2-2: Weight budget of the onboard system and payload...12 Table 3-1: Power budget...23 Table 3-2: The format of the downlink frame...34 Table 3-3: System loading sequence...35 Table 4-1: Operating time under battery power...40 Table 4-2: The results of EMI test...42 VI

LIST OF FIGURES Figure 1-1: Sperry s Aerial Torpedo...1 Figure 1-2: RQ-1 Predator with hellfire antitank missile...3 Figure 1-3: X-45 by Boeing, DARPA, U.S. Air Force, and NASA...3 Figure 1-4: Helios in flight...3 Figure 1-5: Aerosnode...4 Figure 1-6: FireMite of Simon Fraser University...4 Figure 1-7: Autonomous J3-Cup developed by Georgia Tech...5 Figure 1-8: The division of the UAV project in RMRL, NCKU...7 Figure 2-1: High level system architecture...8 Figure 2-2: 1/5 miniature Cessna 182...11 Figure 2-3: The position of the GPS antenna...12 Figure 2-4: Pitot tube on the UAV...13 Figure 2-5: Distribution of onboard components...14 Figure 3-1: Onboard hardware architecture...15 Figure 3-2: Onboard computer in a stack...16 Figure 3-3: Voltage output versus altitude...18 Figure 3-4: Voltage output versus airspeed...19 Figure 3-5: Inertial measure unit...19 Figure 3-6: The string format of the IMU...20 Figure 3-7: Circuitry of the RC switch...21 Figure 3-8: RC switch and SSC...22 Figure 3-9: Power regulator...24 VII

Figure 3-10: The OBC case with interface panel...25 Figure 3-11: VGA and keyboard connectors...25 Figure 3-12: Process flow of software structure...27 Figure 3-13: Software architecture...28 Figure 3-14: Wide and narrow level of limitation for altitude holding...31 Figure 3-15: The logic of direction holding...32 Figure 3-16: Waypoint determination...33 Figure 4-1: System test procedures...36 Figure 4-2: Regulated 5V power...38 Figure 4-3: Unregulated 5V power...38 Figure 4-4: Altimeter with regulated power...39 Figure 4-5: Altimeter without regulated power...40 Figure 4-6: The track of the wireless ground test...41 Figure 4-7: The comparison of altitude in GPS and altimeter...41 Figure 4-8: Pressure altitude and airspeed of the first fight test...43 Figure 4-9: The trajectory of the flight test...44 Figure 4-10: 2D path of the entire flight...44 Figure 4-11: GPS height of the flight test...45 Figure 4-12: GPS ground speed of the flight test...45 Figure 4-13: Picture taking from the automatic camera on the UAV...46 Figure 4-14: Ground station display panel...47 VIII

1. INTRODUCTION On September 11, 2001, two civil airplanes smashed into two World Trade Center buildings respectively in New York City. There were five civil airplanes crashed in that morning totally. The U.S. government regards Osama Bin Laden who appeared in Afghanistan recent years as the prime suspect. To force the appearance of Bin Laden, the unmanned aerial vehicle, Predators, which have been flown by Air Force for six years to gather intelligence, were operated in the battlefield with Hellfire antitank missiles, powerful weapons usually carried on helicopters. The attacks by the Predators mark a turning point in military history because they have signaled that the Air Force is now able to survey and then shoot at ground positions from lower altitudes without putting pilots at risk [1]. This is the first time we witness an armed unmanned aerial vehicle used on the war. It s also a milestone that marks we have entered the era of UAV unmanned aerial vehicle. 1.1. UAV Developments and Applications It is believed that the first UAV is Sperry s Aerial Torpedo which made its first successful flight on 6 March 1918 at Copiague, Long Island, NY (Figure 1-1) [2]. It is the forerunner of today's guided missiles, which can be considered a one-way UAV. The first returnable and reusable UAV was the British Fairey "Queen" variant of the Fairey IIIF aircraft, first flown in September 1932 [3]. Figure 1-1: Sperry s Aerial Torpedo 1

After many decades developments, the present configuration of UAV is definitely not like a guided missile of today. As a matter of fact, UAV has shown its numerous applications in many fields, as listed in Table 1-1. Table 1-1: Applications in UAV Fields Military Civil Academic Applications Surveillance Reconnaissance Communication relay Weapon launching Combat Communication relay Experiment Research Climate monitor Education Training Experiment Research In military application, UAV can execute such missions as surveillance, reconnaissance, weapon launching, communication relay, and combat. The Predator is one of the famous UAV in this field. It can provide near real-time video imagery day or night in all-weather conditions via satellite worldwide [4]. So the U.S. government uses it to spy the battlefield. Even more than that, it also became a weapon launcher. The use of armed RQ-1 Predators is a revolutionary step in the conduct of warfare. Figure 1-2 shows that the Predator is outfitted with Hellfire antitank missiles in the bottom of the fuselage. The unmanned combat aerial vehicle (UCAV) is not realized today, yet it will be existent in the near future. The successful flight test of X-45 in May 2002 announces the coming epoch of UCAV. Figure 1-3 shows the prototype of X-45 on ground [5]. In civil applications, the Helios is in flight test phase. Its features of long endurance and high altitude will fill a niche in the telecommunications market. A fully operational Helios will operate at about 60,000 feet, above the weather and traffic, and act like a stationary satellite, but without the time delay. The solar-electric powered aircraft had reached an altitude record of 96,863 feet in Aug 2001 [6]. Another good example of UAV is the Aerosonde, which is already famous for its 2

capabilities of meteorological monitoring and long endurance flight. It s the first UAV flying across the North Atlantic Ocean in 1998 [7]. The photos of the Helios and the Aerosnode are shown in Figure 1-4 and Figure 1-5, respectively. Figure 1-2: RQ-1 Predator with hellfire antitank missile Figure 1-3: X-45 by Boeing, DARPA, U.S. Air Force, and NASA Figure 1-4: Helios in flight 3

Figure 1-5: Aerosnode 1.2. Developments of UAV in Universities In year 2000, the School of Engineering Science in Simon Fraser University has developed an autonomous UAV called FireMite. The requirements of the FireMite are assigned to transmit video and positional data to the ground vision system for image processing, and consequently identify the location of various objects. A PC-104 industrial computer stack has been adapted as an onboard computer to execute almost all the functions in the plane. Unlike the FireFly, which is the pervious generation of FireMite, the FireMite software runs on a real time version of Windows called Pharlap ETS instead of prior QNX/Linux. This system allows for the development with Microsoft Developer Studio, which is a convenient and familiar environment [8]. Figure 1-6: FireMite of Simon Fraser University The Georgia Tech Aerial Robotics (GTAR) team has developed a system to 4

complete in the International Aerial Robotics Competition, organized by the Association for Unmanned Vehicle Systems, International [9]. The contest mission is divided into four levels. Level 1 is characterized by the need to fly an air vehicle under autonomous control for a distance of 3 kilometers. Level 2 requires an autonomous system to identify a building and open portals (windows and doors). Level 3 requires an autonomous system to enter a building and return a picture. Level 4 requires all levels to be completed by an autonomous system within 15 minutes. Each mission level must be completed before moving on to the next. In 2001, the team completed the first level of the overall mission, outperforming all other entrants and taking the lead in the contest. A MicroPilot MP2000 autopilot and sensors onboard the vehicle, a Freewave wireless modem link to the ground, and a laptop computer on the ground are utilized for the requirements of the autonomous flight. The MP2000 is a miniature autopilot. Its capabilities include airspeed hold, altitude hold, turn coordination, and GPS navigation. Data logging and manual overrides are supported. All feedback loop gains and flight parameters are user programmable [10]. Figure 1-7: Autonomous J3-Cup developed by Georgia Tech 1.3. Autonomous UAV Project in RMRL, IAA of NCKU The research activities of UAV systems has also arisen and developed no more than 20 years in the universities in Taiwan. RMRL (Remotely piloted vehicle and Microsatellite Research Laboratory) established in early 1980s in Institute of Aeronautics and Astronautics of National Cheng Kung University is one of the major research laboratories in Taiwan for UAV development. In early times, RMRL Lab has devoted to designing and manufacturing different kinds of aerodynamic configurations of UAV. With the well-developed UAV that acts as a multiple payload test bed, RMRL started to address some researches on functional payload subsystem 5

evolution since 1993. Many applications have been realized in UAV such as optical sensing, GPS navigation, and DGPS applications. The entire concept of UAV system development in RMRL can be referred to the RMRL recent review papers [11, 12]. In recent promoting the UAV applications in RMRL, the importance of beyond-visual-range (BVR) flight capability is revealed gradually. The BVR flight capability will make aerial vehicle much more useful for most of the missions in practice. There are two ways to achieve the BVR flight: one is remote controlling the UAV via instrument data/real-time video, the other is autonomous flight by UAV itself. The latter one is adopted in the current study. To accomplish the goal for an autonomous flight is complex due to the combination of both hardware and software in the system. The hardware aboard the aircraft usually consists of a computer, which serves as a heart of the autonomous flight, sensors, and some electronic devices. While on the ground segment, there needs a laptop computer which is basically portable and wireless communicating device. The integration of the hardware on UAV and the communications between airborne and ground system is important and not-an-easy task. Since the goal of autonomous flight is established, the UAV project in the RMRL is divided into five major parts, as shown in Figure 1-8. Each part has individual task but correlated with each other. The INS and GPS Navigation system provides accurate position and attitude information using three rate-gyroscopes to sense the variations of vehicle attitude in three axes of the UAV, and GPS receiver to provide the position of the UAV. The Stability and Control system provides the gains of altitude hold, heading hold, and turn coordinates for the autonomous flight. The Remote Sensing system controls a gimbals platform for the CCD camera to track the desired target base on the attitude and the position of the UAV. The Ground Station receives the data from the UAV to monitor the status of the UAV. There is a digital map on the ground station displaying the position of the UAV in real time. The Onboard Computer coordinates all the onboard components in the airborne system. It collects, computes, stores the data, and then transmits them to the ground station via the wireless modem. The study of this research focuses on the development of an onboard computer platform. The platform must have capabilities of data collections, real-time data downlink, high flexibility, and reliability. The software of the onboard computer has to operate efficiently under the constraints of the performance of the computer, and to allow for adding extra functions without difficulties for the expansion of the applications. 6

The concept and the main structure follow the thesis of Lin in 2000 [13] and Lu in 2001 [14], both graduated from National Cheng Kung University. Figure 1-8: The division of the UAV project in RMRL, NCKU 7

2. SYSTEM OVERVIEW 2.1. System Architecture The high-level system architecture of a complete aircraft/ground system is shown in Figure 2-1, which consists of the airborne system, the UAV, and the ground system. The airborne system comprises a radio controlled aircraft and an onboard system. The ground system comprises a notebook PC and a radio modem to communicate with the airborne system. Figure 2-1: High level system architecture To pack all the onboard hardware, a suitable vehicle with large interior compartment is necessary. A 1/5-scale miniature Cessna 182 is chosen for meeting the requirements. The model is powered by a 2.5 hp gas engine, with a wingspan of 2 m and a fuselage with diameter of about 0.19 m. This large interior compartment has the advantage to facilitate all of the electronic components needed and to carry the payload weight up to 4 kg. The complete development of the UAV system must accompany with the existence of a ground station. A ground station with low cost and easy to move is our expectation. The ground station can real-time display the status of the flying UAV including position, attitude and system health in the visual instruments. It hence provides more sense to realize the flight conditions of the UAV, just like a pilot seating in the cockpit. The system health includes voltages output of batteries and numbers of GPS satellite in tracking. The actual position can also be illustrated on an 8

electronic map in the ground station. For the portable requirement, a notebook PC is the first candidate to be considered. The amiable, easy to access price also saves the budget of developing the ground system. 2.2. Onboard System Developing onboard the computing system on a PC base single-board-computer would be easy to establish and extend. The onboard computer (OBC) is developed under the QNX software environment, which is a real-time operating system with multi-tasking and microkernel. Based on the fundamentals, the onboard computer can acquire data (GPS, sensors, etc ), computing the control and navigation algorithms, store, and downlink data in real-time operation. The downlink information includes the position, attitude, GPS time, payload status, and health status. The voltage output of the batteries and the numbers of the GPS satellite are taken as the health status here. 2.2.1. Onboard hardware In consideration of the volume, weight, and expansion, the PC-104 industrial computer with 486DX66 CPU and 32 MB solid state disk emulated by a Compact Flash memory is chosen for meeting the requirements. Although the PC-based industrial computer consumes more decuple power than the micro controller, the software resources, system expansion, system complexity, and maintenance still make the PC-based computer a better choice. An additional RS-232 module provides four more serial ports to be connected with other subsystems. A Data Acquisition System (DAS) module is also added to acquire such analog data as pressure and angular rates. There still needs some sensors to collect the atmospheric conditions and the UAV data. A pressure altitude sensor and an airspeed sensor are modified from the existing RC electronic products. Their analog voltage is converted into the digital data via the 12-bit resolution A/D converter on DAS module. Meanwhile, a GPS receiver, with 1 Hz update rate, provides the position information to the onboard computer through the serial port. Besides, a 3-axis inertial navigation system developed by RMRL is used to acquire the angular rates of the UAV and integrate them with time to obtain the information of the vehicle Euler angles. A wireless modem with RS-232 interface is used to transmit the data acquired by the onboard system to the ground station. It uses amateur unlicensed frequency of 900 MHz with the data rate up to 115,200 bps and output power of 1W. The transmission 9

range is 20 miles. Rechargeable Ni-MH batteries power all the electronic components during the flights. Various battery sets provide different voltage and capacity to the corresponding devices. In the future autonomous flights for long endurance mission, an additional power generator powered by the aircraft engine may be required in the future. 2.2.2. Onboard software Because of the limitations of weight and volume, the size of the onboard computer must be well constrained. Using a single processor to deal with the multi-tasks is an important consideration. A real-time operating system (RTOS) with multi-tasking feature must be adopted. The RTOS with multi-tasking feature provides a convenient and stable platform so that the user can control the peripherals in simple methods. The special system architecture also can fully make use of the hardware. Here QNX provides a good software platform for facilitating all the system. 2.3. Vehicle System The structure of the onboard system in the present study is designed as an open and flexible system with modularization concept and common PC interface. Thus, it is quite convenient to add on any hardware and software programs in this system. For the convenient expansion of hardware such as various payloads, a stable vehicle with large interior space is important. Following the pervious study in RMRL, both 1/5 scale RC Cessna 182 and J3 Cub have been used for the vehicle of the onboard system [14]. Based on the larger interior requirement, the 1/5 miniature Cessna 182 is then chosen as the test vehicle in the present study (refer to Figure 2-2). Its basic specifications are listed in Table 2-1. 10

Table 2-1: Basic specification of the 1/5 Cessna 182 Length 1.6m Fuselage length 1.53 m Wingspan 2.07 m Wing area 0.611 m2 Weight 4.85 kg (including receiver, servos, and fuel tank) Wing loading 7.93 kg/m2 Usable volume (L x W x H in maximum) 86 x 21 x 19 cm Engine required 2-stroke 0.60~0.91 inch 3 4-stroke 0.90~1.20 inch 3 The model Cessna 182 is well designed for its delicate structure frame that would make it bear great load factor with the onboard system inside. In addition, the fairings in fuselage will highly reduce the form drag so that it can be a potential candidate for the future beyond-visual-range autonomous flight. Figure 2-2: 1/5 miniature Cessna 182 In order to use the model aircraft Cessna 182 as the test vehicle of the developed onboard system, some modifications have to be made both in the interior and exterior of the vehicle. For the original design of the model aircraft, the maximum take-off weight is not more than 6 kilograms. The structures in the wing and the fuselage have to make some improvements enough for carrying the onboard system and payload. The weight budget of the onboard system and the payload is established in Table 2-2. For the fuselage structure, the two main frames connected to the wing are reinforced. While for the wing structure, the fore beam has been strengthened, too. All of these reinforcements are to ensure the safety of the UAV during the flight. 11

An aluminum plate provides a good base to place the components onboard. There are still some hook and loop fastening tapes to fix the components in case of any movement inside the aircraft. Table 2-2: Weight budget of the onboard system and payload Item Weight (gram) Number Total Weight (gram) Onboard computer with case and interface card 1028 1 1028 Servo controller 66 1 66 GPS receiver 52 1 52 INS 190 1 190 Wireless modem with antenna 542 1 542 Altimeter 56 1 56 Air speed sensor 56 1 56 Regulator 156 1 156 5V battery set 334 2 668 12V battery set 274 1 274 Payload (camera) 274 1 274 Miscellaneous (wires, foam) 150 150 Total 3512 For receiving the best satellite signals, the GPS antenna is installed on the top of the vertical fin (Figure 2-3). It s the highest position of the aircraft. Most obstruction during the preparation of the flight can be diminished. Figure 2-3: The position of the GPS antenna In order to obtain the air speed information, a pitot tube to measure the pressure 12

tube is necessary (see Figure 2-4). The installation of the pitot tube has to avoid from the turbulence induced from the propeller and the UAV so that the more accurate total pressure can be taken. Figure 2-4: Pitot tube on the UAV The distribution of the onboard components is shown in Figure 2-5. Most of the onboard components are placed in the cabin and near the center of gravity of the vehicle. The foam rubbers are placed in front and back of the onboard computer to protect the computer in the emergency situation and to decrease the vibration from the engine. The RC receiver is placed far away from the electric components, such like onboard computer and wireless modem, to reduce the influence of the Electromagnetic Interference (EMI) problem. All the servos and their electric wires are shielded with aluminum foil in order to reduce the EMI problem, too. The battery sets are all fixed behind the firewall and in the bottom to allow more tolerance for placing the components behind the center of gravity and keeping the center of gravity near the point suggested by the manufacturer s instructions. 13

Figure 2-5: Distribution of onboard components 14

3. ONBOARD HARDWARE AND SOFTWARE 3.1. Onboard Hardware The major hardware architecture excluding the vehicle is shown in the left part of Figure 3-1. It is composed of an onboard computer, sensors, a servo controller, an RC switch, a wireless modem, and a power regulator. Figure 3-1: Onboard hardware architecture 3.1.1. Onboard computer The onboard computer is operated based on a Single Board Computer (SBC) module, which is originally designed for industrial applications and has the same dimensions as that of a standard PC-104 module (90 x 96 mm). It contains almost everything that a full-fledged computer requires in spite of its small size. An RS-232 module is added to provide the series ports in order for having more connection with other devices, and a DAS module is attached to act as an A/D converter. All components that output analog signals will be connected to the DAS module to 15

acquire the data into the computer. The three modules (that is, computer, RS-232, and DAS) can be stacked together to provide an open and flexible platform for wide and advanced applications of UAV developments. The onboard computer in a stack is illustrated in Figure 3-2. Figure 3-2: Onboard computer in a stack 3.1.1.1. CPU module The PCM-3345 offers all the functions of an AT-compatible industrial computer on a single board [15]. It comes with an embedded STMicroelectronics STPC Client processor on-board. For maximum performance, the PCM-3345 installs a 32 MB EDO/FPM RAM. On-board features also include a socket for a Compact Flash Card (CF), Enhanced IDE interface (EIDE), one parallel port, two serial ports (RS-232), a keyboard, a PS/2 mouse interface, and an SVGA display controller. A 32 MB CF card is adopted as an emulated hard disk that would be the best storage device in UAV because it doesn t have any moving parts to suffer the high acceleration and vibration flight conditions from the vehicle. The operating system and all the programs are installed in the CF card. 3.1.1.2. DAS module The PCM-3718H is a high performance multifunction data acquisition module and offers A/D conversion and digital input/output [15]. The 12-bit A/D converter is jumper selectable between 16 single-ended or 8 differential analog inputs with up to 100 khz sampling rate. The TTL compatible 8-bit digital input/output is not 16

employed in the current study. 3.1.1.3. Serial interface module The PCM-3640 is a 4-port RS-232 serial interface module [15]. It provides four independent serial interfaces with high speed data transmission. The total six serial interfaces including those containing in the CPU module give a wide convenience in the development of the UAV system. It s not hard to add a function or payload via RS-232 because of sufficient ports. 3.1.2. Sensors The UAV employs two kinds of sensor: one is for air data sensing, and the other is for position determination. A GARMIN GPS 25LP is used to determine the position of the UAV and to provide the information for navigation as well. The air data sensors acquire the pressure altitude and airspeed information and output the signal into the computer through the A/D converter. The pressure sensor provides more stable altitude information than the GPS receiver does. It s very important for the needs of autopilot control law and navigation algorithm. The calibration of pressure sensor was done in the range from the sea level to the mountain height of about 1000 meters. It s also the limit of the pressure sensor we chose. Although GPS can provide good accuracy in ground speed, airspeed information is more significant to further usage in autopilot. 3.1.2.1. GPS receiver The GPS receiver is used to locate the position of the UAV. The GARMIN GPS 25LP receiver features small size, low power consumption, low cost, and high performance [16]. The position accuracy in non-differential mode is 15 meters RMS, while the velocity accuracy is 0.2 meter per second. Although the update rate is only 1 second, it is acceptable for the UAV system in the study. 3.1.2.2. Altimeter The altimeter is modified from a commercial altitude holding module so that the amplifier circuit is not considered. The calibration of the altimeter was done from the sea level to the mountain height of 1000 meter in comparison with two GPS receiver. It was done in a sunny day, and the temperature was about 25 degrees centigrade during the calibration. The module not only amplifies the output signal of the pressure sensor but also reverses it so that the voltage increases with the altitude increases. 17

Meanwhile, it constrains the usable range to 943 meters (3096 feet). The result of the calibration is depicted in Figure 3-3. Figure 3-3: Voltage output versus altitude 3.1.2.3. Air speed sensor The calibration of airspeed sensor was done in the low speed wind tunnel located in NCKU. Similarly with the altimeter, it is also modified from a commercial auto-throttle module. The output curve is fitting to a 4th-order polynomial line, and the usable range is only from 0 m/s to 33 m/s because of the limitation of the wind tunnel speed, although the capability of the air sensor itself is up to 128 m/s (250 kts). The result is shown in Figure 3-4. 18

Figure 3-4: Voltage output versus airspeed 3.1.2.4. Inertial measurement unit The inertial navigation system consists of three gyroscopes and one computing board, which is made by RMRL and is depicted in Figure 3-5. The gyroscopes detect the angular rates of three axes of the UAV and then the computing board integrates them into angle information using a PIC16F877 microchip. The I/O interface is RS-232. The data output is in ASCII format which is shown in Figure 3-6. The X, Y, and Z present roll, pitch, and yaw of the UAV in degree, respectively. Figure 3-5: Inertial measure unit 19

Figure 3-6: The string format of the IMU 3.1.3. Wireless modem To maintain the data link with the ground station, a Freewave wireless modem is utilized [17]. It can communicate with another modem in line of sight ranging up to 20 miles with unity gain antenna without any amplifier used. The frequency of the modem can be selected for avoiding the interference from the system of cellular phone in Taiwan. It also provides various types of multi-communication, which allows the onboard system for communicating with more than one ground station without difficulty. 3.1.4. Servo controller To control the servos from the onboard computer, an interface card that can convert the computer command to the Pulse Width Modulation (PWM) signal is necessary. A servo controller named Mini SSC II provides the solution [18], which is an electronic module that controls eight pulse-proportional servos according to the instructions received serially at 2400 or 9600 baud rate. Two SSC II units can share the same serial line to control a total of 16 servos. This addressability is expandable so that a total of up to 32 SSC IIs (controlling up to 255 servos) can share a single serial line. The power requirement of the servo controller ranges from 7V to 15V, which provides a convenient selection of power supply. The picture of the SSC II is located at the right-hand side of Figure 3-8. 3.1.5. RC switch Once the UAV does not fulfill the autonomous flight in all phases, it has to take off and land manually. In that case, there must be a device to switch the function between the computer and the manned control. This is done through an RC switch made in the RMRL, simply because of difficulty to purchase it. The switch board can switch four channels between servo controllers and RC receiver. The switch signal comes from one of the RC channels. The switch function is done by a TC4013BP dual D flip-flop transistor. The circuitry of the RC switch is depicted in Figure 3-7, and the finished switch is located at the left-hand side of Figure 3-8. 20

Figure 3-7: Circuitry of the RC switch 21

Figure 3-8: RC switch and SSC 3.1.6. Power system The power system includes battery sets and a power regulator. It provides a stable and regulated power supply to all the electric devices onboard the UAV. Exposing them to unregulated power in a long time may cause an unknown damage. Besides, the sensors also need a reference voltage for sensing the air information. A home-made power regulator can supply two channels of the electric power with 5V and one channel with 12V. The maximum tolerant current of the 5V output is 3A and that of the 12V is 1A. Although the input range of the regulator is between 5V and 40V, the 12 V output may not supply enough voltage if the power input is less than 12V. The power regulator is depicted in Figure 3-9. According to the power budget of the airborne system listed in Table 3-1, the power requirements are divided into three major parts: onboard computer and its peripherals, RC equipments, and wireless modem. The separation of the RC equipments and the computer is needed to insure that the UAV can operate normally in case the computer consumes all the electric power. Based on the performance of the regulator, the wireless modem is independent of all the other peripherals of the computer because it produces a pulse current that is higher than 1A when transmitting the radio signals. The high current shuts down the power supply of the 12V from the regulator. All the electric power comes from the battery sets. The different capacity of 22

Ni-MH rechargeable batteries are chosen for the requirements. Each battery provides 1.2V electric power and has the capacity from 1500mAh to 3500mAh depending on different needs. The 5V power consists of 4 batteries while the 12V consists of 10 batteries. The Ni-MH battery can provide not only high current power but also high capacity. The lack of the memory effect is also an important advantage that the battery is convenient to use. For the longer endurance flight of the UAV, a power generator may be necessary for powering all the components and charging the batteries, but this is beyond the scope of the present study. Table 3-1: Power budget Item Operating Voltage Normal Current Number Power CPU Module 5V 1.38A 1 6.9W Compact Flash 5V 45mA 1 0.225W 32MB EDORAM 3.3V 440mA 1 1.452W DAS Module 5V 180mA 1 0.9W RS 232 Module 5V 220mA 1 1.1W GPS Receiver 5V 150mA 1 0.75W Altimeter 5V 15mA 1 0.075W Air Speed Sensor 5V 15mA 1 0.075W IMU 5V 300mA 1 1.5W Servo Controller 12V 10mA 1 0.12W Payload 5V 50mA 1 0.25W Total 2.655A 13.347W RC Switch 5V 20mA 1 0.1W RC Receiver 5V 14mA 1 0.07W Servo 5V 283mA (active) 5 7.075W (peak) Total 1.449A 7.245W (maximum) Wireless Modem 12V 650mA (transmitting) 1 1W (average) 23

Figure 3-9: Power regulator 3.1.7. Case and interface card The mental case is chosen for packaging the onboard computer and GPS receiver. The strong structure can protect the onboard computer in case of any damage of the UAV. The metal case not only provides a good shield to isolate the onboard computer and the other components onboard, but also is a good conductor to transmit the heat generated by the computer and GPS receiver to outside of the case. The various components form many kinds of electric wires onboard. Each component has its own signal wires and power wires. It makes the preparation and installation complex before and after the flight tests. The idea to unify the wiring is to make them into one bundle. Here a 6-core phone wire bundle is used to serve this purpose. It combines the signal and power wire into one. An interface card is made as a bridge between the computer and its peripherals. There are 6 RS-232-, 8 A/D-, and 3 DI/O- ports on the main panel. All of the ports are transferred to the phone sockets. Another side has VGA and keyboard connectors for the convenience of operating the computer without opening the case. Figure 3-10 shows the interface panel on the metal onboard computer case, and the VGA and keyboard connector is shown in Figure 3-11. 24

Figure 3-10: The OBC case with interface panel Figure 3-11: VGA and keyboard connectors 25

3.2. Onboard Software The onboard computer handles several tasks such as data acquisition, data processing, data storage, message communication, control algorithm computing, data sending, etc. Every task is important to the whole system and even some of them can not be delayed at all. For the strict time-delay and multi-tasking requirements, a real-time operating system (RTOS) with multi-tasking is necessary for the onboard computer. The term real-time refers to a system s ability to meet its deadlines of operation. Here QNX is chosen for our onboard computer [19]. QNX is UNIX-like operating system with a micro-kernel to fit into a wide range of target systems, from small-embedded boxes to large distributed servers and everything in between. At the same time, the modularity of QNX provides users to tailor a running system, dynamically adding and removing components as required. For real-time operating, the kernel is responsible for allocating CPU time to all processes, which is so-called scheduling. Any process will continue to run until it blocks, finishes, or uses up its timeslices. In QNX, each timeslice is 50 milliseconds. With adequate scheduling, the kernel gives the illusion of many processes running simultaneously this is called multi-tasking. Unlike other commercial multi-tasking operating systems such as Windows 95/98/ME/NT/2000 and Mac OS, QNX responses much faster to the events in real world and promotes performance of the entire system. The micro kernel structure in QNX makes the processes running at the same priority as the system resources. Thus, the application processes relate to the system processes in parallel and the application processes need not request for system resources from the system processes. This strategy is much different from the traditional structure of the single-tasking operating system and will highly reduce the time that many applications request system resources at the same time. Meanwhile, the micro kernel will adequately schedule the running processes in priority in order to make the entire system running in real-time. IPC (Inter-Process-Communication) is another important feature in QNX. With this IPC mechanism, the running processes share common information without difficulties and individual process perform only one function. IPC mechanism brings some chances to break a big and multi-function process into many small processes with single function. This provides modularity of a big software system. It will not modify the main software structure if any additional process to be added in. However, the management of variables in individual process is supposed to be noticeable. 26

Possessing many advantages, QNX indeed performs well in numerous industrial applications. In addition, some research laboratories in universities worldwide also introduce QNX as their operating system in UAVs [20]. 3.2.1. Software architecture The overall software system is constructed on the QNX operating system and writing in Watcom C language. It contains several individual processes which communicate with each other via the unique IPC function in QNX. The initial concept was built by Lin in his thesis on aerial data-acquisition system [13]. The software structure can be divided into four parts, and each part contains several processes which execute similar functions. Figure 3-12: Process flow of software structure Referring to Figure 3-12, the input processes are responsible for data acquisition such as position, attitude, airspeed, and altimeter of the UAV and even uplink data from the ground station. They collect useful data from the sensors via interfaces on computer directly. The data from sensors are not necessarily suitable for the needs of UAV. Thus the data would be sent to the data handling processes to compute some transformations so that they can be recognized by other processes. All the useful data and information are stored on the database process temporarily. It is like the role of random-access memory (RAM) in computer. Further illustration will be introduced in next section. Finally, all the functions of interest are on the function processes 27

including navigation and autopilot algorithm, data storage, downlink function, and payload function. Of course, there are some processes sending final commands to control the hardware. All these procedures are like human beings doing things, while senses the changes of environment from eyes, ears, or nose, and then behave what the best reaction one should do. The complete software architecture is shown in Figure 3-13. Figure 3-13: Software architecture Each block in Figure 3-13 stands for a single process and is a complete program. The I_series blocks represent the input processes. D_series blocks belong to the data handling processes. The AL_series blocks are the function processes. The O_series blocks are processes responsible for performing I/O jobs. The M_onitor block is a monitor process that starts up all processes in definite sequence in the beginning of the flight and monitors the system in the whole journey afterwards. It detects the GPS time to determine if the GPS is working. Most functional processes except the payload process need triggering by the GPS time. This ensures all the processes can request information from the database and execute functions at the same time. The coordination of time is very important for the system developed here. This is the only way that every process can obtain the same data at the same time, and the data can be analyzed easier and clearer after the flight. 3.2.2. Programming of processes As mentioned in the pervious section, every single process is in charge of some unique tasks. Each of them will be illustrated in this section. 28

3.2.2.1. I_GPS and D_GPS The I_GPS is the process to provide the GPS data from the serial port. The output of the GPS data is written in the NMEA 0183 Version 2.0 ASCII format. GPS output has several forms and only the necessary data are used in the data stream. The data provided by the GPS include position, speed over ground, mean sea level height, heading, numbers of satellite, and time. Then the data are sent to D_GPS. In the process of D_GPS, the information of latitude and longitude are transformed from the NMEA format to degree, and the ground speed is transformed to the metric system. Another important work that D_GPS has to do is to send the trigger messages to some functional processes. The time-trigger message accompanying with the GPS time changes every second. It can be treated as the system clock to coordinate the operations of the concurrent processes. 3.2.2.2. I_IMU The I_IMU is responsible for reading the attitude information from the IMU (Inertia Measurement Unit), which consists of three piezoelectric rate gyroscopes to sense the three angular rates of the UAV and integrates them in time into angle information. Since the information provided by the IMU matches the needs of the UAV exactly, the existence of the data handling process is not necessary. The angles of roll, pitch, and yaw are acquired and sent into the database directly. 3.2.2.3. I_AD and D_AD As introduced in the pervious section, there are two functions of DAS module A/D converter and D/IO. Here the I_AD process initiates the DAS module and collects the voltages and digital signals from A/D and D/IO, respectively. There has no any digital input till now. Any sensor whose output signals in analog can be converted to the digital signals for using in the computer. After the acquisition of the analog data, the I_AD process sends collected data to the D_AD process. The D_AD process transforms voltages to the engineering data and then transforms them into specific physical dimensions for each sensor. For the altimeter, there are two kinds of mode to transform the voltage to altitude: one is the absolute height, and the other is the relative height. The absolute height is computed from the results of the calibration directly. The relative height is the height relative to the start of the onboard computer. Since the pressure varies with the weather, the pressure at zero height is not necessarily the same with the calibration. Thus, the 29

default of the altimeter is set to the relative height. 3.2.2.4. DB_base The process of DB_base denotes the database. It s the heart of all processes because it plays the role of collector and provider. Hence, it owns the highest priority of all. The DB_base process reads the pre-write waypoints from the file. It also has a safeguard function against the loss of the reading file. The data handling processes send data to the database actively, and the database sends them to the functional processes when they make a request to the database. The M_onitor process also gets the time information from the database to insure that the whole system is functioning well. 3.2.2.5. AL_NAV The process of AL_NAV is the core of the autopilot. It contains the control law of autopilot and the navigation algorithm. The value of the control gain is written in a file so that the change of the control gains is easy. There are three items that the process should be considered: what to climb/descend, where to go, and when to reach. The basic concept is that the database provides the information required for the autopilot, and then the program computes the parameters based on the control law to determine the appropriate angles that the control surfaces should act accordingly. Here, for simplicity the altitude holding is only driven by the elevators and the direction holding by the rudder. The movement of the ailerons and the engine throttle are not included yet. The information of the deflections of the control surfaces is sent to O_SERVO process. The O_SERVO process transforms the angle information with the format that the servo controller can recognize and then sends to the servo controller through the serial port. There are many disturbances that affect the flight of UAV, and therefore it is very hard to keep it at the same altitude at all time. The wide level and narrow level of the threshold are set for the altitude-holding control. The concept is displayed in Figure 3-14. The goal is the desired altitude, and the wide level is set to 20 meters while narrow level is set to 5 meters. The elevator will keep in neutral point when the UAV flies under the wide level. That means the UAV will not adjust the altitude until deviate out of the wide level. If the UAV flies outside the wide level, it will activate the elevator to adjust the altitude toward the goal. The adjustment stops when the altitude difference between the UAV and the goal reaches the narrow level. Since the unstable output of the GPS height in nature, the pressure altitude from the pitot tube is 30

set as the altitude control of the UAV here. Figure 3-14: Wide and narrow level of limitation for altitude holding To determine the direction that the UAV should go, the UAV heading, position, and the destination coordinates should be considered. Referring to Figure 3-15, the oh vector is the direction of UAV, and the angle β is the heading information form GPS ranging between 0 and 359.9. The ow vector is the direction from UAV to the next waypoint. The position information of both UAV and waypoint must be transformed from the latitude and longitude of the WGS-84 (LLH) to the local horizontal coordinate system (2-degree transverse Mercator projection). The transformation of TWD-97 (EN) has been adopted here [21]. It transforms the geodetic coordinate to the horizontal coordinate so that the distance and direction between the two close points can be determined easily and accurately. Thus the ow vector can be determined by the given, E, N values of the UAV and the waypoint. The γ is the angle of ow vector from the north ranging between 0 and 359.9, while the tracking angle ψ is defined as shown in the same figure. There are four possibilities of ψ: 1. ψ > 0 and ψ > 180, the UAV should make a left turn to desired direction. 2. ψ > 0 and ψ 180, the UAV should make a right turn to desired direction. 3. ψ < 0 and ψ > 180, the UAV should make a right turn to desired direction. 31

4. ψ < 0 and ψ 180, the UAV should make a left turn to desire direction. The four situations listed above contain all the possibilities when the UAV intends to make a turn. This method guarantees that the UAV will not make a turn more than 180 degrees. To decrease the times for turning correction, any turn less than 1 degree will not be applied. Figure 3-15: The logic of direction holding To decide when to reach the waypoints and the final destination is also an important issue. The UAV changes its heading to the next waypoint after passing the current one and stay hovering when reaching the final waypoint. The determination method is sketched in Figure 3-16. There is a target range with radius r. It may be hard to fly directly over the waypoint, for which the UAV is considered already passing through the waypoint within the range of r is achieved. Since the update rate of the distance information is 1 second, there is a possibility that the UAV passes the waypoint but the distance is still longer than the target range. To avoid this event, the concept of the rate of the distance between the UAV and the waypoint has to be introduced. The range can be variant based on the result of the flight test. At the beginning of the flight test, the range of r was set at 50 meters in radius. Another constraint is that the absolute value of tracking angle ψ must be smaller than 90 degree or larger than 270 degree. 32

Figure 3-16: Waypoint determination 3.2.2.6. AL_STORE The AL_STORE process stores some useful information for analysis after the flight test, such as time, position, sensor data, health state, and deflections of control surfaces. The data file is stored in the ASCII format for the convenience of reading. 3.2.2.7. AL_DNLK and O_DNLK The AL_DNLK and O_DNLK processes are responsible for communicating with the ground station. The AL_DNLK requests data from the database and transforms them into the format suitable for transmitting. The downlink string contains all the information the ground station requires. The format of the string is listed in Table 3-2. The O_DNLK process initializes the wireless modem and receives the data from the AL_DNLK. The transmission rate between the onboard computer and the ground station is set at 19200 bps. A string of $DL is put in front of the downlink string, and an EOF (End Of File) character is put in the end. The checksum byte is added in front of the EOF to improve the convenience that the ground station can check if the data have any loss during the transmitting process easily. In addition, some bytes needed for the data handling are allocated in the end of the string. Finally, the total length of the downlink string has 82 bytes, and it is transmitted in a form of packet at 33

1 Hz of the transmission rate. Table 3-2: The format of the downlink frame Item Length (byte) Item Length (byte) Item Length (byte) GPS Numbers GPS Latitude N or S Longitude E or W time of GPS height 4 1 4 1 4 1 4 GPS speed Heading Payload1 Payload2 Payload3 Payload4 Altitude 2 2 1 1 1 1 4 Air Power Regulated Regulated Pitch Roll Yaw speed supply 12V 5V 4 4 4 4 4 4 4 Item Aux.1 Aux.2 Aux.3 Checksum Total Length (byte) 4 4 4 1 72 3.2.2.8. AL_PLO and O_PLO The AL_PLO process determines when and how the payload function should start then send the trigger or command message to O_PLO. There are three sets of payload processes. For the current payload, the AL_PLO process counts a period of time and sends proxy message to the O_PLO process to execute the payload function. Another way is that the AL_PLO process sends proxy message to the O_PLO process when the UAV flies near the assigned waypoints. For further application, the AL_PLO process contains the control algorithm to command the gimbals for camera to track the desired waypoints. The O_PLO process controls the payload directly from the serial port. The current payload is driven by a pulse signal, which is generated from the DTS pin in one of the serial port. This is one of the easiest ways to produce a pulse from the computer. The further O_PLO process will receive the command from the AL_PLO to drive the gimbals via servo controllers. The concept is the same with the O_SERVO. 34

3.2.2.9. M_onitor The M_onitor process is a program that starts all the other processes in definite sequence. It is loaded in the system booting script. The unique IPC function of the QNX limits the sequence of starting the processes. Every process using the message passing mechanism must follow the client/server model in the QNX. After loading all the processes, the M_onitor process and then watch the variation of GPS time from the database process. The loading sequence of all the processes is listed in Table 3-3. Table 3-3: System loading sequence Process Description M_onitor 1. Starting the M_onitor process in background. 2. Executing AD test and confirming the function of wireless modem. 3. Loading all the other processes. A bi sound would appear when each series completes the loading. O_series The initial tests of servo and wireless modem are contained in each process. DB_base The database process starts as a server to request message from D_series and I_IMU. D_series The D_series process starts as a server to request message from I_series and the D_GPS process would try to trigger the AL_series. AL_series Starting to receive messages from the database and sending commands to the O_serises processes at specific intervals. O_PLO Due to message passing order, the O_PLO process must be started after the AL_PLO process. I_series Starting to acquire information from sensors and sending to D_series processes. 35

4. TEST, RESULTS, AND DISCUSSION The overall system tests can be divided into two major parts: ground phase and flight phase. The basic flow of the system test procedures is illustrated in Figure 4-1. Figure 4-1: System test procedures 4.1. Ground Tests The UAV has to be well tested and evaluated on the ground before the real flight test proceeds in the sky. These tests on the ground include the individual functional 36

test of both airborne and ground system and integration test of both. The functional test ensures that the airborne and ground system can execute every function according to the requirements, which is followed by the integration test. The integration test makes sure the entire system in regular status. The adequate function of each subsystem doesn t ensure the well function of a combination system. For instance, the wireless data transmission test revealed that the data delay in the ground station propagating with time increasing at the first beginning. The problem was solved soon, and the data can be synchronized both in airborne and ground system. 4.1.1. Endurance test Endurance test ensures that all the electric components onboard can function well for a long time. Because all the electric components are powered by the battery sets, the time that a battery set can supply and the stability of the power output are concerned. Although the time can be estimated from the power consumption of each single device, there are still many uncertainties which may not have been considered in detail, such as the efficiency of the power regulator and the impedance of the wire and connectors. The easiest way to know the actual time that the system can operate is to put them together and test. Several cross tests have been done. The 12V battery set with 1500mAh capacity is connected to a regulator and supplies to all components except the wireless modem. The 5V battery set with 3500mAh capacity is connected to the onboard computer and to the sensors directly without using a regulator. The result is shown in Figure 4-2, Figure 4-3, and Table 4-1. The 12V output is not a concern here because the only component that requires the 12V power has a wide range of power requirement. 37

Figure 4-2: Regulated 5V power Figure 4-3: Unregulated 5V power Note that the 5V power supplied by the regulator shows the stable capacity of power with time. The drift range is not more than 0.04V, thus the regulator does provide a very stable power output. Due to the lower capacity of the 12V battery set, the battery can only supply electric power about 45 minutes. Referring to the Figure 4-3, the voltage of the 5V battery set decreases with time. The power supply lasts 4737 seconds (about 79 minutes) and the onboard computer shuts down when the battery voltage drops to 4.43V. Several tests have indicated that the onboard computer shuts down when the power supplies between 4.43V and 4.47V. That is, the 4.45V is 38

the lowest limitation that the computer can be operated. The 11% tolerance between 4.45V and 5V is much more than the specification of the onboard computer, which has a 5% tolerance of power supply. The analog sensors such as altimeter and air speed sensor also require a reference voltage when operating. Here the regulator supplies a stable reference voltage. As shown in Figure 4-4 and Figure 4-5, the values of the altimeter decrease with the decay of the unregulated 5V power supply. The values of the altimeter supplied by the regulated 5V have a little better than the unregulated one. Thus, for better performance, the power supplying to the sensors has better been regulated. For the current study, the decrements of the values of the altimeter are still in the tolerance of the UAV. Figure 4-4: Altimeter with regulated power 39

Figure 4-5: Altimeter without regulated power Table 4-1: Operating time under battery power Battery set Devices Operating time 12V, 1500mAh Regulator, Computer and peripherals 45 min 5V, 3500mAh Computer and peripherals 78 min 12V, 1500mAh Wireless modem More than 90 min Furthermore, the computer case contains the onboard computer and the GPS receiver with a sealed surrounding. The endurance test also assures the heat generated inside the case will not influence the computer performance, though without the accurate thermo analysis here. The numerous tests have shown that the onboard computer system here can operate normally more than 12 hours without causing any problems. 4.1.2. Wireless data communication on car After the in-house experiments in the laboratory, the entire system has to be tested in a moving and vibrating condition outdoors to make sure if the environment causes any malfunctions. All the components have been connected during the wireless test onboard a car in stead of the airplane for the time being. The onboard computer was set on a moving car while the ground station was stationary on a fixed remote place. The track obtained from the ground test also depicts in Figure 4-6. The coordinates have been transformed from WGS-84 to the form of the 2-degree 40

transverse Mercator projection (2 TM, TWD-97, EN). The ground test also indicates that the value of the airspeed sensor behaves quite the same comparing with the ground speed reading from the GPS receiver. The altimeter also shows its stability of sensing the altitude better than the GPS does. Both results are compared and illustrated in Figure 4-7. It seems that the GPS lost track of satellite signals at the beginning of the test. Even though the GPS receiver received the satellite signals, the stability is still worse than that of the altimeter as well. Figure 4-6: The track of the wireless ground test Figure 4-7: The comparison of altitude in GPS and altimeter 41

4.1.3. EMI test The electromagnetic interference (EMI) test is made to ensure that the electrical devices and RC receiver do not interfere with each other, and the communication between the onboard computer and the ground station will not be interfered by other factors. The EMI tests were held several times in the top floor of the IAA and EE building. All the components were placed onboard and the UAV parked on one side of the IAA building while the ground station was on the other side with a distance of about 60 meters apart. The antenna of the RC transmitter was in closed position. The relevant effective transmitting distance shows in Table 4-2. Table 4-2: The results of EMI test Experiment condition Regulator, SSC, wireless modem, onboard computer, and all sensors Regulator with aluminum shielding, SSC, wireless modem, onboard computer, and all sensors SSC, wireless modem, onboard computer, and all sensors Effective distance 3 m 5 m 56 m From Table 4-2, the regulator causes a serious EMI problem even the aluminum shielding does not make obvious improvement. The reason is that the inductance on the regulator generates an open magnetic field that seriously influences the RC receiver. 4.2. Flight Tests After the ground test, the flight test was put into practice. The major purpose is to ensure if the real-time data link is accomplished at the first flight test. The process was not as smooth as what expected. The first problem was the onboard computer didn t connect well with the ground station because of some unknown reasons. Every light or sound signal onboard indicated that the computer operated correctly, while the ground station didn t receive any significant data from the screen. It took several times to reboot the onboard computer and to reconnect the devices on the ground station. While the computer and ground station got connected again, the UAV was ready to fly. After took off, unfortunately, the UAV crashed into the ground within 30 seconds. No obvious damage was found in the peripherals onboard but the airplane 42

and the engine were tragically damaged and could not be used anymore. Both of the data stored in the onboard computer and the ground station revealed that the GPS receiver didn t receive any satellite signal during the flight. The only information recorded were the data from the DAS module including altimeter, airspeed, and voltage of the UAV. 5 sec Figure 4-8: Pressure altitude and airspeed of the first fight test Figure 4-8 shows the variations of the altitude and airspeed versus time before the UAV crashed. Notice that the airspeed increases and altitude decreases at the last moment. Comparing the data stored in the onboard computer and the ground station, extra 5 seconds of the data were stored in the ground station, which was longer than that stored in the onboard computer. Thus the data of the last 5 seconds in the figure are retrieved from the ground station. The differences of the data between the onboard computer and ground station may be because the onboard operating system, QNX, did not write the data into the compact flash card until the buffer of the IO reached a full volume. This ensures the efficiency of the operating system for the low speed action during writing data into the disk. The data in the ground station indicates that the last data transmitted terminated at the altitude of 3.4 meters and the airspeed of 75 km/h, while the data onboard were 21.4 m and 65.16 km/h, respectively. During the reconstruction of the aircraft and re-evaluation of numerous ground tests, the UAV proceeded again flying into the sky and successfully transmitted data to the ground station with many useful data, such as GPS, altimeter, etc. They will be discussed as following 43

Trajectory of full flight 180 160 140 altitude (m) 120 100 80 60 40 20 2.538 x 10 6 2.5378 2.5376 N (m) 2.5374 2.5372 1.755 Runway 1.756 1.757 E (m) 1.758 x 10 5 1.759 Figure 4-9: The trajectory of the flight test Figure 4-9 depicts the trajectory of the flight test. Figure 4-10 shows that the UAV flew in a horizontal range of 300 meters along east-west and 700 meters along north-south directions. Figure 4-11 illustrates the GPS height (MSL) of the flight test. The GPS ground speed is depicted in Figure 4-12 throughout the flight time. Figure 4-10: 2D path of the entire flight 44

Figure 4-11: GPS height of the flight test Figure 4-12: GPS ground speed of the flight test 45

Figure 4-13: Picture taking from the automatic camera on the UAV Figure 4-13 shows a picture taking from the automatic camera onboard the UAV. It was taken when the computer sent the command signal to the onboard camera to automatically take the picture without the command control from the ground, indicating the onboard computer s hardware and software integration is functioning well according to the design. Once the ground station receives the data transmitted from the onboard computer, it subsequently decodes and then displays on the display panel. The displayed information is classified into numerical, graphical, and map displays. The detailed display panel depicting the data from the UAV is shown in Figure 4-14. For the detailed description of the ground station, please refer to the work by Wu [22] in her master thesis. 46

Figure 4-14: Ground station display panel 47

5. CONCLUSION 5.1. Concluding Remarks The results of the present study have shown that the functions of the onboard computer and the ground station are verified both in the ground test and the flight test. Some significant features from this study can be conducted as following: 1. The onboard system has been developed successfully to have had the capability of collecting data such as position, airspeed, altitude, heading, and health status of the UAV. The information allows for the implementation of the basic ability for the autonomous flight. 2. The features of the onboard software enable us to add any function without difficulty. It also shows the high efficiency and robust performance running on a simple industrial computer. The mono-function-module programming simplifies the debugging process and highly reduces the development time as well. 3. The success of the data link has proved that the transmitting distance are more than 2 kilometers during the car test without apparent data loss in the ground station. 4. The success of the flight test reveals that the onboard system can operate normally and overcome the environment of vibration and EMI problem in the UAV. 5. The calibrations of pressure sensors for airspeed and altitude have ensured the stability, range, and resolution for practical applications in the UAV. Even the inspiring achievements being made, there still have many improvements and modifications to be done. The problems and comments for the system are remarked as following: 1. The crash of the airplane indicates the serious problems in the integration although both functions of the onboard computer and the ground station perform well in the laboratory and ground test. All evidences indicate that the problems come from the EMI. The principal source of the EMI, in fact, comes from the voltage regulator. That is, the inductance on the regulator produces an open magnetic field to influence the RC receiver. Replacing the normal inductance to coil inductance may reduce the problem. 2. The power consumption is too high to maintain a long endurance flight. The 48

inclusion of a power generator connected to the aircraft engine may be necessary for the endurance flight in a long distance. 3. The attitude sensors such as gyroscopes are not included in the onboard system yet. It s important to add the sensors to obtain more information of the UAV and more precise design of the control law. 4. The cost for the onboard system is still high because most of the equipments or instruments are all made off-the-shelf products. The commercial products may eliminate many workloads in hardware development but heavily increase the cost of the entire system. This means any loss during the operations will be very expensive. This will be an important issue to proceed the UAV project without enough funding resources. 5.2. Future Work Once the onboard computer platform has been established and verified through the ground and flight tests, it is not far on the way to the autonomous flight capability. The following steps can be further taken into actions to achieve the goal of autonomous flight in the future development: 1. A suitable power regulator is necessary for the long endurance data collection. It s not difficult to modify current regulator to eliminate the EMI problem. 2. In the advanced flight test, it is recommended that only one type of autopilot such as altitude hold or heading hold be switched in one flight test. Once one autopilot has achieved, the other autopilot can be combined into the flight test. 3. For longer endurance time and various missions, a larger vehicle is suggested. 4. A watch dog function is better to be added to monitor, if every process is working correctly. When necessary, restart all the processes. 49

REFERENCES 1. Ricks, T.E., U.S. Arms Unmanned Aircraft Revolution in sky above Afghanistan, The Washington Post, 18 October 2001 2. Schick, W. and Meyer, I., Luftwaffe Secret Projects: Fighters, 1939-1945 (Volume 1), ISBN 1857800524, August 1997 3. UAV forum: http://www.uavforum.com/index.shtml 4. General Atomics Aeronautical Systems, Inc.: http://www.ga.com/asi/home.html 5. The Boeing Company: http://www.boeing.com/ 6. The X-Press Volume 44, NASA Dryden Flight Research Center, 8 May 2002 7. Aerosnode: http://www.aa.washington.edu/research/aerosonde/laima.htm 8. Hennessey, C., Autonomous Control of a Scale Airplane, School of Engineering Science, Simon Fraser University, 14 April 2000 9. Association for Unmanned Vehicle Systems International: http://www.auvsi.org/ 10. Johnson, E. N., Hart, M. G., and Christophersen, H.B., Development of an Autonomous Aerial Reconnaissance System at Georgia Tech, AIAA's 1 st Technical Conference and Workshop on Unmanned Aerospace Vehicles, Systems, Technologies, and Operations, 20-23 May 2002 11. Hsiao, F. B. and Lee, M. T., System Engineering and Practice in Aircraft Design for Aerospace Education, UNESCO 4th Annual Conference on Engineering Education, Bangkok, Thailand, 7-10 February 2001 12. Hsiao, F. B. and Lee, M. T., The Development of Unmanned Aerial Vehicle in RMRL/NCKU, 4 th Pacific International Conference on Aerospace Science and Technology, Kaohsiung, Taiwan, May 2001 13. Lin, Y. R., The Development of an Onboard Computer System for Unmanned Aerial Vehicle, Master thesis, Institute of Aeronautics and Astronautics, National Cheng Kung University, July 2000 14. Lu, W. C., The Development of a Data Collection and Navigation System For an Unmanned Aerial Vehicle, Master thesis, Institute of Aeronautics and Astronautics, National Cheng Kung University, July 2001 15. Advantech: http://www.advantech.com.tw/ 16. Garmin: http://www.garmin.com/ 50

17. Freewave Technologies: http://www.freewave.com/ 18. Scott Edwards Electronic, Inc.: http://www.seetron.ocm/ 19. QNX Software System: http://www.qnx.com/ 20. Evans, J., Inalhan, G., Jang, J. S., Teo, R., and Tomlin, C. J., Dragonfly: A Versatile UAV Platform for the Advancement of Aircraft Navigation and Control, the Proceedings of the 20 th IEEE Digital Avionics Systems Conference, October 2001 21. Huang, W. W., A Study of Geodetic Datum Transformation between TWD97 and TWD67 Using Transverse Mercator Coordinates, Master thesis, Department of Surveying Engineering, National Cheng Kung University, July 2001 22. Wu, C. R., The Development of a Portable Ground Control Station for the Unmanned Aerial Vehicle, Master thesis, Institute of Aeronautics and Astronautics, National Cheng Kung University, July 2002 23. Kolnick, F., The QNX 4 Real-time Operating System, Basis Computer System Inc., ISBN 0-921960-01-8, 1998 24. Sams, H. W., The Waite Group s Turbo C Programming for the PC, Revised Edition, Howard W. Sams, 1009 51

APPENDIX A Onboard hardware specifications Advantech PCM-3345 CPU Module CPU: ST Thomson DX-66 STPC Client System Memory: 144 Pin SODIMM x 1 SSD: Compact Flash Card Power Consumption: +5 V @ 1.09 A Size/Weight: 96 x 90 mm, 0.098 Kg Temperature: 0 ~ 70 C, operating PCM-3640 4 RS-232 Module Bus interface: ISA Number of ports: 4 I/O address: 0x0200 ~ 0x03F8 IRQ: 3, 4, 5, 6, 7, 9, 10, 11, 12, 15 Speed (bps): 50 ~ 921.6k Connectors Four DB-9 male Power requirement: +5V @ 200 ma Temperature: 0 ~ 65 C, operating PCM-3718 12-bit DAS Module Analog Input Channels: 16 single-ended or 8 differential inputs Resolution: 12 bits Input Range (Unipolar): 0~10, 0~5, 0~2.5, 0~1.25 V Digital Input/Output Channels: two 8-bit TTL-level Digital I/O channels Power requirements: +5V, 5% tolerance Temperature: 0 ~ 60 C, operating 52

Perry Design PDC20 Altitude Hold Power: 5.5V ~ 6.5 V @15 ma Sensor Resolution: 1 ft. Sensor Range: 4096 ft. Usable Range: 3096 ft. AGL Altitude Hold: +/-25 ft. (level flight) PDC25 Auto-Throttle Power: 5.5V ~ 6.5 V @ 15 ma Sensor Resolution: 0.1 kts. Sensor Range: 0 250 kts. Airspeed Hold: +/-2 kts. (level flight) GARMIN GPS 25 LP Tracks up to 12 satellites Update rate: 1 second Position accuracy: DGPS: Less than 5 meters RMS Non-differential GPS: 15 meters RMS Velocity accuracy: 0.2 m/s RMS steady state Dynamics: 999 knots velocity, 6g dynamic Input voltage: 3.6 VDC to 6.0 VDC Input current: 140 ma typical, 105 ma max Operating temperature: -30 C to 85 C (board temperature) Receiver sensitivity: -165dBW minimum 53

FreeWave DGR-115R Frequency: 902 to 928 MHz Output Power: 955 mw at 9.5 to 14.0 V Range: 20 miles (line of sight) Modulation: GFSK, 120kBs 170kBs Occupied Bandwidth: 230 khz Error Detection: 32-bit CRC, resend on error Data Encryption: Substitution, dynamic key Link Throughput: 115 KBaud Interface: RS-232 1200 Baud to 115.2 KBaud, asynchronous, full duplex Power Requirement: 650 ma at 12V for 1W (transmit) Operating Environment: -40 C to 75 C 54