Miniature Aircraft Deployment System (MADS) Approval Name Affiliation Approved Date Customer Eric Frew CU Advisor #2

Transcription

1 University of Colorado Department of Aerospace Engineering Sciences Senior Projects ASEN 4018 Miniature Aircraft Deployment System (MADS) (PDD) Document History Release Version Date Description of Top Level PM Name Changes Draft Creation of Document Travis Schafhausen Final 9/11/2008 Edited based on feedback Travis Schafhausen Approval Name Affiliation Approved Date Customer Eric Frew CU Advisor #1 CU Advisor #2 CU CC Jean Koster CU

2 Aerospace Senior Projects (ASEN 4018 & 4028) Acronyms AAA Advanced Aircraft Analysis AES Aerospace Engineering Sciences AGL Above Ground Level AMA American Model Association CFD Computational Fluid Dynamics COTS commercial-off-the-shelf CG Center of Gravity CPP Cermak Peterka Petersen CUPIC Colorado University Peripheral Interface Controller DLC Discovery Learning Center FAA Federal Aviation Administration ITLL Integrated Teaching and Learning Laboratory SV Sub-Vehicle PAB Professional Advisory Board PV - Primary Vehicle RC Radio Controlled RECUV Research and Engineering Center for Unmanned Vehicles SI System International SV Sub-Vehicle UROP Undergraduate Research Opportunity Program Definitions Deployed The SV is physically separated from the PV and deployment mechanism. Deployment Mechanism Only refers to the structure and release mechanism that attaches to the primary vehicle. Deployment System The deployment mechanism and sub-vehicles combined together as a system. 2

3 1.0 Information 1.1 Project Title Miniature Aircraft Deployment System (MADS) 1.2 Project Customer Professor Eric Frew Research and Engineering Center for Unmanned Vehicles (RECUV) University of Colorado at Boulder 429 UCB Boulder, CO Phone: Group Members - 8 Leah Crumbaker Phone: leah.crumbaker@colorado.edu James Gordon Phone: james.gordon@colorado.edu Jeff Mullen Phone: jeffrey.mullen@colorado.edu Scott Tatum Phone: scott.tatum@colorado.edu 2.0 Background and Context Jason Farmer Phone: jason.farmer@colorado.edu Matthew Lenda Phone: matthew.lenda@colorado.edu Travis Schafhausen Phone: travis.schafhausen@colorado.edu Kristina Wang Phone: kristina.wang@colorado.edu The mission of MADS is to develop a mechanism for a Research and Engineering Center for Unmanned Vehicles (RECUV) vehicle that is capable of storing and deploying multiple subvehicles (SVs) in flight. Similar projects have been attempted by previous senior design groups, namely, D-SUAVE (Deployable Small Unmanned Aerial Vehicle Explorer, AY ). Since the objectives of previous attempts were not met, MADS provides an opportunity to de-scope and focus on the deployment system and SV design. Deployable SVs are most applicable in data-collection situations that are dangerous or difficult to access for human observation. Tornado weather observation is a specific example of such an application observers would be able to send an unmanned aircraft towards a storm, which would then deploy SVs towards the tornado to collect data. This information would then be relayed back through the primary vehicle (PV) to observers on the ground. While the exact MADS platform may not be completely translated to such a mission, a successful fulfillment of current objectives would provide baseline work for future modifications of different PVs and SVs. This application is particularly valuable to RECUV, since this data-collection ability would allow RECUV to develop new projects and expand their partners and clientele. 3

4 3.0 Goal The goal of MADS is to develop a system that can attach to the radio controlled (RC) PV and is capable of in-flight deployment of four SVs that are capable of self-sustained flight. This will create a test platform that will allow the customer to test communication protocols among multiple aircraft and algorithms concerning the optimization of deployment and utilization of multiple, disparately sized aircraft. 4.0 Objectives The primary objective for this project is to design a deployment system that will deploy four SVs, of which at least one will be flight-capable, on demand from a PV. The system cannot significantly degrade the performance of the PV s flight characteristics as stated in the requirements below. The project is going to be divided into two main parts: the design of the deployment mechanism and the SVs. The SVs will be controlled by an autopilot upon deployment from the PV and must fulfill their endurance requirements. After the flight, the PV and the SVs will land at a designated location and be picked up by the operator(s). Extra space and power will be provided on the SVs for any experiments or communication systems that may be used in the future. For project success, a working deployment mechanism and one flight capable SV will be delivered to the customer. 4

5 5.0 Functional Block Diagram The functional block diagram is as follows: Figure 1 Functional Block Diagram 5

