. Massachusetts Institute of Technology Unmanned Aerial Vehicle Team Jonathan Downey, Buddy Michini Matt Doherty, Carl Engel, Jacob Katz, Karl Kulling 2006 AUVSI Student UAV Competition Journal Paper, Submitted June 1, 2006 Abstract This journal paper gives an overview of the Project AARES design process. The aircraft was designed to meet the need of modern UAVs to adapt to rapidly changing functional requirements. The modular, flexible design lends itself to the rapid development of all systems involved. Avionics, control architecture, navigation autonomy, and ground station support were custom-designed by students to meet the AUVSI mission requirements as well as future challenges. The result is a highly-capable UAV able to complete the competition objectives.
Contents 1 Introduction 1 2 Design Overview 1 3 Airframe 2 4 Avionics 3 4.1 Requirements................................... 3 4.2 Rapid Prototyping of Avionics.......................... 4 4.3 General Architecture............................... 4 4.4 Modular Hardware................................ 5 4.4.1 Power Module.............................. 6 4.4.2 Inertial Measurement Unit....................... 6 4.4.3 RF Transceiver.............................. 6 4.4.4 GPS Receiver Module.......................... 7 4.4.5 RC Receiver................................ 7 4.4.6 Air Data Module............................. 7 4.4.7 Quad Actuator.............................. 7 4.5 Modular Software................................. 8 4.6 Testing....................................... 8 4.6.1 Individual Board Testing........................ 8 4.6.2 Networked Ground Testing....................... 8 4.6.3 Flight Testing............................... 9 5 Controls 9 5.1 Modeling...................................... 9 5.2 Numerical Simulation.............................. 10 5.3 Controller Design................................. 10 5.4 Final Controller Architecture.......................... 12 5.5 Discretization and Code Generation...................... 12 6 Autonomy 13 6.1 Navigation Algorithm.............................. 13 6.2 Mission Execution................................. 13 6.3 Contingency Operations............................. 14 6.4 Hardware-in-the-Loop Simulator........................ 15 7 Ground Control Station 15 8 Safety 17 8.1 Safety Override.................................. 17 8.2 Power Systems.................................. 17 8.3 RFI Protection................................... 18 9 Conclusion 18
List of Figures 1 Photograph of airframe.............................. 3 2 RF Transceiver................................... 6 3 RC Receiver.................................... 7 4 Air Data Module................................. 7 5 Quad Actuator................................... 7 6 Modular Software................................. 8 7 Example of Controller Inner-Loops....................... 11 8 Altitude Correction................................ 12 9 Example of Circular Arc Approximation.................... 14 10 Example of Waypoint Tracking......................... 14 11 Example Mission................................. 14 13 HUD and Flight Tracker............................. 16
- Acknowledgements We d like to thank our faculty advisors, Professor Jon How and Col. Peter Young, for their guidance and support. We d also like to thank our academic sponsors, the MIT Department of Aeronautics and Astronautics, the MIT Department of Mechanical Engineering, the MIT Department of Electrical Engineering and Computer Science, and especially the MIT Edgerton Center. Finally, we d like to thank our corporate sponsors, Altium for their fantastic printed circuity board design software, NovAtel for their GPS equipment, and Microsoft for their development software. Thanks to all of our other sponsors as well: AME Manufacturing, EHKA&A, the Mathworks, Advanced Circuits, Geneva Aerospace, FreeWave Technologies, Phytec, Microchip Technologies, Analog Devices, PCB Express, and MicroStrain. Thank you!
1 Introduction Project AARES (Autonomous Aerial Reconnaissance Exploration System) is an interdisciplinary team of MIT undergraduate students with the shared aspiration of developing a fully-autonomous modular Unmanned Aircraft from the ground-up. These students, representing Aerospace, Electrical, and Mechanical Engineering, combine their diverse backgrounds and collective knowledge to solve difficult problems and develop innovative solutions. As UAVs see more use in increasingly diverse roles, their functions and capabilities must change as rapidly as their requirements. To develop innovative unmanned aircraft in minimal time and at minimal cost, we must have the ability not only to rapidprototype airframes; we must integrate complex avionics systems, control architectures, and ground station support equipment as well. To do this, standard ready-to-use components must be developed just as software can be rapidly composed from ready-to-use libraries. Given the wide range of real-world tasks assigned to UAVs today, we believe that flexibility and modularity are some of the most important factors in modern UAV design. There are no black boxes aboard our aircraft. Avionics hardware and software were designed by students using rapid-prototyping concepts, and autopilot and autonomy systems were designed and implemented from the ground-up. This journal paper gives an overview of the entire AARES project including design, implementation, testing, and safety. 2 Design Overview A modified NorthEast Sailplanes Viking was chosen as the airframe for the AUVSI competition. The aircraft is a small (4.5 ft. wingspan), electric-propulsion platform that is low-maintenance, lightweight, and extremely portable. In previous years, a larger gaspowered airframe was used but was found to be cumbersome to transport and difficult to service. The smaller Viking has adequate payload capabilities and excellent stability characteristics, making it ideal for our purposes. Custom avionics boards were designed entirely by students. The custom design of each board and modular architecture of the entire avionics system makes the aircraft flexible, upgradeable, and able to take on a wide range of tasks. The avionics were designed for rapid prototyping, giving us the ability to quickly design and upgrade the aircraft to meet changing mission and design requirements. 1
Aircraft dynamics were modeled mathematically using a variety of computational fluid dynamics tools. Wing and fuselage geometry and centers of mass were measured and used as parameters for computational fluid dynamics (CFD) software. A 3D model of the aircraft was created and imported into Athena Vortex Lattice (AVL), which was used to compute aerodynamics coefficients and stability derivatives. These were then used to model aircraft dynamics in Simulink using the Aerosim Blockset. This simulation provided a basis for the design of the control system. Controllers were designed from the ground-up with inner-loops controlling low-level functions such as pitch and roll and outer-loops controlling high-level functions such as heading and altitude. With the flexibility to choose a robust guidance platform, a unique nonlinear guidance controller was adapted from previous research. 1 The algorithm is efficient and tailored for this mission specifically, with the ability to dynamically change mission objectives mid-flight and follow new waypoints on-the-fly. A hardware-in-the-loop simulation was used to test and debug the control systems and guidance algorithms, minimizing the risk of in-flight failure. A ground station server computer handles all communication with the aircraft. The server then broadcasts state information (such as telemetry) via a TCP/IP network to peripheral ground station computers. These peripheral computers manage specific aspects of the mission and include a HUD/Telemetry Computer, a Mission Management Computer, and a Payload Computer. These three stations have the ability to send commands to the aircraft, but must do so through the server. The Flight Manager oversees all flight operations while three other team members man the peripheral computers and report directly to the Flight Manager. The aircraft was designed with safety as a top priority. The R/C receiver module has an integrated safety override should the autopilot fail, returning manual control to the pilot. If all radio communication is lost, the module commands a hard-over spin per competition regulations. Power systems are kept separated to lessen the probability of a system-wide power loss. Extensive measures have been taken to minimize RFI complications including wire shielding, RFI enclosures for high-risk boards, and strategic hardware placement. 3 Airframe While the competition does not have any specific requirements for the aircraft itself, the team made their own criteria to aid in airframe selection. From last year s experience, the team knew they needed a smaller, more manageable aircraft. However, it still 1 Park, S (2004) Avionics and Control System Development for Mid-Air Rendezvous of Two Unmanned Aerial Vehicles. PhD thesis. Massachusetts Institute of Technology. 2
needed to be able to carry up to 3 pounds of payload. To avoid the hassle of gasoline or glow engines, the team opted for an 4.5 ft. wingspan plane with an electric propulsion system. Its small size and electric propulsion would enable the aircraft to have its initial flight tests held on campus, rather than transporting everything to a distant airfield. Autopilot testing is done entirely at remote airfield locations due to safety concerns. The team chose the North East Sailplanes Viking (airframe shown in Figure 1). It met all of team s specifications with its light weight, low wing loading, easy handling, and electric power plant. The team built the aircraft stock, with only a few modifications to integrate the avionics. Initial flight testing proved that Figure 1: Photograph of airframe it was capable of handling 3 pounds of payload with minimal impact on flight characteristics. With the aircraft fully loaded, the 4200 mah lithium polymer battery pack and MP Jet 2810 brushless outrunner motor can deliver over 30 minutes of flight time. 4 Avionics 4.1 Requirements An avionics system designed for rapid prototyping must be able to measure the aircraft s state, act on its state, communicate with users on the ground, execute control algorithms, and be able to control a payload in order to complete a specific mission. In addition to the functions that the system must perform, there are several other design requirements which must be addressed if this system is to be successful. The system must expandable, in order to accommodate future needs that are yet unknown. New components must be easily added without altering previous hardware. The system must be fault tolerant because an aircraft in flight can be a dangerous situation. The propagation of errors must be controlled in a way that allows low-level failures to be masked and handled appropriately whenever possible. The failure of a non-essential sensor must not affect the ability of someone to fly the aircraft. The system must also be reconfigurable. If one component of the system needs to be changed, that change must not have global consequences which affect other aspects of the system. Finally, the system must exhibit managed complexity. If the avionics for an experimental aircraft are to be quickly setup, they must be reasonably easy to use and not overly complex. 3
4.2 Rapid Prototyping of Avionics If we are to develop innovative unmanned aircraft in minimal time, we must have the ability to rapidly build complex avionics systems from standard ready-to-use components just as software can be rapidly built from ready-to-use libraries. If these avionics systems are to be of use in these next generation aircraft, they must be extendable, reconfigurable, fault tolerant, and must exhibit managed complexity. To make this vision possible, several steps must be taken: 1. A power and communication standard must be developed which each module must adhere to. 2. Modular hardware must be designed to perform many of the core functions that are necessary for unmanned aircraft. Modules used on the aircraft are described in detail below. 3. Modular software must be developed that connect the hardware modules together and allow them to communicate with each other. 4. Module specific software must be written to enable each module to perform its specific functions. 5. Each module must be tested individually to ensure that it works according to specifications. 6. The modules should be integrated on an aircraft and flown in order to demonstrate their effectiveness. Many flight tests have been performed which demonstrated the operation of the modules on the aircraft. 4.3 General Architecture In order to meet the proposed design goals, the architecture of the avionics system is entirely modular. Each module is designed for a specific task and either measures some quantity, controls some device, communicates with the ground, or processes control algorithms. Additionally, a payload, such as a camera, can be controlled to complete mission requirements. Power is distributed to each module from the Power Module connected to the bus. This module monitors the batteries and regulates voltages. All communication between modules is done using the Controller Area Network (CAN) bus. This bus has come to dominate the automotive industry because of its fault-tolerant, noise tolerant, high bandwidth, event-driven architecture. Unlike Ethernet, the CAN bus is deterministic with nondestructive bus arbitration. 4
Communication on the bus is divided into two types of messages: broadcasts and commands. Commands can be sent to a specific module in order to control it. Broadcasts are sent from a module to every module on the bus. This allows for every module to have access to data which may be relevant to its operation. For example, a gimbaled video camera can be programmed to automatically adjust to the aircraft s pitch and roll without interference from the flight computer by accepting broadcasts from the Inertial Measurement Unit directly. More importantly, this design allows for the RF Transceiver to have access to all of the measured quantities on the aircraft. The RF Transceiver can then be programmed to stream telemetry data to the ground regardless of the state of the Flight Computer. If the Flight Computer were to fail or was not present at all, users on the ground could still have access to the aircraft s telemetry and use that information to make a safe manual landing. In operation, the flight computer initializes devices. Sensors broadcast their information on the bus. The flight computer uses the sensor information to execute flight control algorithms and then sends commands to actuators in order to control the aircraft. All the while, the RF modem is also receiving broadcasts and is able to transmit telemetry to the ground even in the absence of the flight computer. If a user desires to gain manual control of the aircraft, the RC receiver (being controlled by an RC transmitter on the ground) can send command packets directly to the actuators. This allows for manual control of the aircraft should anything go wrong. Control of the payload from the ground is also possible. A block diagram of the entire system is shown in Appendix A. 4.4 Modular Hardware Each hardware module is a union of general and specialized components. General components are common to nearly all of the avionics modules and allow for each module to interface with the avionics bus, display its status, and be programmed with custom software. In addition to the general components that define the universal capabilities of the system, specialized components exist that define the unique capabilities of an individual module. This specialized hardware often consists of a commercial off-the-shelf (COTS) component such as the Xtend radio modem or 3DM-GX1 inertial sensor. Other custom hardware typically exists to interface this COTS hardware with the microcontroller. On other boards such as the air data board, nearly all of the hardware is custom. 5
4.4.1 Power Module The Power Module is responsible for regulating and distributing power as well as monitoring battery status and current consumption. This power module is designed for use in an electric powered aircraft and has connections to two batteries. The primary battery powers all of the avionics and is designed to be either a 3-cell lithium ion battery or a 9-cell NiMH battery. The second battery is for powering the aircraft s electric motor and can be various sizes. The voltage and current draw can be measured from both batteries. Both the avionics and propulsion power systems can be turned on and off with using two switches. Additionally, the avionics can be powered from a ground power source which can be connected to this module. This connection can provide tethered power to the avionics when the plane is on the ground in order to minimize the drain on the main avionics battery and ensure maximum flight time. This ground connection also extends to the CAN bus to an external PC which can be used for debugging or ground testing. 4.4.2 Inertial Measurement Unit The Inertial Measurement Unit is responsible for measuring the attitude and change in attitude of the aircraft. The 3DM-GX1 was selected as the inertial sensor (IMU) to use for this module because of its integrated filtering, small size, and low power consumption. This device is capable of reporting its orientation at 75Hz over a simple RS-232 connection. It is also capable of measuring the lateral and vertical accelerations felt by the aircraft. 4.4.3 RF Transceiver When designing the RF Transceiver module, reliability and size were the most important considerations. The 900 MHz Xtend radio modem from MaxStream was selected as the COTS component of this module. This device is a frequency hopping spread spectrum modem capable of communicating over a range of several miles with error correction and packet acknowledgement. An LED is included on this module to indicate when the modem is transmitting and receiving. An integrated circuit provides power consumption monitoring, as the modem can use nearly 4 Figure 2: RF Transceiver watts of power from the 5.0 volt power supply. Finally, a temperature sensor in included to ensure the module does not over heat. 6
4.4.4 GPS Receiver Module The GPS Receiver Module is responsible for measuring the position and true velocity of the aircraft. Using a NovAtel Superstar II, this module is able to obtain these measurements at 5Hz with a position error of as little as +/- 1 meter and velocity error of +/- 0.05 meters per second. The Superstar II is a 12 channel receiver capable of carrier phase tracking. It can make use of both differential and WAAS corrections and reports its accuracy in real time. 4.4.5 RC Receiver The RC Receiver Module is responsible for receiving the radio frequency signal from a standard RC transmitter and measuring the pulse widths that are transmitted. The processor is able to measure the pulse widths that are decoded by the Electron 6 RC receiver. 4.4.6 Air Data Module The Air Data Module is responsible for measuring the aircraft s altitude and airspeed using pressures from the aircraft s Pitot tube. The Pitot tube delivers static and dynamic pressures which are measured using sensors P1 and P2. By decreasing the range of the sensor to 0-5,000 ft above sea level, the module should have a resolution of 0.07 feet. Additionally, the connection for an external temperature sensor is present in case the air temperature is needed in calculations. Figure 3: RC Receiver Figure 4: Air Data Module 4.4.7 Quad Actuator The Quad Servo Controller (or Quad Actuator) is designed to control four standard RC servos. Several of these modules can be connected to the bus if more than four servos need to be controlled. Each servo is controlled by varying the length of a digital pulse that is sent to the servo at 50Hz. This module allows for the pulse width to each servo to vary between 500us and 2500us with a resolution of less than 1us. Figure 5: Quad Actuator 7
4.5 Modular Software As each module contains a set of common hardware components, it is desirable to also write both common and specific software for each hardware module. As indicated in the graphic to the right, modules contain a block of Core Software with core Interface Modules that handle low level functionality including CAN connectivity, status LED control, and system timing. The Core Software handles basic functionality including resetting the device and changing the device s operation mode. Another layer is built upon this low-level and mid-level core software which is specific to each hardware module. This software includes both low-level custom Interface Modules and high-level Board Specific Software. This organization of embedded code is beneficial for several reasons. First, if a feature is to be added to the system such that it will be used on all hardware modules, that feature needs only to be added in the core software which will be loaded onto all hardware modules. Second, when writing software for a new module, a large portion of the code from previous modules is easily reused as it is present in the Core Software. Third, when changes need Figure 6: Modular Software to be made during testing, these changes can generally be made in one place as they are either specific to a single board or included in the Core Software which is common to all boards. 4.6 Testing 4.6.1 Individual Board Testing Each board is tested by powering the module and connecting it to a PC using a CANto-USB converter. This enables the PC to receive and send CAN packets to the avionics hardware. Custom programs written in visual basic are able to display data from the avionics modules and allow for interaction with the module. 4.6.2 Networked Ground Testing When several modules have passed the individual board testing, they are connected together on the ground to ensure that they do not interfere with each other and can operate collectively. During this testing, there were several problems with radio frequency interference (RFI). These problems were solved using wire shielding and RFI enclosures, and by changing the orientation of hardware modules. 8
4.6.3 Flight Testing When modules had been proven to work together collectively without interference, they were installed on the aircraft. The aircraft was able to stream telemetry information to the ground using the RF Transceiver. On the ground, this information was received using an Xtend RF modem connected to a laptop s serial power. This serial information was displayed in the Heads Up Display (HUD) in order to demonstrate the functionality of the RF Transceiver, IMU, Power Module, and GPS in flight. 5 Controls 5.1 Modeling One of the first steps to modeling our airplane was to measure the various quantities that determine the dynamics and stability of the airplane. Quantities that had to be measured were the dimensions of the airplane, the airfoil shape, control surface deflections, the mass, and the moments of inertia about the three axes of the airplane. All geometry measurements were referenced with respect to the propeller nut, with the x- axis pointing from the reference point to the front of the horizontal stabilizer, the y-axis towards the right wing, and the z-axis up. The sizes of the various airplane components were measured, as well as their position with respect to the reference point. The control surface deflections were also measured with a ruler, and then the angles computed trigonometrically. The wing s airfoil was determined by measuring the maximum camber, maximum camber location, and the maximum thickness and approximating the airfoil as a NACA 4-digit airfoil. Moment of inertia measurements were important to establish the correct dynamics of the airplane. Although not all payload was available, a representative payload was placed in the airframe to correctly simulate the mass distribution of the airplane. To measure the moment of inertia about the x-axis, the airplane was hung vertically from a spring with the x-axis pointing directly down. The airplane was then turned approximately 30 degrees about the vertical axis, and allowed to rotate back and forth. The moment of inertia was determined using the relationship between the spring s rotational spring constant and the period of rotation. This technique was repeated for the other two axes. The mass of the airplane was determined by individually weighing the airplane and the various components that would be making up the payload. The next step after all quantities had been measured was to build a virtual model of the 9
airplane. The program Athena Vortex Lattice (AVL) was chosen for this task. AVL is a 3-dimensional aerodynamics analysis program that provides the forces on the airplane and their coefficients as well as stability derivatives. The airplane s operating parameters and the control surface deflections can be changed to simulate the aircraft under different flight conditions in the linear flight regime. The information that AVL provided about the aircraft was essential for a complete characterization of the aircraft about our intended operating point. 5.2 Numerical Simulation The MATLAB Simulink toolbox was used to create a real-time simulation of the aircraft for controller development and hardware-in-the-loop simulation. Instead of building a dynamics model of the aircraft from scratch, Dynamics Unlimited s AeroSim Blockset was utilized as a baseline. It was modified with the stability derivatives, mass properties, and aerodynamic coefficients found from modeling the aircraft in AVL. To verify that the simulation was realistic, vehicle visualization was performed using FlightGear, an open-source flight simulator. The team s pilots then flew the dynamics model as a standard R/C simulator, comparing the handling characteristics of the simulation with the actual aircraft. They found that it flew very much like the actual aircraft after adjusting a couple of stability derivatives. The finished Simulink model allowed for development of the control architecture in parallel with that of the flight electronics. 5.3 Controller Design The low-level controllers are designed to stabilize and control the aircraft s altitude, airspeed, and heading. This control layer is then commanded by upper-level navigation algorithms. The low-level controllers are based on an independent nested PID control loop layout. Nested PID compensators were chosen for their robust performance and straight-forward gain tuning. They also allow the user (human or upper-level controllers) to directly command different aircraft states than initially decided if desired, such as turn rate or bank angle instead of heading. Also, the actual aircraft dynamics are masked for the upper level controllers by layering the control loops. The upper level controllers see the dynamics of the lower level controllers, which can be controlled by the designer. This allows for higher performance with relatively low complexity. The innermost controllers perform the most basic functions, including commanding roll and pitch angle, to stabilize the aircraft. An altitude controller was designed and tuned to the dynamics of the pitch angle controller it commands. Likewise, a turn rate controller commands a bank angle to the bank angle controller. To command a desired 10
heading, a third layer is added, which outputs turn rate commands to achieve that heading. Figure 7: Example of Controller Inner-Loops The controllers were designed and tuned from the inner-most outward. This is necessary because the inner controller dynamics determine the tuning of the outer compensators. Gains were initially set using the Ziegler-Nichols closed-loop tuning method. Once these were found, they were manually tuned for a fast response with acceptable levels of overshoot and steady-state tracking. Once set, the overlaying compensator is tuned the same way. While each command path may contain more than one controller, each path is independent of the others, and is treated as a single-input, single-output system. While this is not the ideal control architecture, it fits well into the managed modularity with low complexity theme of the entire system. It takes advantage of the fact that the aircraft being used has only a small amount of axis coupling. Any change in state by an outside controller is seen as a disturbance by the compensator of that state. This can most easily be seen during a turn. As the aircraft is banked, it will start to lose altitude if the elevator trim is not changed. A human pilot knows this and corrects for it during the turn by applying up elevator as he or she banks the aircraft. In this control architecture, a heading change command only directly affects the controllers in that control path; the pitch control path is ignored. However, as soon as the aircraft starts to bank and loses altitude, the altitude controller sees the change as a disturbance and compensates for it, just as it would react to a wind gust or thermal. To determine how well this architecture performs, a simulation was set up with an 180 commanded turn while commanding constant altitude. As can be seen from Figure 9, the altitude controller reacted to the initial loss of altitude nearly immediately with only 2 meters of deviation. A second simulation was run with the pitch controller turned off, holding the elevator 11
trim, which can be seen in red. This resulted in a 70 meter loss of altitude, demonstrating the effectiveness of the independent control architecture. Figure 8: Altitude Correction 5.4 Final Controller Architecture Block diagrams of the final controller architecture are shown in Appendix B. 5.5 Discretization and Code Generation As described above, the control architecture was designed and tested in a continuous (non-discrete) context. In order to implement the controllers on a flight computer, the transfer functions were discretized. While this could have been done by hand using a simple Tustin transformation into the discrete Z-domain, Simulink s Model Discretizer was used. This tool performs an identical Tustin transformation, and allows for an inherited time step (sample rate) which adds flexibility in setting the hardware sample rate(s). After the various control blocks were discretized, MATLAB was again used to generate C-code for the entire control architecture. Again, the code could have been written by 12
hand by converting the discrete transfer functions into algebraic difference equations. However, given the probability of error and the intricacy of the inner-outer loop setup, the code generator saved a huge amount of coding and debugging time. Code was then simply copied to the flight computer with minimal modification to setup communication with the sensors and actuators. A hardware-in-the-loop simulation was used to verify and tune the discrete computer control architecture (see Autonomy ). 6 Autonomy To complete a mission the AARES autonomy module must provide three functions: 1. Control of basic aircraft stability 2. Flight path tracking 3. Mission plan execution, including dynamic task assignment These capabilities are provided by a low level closed-loop control system (described above), a high level navigation algorithm, and a mission executive based on a series of commands called air task orders. Like most components of AARES, each part of the autonomy module is a custom component created by students. 6.1 Navigation Algorithm With the flexibility to choose a robust guidance platform, the AARES team implemented a unique nonlinear guidance controller. In contrast to traditional path following methods, the controller does not use cross track error to drive the aircraft toward the desired flight path. Instead, the controller searches the path for a point that is a fixed distance away from the aircraft, forming an instantaneous tracking point for the trajectory. To generate a control command, the flight path between the current position and the target position is approximated by a circular arc (Figure 10). Using this arc and the current velocity, a desired lateral acceleration is calculated and actuated with a simple low level roll command. Once the aircraft gets close enough to the end of the segment that it cannot track the segment anymore, the aircraft begins tracking the segment between the next two waypoints (Figure 11). The result is a trajectory which naturally converges with the desired flight path and anticipates discrete changes in the path s direction with smooth turns. 6.2 Mission Execution To provide commands for navigation and low level control, a command structure was created called an air task order. Air task orders are created by stringing together 13
Figure 9: Example of Circular Arc Approximation Figure 10: Example of Waypoint Tracking two components: waypoints and segments. Segments describe the movement between two points, and waypoints define the actions to be performed at these points. In general, waypoints are designated as navigation waypoints, which define the general shape of the desired flight path and are not absolutely vital to mission success. When a waypoint is critical to the flight plan it is designated as a mission waypoint. If a mission waypoint is missed, the aircraft will execute a pre-defined contingency operation as described in the next section. Several pre-defined actions can be appended to waypoints to simplify common mission tasks such as loitering, changing altitude in a fixed location, or taking a picture. For more complex operations, an air task order is created to provide a sequence of commands to the navigation and control software (Figure 12). To create a mission, several air task orders are uploaded to the flight computer to be executed in series. The Figure 11: Example Mission air task order structure also allows for dynamic re-tasking. The ground station operators can insert a waypoint or entire flight plan into the original mission sequence during the flight by simply uploading a new air task order. 6.3 Contingency Operations During any flight, the autonomy software will continually monitor the status of the RF communication link and the progress of the current air task order. In the event of an 14
anomaly, the software will execute pre-defined air task orders that are uploaded at the start of the mission. For example, an RF modem signal loss will result in the aircraft heading to a pre-defined home position. The RC link and RF modem are also independently monitored by the RcMUX board, which will independently execute a hard over if all control is lost. 6.4 Hardware-in-the-Loop Simulator To provide a realistic environment for developing flight software, the AARES avionics system is capable of entering a special Hardware In the Loop (HIL) simulation mode. In HIL mode, onboard sensor modules are disabled and an external simulator is directly connected to the avionics bus. The simulator, which utilizes the same flight model used for initial controls prototyping, replicates the messages sent by all onboard sensor systems and broadcasts them to the avionics bus. This architecture requires no special modifications to the flight computer software, allowing the flight computer to operate exactly as it would in a real flight. The RF communication link also remains unaffected, providing the capability for a complete mission simulation from ground station software. 7 Ground Control Station The ground control station (GCS) features a highly modular architecture. It is composed of four major components. The server receives data from the RF link and passes it to the heads up display (HUD), mission management (MM), and payload clients. One advantage of the GCS s server/client architecture is that it allows communication with the plane to be abstracted away from the controls on the ground. The GCS s modularity also allows its individual components to be designed, implemented, and tested independently of the others. In addition, it precludes individual errors from propagating and causing the entire system to fail. Together, the server s three major clients provide all the ground control and observation capability required to accomplish the mission. After receiving the RF packets in CAN format, the server parses them and updates its copy of the aircraft state with the new data. In parallel, the server also converts the current state into an extensible markup language (XML) schema and transmits it over TCP/IP to the other nodes. XML was chosen because its parsers are simple to write in a wide variety of languages: thus, the choice of language at each node is neatly abstracted away. The three clients (HUD, MM, and payload) receive the state information and, optionally, send commands back to the server (in XML as well) to be relayed to the aircraft s flight computer. 15
The HUD shows the current state of the aircraft and allows manual joystick control. Specifically, it shows the aircraft s altitude, pitch, roll, heading in a flight simulatorlike interface. It also shows battery life indicators for the motor batteries and avionics batteries, and RF signal strength. A top-down view of the aircraft on a map of the area is displayed. Simply by clicking a button, the user can override the aircraft s autopilot and take manual control. Through the HUD, the aircraft can be controlled with a joystick or through higher-level commands, such as change heading, or hold altitude. First, a flight plan, consisting of air task orders, is created with the MM software. To create the flight plan, the user first loads a satellite image of the terrain into the program. Then, onto this map image air task orders are created and appended together. In each air task order, the user can place a runway, mission waypoints, navigational waypoints, and other points of interest. The runway is the point at which the aircraft takes off and lands. Mission waypoints are mission-critical, and may not be missed. Navigational waypoints are placed to aid the flight computer in finding a path between mission waypoints; thus, they can Figure 13: HUD and Flight Tracker be skipped if necessary. For both types of waypoint, target velocity, altitude and tolerance can be set. All of these attributes along with corresponding points and a map are saved as air task orders, and any combination of air task orders with take-off and land operations can constitute a flight plan and be sent to the flight computer. Then, while the mission is underway, the map shows in real time aircraft s position in relation to the map and targets, and its progress toward completing the ATO. Finally, the payload node handles mission-specific duties. For the AUVSI competition, the still camera s photos are downloaded to the payload node and entered into the software. This software generates Keyhole markup language (KML) that associates the still images with their location and perspective on the ground. Google Earth then reads the KML and overlays the still images onto the map. In order to manage all the components of the GCS effectively, a single user (the GCS operator ) is the primary point of contact during the mission. While other users can 16
help identify problems and troubleshoot, the GCS operator is responsible for relaying mission status to the other members of the team. If significant problems arise, the GCS operator will first attempt to take manual control of the aircraft with the HUD node. In the case of an emergency, this user will delegate control to an experienced RC pilot who will override the flight computer and safely land the plane. Together, the components of the GCS are a highly-modular approach to aircraft ground support, allowing rapid response to ever-changing mission requirements. 8 Safety When developing and operating UAVs, safety is of utmost importance. Throughout the development of the team-designed autopilot, every possible precaution was taken to ensure safe operation. 8.1 Safety Override The autopilot is integrated in parallel with a standard R/C receiver. Servo commands from the R/C receiver and autopilot are sent to a safety switch, which then selects which device controls the servos. Channel 5 from the R/C receiver is connected to the Master input of the safety switch. This assures that control can be turned over to R/C control in the case of any type of autopilot loss. It also gives the pilot complete authority to override the autopilot whenever he or she deems necessary without any action needed from the ground station or flight computer. The safety switch setup assures that control of the vehicle is maintained in the event of autopilot failure. AUVSI rules state that the aircraft is to execute a hard-over spin in the case that manual control is lost. This is accomplished using a PCM R/C receiver that is programmed to select manual control and command the servos to their hard-over positions if the transmitter signal is lost. 8.2 Power Systems These safety measures only work as long as the power system on the aircraft is functioning. To minimize the chances of a power failure, the autopilot and backup R/C systems have independent power circuits. All the voltages and currents are monitored on the ground for any problems. The servos are powered as a part of the backup R/C system, so control of the aircraft is maintained in the event of total autopilot power failure. 17
8.3 RFI Protection Radio frequency interference proved to be a problem during the initial testing phases. RFI from the switching power supply, GPS board, and unshielded cables weakened the R/C link among other things. This was accounted for by using RFI enclosures for avionics boards as necessary, shielding and winding all cables within the fuselage, and strategically placing hardware and antennas such that RFI was minimized. 9 Conclusion As UAVs see more use in increasingly diverse roles, their functions and capabilities must change as rapidly as their requirements. The Project AARES UAV was designed specifically with this in mind. The aircraft s suite of custom, modular components make it easily adaptable to a wide range of missions. This design lends itself to the rapid development of avionics, control architecture, and ground station support equipment, and the AUVSI competition has given the team an opportunity to exercise these techniques. The result is a UAV that is highly-customized, designed from the ground-up by students, and ready to take on the challenges that the competition has to offer. 18
Appendix A - Full System Block Diagram Flight Computer GPS Receiver Power Module Li-Ion Li-Polymer ESC Servo Power Brushless Motor Air Data Module IMU CAN Bus RC Safety Override Servo Servo Servo Servo Sonar Altimeter Prism Servo RF Transceiver Video Transmitter PCM Receiver 900 MHz Ground Power HIL Sim Plane Ground 2.4 GHz 72 MHz RF Transceiver CAN GCS Server Video Receiver RC Transmitter TCP/IP USB Backup Pilot HUD Diagnostics Mission Management Payload / Imaging HUD Operator Safety Officer Mission Manager
Appendix B - Overall Control Architecture Stability Control Architecture