6 6.0 System Operational Timeline (Concept of Operations) The concept of operations is as follows: Figure 2 Concept of Operations Diagram 6.1 Preflight Prepare deployment system Check batteries Attach SVs to deployment mechanism Prepare PV for flight Fuel PV Check control surfaces Warm-up 6.2 Take-Off Climb to an altitude of 50m 6.3 Cruise Establish steady, controllable flight 6.4 SV Deployment On-demand from ground operations 6.5 SVs (After Deployment) Autopilot Control Loiter for a minimum of 15 minutes Land 6.6 Primary Vehicle (After Deployment) Ground Operations Control Loiter (if needed) Land 6

7 7.0 Project Requirements (0.PRJ) 7.1 Deployment Mechanism Requirement (0.PRJ.1) Statement: The deployment mechanism shall be able to carry and deploy four SVs in flight Explanation: The deployment system must be able to demonstrate that it is capable of deploying multiple SVs for future research Parent: From the customer requirements Verification: Deployment testing with one flight-capable SV and non-functional mock-up SVs. This entails bench testing until repeatability can be verified (15 successful repetitions) followed by in-flight testing. 7.2 Primary Vehicle Requirement (0.PRJ.2) Statement: The PV shall be the RC aircraft SIG Rascal Explanation: The SIG Rascal 110 is currently utilized by the customer for research purposes Parent: From the customer requirements Verification Method: Inspection by customer. 7.3 Sub-Vehicle Requirement (0.PRJ.3) Statement: The team shall deliver one flight capable SV in spring Explanation: A flight capable SV will be used to demonstrate that the system can deploy SVs with the proper endurance and power capabilities Parent: From the customer requirements Verification: System test to verify that the SV meets system requirements 0.SYS.1 through 0.SYS Metric Measurement System Requirement (0.PRJ.4) Statement: All units of measurement used throughout the project shall be metric Explanation: Making a requirement to use consistent units throughout the project should prevent the team from having any conversion errors Parent: From the customer requirements Verification: Documentation. 7.5 Academy of Model Aeronautics (AMA) Rules and Regulations (0.PRJ.5) Statement: The PV and SVs shall abide by all rules and regulations enforced by the Academy of Model Aeronautics Explanation: This is required for all RC aircraft and by the Federal Aviation Association (FAA) Parent: From the customer requirements Verification: Documentation. 8.0 Top Level System Requirements (0.SYS) 8.1 Sub-Vehicle Endurance Requirement (0.SYS.1) Statement: The SV shall have a minimum 15 minute, post-deployment flight endurance Explanation: This requirement will ensure that the SV is capable of flight long enough to satisfy the customer s research requirements Parent: 0.PRJ Verification: A timed flight test of the SV. 8.2 Sub-Vehicle Airspeed Requirement (0.SYS.2) 7

8 8.2.1 Statement: The SV shall have a minimum airspeed of 5 meters per second Explanation: This requirement will ensure that the SV is capable of satisfying the customer s research requirements Parent: 0.PRJ Verification: CUPIC GPS measurements taken during flight test will be used to verify airspeed. 8.3 Sub-Vehicle Deployment Altitude Requirement (0.SYS.3) Statement: The SV shall be deployed from an altitude between 50 and 100 meters above ground level (AGL) with respect to Boulder, Colorado Explanation: This requirement will ensure that the PV and SVs will stay within the restrictions imposed by the AMA Parent: 0.PRJ.3, 0.PRJ Verification: CUPIC GPS measurements taken during flight test will be used to verify altitude. 8.4 Sub-Vehicle Power Requirement (0.SYS.4) Statement: The SV shall have a TBD (determined by 10/14) voltage and TBD (determined by 10/14) amperage power supply Explanation: The SV must provide adequate power to the propulsion, avionics, communications systems, and a simulated science payload Parent: 0.PRJ Verification: Bench testing to verify that the power system can provide the required voltage and amperage. 8.5 Sub-Vehicle Autopilot Requirement (0.SYS.5) Statement: The SV shall utilize the GPS-integrated autopilot chips (CUPIC) Explanation: The customer currently uses this autopilot for research purposes Parent: 0.PRJ Verification: Inspection by customer. 8.6 Sub-Vehicle Control Requirement (0.SYS.6) Statement: The SV shall be capable of stable flight under autopilot control Explanation: This ensures that the SVs will be capable of self-sustained flight after release from the PV Parent: 0.PRJ Verification: Static test to ensure the autopilot is capable of control of SV throttle and all control surfaces as well as instrumented flight test to verify stable flight under autopilot control. 8.7 Deployment System Performance Degradation Requirement (0.SYS.7) Statement: The deployment system shall not decrease the endurance or range of the PV by more than 20% Explanation: The PV must maintain performance capabilities that continue to meet the customer s research requirements despite the addition of the deployment system Parent: 0.PRJ.1, 0.PRJ Verification: Wind tunnel testing and/or Computational Fluid Dynamics (CFD) simulations to determine losses due to the additional drag and weight of the deployment system, as well as full system flight tests. 8.8 Deployment System Stability Degradation Requirement (0.SYS.8) 8

9 8.8.1 Statement: The deployment system shall not decrease the stability and handling characteristics of the PV such that it cannot be flown by an experienced RC pilot during all mission phases (see 6.0) Explanation: This ensures that the PV is capable of performing the mission laid out in Parent: 0.PRJ.1, 0.PRJ Verification: Aerodynamic analysis and wind tunnel testing or CFD simulation of the PV stability and flight characteristics with the deployment system attached, as well as qualitative evaluation by an experience RC pilot during flight test. 8.9 Deployment Mechanism Requirement (0.SYS.9) Statement: The deployment mechanism shall deploy each SV on demand Explanation: The customer requires the deployment mechanism to be able to release when instructed during flight Parent: 0.PRJ Verification: Deployment testing entails bench testing until repeatability can be verified (15 successful repetitions) followed by in-flight testing. 9.0 Minimum Requirements for Success 9.1 Deployment Requirement (0.PRJ.1) 9.2 Primary-Vehicle Requirement (0.PRJ.2) 9.3 Sub-Vehicle Requirement (0.PRJ3.) 10.0 Deliverables 10.1 Hardware Deliverables (0.DEL.1) The customer shall receive at least one functional SV, the deployment mechanism, the PV, and any other associated hardware Software Deliverables (0.DEL.2) The customer shall receive all software source code Intellectual Deliverables (0.DEL.3) The customer shall receive all documentation associated with the operation and maintenance of software and hardware for the SVs, the PV, and the deployment mechanism Technical Risks The MADS team is aware that there are many risks associated with this project. The following are considered the greatest risks to its success Primary Vehicle Performance Degradation (0.RSK.1) Risk: Little is known about the capabilities and characteristics of the PV at this time. The addition of the deployment system to the PV could disrupt the airflow, simultaneously decreasing lift and increasing drag. This could result in failure to meet the deployment system requirement (0.SYS.7) Mitigation: The deployment system will be designed considering PV performance loss. Wind tunnel tests will be conducted and/or CFD models will be analyzed to study the effect of the deployment system on the PV. Additionally, should the PV prove to be incapable of meeting the 0.SYS.7 9

10 performance requirement and the 0.PRJ.1 requirement specifying four SVs simultaneously, the customer has stated that modification of the 0.PRJ.1 deployment mechanism requirement to support only two SVs is acceptable Sub-Vehicle Stability (0.RSK.2) Risk: The initial conditions imposed on the SVs by their proximity relative to the PV may lead to unstable flight upon release. This could result in the SV impacting the PV upon deployment. Additionally, SV stability and aerodynamics are difficult to analyze due to the low Reynolds number flow Mitigation: The deployment system will be designed to ensure SV stability after deployment and clean separation of the SV from the PV. Wind tunnel tests will be conducted and/or CFD models will be created to analyze the effect of the PV flow field on SV stability. A SolidWorks model of the SV will provide the location of the center of gravity (CG), and the airfoil of the SV can be analyzed with XFoil or other similar programs Deployment Mechanism Failure (0.RSK.3) Risk: The deployment mechanism may fail prior to or during SV release. This could result in early and/or unstable deployment or non-deployment resulting in mission failure Mitigation: Extensive bench testing will be conducted to ensure the reliability of the deployment mechanism prior to full system tests Sub-Vehicle Incapable of Flight (0.RSK.4) Risk: It is possible that the design and development of a SV that is capable of self-sustained flight will prove to be infeasible Mitigation: The deployment mechanism can be designed and tested without a flight capable SV. The deployment mechanism may also be designed to be adaptable to other SVs. Finally, the use of a commercial-off-the-shelf (COTS) aircraft as the SV is an option that may be pursued in order to avoid the additional complications of designing a flight capable SV Primary Vehicle Structural Failure (0.RSK.5) Risk: The addition of a deployment system to the PV may cause structural failure Mitigation: The PV will be structurally analyzed to verify that it is capable of sustaining the additional weight and the modifications made for the deployment system. Modifications may also be made to the PV to handle the increased load of the deployment system Anticipated Engineering Expertise The MADS project requires a broad range of engineering expertise because of the number of technical fields that must be consolidated for mission success. Table 1 summarizes the technical positions proposed for the MADS team. 10

11 Table 1: MADS Engineering Expertise Engineering Skill How Applied Team Members Aerodynamics Analyze the flight performance effects of the deployment system as well as the aerodynamics of the sub-vehicles post-deployment. Jeff Mullen Kristina Wang Leah Crumbaker Structures Controls, Avionics, and Electronics Deployment Mechanism Sub-Vehicle Design Software Systems Management PV structural modification for the deployment system; model the system in 3-dimensional CAD drawings for structural analysis and as an input to the aerodynamic analysis. Design for stable deployment of the sub-vehicles from the primary vehicle and study the stability of all vehicles pre- and post-deployment; integrate the power system with the subvehicle s autopilot chip, the control surfaces, and propulsion system; design for flexibility of modular payload packages for future projects. Design a robust deployment mechanism that allows for stable release and flight of the subvehicles and does not significantly degrade the performance of the primary vehicle. Design the sub-vehicles with aerodynamic, structural, propulsion, and control considerations for post-deployment autonomous flight. Integrate the software within the microprocessor in the sub-vehicle autopilot chips with on-board, real-time system checks prior to deployment; develop computer simulations for system analysis. Define system requirements and oversee the integration of all subsystems into a single cohesive design; perform process engineering and systems-level tests. Organize the 8-member team and oversee each element of the design process with the Systems Engineer; consolidate and coordinate team activities; contribute technical skills to all systems. Jason Farmer Scott Tatum James Gordon Matt Lenda James Gordon Jeff Mullen Travis Schafhausen Scott Tatum Jason Farmer Leah Crumbaker Kristina Wang Matt Lenda Travis Schafhausen James Gordon Matt Lenda Leah Crumbaker Travis Schafhausen Table 2 lists the team members that will lead the positions required by the AES Senior Projects course. Some positions are cross-listed and redundant in Table 1. Table 2: AES-Required MADS Team Leads Position Chief Financial Officer (CFO) Electronics Lead Team Member Scott Tatum Matt Lenda 11

12 Fabrication Lead Safety Lead Software Lead Test Lead Webmaster Jason Farmer Leah Crumbaker James Gordon Jeff Mullen Kristina Wang 13.0 Resources 13.1 Facilities AES Electronics Lab: The vehicles avionics elements require access to proper electronics fabrication equipment. The AES Electronics Lab is equipped to support these needs AES Machine Shop: Both the primary vehicle and the sub-vehicles require access to the AES Machine Shop for precision fabrication purposes AES Visions Lab: The multiple flight configurations proposed for the MADS mission will require the use of Computational Fluid Dynamics (CFD) software. The AES visions lab is supplied with the PowerFLOW CFD package; several members of the MADS team have used this software CU Integrated Teaching and Learning Laboratory (ITLL): Software packages such as Advanced Aircraft Analysis (AAA) and SolidWords are not available for public use but are available to AES students in the ITLL. Access to these resources will be instrumental for MADS engineering design and analysis CU Research and Engineering Center for Unmanned Vehicles (RECUV): RECUV will provide laboratory workspace in the Systems Integration Lab (SIL) in the Discovery Learning Center (DLC) RC Field: Operational flight tests for all MADS vehicle systems require approved air space for RC aircraft activities. The RECUV Table Mountain Flight Range, the Boulder RC Field, and the Arvada Associated Modelers airfield are available for use Wind Tunnel Testing Facility: The manufacturers of the primary vehicle generally do not release the aerodynamic and flight performance characteristics of their aircraft to the public. A large wind tunnel may be procured for experimental data to confirm the results of the CFD analysis. CPP (Cermak Peterka Petersen) Wind Engineering and Air Quality Consultants in Ft. Collins have 4 large wind tunnels and CFD software for testing purposes. The United States Air Force Academy and the University of Kansas (KU) also have large wind tunnels which may be utilized for testing purposes Additional Advisors Other RECUV and CU AES professionals such as Professor Brian Argrow and Professor Scott Palo also have knowledge relevant to the project. 12

13 Professor Dale Lawrence and Bill Pisano will be valuable contributors to the project, as they designed and built the CUPIC autopilot that will be used in the sub-vehicles Tom Aune, the RECUV RC-certified pilot, will be available for flight test of the primary vehicle in order to reduce flight test logistical issues and provide feedback regarding the handling quality of the PV Funds MADS will use the allotted $4000 standard AES department funding. A UROP proposal may also be submitted for additional monetary support, though the team does not anticipate that the project will require such auxiliary funding RECUV will provide financial support by providing materials. Three SIG Rascal 110 ARF kits will be provided for assembly, modification and spare parts purposes. Additionally, RECUV will provide GPS-integrated autopilot chips (CUPIC) for the SVs Acknowledgements 14.1 Professor Eric Frew Our customer has offered many hours in helping us develop our project goal and requirements as well as helping this team with its initial inception as a team for a helicopter design competition Professional Advisor Board The members of the PAB have provided constructive criticism, feedback, and guidance throughout project definition and development Sourcegear Vault Sourcegear donated eight licenses of their Vault software to help us manage our documentation and code. 13