ritedge.rit.edu/content/p07109/public/admin files...project 20006: yaw controlled, balloon tethered...
TRANSCRIPT
Preliminary Design Review 5/12/2006
R⋅I⋅T Multi-Disciplinary Senior Design Kate Gleason College of Engineering
Rochester Institute of Technology Rochester, New York
November 2005
Microsystems Engineering and Technology for the Exploration of Outer Regions
Project 20006: Yaw controlled, balloon tethered platform for METEOR Project
2005/2006 Team
Michael Giannotti (EE) – Rina Matoba (ME) Richard Paasch (ME) – Vivek Shah (EE)
Jennifer Indovina (EE)
Preliminary Design Review
November 2005 Project 06005
Project 06005 Page 1 of 93
Preliminary Design Review 5/12/2006
TABLE OF CONTENTS 1 Abstract......................................................................................................4 2 Introduction ...............................................................................................6 3 Objectives and Specifications ..................................................................7
3.1 Recognize and Quantify the Need ......................................................................... 7 4 Product Specification................................................................................8
4.1 Actuation System for Attitude and Location Control, ALC.................................. 8 4.2 Airborne Control Software, ACS........................................................................... 8 4.3 On Screen Telemetry Display, OSTD ................................................................... 8 4.4 Ground Control Software, GCS............................................................................. 8 4.5 Thermal Model and Analysis................................................................................. 9 4.6 Team Requirements ............................................................................................... 9 4.7 Stakeholders........................................................................................................... 9 4.8 Objectives ............................................................................................................ 10 4.9 Quarterly Gantt Charts......................................................................................... 11
5 Concept Development .............................................................................13 5.1 Actuation System for Attitude and Location Control, ALC................................ 13 5.2 Airborne Control Software, ACS......................................................................... 14 5.3 On Screen Telemetry Display, OSTD ................................................................. 17 5.4 Ground Control Software, GCS........................................................................... 18 5.5 Thermal Model and Analysis............................................................................... 19 5.6 System Diagram................................................................................................... 23 5.7 Launch Preparation Diagram ............................................................................... 24
6 Feasibility Analysis .................................................................................26 6.1 Limitations ........................................................................................................... 26 6.2 Pugh Analysis ...................................................................................................... 26 6.3 Quality Function Deployment.............................................................................. 30
7 Preliminary Analysis and Synthesis ......................................................36 7.1 Actuation System for Attitude and Location Control, ALC................................ 36 7.2 Airborne Control Software, ACS......................................................................... 38 7.3 On Screen Telemetry Display, OSTD ................................................................. 39 7.4 Ground Control Software, GCS........................................................................... 42 7.5 Thermal Model and Analysis............................................................................... 44
8 Conclusion................................................................................................48 9 Bibliography ............................................................................................49 10 Appendices ...........................................................................................50
10.1 Airborne Control Software (C source code) ........................................................ 50 10.2 Ground Control Software (C++ source code)...................................................... 50
10.2.1 DIJoystick.cpp ............................................................................................. 50 10.2.2 MeteorControl.cpp ....................................................................................... 73 10.2.3 MeteorControl.h........................................................................................... 75 10.2.4 MeteorControlDlg.cpp................................................................................. 76 10.2.5 MeteorControlDlg.h..................................................................................... 78
10.3 Bill of Materials (per launch)............................................................................... 80
Project 06005 Page 2 of 93
Preliminary Design Review 5/12/2006
10.4 Quality Function Deployment.............................................................................. 81 10.5 Pugh Charts.......................................................................................................... 86 10.6 Gantt Charts ......................................................................................................... 88 10.7 Functional Diagrams............................................................................................ 90 10.8 System Diagram................................................................................................... 91 10.9 Launch Preparation Diagram ............................................................................... 92
Project 06005 Page 3 of 93
Preliminary Design Review 5/12/2006
1 Abstract
METEOR is a university-based project, whose short-term goal is to launch and
place small payloads in low earth orbit, and whose long-term goal is to place such
payloads on near earth asteroids and lunar surfaces. Meteor is a hands-on, multi-phase,
multi-disciplinary, teaching and research program for investigating and developing
micro-systems engineering, science, and technologies for the exploration of outer
space.
This project will provide the RIT Engineering Department the ability to launch
small payload volumes for conducting micro-systems and other scientific experiments
into outer space. The Meteor Project will accommodate and promote multi-disciplinary
collaborations with the Electrical and Mechanical Engineering Departments. This
project also provides research opportunities for both undergraduate and graduate
students.
Figure 1.1 METEOR Platform/Pico-satellite Concept Launch, Courtesy of Project METEOR Concept Video, 2004
Project 06005 Page 4 of 93
Preliminary Design Review 5/12/2006
The METEOR Platform is a lightweight restructure that will be used to launch
satellites from already high altitudes. This means that the METEOR Platform is a cost
effective way to get payloads into space. Since the platform itself is lightweight, it can
be lifted into the upper troposphere using high altitude helium balloons and fall back
down to the surface of the Earth with a parachute system once its rocket/satellite
payload has been released. The retrievable platform will also be rebuilt with fewer off
the shelf components. Using custom built components will save money for the
resulting launches that will be required to test the propulsion system.
The image below represents what the design platform may look like at the end of
the Spring 2005-03 term. However, since the Propulsion system has not been built yet,
there might be changes during the build phase.
Figure 2.1 Possible Graphic Representation of the 2006 METEOR Platform
Project 06005 Page 5 of 93
Preliminary Design Review 5/12/2006
2 Introduction
The METEOR project is currently in its third phase, which consists of designing a
platform capable of reaching an altitude of about 100,000 feet utilizing helium filled,
high-altitude balloons. The successive designs of this platform will be the launching
point for future space bound missions. The design team is working on the program
through the Rochester Institute of Technology multi-disciplinary senior design project
and is composed of 5th year Electrical and Mechanical engineering students who are
enrolled in Senior Design I and II during the Fall 2005-01 and Spring 2005-03 quarters.
The subject matter that is incorporated in this phase of the design project includes
ground to platform radio communication, backup systems design, board layout
redesign, and an actuation system for attitude and location control of the platform.
Future work will include rocket, Pico-satellite, and space mission design.
Project 06005 Page 6 of 93
Preliminary Design Review 5/12/2006
3 Objectives and Specifications 3.1 Recognize and Quantify the Need
To exclude a 6-month Federal Aviation Administration (FAA) waiver application
process, the METEOR Platform below the balloon needs to weigh less than twelve
pounds. This however, does not include the weight of the future rocket appendages for
which the waiver will be required for other reasons.
The main design criteria for this years addition to the platform is as follows:
Custom hardware is to be included which will decrease weight and power consumption, perhaps a single board design to eliminate previous designs with over excessive wire usage.
A Thermal model will be created to ensure proper operation of all subsystems.
A Propulsion system will be attached to hull of the platform to control attitude
and rocket launch location.
Project 06005 Page 7 of 93
Preliminary Design Review 5/12/2006
4 Product Specification 4.1 Actuation System for Attitude and Location Control, ALC
The objective of the actuation system is to move the platform along the Earth’s
surface at 30 kilometers. The system will provide the future METEOR mission to have
safety features to guide the craft away from a populated area and assist mobile recovery
teams. Having this feature would allow confidence in our platform that it can safely fire
a rocket and allow the FAA to ease the weight restrictions our platform currently has.
4.2 Airborne Control Software, ACS
The primary function of the airborne control software is the idea of tracking the
platform in order to make it recoverable. Platform data such as the latitude, longitude,
altitude, speed, course, time, internal and external temperature, atmospheric pressure,
and acceleration in 3 axes are outputted two separate ways. The PIC outputs data to the
on screen display, which then transmits the data to the ground via the 70 cm band, and
the same data is also outputted in an APRS formatted packet to the TNC, which then
transmits the APRS formatted packet to the ground via the 2-meter band, so as to be
repeated in the APRS system.
4.3 On Screen Telemetry Display, OSTD
The redesigned OSD will have different parameters and guidelines than the original
OSD, thus it will be necessary to alter the current software to meet the specifications of
the different technology.
4.4 Ground Control Software, GCS
The objective of the ground control software is to provide manual control for the
propulsion system on the platform from the ground, and to allow the operator to have
full knowledge of the platform status during flight. This requires that the software use
some means for mechanical control, in this case a joystick, to interface with object-
oriented software and a graphical user interface. The interface itself will contain data
Project 06005 Page 8 of 93
Preliminary Design Review 5/12/2006
about the platform (such as internal and external temperatures), heading and speed, and
an orientation model of the platform, all within the GUI window. The GUI itself has
certain specifications that include:
Windows 98/2000 Operating System
Visual C++ .NET 6.0 Development Environment
UI View Software for Ground Control Monitoring
Microsoft Sidewinder Joystick
4.5 Thermal Model and Analysis
The thermal analysis model will contain the heat transfer information from the
platform, obtained during flight. Areas of the platform that will be observed include
external temperature, heat sources (circuit components), and radiation from the sun.
The number of holes in the platform hull will be considered in the 3D thermal model,
since the holes serve as a natural heat sink. However, comparison with actual data from
the launch will produce a better platform.
4.6 Team Requirements
The two previous senior student teams assigned to the METEOR Project have
designed and developed the platform up to the current version. The 2005/2006 Team will
develop the custom ground control software interface and GUI (GCS); customize the On
Screen Telemetry Display (OSTD); design a propeller based high altitude actuator
(ALC); create a thermal model of the platform; and the Airborne Control Software will
be extended to accommodate the system upgrades and changes (ACS).
This year’s team will not be required to have successful launches as part of the grade.
Only land-based testing of the individual subsystems is required by May 2006. However,
the Team has scheduled two launches in the Spring 2005-2006 term.
4.7 Stakeholders
Major stakeholders in the 2005/2006 METEOR Project include:
Project 06005 Page 9 of 93
Preliminary Design Review 5/12/2006
Dr. Dorin Patru, Team Mentor and Advisor
Dr. Robert Bowman and the Electrical Engineering Department, Project
Funding
Dr. Jeff Kozak, Mechanical Engineering Advisor
4.8 Objectives
The key goals of this term are to deliver a successful solution to the project needs
while respecting limitation, achieving schedule milestones, and limiting cost. The key
goals of the project are as follows:
Current budget of $2000.00
Design an integrated single board platform.
Platform is to have a total weight of less than 12 lbs (FAA regulations).
Design a lightweight transceiver with low power consumption.
Low power consumption is desirable so that fewer batteries are needed on the
platform, making the platform lighter.
Platform should be controlled from a ground station on demand, and it should
move a motor to change the position of the payload. The payload will
eventually be a rocket or a satellite.
Platform should reach an altitude higher than 30 kilometers (~100,000 feet),
and be stable for a certain period of time, at which the payload will perform its
purpose.
Platform should be 100% recoverable and reusable. This will reduce the cost of
rocket or satellite launching, by having a reusable launch pad that is inexpensive to use.
Project 06005 Page 10 of 93
Preliminary Design Review 5/12/2006
4.9 Quarterly Gantt Charts
Week 6 Week 7 Week 8 Week 9 Week 10Mike Code Reasearch METEOR 3 Launch METEOR 2005 Research PDR
CANCELLED Code ReasearchPeer Review
Vivek GPS research METEOR 3 Launch PDRCANCELLED 70cm Tx Research
Peer ReviewJennifer Basic GUI base METEOR 3 Launch Continue designing window PDR
Joystick and axis map CANCELLED Joystick applicationPeer Review
Rina Software research METEOR 3 Launch PDRTemperature Modeling CANCELLED Temperature ModelingPeer Review
Rich Determine reqs METEOR 3 Launch PDRfor propellor design CANCELLED Rotor Software SearchPeer Review
Fall 2005
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Team Add code to software to integrate Verify
Meeting GUI, joystick, propeller motor, backup GPS PDRChanges
Vivek Team VerifyMeeting Update Documentation for PDR PDR
PCB Express Layout/Board Redesign ChangesJennifer Team Verify
Meeting Redo PDR Documentation PDRChanges
Rina Team VerifyMeeting Review new software PDR
ChangesRich Team Verify
Meeting Learn XROTOR Software PDRChanges
Winter 2005
Project 06005 Page 11 of 93
Preliminary Design Review 5/12/2006
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Continue integration Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results
Launch Repair Platform Launch Documentation CDRAssist w/ assembly Rebuild Platform
Vivek Begin assembly Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultsof platform for launch Launch Repair Platform Launch Documentation CDR
Rebuild PlatformJennifer Integrate software Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results
with ACS Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly
Rina Testing METEOR 3 Document Temp Data Testing METEOR 4 Review ResultsFluent / MATLAB Launch ANSYS Thermal Modeling Launch Documentation CDR
Rich Review software and Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultstest with motors Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly
Spring 2005
Project 06005 Page 12 of 93
Preliminary Design Review 5/12/2006
5 Concept Development 5.1 Actuation System for Attitude and Location Control, ALC
Development of a propulsion system to control the attitude and location of the
platform requires more than one concept for consideration. The first is concept
considered is a direct current brush-less motor driven propeller. The second concept is
using a gas turbine propulsion unit, similar to the picture shown below.
(i) (ii)
Figure 3.1.1(i) Gas turbine on test stand (ii) Gas turbine mounted on model airplane
Courtesy of Tower Hobbies
The advantages of a gas turbine are that it would provide the most thrust compared
to the propeller, somewhere between 100 and 100,000 pounds of thrust (lbst.). However,
their weight ranges from 30-20,000 pounds (lbs.) making this an impossible choice for the
METEOR platform. A propeller at the target altitude of METEOR has very little air
density, therefore provides little thrust. A DC motor has an almost immediate response.
The propeller is the obvious choice due to its simplicity and ability to be designed and
constructed at RIT.
Project 06005 Page 13 of 93
Preliminary Design Review 5/12/2006
5.2 Airborne Control Software, ACS
The Airborne Control Software (ACS) is responsible for coordinating the operation
of the PIC micro controller on the METEOR platform. The PIC allows for data links to
be made between the data transceiver and the different sensors and components in the
platform. The flow diagram of the software’s main loop is displayed in Figure 5.2.1.
Project 06005 Page 14 of 93
Preliminary Design Review 5/12/2006
Figure 5.2.1: Software Main Loop Flow Diagram Original Version, Courtesy of METEOR Team 2004/2005
Project 06005 Page 15 of 93
Preliminary Design Review 5/12/2006
The interrupt sequence for the ACS allows the main loop to be broken and specific commands sent from the ground to be implemented.
Figure 5.2.2: Software Interrupt Flow Diagram
Project 06005 Page 16 of 93
Preliminary Design Review 5/12/2006
5.3 On Screen Telemetry Display, OSTD
The METEOR platform has four video cameras that are used by the ground control
team to monitor conditions around the METEOR platform. The 2005 METEOR team
used video overlay board to be able to overlay environmental and location data gathered
by the PIC onto the video stream from the video camera, before it is transmitted to the
ground station via the 70-cm radio transmitter. A block diagram of the video overlay
board is provided in Figure 5.3.1.
Figure 5.3.1: Block Diagram of OSD Design
The video overlay board was designed by Intuitive Circuits LLC and priced at
$99.00. A goal for the METEOR 2006 team is to reverse engineer the Intuitive Circuits
design such that the circuit can be built by the METEOR team, or to create a new design
of a video overlay board.
The inputs to the OSD System are the overlay text data and the composite video
input. The composite video input is a 1V peak-to-peak input signal containing sync data
and video data. The text overlay data can be sent via an RS-232 bus, I2C bus, or via a
UART. The output should be a 1V peak-to-peak composite video signal with 75Ω
impedance. In the new design component values also need to be chosen such that the
quality and performance specifications of the new design are as good, or better than the
Intuitive Circuits LLC design.
Three different types of On-Screen display systems were found. The first type is a
video amplifier system with a built in OSD. Its main purpose is to amplify RGB video
signals, and was designed for operation with devices such as computer monitors. The
second type is a TV microcontroller with a built in OSD. This type of system is built for
PIC Text Overlay Data
OSD Composite Video Output System
Composite Video Input
Project 06005 Page 17 of 93
Preliminary Design Review 5/12/2006
working with basic analog TV’s and can be made to take inputs from various devices that
interface with TV’s such as remote controls. Its main purpose is to take a composite
video signal from a 75Ω television cable overlay the data and provide an output in RGB
format. The final integrated circuit is one whose primary purpose is the OSD, and has no
other extra features. This system can take inputs from up to 8 composite video sources,
and provides outputs for up to 8 sources. The OSD characters that this system accepts
need to be stored into a memory, and the characters that are stored in the memory are
inputted by a microcontroller that communicates with the OSD.
If either the video amplifier system or TV microcontroller are used, then additional
components are needed for conversion between the RGB format to/from the specified
NTSC format. A video decoder can be used to convert the NTSC signal to an RGB
signal to obtain the required inputs for the video amplifier system. A video encoder
could be used on the outputs of both the video amplifier OSD and the TV
microcontroller. Although the standalone OSD would not need either of these two
components, an external 16Mb SDRAM is needed to store the OSD character
information.
5.4 Ground Control Software, GCS
The previous teams did not have a redundant method of storing flight data from the
platform. The new ground control software will allow the mission controller to remain
equipped with platform condition information throughout the launch, mission, and
recovery periods. The image in Figure 5.4.1 represents the functional diagram of the
software to hardware interface between the motors and ground control software.
Project 06005 Page 18 of 93
Preliminary Design Review 5/12/2006
Figure 5.4.1 Block Diagram of Ground Control Software
5.5 Thermal Model and Analysis
As the platform ascends through the atmosphere forced convection will occur on the
surface of the platform and free (otherwise known as natural) convection will occur
inside the platform. The heat created from circuit components will be conducted through
the platform and will increase the internal temperature.
Thermal model analysis will help future developments of the platform to be more
efficient in dispersing heat. Examples of the model were created to scale of the METEOR
Platform in two views of the cross section of the platform in 2D (time dependent in the
animation):
Closed platform without heat source (Figure 5.4.1, 2, 3) Closed platform with heat source (Figure 5.4.4, 5, 6)
Figure 5.4.1: Temperature model of the platform without heat source
Project 06005 Page 19 of 93
Preliminary Design Review 5/12/2006
Figure 5.4.2: Thermal gradient model of the platform without heat source (vector plot)
Figure 5.4.3: Thermal flux model of the platform without heat sources (element solution)
Project 06005 Page 20 of 93
Preliminary Design Review 5/12/2006
Figure 5.4.4: Temperature model of the platform with heat source (nodal solution)
Figure 5.4.5: Thermal gradient model of the platform with heat source (nodal solution)
Project 06005 Page 21 of 93
Preliminary Design Review 5/12/2006
Figure 5.5.6: Thermal flux model of the platform with heat source (nodal solution)
Project 06005 Page 22 of 93
Preliminary Design Review 5/12/2006
5.6 System Diagram
Motor
Actuator(Propeller)
70-cm Tx439.25 MHz
Video Overlay
Video Camera 1
GPS(Harris)
2 Internal Temp
Sensors
Pressure Sensor
3 Accelerometers
Digital Compass
RS232
/ 2Analog
TTL
RS232
Analog
/ 3Analog
Beacon
MAX232(RS232 Driver)
TTL
RS232
RS232
VIDEO MUX
Video Camera 2
Video Camera 3
Video Camera 4
DUAL UART MUX
TTL TTL
PIC
ADC
/ 3Select Lines
/ 3Select Lines
DEMUX
Power Control
2-m Tx/Rx
RTS Signal
TTL
/ 2Analog
2 External Temp
Sensors
TNCDuplexer
Analog Compass
Composite
Digital Compass
/ 4N S E W
Analog
Composite
Composite
Composite
Composite
/ 3Select Lines
GPS(Tyco)
FM Tx144.39 MHz
RS232 Driver
TTL
RS232
TNC
Tones
TTL
Driver(Joystick
Coordinates from 2-m Tx/Rx to PIC)
Photovoltaic Cells,
DC to DC Converter
Figure 5.6.1: System Diagram
Project 06005 Page 23 of 93
Preliminary Design Review 5/12/2006
The complete system flow diagram for this year’s platform design is located in the
figure above. The system flow diagram shows the connections between the external
platform components, software, and communication.
5.7 Launch Preparation Diagram
Many of the launch protocols were defined during the previous METEOR Teams
successful launches. These protocols have only been slightly altered. In order to have a
quicker retrieval time a second Mobile Command Station has been built and will be
tested during the METEOR III Launch. The plan is to use the same two-station design for
METEOR IV also. Reference the Mobile Command Diagrams in the figures in the
Appendix section.
Reference the Launch Preparation Flow Chart below, since it is the responsibility of
the Ground Control Operator to keep a mission on the pre-approved time schedule.
Project 06005 Page 24 of 93
Preliminary Design Review 5/12/2006
Figure 5.7.1: Launch Protocol Time Schedule and Diagram Also available in Appendix
Project 06005 Page 25 of 93
Preliminary Design Review 5/12/2006
6 Feasibility Analysis 6.1 Limitations
The limitations associated with this project are made clear using the Pugh Method of
analysis and comparison. The results of the analysis are located in the subsequent section.
The tables use a numerical base of 1 to relate characteristics of performance and
usability.
The QFD Analysis weighs the similarities between specifications and requirements in
order to relate the order of importance of tasks required for the project to be successful.
The major limitations associated with this project are:
FAA regulations (flight time, duration, location, and weight of platform)
Power consumption
Successful communications between the platform and ground control
Successful ground tests of the ALC
6.2 Pugh Analysis
CriteriaImportance
RankingWeighted Ranking
Visual C++ Studio .NET JAVA
Visual Basic IDE
Purchase Cost 7 0.1061 0.1061 0.1061 0.1061Operating Cost 7 0.1061 0.1061 0.1061 0.1061Cycle Time 10 0.1515 0.1515 0.0606 0.0303Mean time between failures 7 0.1061 0.1212 0.0909 0.1364Operating Time 10 0.1515 0.1515 0.0758 0.1061Constant operation 4 0.0606 0.0606 0.0758 0.0303
Mean Time to repair 7 0.1061 0.0909 0.0455 0.0606Current system compatibility 10 0.1515 0.1515 0.1212 0.1000Startup time 4 0.0606 0.0455 0.0152 0.0455Best Option based on weighted Criteria 1.0000 0.9848 0.6970 0.7212
Figure 6.3.1: Pugh Analysis for Ground Control Software (GCS)
Project 06005 Page 26 of 93
Preliminary Design Review 5/12/2006
Figure 6.3.2: Radar Chart Analysis for Ground Control Software (GCS)
CriteriaImportance
RankingWeighted Ranking
Single Propeller
Gas Turbine
Purchase Cost 8 0.1096 0.0959 0.0959Operating Cost 7 0.0959 0.0959 0.0959Response Time 10 0.1370 0.1370 0.0548Failure Time 9 0.1233 0.1096 0.0822Operating Time 10 0.1370 0.1370 0.0685Constant operation 8 0.1096 0.0548 0.0685Mean Time to repair 7 0.0959 0.0822 0.0411Current system compatibility 10 0.1370 0.1370 0.1096Startup time 4 0.0548 0.0411 0.0137Best Option based on weighted Criteria 1.0000 0.8904 0.6301
Visual C++ .NET Pugh Analysis
0.0000
0.0500
0.1000
0.1500
0.2000Purchase Cost
Operating Cost
Cycle Time
Mean time betw een failures
Operating TimeConstant operation
Mean Time to repair
Current system compatibility
Startup time
Visual C++ Studio .NET
JAVA
Visual Basic IDE
Figure 6.3.3: Pugh Analysis for Actuation System Attitude and Location Control (ALC)
Project 06005 Page 27 of 93
Preliminary Design Review 5/12/2006
Single Propeller Design Pugh Analysis
0.0000
0.0500
0.1000
0.1500Purchase Cost
Operating Cost
Response Time
Failure Time
Operating TimeConstant operation
Mean Time to repair
Current system compatibility
Startup time
Single PropellerGas Turbine
Figure 6.3.4: Radar Chart for Actuation System Attitude and Location System (ALC)
CriteriaImportance
RankingWeighted Ranking ANSYS ProE
System Stability 8 0.1290 0.1129 0.1129Ease of Use 7 0.1129 0.1129 0.1129Thermal Modeling Capability 10 0.1613 0.1613 0.0645Thermal Model 9 0.1452 0.1290 0.0968Correct results 10 0.1613 0.1613 0.0806Constant operation 8 0.1290 0.0645 0.0806
Mean Time to repair 7 0.1129 0.0968 0.0484Current system compatibility 1 0.0161 0.0161 0.1290Startup time 2 0.0323 0.0323 0.0161Best Option based on weighted Criteria 1.0000 0.8871 0.7419
Figure 6.3.5: Pugh Analysis for Thermal Model Software Comparison
Project 06005 Page 28 of 93
Preliminary Design Review 5/12/2006
Figure 6.3.6: Radar Chart for Thermal Model Software Comparison
Figure 6.3.7: Pugh Analysis for On Screen Telemetry Display
Thermal Model Pugh Analysis
0.0000
0.0500
0.1000
0.1500
0.2000System Stability
Ease of Use
Thermal Modeling Capability
Thermal Model
Correct resultsConstant operation
Mean Time to repair
Current system compatibility
Startup time
ANSYSProE
CriteriaImportance
RankingWeighted Ranking
Video Amplifier
OSDµC with
OSDOSD Video Generator
Purchase Cost 10 0.1493 0.1493 0.0746 0.0299Operating Cost 5 0.0746 0.0746 0.0896 0.0746Response Time 4 0.0597 0.0448 0.0597 0.0597Failure Time 10 0.1493 0.1343 0.1493 0.1343Operating Time 5 0.0746 0.0448 0.0597 0.0746Constant operation 10 0.1493 0.1493 0.1493 0.1493
Mean Time to repair 8 0.1194 0.0896 0.1045 0.0896Current system compatibility 10 0.1493 0.0746 0.1045 0.0746Startup time 5 0.0746 0.0746 0.0746 0.0746Best Option based on weighted Criteria 1.0000 0.8358 0.8657 0.7612
Project 06005 Page 29 of 93
Preliminary Design Review 5/12/2006
Pugh Analysis of the On Screen Telemetry Display
0.0000
0.0200
0.0400
0.0600
0.0800
0.1000
0.1200
0.1400
0.1600Purchase Cost
Operating Cost
Response Time
Failure Time
Operating TimeConstant operation
Mean Time to repair
Current system compatibility
Startup time
Weighted RankingVideo Amplifier OSDµC with OSDOSD Video Generator
Figure 6.3.8: Radar Chart for On Screen Telemetry Display
.3 Quality Function Deployment
Due to the complex nature of this Senior Design Project, the Quality Function
De
6
ployment (QFD) has been separated to reflect each member’s contribution to the
design effort. Tasks such as launch preparation and testing are the responsibility of the
entire team, and therefore not represented in the individual QFD's.
Project 06005 Page 30 of 93
Preliminary Design Review 5/12/2006
Richard Paasch
Tasks
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~1
00 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
spe
ed (s
ampl
e ev
ery
30 s
econ
ds)
Pla
tform
sha
ll be
abl
e to
mov
e/re
posi
tion
itsel
f with
in
0.5
met
ers
of m
ax h
eigh
t
Mot
or p
ower
con
sum
ptio
n w
ill b
e 5
mill
iam
ps fo
r no
mor
e th
an m
ax. f
light
dur
atio
n
Mot
or p
ower
sha
ll be
sup
plie
d by
bat
terie
s
Pla
tform
sha
ll by
abl
e to
repo
sitio
n in
self
with
in 0
.5
met
ers
Pla
tform
sha
ll be
abl
e to
pos
ition
itse
lf us
ing
prop
elle
rs
with
a m
inim
um s
peed
of 1
0 m
/sec
for 1
20 m
ins
Pla
tform
will
with
stan
d la
ndin
g ve
loci
ty o
f x m
/sec
Pla
tform
sha
ll be
retri
evab
le o
n an
y te
rrai
n or
alti
tude
Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 0 9 9 0 0 0Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 7 0 0 7 9 0
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0 0 0 9Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 0 0 0 0 0Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 0 7 0 0 7Platform shall be reusable 9 3 0 0 0 0 0 7 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 9 7 7 9 9 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 7 9 9 7 7 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0 0 0 0Pre-flight Ground Station operator 0 3 3 3 0 0 5 0 0 0 0Flight Ground Station operator 4 3 3 3 0 9 0 0 9 9 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0 0 0 5Ground Station data server Analyst 4 3 3 3 0 0 0 0 0 0 0
Specifications
0
0
8
000
0
000070
Project 06005 Page 31 of 93
Preliminary Design Review 5/12/2006
Michael Giannotti
Tasks
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~10
0 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be a
ble
to d
eter
min
e in
stan
tane
ous
plat
form
sp
eed
(sam
ple
ever
y 30
sec
onds
)
Pla
tform
will
con
tinuo
usly
con
sum
e ~3
00 m
a fo
r 15
hour
s
Bat
tery
con
sum
ptio
n w
ill be
less
than
x a
mp-
min
s
All
anal
og d
ata
will
be c
onve
rted
to d
igita
l with
x re
solu
tion
and
sam
pled
eve
ry x
mse
c
Pla
tform
sha
ll tra
nsm
it au
dibl
e an
d vi
sibl
e la
ndin
g po
sitio
n fo
r 100
mile
s
Mot
or C
ontro
ller w
ill ne
ed to
sup
ply
pow
er a
t x m
illia
mps
to
a m
otor
at 1
x R
PM
s
Pla
tform
will
be
able
to s
tore
1 k
byte
s of
dat
a if
data
tra
nsm
issi
on is
lost
Pla
tform
sha
ll tra
nsm
it w
hen
the
plat
form
mem
ory
buffe
r be
com
es 9
0% fu
ll
Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 5 2 6 2 0 4 9Platform shall be able to reach height and land 0 0 0 0 0 5 0 0 0 0 3 6Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 5 7 3 7 5 5 8Platform shall warn pedestrians upon re-entry 0 9 0 9 0 1 9 0 9 0 0 6
Platform shall disclose its position throughout the flight, re-entry and on ground 2 9 8 9 0 0 9 8 9 0 5 6
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 4 7 0 7 1 4 0Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 4 7 8 3 3 4 5Ground Station will be able to transmit commands to Platform 4 7 8 8 0 5 7 8 8 0 5 6
Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 5 7 9 8 3 5 8
Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 7 6 8 1 0 5
Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 0 7 6 8 0 0 5Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 2 9 9 8 4 9 9Platform shall transmit all flight data 9 9 9 8 0 5 9 9 8 0 9 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 5 7 1 8 0 5 9Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 4 0 0 0 0 4 4Platform will illuminate during re-entry 5 9 0 8 0 3 9 0 8 0 3 7Platform shall be reusable 9 3 0 0 0 0 3 0 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 7 5 0 2 5
Specifications
Project 06005 Page 32 of 93
Preliminary Design Review 5/12/2006
Vivek Shah
Tasks
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~1
00 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
spe
ed (s
ampl
e ev
ery
30 s
econ
ds)
Pla
tform
sha
ll tra
nsm
it its
land
ing
with
in 2
0 m
eter
s fo
r 10
0 m
eter
dis
tanc
e
GP
S d
ata
gath
erin
g, s
tora
ge, a
nd tr
ansm
issi
on,
seco
ndar
y
LED
Fla
shin
g C
ircui
try/T
empe
ratu
re S
enso
r/Com
pass
OS
D-G
PS
Tex
t ove
rlay
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 5 0Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0 0Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 0 0
Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 2 9 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 9 0Platform shall transmit all flight data 9 9 9 8 0 0 0 5Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 0 9 9Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 2 0Platform will illuminate during re-entry 5 9 0 8 0 0 0 9Platform shall be reusable 9 3 0 0 0 0 0 9during flight. 6 6 7 8 1 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 6 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 0 0 7Pre-flight Ground Station operator 0 3 3 3 0 0 0 0Flight Ground Station operator 4 3 3 3 0 0 0 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0Ground Station data server Analyst 4 3 3 3 0 0 0 0
Specifications
0
90
90
0
09
00090
0
0920000
Project 06005 Page 33 of 93
Preliminary Design Review 5/12/2006
Rina Matoba
Tasks
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~10
0 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
sp
eed
(sam
ple
ever
y 30
sec
onds
)
Sim
ulat
ion
resu
lts to
impa
ct d
esig
n
Tem
pera
ture
of e
lect
roni
cs s
hall
not e
xcee
d x
degr
ees
Def
ine
fligh
t the
rmo
sens
ors
to m
onito
r and
trac
k
Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 9 9Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 0Platform shall transmit all flight data 9 9 9 8 0 8 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0Platform shall be reusable 9 3 0 0 0 0 0Thermo-characteristics will be modeled during design and then measured during flight. 6 6 7 8 1 9 9
Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 0
Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0Radiation (i.e. heat build-up) will be measured during flight. 6 9 7 8 0 8 8Temperature Sensor monitoring internal and external temperatures (~20 C) 6 9 7 8 0 7 9
Specifications
80
0
07
0
9
0
08
8
Project 06005 Page 34 of 93
Preliminary Design Review 5/12/2006
Jennifer Indovina, Team Leader
Tasks
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~10
0 m
iles
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
sp
eed
(sam
ple
ever
y 30
sec
onds
)
Pla
tform
sha
ll tra
nsm
it au
dibl
e an
d vi
sibl
e la
ndin
g po
sitio
n fo
r 100
mile
s
Pla
tform
will
be
able
to s
tore
1 k
byte
s of
dat
a if
data
tra
nsm
issi
on is
lost
Pla
tform
sha
ll tra
nsm
it w
hen
the
plat
form
mem
ory
buffe
r be
com
es 9
0% fu
ll
Pla
tform
sha
ll tra
nsm
it its
land
ing
with
in 2
0 m
eter
s fo
r 100
m
eter
dis
tanc
e
Pla
tform
sha
ll be
retri
evab
le o
n an
y te
rrain
or a
ltitu
de
Gro
und
Con
trol s
oftw
are
- GU
I, flo
wch
art,
tele
met
ry d
ispl
ay,
and
long
term
sto
rage
Gro
und
cont
rol t
rans
mis
sion
sha
ll ha
ve a
rang
e of
x m
iles
Pla
tform
sha
ll tra
nsm
it ev
ery
~30
seco
nds
Platform shall remain powered and functional for the duration of the flight 9 6 0 2 4 9 5 0 3 3Platform shall be able to reach height and land 0 0 0 0 3 6 0 0 9 8Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 3 5 7 5 8 0 0 6 4Platform shall warn pedestrians upon re-entry 0 0 0 9 0 6 0 0 0 5Platform shall disclose its position throughout the flight, re-entry and on ground 2 8 0 9 5 6 9 9 8 3
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 0 1 7 4 0 0 8 7 8Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 8 3 3 4 5 0 0 7 9
Ground Station will be able to transmit commands to Platform 4 8 0 8 5 6 0 0 9 5Platform will be able to transmit to Ground Station real time video and digital data 4 9 3 8 5 8 0 0 9 5Platform electronics will apply standard interface protocols (i.e. USB) 4 6 1 8 0 5 0 0 9 5
Platform will ensure reliable operation and apply redundant circuitry where necessary 0 6 0 8 0 5 2 0 0 0
Platform shall store critical flight telemetry data until data transmission occurs 0 9 4 8 9 9 0 0 6 3Platform shall transmit all flight data 9 9 0 8 9 9 0 0 8 4Platform shall operate autonomously if communications with Ground Station is lost 4 1 0 8 5 9 0 0 0 5Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 4 4 0 0 0 0Platform will illuminate during re-entry 5 0 0 8 3 7 0 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 7 1 8 2 2 0 0 9 7Non-integrated beacon sucessful in platform retrieval 5 7 0 5 2 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 5 0 0 0 0Pre-flight Ground Station operator 0 3 0 3 9 0 0 0 9 9Flight Ground Station operator 4 3 0 3 9 5 0 0 9 8Post-flight Ground Station operator 4 3 0 3 6 0 0 7 9 9Ground Station data server Analyst 4 3 0 3 6 6 0 0 9 8pedestrians at landing zone 0 0 0 0 2 0 6 0 4 0Land owner at landing zone 0 0 0 0 2 0 0 0 1 0Chasers 4 0 0 0 5 0 6 0 1 3FAA Analyst (if pre-flight approval is needed) 0 0 0 0 0 0 0 0 1 0Equipment Transporters 0 0 0 0 6 0 0 0 1 0
Specifications
56
24
9
7
9
9
8
8
0
77
000
700444400020
Project 06005 Page 35 of 93
Preliminary Design Review 5/12/2006
7 Preliminary Analysis and Synthesis 7.1 Actuation System for Attitude and Location Control, ALC
Drag force is defined “the aerodynamic force that opposes an aircraft's motion through the air. ” Or simply by the equation:
DD CSVF 2
21
∞∞= ρ (Equation 1)
Before finding out the drag, Reynolds’s number must be determined:
∞
∞∞=µ
ρ dVRe (Equation 2)
The drag coefficient in Equation 1 is dependent on Reynolds’s number:
Figure 7.1.1: Drag coefficient for a uniform flow over a sphere as a function of the Reynold’s number Experimental data from Schlichting (1979), Achenbach (1972) and Maxworthy (1969)
If we go by Achenbach’s approximation, then the drag coefficient can be assumed to be 0.5.
Project 06005 Page 36 of 93
Preliminary Design Review 5/12/2006
Drag Force vs. Velocity
0
20
40
60
80
100
120
0 5 10 15 20 25Velocity (m/s)
Dra
g Fo
rce
(N)
Figure 7.1.2: Drag Force and Velocity Relationship
Note: This is the drag created by the balloon. Analysis of the parachute, box and
rocket will be ignored since their cross sectional area is very small compared to the balloon and will not create much drag.
Atmospheric Conditions
The National Oceanic & Atmospheric Administration (NOAA) supplies data of atmospheric conditions. While they do have data on wind speed, it is only up to ~14 kilometers (48,000 feet.)
Figure 7.1.3: Altitude and Wind Speed Relationship (meters vs. knots)
Project 06005 Page 37 of 93
Preliminary Design Review 5/12/2006
This is a graph showing the altitude versus wind speed taken over Riverton,
Wyoming in an August 2001 weather balloon launch. While wind speeds vary over
different regions of the Earth, this graph shows wind speed can get as much as ~15 knots
(~17.26 mph or ~7.71 m/s.) It is also evident that wind speeds vary from season to season
depending on the region. Since there is no data over the wind speed in our, an assumption
can be made that the platform can experience wind speeds close to these figures.
If the worst-case scenario were assumed of having a wind speed in the upper
atmosphere of 7.71 m/s, this would give us a drag force of roughly 10.3 Newtons (2.32
pounds.)
It has been decided that the propeller design will be done with XROTOR software.
The XROTOR software allows the designer to model and synthesize designs of
propellers.
7.2 Airborne Control Software, ACS
Accurately extending the existing software program is a crucial task in the process
of obtaining proper functionality from new components. The main program file
(meteor.c) and header file (meteor.h) are neatly programmed and commented, which
simplifies the act of troubleshooting and lengthening the code.
Components being added to the system include a propulsion system, a custom
GPS unit, a ground control interface, and a redesigned OSD. A flow diagram of the PIC
is displayed below.
Project 06005 Page 38 of 93
Preliminary Design Review 5/12/2006
2 Internal Temp
Sensors
Pressure Sensor
3 Accelerometers
OO
PIC
ADC
O
2 External Temp
Sensors
Analog Compass
O
Tx/Rx
TNC
OSD
Video MUXCameras
Video Tx
GPS(Harris)
UART MUX//
//
X
*
**
*
Propeller Motor Driver
(Joystick Coordinates from Tx/Rx to PIC)
Digital Compass
\\
RS232 DriverO
O
TNC Interrupt
*
Digital Compass
O
*
X
X
Demux X
X
Legend
O Sensor Data // Video Signal X Telemetry * Digital Data
\\ Motor Control
O
\\
X X
X
Figure 7.2.1: PIC Microcontroller Flow Diagram
The on-board computer PIC18F2680 microcontroller and is able to maintain data
links between the data transceiver and the different sensors and components in the
platform. As the project becomes more complex, and includes more sensors and
actuators, the microcontroller should be able to keep an active link to all new
components. Using different interfaces the new microcontroller should be able to support
all the interfaces that are needed.
7.3 On Screen Telemetry Display, OSTD
The SAA55XX microcontroller with OSD was chosen and a schematic for the system
was created. The block diagram of the OSD system is provided in Figure 7.3.1.
Project 06005 Page 39 of 93
Preliminary Design Review 5/12/2006
PIC Text &
Figure 7.3.1: Block Diagram of the OSD System
The three main components of this system are the SAA55XX microcontroller, the
AD723 RGB to NTSC video encoder, and the EL1883 video sync separator. Currently
many of the features of the microcontroller are not being used such as its various I/O
ports, and one of the I2C ports, but the PCB design of the system will make these ports
available to the outside in case the design changes and the need for these ports arise. The
video input is directly fed into a Chroma Filter, which is basically a low pass filter with a
cut off at 0.5MHz. This filter helps increase the signal-to-noise ratio of the composite-
video input, which is good to have especially for systems with space applications. The
output of the filter is sent to both the EL1883 sync separator and to the microcontroller.
The second input is an I2C data input and I2C clock that comes from the main computer
and provides the OSD data to be displayed over the video. The sync separator outputs
are composite sync, vertical sync, and horizontal sync. The composite sync output is not
used, and is thus left floating. The other two outputs are necessary for both the AD723
video encoder and the microcontroller. The RGB output of the microcontroller is fed
directly to the video encoder. The encoder then converts the RGB information into a
CVBS (color, video, and blanking signal) or composite video signal.
The design of the actual circuit requires other components such as passive devices
and clocks. The schematic is given below in Figure 7.3.2.
Clock Data
Composite Video Input
Composite Video Output
Microcontroller SAA55XX
RGB to NTSC Video Encoder AD723
Vertical Sync Separator EL1883
Chroma Filter
2 R
G B
HSYNC VSYNC
Project 06005 Page 40 of 93
Preliminary Design Review 5/12/2006
Figure 7.3.2: Schematic of the OSD System
One thing to note in the schematic is with the AD723. Along with the CVBS output
there are also luminance and chrominance outputs, which are not left floating. This is
done because the AD723 cannot operate with those outputs floating, even if the outputs
are not in use. The AD723 does have smart sensing to determine which of the outputs are
being used and limits the current outputs of the luminance and chrominance outputs
which are not in use. Two clocks are needed for this circuit, a 12MHz clock for the
microcontroller, and a 14.31818MHz clock for the AD723. Both clocks are readily
available and can be found on Digi-Key.
The EL1883 and AD723 are designed to operate at temperatures between -40°C and
80°C. The SAA55XX is designed to operate between 0°C and 70°C. The clocks have
also been chosen to operate between 0°C and 70°C. The overall design should be able to
work on a single 3.3V power supply between the temperature ranges of 0°C and 70°C.
Project 06005 Page 41 of 93
Preliminary Design Review 5/12/2006
7.4 Ground Control Software, GCS
The ground control software allows the person monitoring the platform at high
altitudes to send commands to the platform and operate joystick control of the
propeller based propulsion system, from the ground. Consisting of a graphical user
interface (GUI), joystick interface, joystick hardware, and the already utilized software
package UI View; the platform will be better controlled from the mission control
operator in the mobile command station.
Create Visual Window Object
display temp, pressure, heading
refresh PIC
get PIC stream data
0
1
display joystick data in window
joystick connection
get joystick data
joystick.c
Create Visual Window Object
send joystick position to motors
motors get data
send motor coordinates
check motor position
1
0
1
0
1
0
Figure 3.2.1: Ground Control Software Flow Chart
Project 06005 Page 42 of 93
Preliminary Design Review 5/12/2006
The METEOR Platform radio call sign is KCGXT-7. Since the ground control
operator is required to operate UI View to track the platform, amateur radio licensing is
mandatory.
The graphical user interface will be designed and implemented using C++ in the
Microsoft Visual Studio .NET development environment. This is a required system,
since the joystick and mobile command laptops are Microsoft compatible. Also, the
ACS software is written in C, choosing a C++ GUI will help make the portability of
information between the platform and the GUI simple. Figure 7.4.1 is of the current
GUI design, demonstrating the ability to control a joystick. The GUI will eventually
also be able to accept strings of data from the processor on the platform, utilizing the
ACS-GUI C structure.
Figure 7.4.1 Current Design of Ground Control Graphical User Interface
Project 06005 Page 43 of 93
Preliminary Design Review 5/12/2006
7.5 Thermal Model and Analysis
The thermal analysis of the platform allows us to observe the thermal model of the
platform throughout the launch. However, in ANSYS the time dependent heat transfer
model is observed at sea level, not as ascending through the atmosphere.
The animation of the transient thermal model does not show exactly how heat
transfer will occur throughout actual launching since there are differences in change of
temperature and density at the level of altitude in the air. Therefore comparing the actual
data and the result from ANSYS is necessary for more accurate observation.
Project 06005 Page 44 of 93
Preliminary Design Review 5/12/2006
Properties of the U.S. standard atmosphere
External
Temperature Time Altitude Density
Thermal
Conductivity
Specific
Heat
K ˚C s min m ft Kg/m3 W/m K J/kg K
288.15 15.0 0 0 0 0.0 1.221 25.35 1006.8
284.90 11.8 125 2 500 1640.4 1.165 25.09 1006.7
281.65 8.5 250 4 1000 3280.8 1.108 24.83 1006.6
275.15 2.0 500 8 2000 6561.7 1.005 24.31 1006.5
268.65 -4.5 750 13 3000 9842.5 0.907 23.79 1006.4
262.15 -11.0 1000 17 4000 13123.4 0.814 23.27 1006.2
255.65 -17.5 1250 21 5000 16404.2 0.732 22.75 1006.1
249.15 -24.0 1500 25 6000 19685.0 0.660 22.23 1006.0
242.65 -30.5 1750 29 7000 22965.9 0.588 21.68 1006.1
236.15 -37.0 2000 33 8000 26246.7 0.521 21.14 1006.3
229.65 -43.5 2250 38 9000 29527.6 0.464 20.59 1006.4
223.15 -50.0 2500 42 10000 32808.4 0.412 20.04 1006.5
216.65 -56.5 5000 83 20000 65616.8 0.088 19.50 1006.7
217.65 -55.5 5250 88 21000 68897.6 0.072 19.58 1006.6
218.65 -54.5 5500 92 22000 72178.5 0.062 19.67 1006.6
219.65 -53.5 5750 96 23000 75459.3 0.052 19.75 1006.6
220.65 -52.5 6000 100 24000 78740.2 0.041 19.83 1006.6
221.65 -51.5 6250 104 25000 82021.0 0.036 19.92 1006.6
222.65 -50.5 6500 108 26000 85301.8 0.031 20.00 1006.5
223.65 -49.5 6750 113 27000 88582.7 0.026 20.09 1006.5
224.65 -48.5 7000 117 28000 91863.5 0.021 20.17 1006.5
225.65 -47.5 7250 121 29000 95144.4 0.021 20.25 1006.5
226.65 -46.5 7500 125 30000 98425.2 0.015 20.34 1006.5
Table 6.4.1: Temperature, density, thermal conductivity, and specific heat of air at different
altitudes
Project 06005 Page 45 of 93
Preliminary Design Review 5/12/2006
Note:
• Time is assumed when the velocity is 3m/s.
• External temperature and density at different altitudes are calculated by using the
website: http://www.onlineconversion.com/atmosphere.htm.
• Thermal conductivity and specific heat at different temperature is calculated from
“Fundamental of Heat and Mass Heat Transfer by Frank P. Incropera and David P.
DeWitt” data.
Density (Kg/m3)
Thermal
Conductivity
(W/m·K)
Specific Heat
(J/kg·K)
Styrofoam 35 0.027 6.0185
Silicon (Circuit) 2329 124 2.561
Table 6.4.2.: Density, thermal conductivity, and specific heat of Styrofoam (platform) and
Silicon (circuit components).
Note:
• The data is from www.matweb.com
Project 06005 Page 46 of 93
Preliminary Design Review 5/12/2006
Temperature vs. altitude (m)
y = 2E-07x2 - 0.0074x + 287.11R2 = 0.9786
200.00
210.00
220.00
230.00
240.00
250.00
260.00
270.00
280.00
290.00
300.00
0 5000 10000 15000 20000 25000 30000 35000
Altitude (m)
Exte
rnal
Tem
pera
ture
(K)
temp. at diff. altitudePoly. (temp. at diff. altitude)
Figure 6.4.1.: Temperature change (K) vs. altitude (m) graph
Project 06005 Page 47 of 93
Preliminary Design Review 5/12/2006
8 Conclusion
With the completion of this project, RIT will have the means to do near-space
research and rocket deployment. The fact that this project is ongoing will require the
2005/2006 METEOR Team to do extensive analysis, testing, and documentation.
After defining the needs and goals of this project, it is now possible to explore the
different possibilities and means by which the goals can be achieved. This project will
give aerospace and other engineering facilities the ability to move forward with
previously inaccessible research methods.
Project 06005 Page 48 of 93
Preliminary Design Review 5/12/2006
9 Bibliography Complete Design Review, Team METEOR 2004/2005 Team, Carlos Barrios & Chris Ayre, May 2005 Florida International University, NASA, ALLSTAR Network: Aircraft Propulsion, Gas Turbines Operation and Design Requirements, http://www.allstar.fiu.edu/aero/turbine2.html, 1995-2006 Preliminary Design Review, Team METEOR 2004/2005 Team, Carlos Barrios & Chris Ayre, November 2004 MATWEB, Material Property Data, www.matweb.com, 1996-2006 Microsoft Visual .NET Studio, Microsoft Development Environment, 1987-2001 NASA Glenn Research Center, What is Drag?, http://www.grc.nasa.gov/WWW/K-12/airplane/drag1.html, 1995-2006 Tower Hobbies, http://www.towerhobbies.com, 1994-2005
Project 06005 Page 49 of 93
Preliminary Design Review 5/12/2006
10 Appendices 10.1 Airborne Control Software (C source code)
The source code for the Airborne Control Software was written by 2004/2005 METEOR Team member Carlos Barrios.
No significant changes have been made in the code. The revised ACS code will be in the 2005/2006 Meteor Team’s Complete Design Review (CDR).
10.2 Ground Control Software (C++ source code)
The source code for the Ground Control Software was written by 2005/2006 team member Jennifer Indovina.
10.2.1 DIJoystick.cpp // DIJoystick.cpp: implementation of the CDIJoystick class. // // Microsoft Foundation Classes // // Utilized by Jennifer Indovina // ////////////////////////////////////////////////////////////////////// #include "stdafx.h" #include "MeteorControl.h" #include "DIJoystick.h" #ifdef _DEBUG #undef THIS_FILE static char THIS_FILE[]=__FILE__; #define new DEBUG_NEW #endif // DIJoystick.cpp: implementation of the CDIJoystick class. #include "stdafx.h" #include "DIJoystick.h" #define BUFFERSIZE 16
Project 06005 Page 50 of 93
Preliminary Design Review 5/12/2006
// Set the maxmimum range to which we'll gauge the swing // JEN: the servo-motor range may be smaller - so adjust // the joystick grid accordingly. #define JOYMAX 10000 #define JOYMIN -10000 /* Y ^ | | X -10,000 <---*---> +10,000 | | \/ */ // Dead zone is the amount of sway the joystick can have before we start registering movement // In this case 20% #define JOYDEAD 2000 // The Saturation Point Is Where the Joystick is deemed to be at Full Swing, in this case 95% #define JOYSAT 9500 ////////////////////////////////////////////////////////////////////// // Construction/Destruction ////////////////////////////////////////////////////////////////////// CDIJoystick::CDIJoystick() // Initialize Member Variables m_EnumerationStarted=false; m_Initialized=false; m_hInstance=GetModuleHandle(NULL); // Initialize Direct Input Initialize(); // Start Enumeration of Attached Joysticks. Enumerate_Joysticks(); //////////////////////////////////////////////////////////////////////
Project 06005 Page 51 of 93
Preliminary Design Review 5/12/2006
// // Destroy The Direct Input Joystick Control and tidy up. // ////////////////////////////////////////////////////////////////////// CDIJoystick::~CDIJoystick() Shutdown(); ////////////////////////////////////////////////////////////////////// // // Initialize Direct Input // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::Initialize() HRESULT hr; hr = DirectInputCreateEx(m_hInstance, DIRECTINPUT_VERSION, IID_IDirectInput7, (void**)&m_lpDI, NULL); if FAILED(hr) // DirectInput not available; // take appropriate action OutputDebugString("Failed To Initialize Direct Input 7 in CDIJoystick::Initialise\n"); OutputDebugString(GetDIError(hr)); return false; m_hwnd=NULL; if FAILED(hr) OutputDebugString(GetDIError(hr)); Shutdown(); return false; m_Initialized=true; return true; // Successfully Created Direct Input 7 Object ////////////////////////////////////////////////////////////////////// // // Shutdown the Direct input object and release it.
Project 06005 Page 52 of 93
Preliminary Design Review 5/12/2006
// // Basically clean up any memory allocated to this object // ////////////////////////////////////////////////////////////////////// void CDIJoystick::Shutdown() ClearFriendlyButtonNames(); // Remove Joystick Information if(!m_DIJoystickList.IsEmpty()) POSITION pos=m_DIJoystickList.GetHeadPosition(); LPVOID del=NULL; while(pos) del=static_cast<LPVOID>(m_DIJoystickList.GetNext(pos)); if(del) delete del; m_DIJoystickList.RemoveAll(); // Shutdown Direct Input! if (m_lpDI) if (m_lpDIDevice) // Always unacquire device before calling Release(). try Acquire(false); m_lpDIDevice->Release(); m_lpDIDevice = NULL; catch(...) OutputDebugString("Failed to Release Pointer in CDIJoystick::Shutdown\n"); try m_lpDI->Release();
Project 06005 Page 53 of 93
Preliminary Design Review 5/12/2006
m_lpDI = NULL; catch(...) OutputDebugString("Failed to Release DI7 Pointer in CDIJoystick::Shutdown\n"); m_Initialized=false; ////////////////////////////////////////////////////////////////////// // // Start the Enumeration Of Attached Joystick Devices. // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::Enumerate_Joysticks() HRESULT hr=NULL; if(!m_Initialized) Initialize(); if(!m_lpDI) // Has a Direct Input Interface Already Been Initialized? hr = DirectInputCreateEx(m_hInstance, DIRECTINPUT_VERSION, IID_IDirectInput7, (void**)&m_lpDI, NULL); if FAILED(hr) OutputDebugString("Error in CDIJoystick::Enumerate_Joysticks()\n"); OutputDebugString(GetDIError(hr)); return false; if(m_lpDI) hr=m_lpDI->EnumDevices(DIDEVTYPE_JOYSTICK ,EnumDevicesProc,this,DIEDFL_ATTACHEDONLY); if FAILED(hr) OutputDebugString("Error in CDIJoystick::Enumerate_Joysticks()\n"); OutputDebugString(GetDIError(hr)); return false;
Project 06005 Page 54 of 93
Preliminary Design Review 5/12/2006
OutputDebugString("Enumerating Joystick Devices\n"); return true; ////////////////////////////////////////////////////////////////////// // // Add Enumerated Devices To A Link List Object // Continue Enumeration Of The Device // ////////////////////////////////////////////////////////////////////// BOOL CDIJoystick::EnumDevicesProc(LPCDIDEVICEINSTANCE lpddi, LPVOID pvRef) CDIJoystick *obj=(CDIJoystick*)(pvRef); obj->AddDeviceInfo(lpddi); return DIENUM_CONTINUE; ////////////////////////////////////////////////////////////////////// // // Add Device Info To The List Of Pointers Held in m_DIJoystickList // // return true = Successfully Added // false = Failed To Add // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::AddDeviceInfo(LPCDIDEVICEINSTANCE lpddi) m_EnumerationStarted=true; LPCDIDEVICEINSTANCE lpdi2=new DIDEVICEINSTANCE; if(lpdi2) memcpy((void*)lpdi2,lpddi,sizeof(DIDEVICEINSTANCE)); if(m_DIJoystickList.AddHead((void*)lpdi2))return true; OutputDebugString("Failed To Add Device Info in CDIJoystick::AddDeviceInfo(LPCDIDEVICEINSTANCE lpddi)\n"); return false; ////////////////////////////////////////////////////////////////////// // // Return First Joystick Device Data If Possible
Project 06005 Page 55 of 93
Preliminary Design Review 5/12/2006
// // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// LPCDIDEVICEINSTANCE CDIJoystick::GetFirstJoystickID() if(!m_EnumerationStarted) OutputDebugString("Joystick Have Not Yet Been Enumerated Returning NULL from CDIJoystick::GetFirstJoystickID()\n"); return NULL; if(m_DIJoystickList.IsEmpty()) OutputDebugString("Joysticks Have Been Enumerated However None Were Found Attached To This System\n" "Therefore I am Returning NULL from CDIJoystick::GetFirstJoystickID()\n"); return NULL; m_DevicePOS=m_DIJoystickList.GetHeadPosition(); return GetNextJoystickID(); LPCDIDEVICEINSTANCE info=static_cast<LPCDIDEVICEINSTANCE>(m_DIJoystickList.GetNext(m_DevicePOS)); return info; ////////////////////////////////////////////////////////////////////// // // Return Next Joystick Device Data If Possible // // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// LPCDIDEVICEINSTANCE CDIJoystick::GetNextJoystickID() if(!m_DevicePOS) return NULL; return static_cast<LPCDIDEVICEINSTANCE>(m_DIJoystickList.GetNext(m_DevicePOS));
Project 06005 Page 56 of 93
Preliminary Design Review 5/12/2006
////////////////////////////////////////////////////////////////////// // // Return First Joystick Button Name Data If Possible // // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// TCHAR* CDIJoystick::GetFirstButtonName() if(!m_EnumerationStarted) OutputDebugString("Joystick Have Not Yet Been Enumerated\nor None attached to this systemReturning NULL from CDIJoystick::GetFirstJoystickID()\n"); return NULL; if(m_DIButtonNames.IsEmpty()) OutputDebugString("Joysticks Have Been Enumerated However None Were Found Attached To This System\n" "Therefore I am Returning NULL from CDIJoystick::GetFirstButtonName()\n"); return NULL; m_ButtonPOS=m_DIButtonNames.GetHeadPosition(); TCHAR* info=static_cast<TCHAR*>(m_DIButtonNames.GetNext(m_ButtonPOS)); return info; ////////////////////////////////////////////////////////////////////// // // Return First Joystick Button Name Data If Possible // // return NULL if Failed or No Joysticks Available // ////////////////////////////////////////////////////////////////////// TCHAR* CDIJoystick::GetNextButtonName() if(!m_ButtonPOS) return NULL; return static_cast<TCHAR*>(m_DIButtonNames.GetNext(m_ButtonPOS));
Project 06005 Page 57 of 93
Preliminary Design Review 5/12/2006
////////////////////////////////////////////////////////////////////// // // Create the Joystick Device Using GUID Passed // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::CreateDevice(GUID *guid) HRESULT hr=NULL; // If a device already exists and is created, Release it. if (m_lpDIDevice) // Always unacquire device before calling Release(). try hr=m_lpDIDevice->Unacquire(); catch(...) try hr=m_lpDIDevice->Release(); if(FAILED(hr)) OutputDebugString(GetDIError(hr)); else m_lpDIDevice = NULL; catch(...) OutputDebugString("Failed to Release Pointer in CDIJoystick::CreateDevice(GUID *guid)\n"); // Check to see that Direct Input has been created and initialized. if(!m_lpDI) OutputDebugString("Failed to Create DI 7 interface to device in CDIJoystick::CreateDevice(GUID *guid) m_lpDI not initialized.\n"); return false;
Project 06005 Page 58 of 93
Preliminary Design Review 5/12/2006
// Attempt to create the device based on the GUID passed to this routine hr=m_lpDI->CreateDeviceEx(*guid,IID_IDirectInputDevice7,(void**)&m_lpDIDevice,NULL); if(FAILED(hr)) OutputDebugString("Failed to Create DI 7 interface to device in CDIJoystick::CreateDevice(GUID *guid)\n"); return false; // We must have been successful at this point. // Therefore copy the GUID to this members instance for future reference. memcpy(&m_JoystickGUID,guid,sizeof(GUID)); return true; ////////////////////////////////////////////////////////////////////// // // Return How Many Buttons The Attached Device Has Installed // When giving the player an option of which joystick to use // You may wish to evaluate the buttons available per attached device. // Returns the number of buttons for the currently selected device. // ////////////////////////////////////////////////////////////////////// int CDIJoystick::HowManyButtons() DIDEVICEOBJECTINSTANCE didoi; DWORD x; DWORD dwOfs; int count=0; HRESULT hr=NULL; ClearFriendlyButtonNames(); //if(m_lpDIDevice) if(InitDevice()) ZeroMemory(&didoi,sizeof(DIDEVICEOBJECTINSTANCE)); didoi.dwSize = sizeof( didoi ); for ( x = 0; x < 32; x++ ) dwOfs = DIJOFS_BUTTON( x );
Project 06005 Page 59 of 93
Preliminary Design Review 5/12/2006
hr=m_lpDIDevice->GetObjectInfo( &didoi, dwOfs, DIPH_BYOFFSET ); if ( SUCCEEDED( hr ) ) count++; TCHAR* name=new char[sizeof(didoi.tszName)]; // Should include UNICODE support here. strcpy(name,didoi.tszName); // Add the button name to the Pointer List for future reference. m_DIButtonNames.AddTail(name); else OutputDebugString(GetDIError(hr)); return count; // How many buttons did we find? //////////////////////////////////////////////////////////////////////// // // Shutdown the the link list of Friendly Button Names // //////////////////////////////////////////////////////////////////////// void CDIJoystick::ClearFriendlyButtonNames() try if(!m_DIButtonNames.IsEmpty()) POSITION pos=m_DIButtonNames.GetHeadPosition(); LPVOID del=NULL; while(pos) del=static_cast<LPVOID>(m_DIButtonNames.GetNext(pos)); if(del) delete del;
Project 06005 Page 60 of 93
Preliminary Design Review 5/12/2006
m_DIButtonNames.RemoveAll(); catch(...) OutputDebugString("Some unforseen error occurred in CDIJoystick::ClearFriendlyButtonNames()\n"); ////////////////////////////////////////////////////////////////////// // // Initialize The Joystick! // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::InitJoystick() // Set range. // Note: range, deadzone, and saturation are being set for the // entire device. This could have unwanted effects on // sliders, dials, etc. DIPROPRANGE diprg; diprg.diph.dwSize = sizeof( diprg ); diprg.diph.dwHeaderSize = sizeof( diprg.diph ); diprg.diph.dwObj = 0; diprg.diph.dwHow = DIPH_DEVICE; diprg.lMin = JOYMIN; diprg.lMax = JOYMAX; if ( FAILED( m_lpDIDevice->SetProperty( DIPROP_RANGE, &diprg.diph ) ) ) return FALSE; // Set deadzone. DIPROPDWORD dipdw; dipdw.diph.dwSize = sizeof( dipdw ); dipdw.diph.dwHeaderSize = sizeof( dipdw.diph ); dipdw.diph.dwObj = 0; dipdw.diph.dwHow = DIPH_DEVICE; dipdw.dwData = JOYDEAD; if ( FAILED( m_lpDIDevice->SetProperty( DIPROP_DEADZONE, &dipdw.diph ) ) ) return FALSE;
Project 06005 Page 61 of 93
Preliminary Design Review 5/12/2006
// Set saturation. dipdw.dwData = JOYSAT; if ( FAILED( m_lpDIDevice->SetProperty( DIPROP_SATURATION, &dipdw.diph ) ) ) return FALSE; // Find out if force feedback available. DIDEVCAPS didc; didc.dwSize = sizeof( DIDEVCAPS ); if ( FAILED( m_lpDIDevice->GetCapabilities( &didc ) ) ) return FALSE; m_FFAvailable = ( didc.dwFlags & DIDC_FORCEFEEDBACK ); // If it's a force feedback stick, turn off autocenter so it doesn't // get in the way of our effects. if ( m_FFAvailable ) DIPROPDWORD DIPropAutoCenter; DIPropAutoCenter.diph.dwSize = sizeof( DIPropAutoCenter ); DIPropAutoCenter.diph.dwHeaderSize = sizeof( DIPROPHEADER ); DIPropAutoCenter.diph.dwObj = 0; DIPropAutoCenter.diph.dwHow = DIPH_DEVICE; DIPropAutoCenter.dwData = 0; m_lpDIDevice->SetProperty( DIPROP_AUTOCENTER, &DIPropAutoCenter.diph ); return TRUE; ////////////////////////////////////////////////////////////////////// // // Initialize The Joystick Device // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::InitDevice() HRESULT hr; DIDEVICEINSTANCE diDeviceInstance; // Just a precaution when Enumerating Devices and button Names if you create // An options Dialog before creating your main gaming window. // Then simply use the desktop window, temporarily! if(!m_hwnd)m_hwnd=::GetDesktopWindow(); // Release device if it already exists.
Project 06005 Page 62 of 93
Preliminary Design Review 5/12/2006
if ( m_lpDIDevice ) //if ( m_FFAvailable ) ReleaseEffects(); Acquire( false); hr=m_lpDIDevice->Release(); if(FAILED(hr)) OutputDebugString("Error Releasing Interface in CDIJoystick::InitDevice()\n"); OutputDebugString(GetDIError(hr)); else m_lpDIDevice=NULL; // Create game device and set IDirectInputDevice7 interface in m_lpDIDevice. if(!CreateDevice( &m_JoystickGUID )) OutputDebugString("Failed to create device in CDIJoystick::InitDevice()\n"); return false; // Find out what type it is and set data format accordingly. diDeviceInstance.dwSize = sizeof( DIDEVICEINSTANCE ); hr=m_lpDIDevice->GetDeviceInfo( &diDeviceInstance ); if ( FAILED( hr ) ) OutputDebugString("Failed to obtain device info in CDIJoystick::InitDevice()\n"); OutputDebugString(GetDIError(hr)); return false; // Set the data format to be a Joystick hr = m_lpDIDevice->SetDataFormat( &c_dfDIJoystick2 ); if ( FAILED( hr ) ) OutputDebugString("Failed to create device in CDIJoystick::InitDevice()\n"); OutputDebugString(GetDIError(hr)); return false;
Project 06005 Page 63 of 93
Preliminary Design Review 5/12/2006
// Set cooperative level. DWORD cl, cl1; cl = DISCL_EXCLUSIVE; // Set foreground level for release version, but use background level // for debugging so we don't keep losing the device when switching to // a debug window. //cl1 = DISCL_FOREGROUND; cl1 = DISCL_BACKGROUND; #ifdef _DEBUG cl1 = DISCL_BACKGROUND; #endif // now set the co-operation level. hr=m_lpDIDevice->SetCooperativeLevel( m_hwnd, cl | cl1 ); if ( FAILED( hr )) OutputDebugString( "Failed to set game device cooperative level.\n" ); OutputDebugString(GetDIError(hr)); return false; // Set up the data buffer. DIPROPDWORD dipdw = // The header. sizeof( DIPROPDWORD ), // diph.dwSize sizeof( DIPROPHEADER ), // diph.dwHeaderSize 0, // diph.dwObj DIPH_DEVICE, // diph.dwHow , // Number of elements in data buffer. BUFFERSIZE // dwData ; hr=m_lpDIDevice->SetProperty( DIPROP_BUFFERSIZE, &dipdw.diph ); if(FAILED(hr)) OutputDebugString( "Failed to set up Data Buffer property.\n" ); OutputDebugString(GetDIError(hr)); return false;
Project 06005 Page 64 of 93
Preliminary Design Review 5/12/2006
// Resest the Force Feedback Flag m_FFAvailable = FALSE; // Try and initialize the Joystick! if ( !InitJoystick() ) return FALSE; // In case you were wondering, this is not a good time to acquire the // device. For one thing, we can't acquire in foreground mode here // because the options dialog may be open. We'll acquire it when the // main window is activated. return TRUE; //////////////////////////////////////////////////////////////////////////////// // // Either Acquire or Unacquire the Device! // //////////////////////////////////////////////////////////////////////////////// bool CDIJoystick::Acquire(bool state) HRESULT hr; if(!m_lpDIDevice) OutputDebugString("Error in CDIJoystick::Acquire(bool state)\nDevice Has Not Been Created.\n"); return false; if ( !state ) // Unacquire. hr = m_lpDIDevice->Unacquire(); else // Acquire. // This could take a while with FF. ::SetCursor( m_hCursorWait ); hr = m_lpDIDevice->Acquire(); if ( SUCCEEDED( hr ) ) // Initialize effects; ignore failure and just // pretend FF not there. if ( m_FFAvailable ) // First set when device initialized.
Project 06005 Page 65 of 93
Preliminary Design Review 5/12/2006
//m_FFAvailable = InitFFEffects(); if(FAILED(hr)) OutputDebugString("Failed in CDIJoystick::Acquire(bool state)\n"); OutputDebugString(GetDIError(hr)); return false; return true; ////////////////////////////////////////////////////////////////////// // // Set the HWND that will be used when Acquiring Devices! // ////////////////////////////////////////////////////////////////////// void CDIJoystick::SetHWND(HWND hwnd) //Shutdown(); m_hwnd=hwnd; //m_EnumerationStarted=false; m_hInstance=GetModuleHandle(NULL); // Initialize Direct Input //Initialize(); // Start Enumeration of Attached Joysticks. //Enumerate_Joysticks(); ////////////////////////////////////////////////////////////////////// // // Set the preferred GUID for the joystick device // ////////////////////////////////////////////////////////////////////// void CDIJoystick::SetPreferredDevice(GUID *pguid) memcpy(&m_JoystickGUID,pguid,sizeof(GUID)); ////////////////////////////////////////////////////////////////////// // // Re-Initialize this object, used when changing HWND or Device
Project 06005 Page 66 of 93
Preliminary Design Review 5/12/2006
// Not yet implemented. // ////////////////////////////////////////////////////////////////////// bool CDIJoystick::ReInitialize() // m_EnumerationStarted=false; // m_hInstance=GetModuleHandle(NULL); // Enumerate_Joysticks(); return true; ////////////////////////////////////////////////////////////////////// // // Return Error Text From HRESULT // ////////////////////////////////////////////////////////////////////// TCHAR* CDIJoystick::GetDIError(HRESULT error) switch(error) case E_PENDING : return _T("E_PENDING : Data Not Available.\n"); break; case E_HANDLE : return _T("E_HANDLE : The HWND parameter is not a valid top-level window that belongs to the process.\n"); break; case DIERR_UNSUPPORTED : return _T("DIERR_UNSUPPORTED : The function called is not supported at this time. This value is equal to the E_NOTIMPL standard COM return value.\n"); break; case DIERR_UNPLUGGED : return _T("DIERR_UNPLUGGED : The operation could not be completed because the device is not plugged in.\n"); break; case DIERR_REPORTFULL : return _T("DIERR_REPORTFULL : More information was requested to be sent than can be sent to the device.\n"); break; case DIERR_READONLY : return _T("DIERR_READONLY : The specified property cannot be changed. This value is equal to the E_ACCESSDENIED standard COM return value.\n"); break; case DIERR_OUTOFMEMORY : return _T("DIERR_OUTOFMEMORY : The DirectInput subsystem could not allocate sufficient memory to complete the call. This value is equal to the E_OUTOFMEMORY standard COM return value.\n"); break; // case DIERR_OTHERAPPHASPRIO : return _T("DIERR_OTHERAPPHASPRIO : Another application has a higher priority level, preventing this call from succeeding. This value is equal to the E_ACCESSDENIED standard COM return value. This error can be
Project 06005 Page 67 of 93
Preliminary Design Review 5/12/2006
returned when an application has only foreground access to a device but is attempting to acquire the device while in the background. "); // break; case DIERR_OLDDIRECTINPUTVERSION : return _T("DIERR_OLDDIRECTINPUTVERSION : The application requires a newer version of DirectInput.\n"); break; case DIERR_OBJECTNOTFOUND : return _T("DIERR_OBJECTNOTFOUND : The requested object does not exist.\n"); break; case DIERR_NOTINITIALIZED : return _T("DIERR_NOTINITIALIZED : This object has not been initialized.\n"); break; // case DIERR_NOTFOUND : return _T("DIERR_NOTFOUND : The requested object does not exist.\n"); // break; case DIERR_NOTEXCLUSIVEACQUIRED : return _T("DIERR_NOTEXCLUSIVEACQUIRED : The operation cannot be performed unless the device is acquired in DISCL_EXCLUSIVE mode.\n"); break; case DIERR_NOTDOWNLOADED : return _T("DIERR_NOTDOWNLOADED : The effect is not downloaded.\n"); break; case DIERR_NOTBUFFERED : return _T("DIERR_NOTBUFFERED : The device is not buffered. Set the DIPROP_BUFFERSIZE property to enable buffering.\n"); break; case DIERR_NOTACQUIRED : return _T("DIERR_NOTACQUIRED : The operation cannot be performed unless the device is acquired.\n"); break; case DIERR_NOINTERFACE : return _T("DIERR_NOINTERFACE : The specified interface is not supported by the object. This value is equal to the E_NOINTERFACE standard COM return value.\n"); break; case DIERR_NOAGGREGATION : return _T("DIERR_NOAGGREGATION : This object does not support aggregation.\n"); break; case DIERR_MOREDATA : return _T("DIERR_MOREDATA : Not all the requested information fit into the buffer.\n"); break; case DIERR_INVALIDPARAM : return _T("DIERR_INVALIDPARAM : An invalid parameter was passed to the returning function, or the object was not in a state that permitted the function to be called. This value is equal to the E_INVALIDARG standard COM return value.\n"); break; case DIERR_INPUTLOST : return _T("DIERR_INPUTLOST : Access to the input device has been lost. It must be reacquired.\n");
Project 06005 Page 68 of 93
Preliminary Design Review 5/12/2006
break; case DIERR_INCOMPLETEEFFECT : return _T("DIERR_INCOMPLETEEFFECT : The effect could not be downloaded because essential information is missing. For example, no axes have been associated with the effect, or no type-specific information has been supplied.\n"); break; // case DIERR_HANDLEEXISTS : return _T("DIERR_HANDLEEXISTS : The device already has an event notification associated with it. This value is equal to the E_ACCESSDENIED standard COM return value.\n"); // break; case DIERR_GENERIC : return _T("DIERR_GENERIC : An undetermined error occurred inside the DirectInput subsystem. This value is equal to the E_FAIL standard COM return value.\n"); break; case DIERR_HASEFFECTS : return _T("DIERR_HASEFFECTS : The device cannot be reinitialized because there are still effects attached to it.\n"); break; case DIERR_EFFECTPLAYING : return _T("DIERR_EFFECTPLAYING : The parameters were updated in memory but were not downloaded to the device because the device does not support updating an effect while it is still playing.\n"); break; case DIERR_DEVICENOTREG : return _T("DIERR_DEVICENOTREG : The device or device instance is not registered with DirectInput. This value is equal to the REGDB_E_CLASSNOTREG standard COM return value.\n"); break; case DIERR_DEVICEFULL : return _T("DIERR_DEVICEFULL : The device is full.\n"); break; case DIERR_BETADIRECTINPUTVERSION : return _T("DIERR_BETADIRECTINPUTVERSION : The application was written for an unsupported prerelease version of DirectInput.\n"); break; case DIERR_BADDRIVERVER : return _T("DIERR_BADDRIVERVER : The object could not be created due to an incompatible driver version or mismatched or incomplete driver components.\n"); break; case DIERR_ALREADYINITIALIZED : return _T("DIERR_ALREADYINITIALIZED : This object is already initialized\n"); break; case DIERR_ACQUIRED : return _T("DIERR_ACQUIRED : The operation cannot be performed while the device is acquired.\n"); break; case DI_TRUNCATEDANDRESTARTED : return _T("DI_TRUNCATEDANDRESTARTED : Equal to DI_EFFECTRESTARTED | DI_TRUNCATED\n"); break;
Project 06005 Page 69 of 93
Preliminary Design Review 5/12/2006
case DI_TRUNCATED : return _T("DI_TRUNCATED : The parameters of the effect were successfully updated, but some of them were beyond the capabilities of the device and were truncated to the nearest supported value.\n"); break; case DI_PROPNOEFFECT : return _T("DI_PROPNOEFFECT : The change in device properties had no effect. This value is equal to the S_FALSE standard COM return value.\n"); break; case DI_POLLEDDEVICE : return _T("DI_POLLEDDEVICE : The device is a polled device. As a result, device buffering does not collect any data and event notifications is not signaled until the IDirectInputDevice7::Poll method is called.\n"); break; case DI_OK : return _T("DI_OK : The operation completed successfully. This value is equal to the S_OK standard COM return value.\n"); break; // case DI_NOTATTACHED : return _T("DI_NOTATTACHED : The device exists but is not currently attached. This value is equal to the S_FALSE standard COM return value.\n"); // break; // case DI_NOEFFECT : return _T("DI_NOEFFECT : The operation had no effect. This value is equal to the S_FALSE standard COM return value.\n"); // break; case DI_EFFECTRESTARTED : return _T("DI_EFFECTRESTARTED : The effect was stopped, the parameters were updated, and the effect was restarted.\n"); break; case DI_DOWNLOADSKIPPED : return _T("The parameters of the effect were successfully updated, but the effect could not be downloaded because the associated device was not acquired in exclusive mode.\n"); break; // case DI_BUFFEROVERFLOW : return _T("DI_BUFFEROVERFLOW : The device buffer overflowed and some input was lost. This value is equal to the S_FALSE standard COM return value.\n"); // break; default: return _T("Unknown Error Code.\n"); ////////////////////////////////////////////////////////////////////////////////////////// // // Update member variables to reflect the state of the device // ////////////////////////////////////////////////////////////////////////////////////////// bool CDIJoystick::PollDevice() static loopcount=0;
Project 06005 Page 70 of 93
Preliminary Design Review 5/12/2006
HRESULT hr; //DIDEVICEOBJECTDATA rgdod[BUFFERSIZE]; //DWORD dwItems; ZeroMemory(&m_dijs,sizeof(m_dijs)); // Has device been initialized ? if (!m_lpDIDevice) // Try and initialize device if(!InitDevice()) OutputDebugString("Failed To Initialize and Poll Joystick in CDIJoystick::PollDevice()\n"); return false; hr=m_lpDIDevice->Poll(); // May be unnecessary but never hurts. if(FAILED(hr)) OutputDebugString("Failed To Poll Joystick in CDIJoystick::PollDevice()\n"); OutputDebugString(GetDIError(hr)); getImmediateData: if(loopcount>20) return false; // Infinite Loop Protection hr = m_lpDIDevice->GetDeviceState( sizeof( DIJOYSTATE2 ), &m_dijs ); // The data stream was interrupted. Reacquire the device and try again. if ( hr == DIERR_INPUTLOST ) OutputDebugString("Failed To Obtain Immediate Device State in CDIJoystick::PollDevice()\n"); OutputDebugString(GetDIError(hr)); // Increment Infinite Loop Protection Counter and try again. loopcount++; // Try and acquire device and start again. if ( Acquire( true ) ) goto getImmediateData; // We can't get the device because it has not been acquired so try and acquire it. if ( hr == DIERR_NOTACQUIRED )
Project 06005 Page 71 of 93
Preliminary Design Review 5/12/2006
// Increment Infinite Loop Protection Counter. loopcount++; OutputDebugString("Device Not Acquired Trying Again immediate CDIJoystick::PollDevice()\n"); if(!Acquire(true)) OutputDebugString("Unable to acquire Immediate Device in CDIJoystick::PollDevice() Quitting\n"); return false; // Try and get buffered data if device is buffered! goto getImmediateData; if ( FAILED(hr)) OutputDebugString("Unable to obtain Immediate Data from Device in CDIJoystick::PollDevice() Quitting\n"); return false; // First set immediate direction if your only interested in basic movement if ( m_dijs.lX < 0 ) m_JoyLeft=true; else m_JoyLeft=false; if ( m_dijs.lX > 0 ) m_JoyRight=true; else m_JoyRight=false; if ( m_dijs.lY < 0 ) m_JoyUp=true; else m_JoyUp=false; if ( m_dijs.lY > 0 ) m_JoyDown=true; else m_JoyDown=false; m_JoyFire1=false; #ifdef _DEBUG int firecount=0; #endif for(int i=0;i<sizeof(m_dijs.rgbButtons);i++) if(m_dijs.rgbButtons[i]&0x80) #ifdef _DEBUG firecount++; #endif m_JoyFire[i]=true; m_JoyFire1=true; else m_JoyFire[i]=false;
Project 06005 Page 72 of 93
Preliminary Design Review 5/12/2006
#ifdef _DEBUG if(firecount>0) OutputDebugString("Many Buttons Pressed\n"); #endif return true; ////////////////////////////////////////////////////////////////////// // // Run the joystick Control Panel! // ////////////////////////////////////////////////////////////////////// void CDIJoystick::RunControlPanel() if(!m_lpDI) return; m_lpDI->RunControlPanel(m_hwnd,NULL);
10.2.2 MeteorControl.cpp // MeteorControl.cpp : Defines the class behaviors for the application. // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #include "stdafx.h" #include "MeteorControl.h" #include "MeteorControlDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp BEGIN_MESSAGE_MAP(CMeteorControlApp, CWinApp)
Project 06005 Page 73 of 93
Preliminary Design Review 5/12/2006
//AFX_MSG_MAP(CMeteorControlApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp construction CMeteorControlApp::CMeteorControlApp() // TODO: add construction code here, // Place all significant initialization in InitInstance ///////////////////////////////////////////////////////////////////////////// // The one and only CMeteorControlApp object CMeteorControlApp theApp; ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp initialization BOOL CMeteorControlApp::InitInstance() AfxEnableControlContainer(); // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need. CMeteorControlDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) // TODO: Place code here to handle when the dialog is // dismissed with OK else if (nResponse == IDCANCEL) // TODO: Place code here to handle when the dialog is
Project 06005 Page 74 of 93
Preliminary Design Review 5/12/2006
// dismissed with Cancel // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE;
10.2.3 MeteorControl.h // MeteorControl.h : main header file for the METEORCONTROL application // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #if !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_) #define AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp: // See MeteorControl.cpp for the implementation of this class // class CMeteorControlApp : public CWinApp public: CMeteorControlApp();
Project 06005 Page 75 of 93
Preliminary Design Review 5/12/2006
// Overrides // ClassWizard generated virtual function overrides //AFX_VIRTUAL(CMeteorControlApp) public: virtual BOOL InitInstance(); //AFX_VIRTUAL // Implementation //AFX_MSG(CMeteorControlApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //AFX_MSG DECLARE_MESSAGE_MAP() ; ///////////////////////////////////////////////////////////////////////////// //AFX_INSERT_LOCATION // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_)
10.2.4 MeteorControlDlg.cpp // MeteorControl.h : main header file for the METEORCONTROL application // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #if !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_) #define AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_ #if _MSC_VER > 1000
Project 06005 Page 76 of 93
Preliminary Design Review 5/12/2006
#pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols ///////////////////////////////////////////////////////////////////////////// // CMeteorControlApp: // See MeteorControl.cpp for the implementation of this class // class CMeteorControlApp : public CWinApp public: CMeteorControlApp(); // Overrides // ClassWizard generated virtual function overrides //AFX_VIRTUAL(CMeteorControlApp) public: virtual BOOL InitInstance(); //AFX_VIRTUAL // Implementation //AFX_MSG(CMeteorControlApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //AFX_MSG DECLARE_MESSAGE_MAP() ; ///////////////////////////////////////////////////////////////////////////// //AFX_INSERT_LOCATION // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_METEORCONTROL_H__9AFD07A8_208A_46F3_A723_0E4F302656EA__INCLUDED_)
Project 06005 Page 77 of 93
Preliminary Design Review 5/12/2006
10.2.5 MeteorControlDlg.h // MeteorControlDlg.h : header file // // Author : Jennifer Indovina // // Date Created : 9/10/2005 // // Last Modified : 10/31/2005 // #if !defined(AFX_METEORCONTROLDLG_H__53AA2313_BBB5_4D9D_AD57_0975B0CBBD49__INCLUDED_) #define AFX_METEORCONTROLDLG_H__53AA2313_BBB5_4D9D_AD57_0975B0CBBD49__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #include "DIJoystick.h" ///////////////////////////////////////////////////////////////////////////// // CMeteorControlDlg dialog class CMeteorControlDlg : public CDialog // Construction public: CMeteorControlDlg(CWnd* pParent = NULL); // standard constructor // Dialog Data //AFX_DATA(CMeteorControlDlg) enum IDD = IDD_METEORCONTROL_DIALOG ; // NOTE: the ClassWizard will add data members here CComboBox m_ctlButtonNames; CComboBox m_ctlJoystickName; BOOL m_Down; BOOL m_Fire; BOOL m_Left; BOOL m_Right; BOOL m_Up; CString m_XAxis; CString m_YAxis;
Project 06005 Page 78 of 93
Preliminary Design Review 5/12/2006
CString m_ZAxis; CString m_FireText; CString m_RXAxis; CString m_RYAxis; CString m_RZAxis; //AFX_DATA // ClassWizard generated virtual function overrides //AFX_VIRTUAL(CMeteorControlDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support //AFX_VIRTUAL // Implementation protected: HICON m_hIcon; // Generated message map functions //AFX_MSG(CMeteorControlDlg) virtual BOOL OnInitDialog(); afx_msg void OnSysCommand(UINT nID, LPARAM lParam); afx_msg void OnPaint(); afx_msg HCURSOR OnQueryDragIcon(); afx_msg void OnSelchangeButtonNames(); virtual void OnCancel(); afx_msg void OnButton1(); afx_msg void OnTimer(UINT nIDEvent); afx_msg void OnSelchangeJoystickName(); //AFX_MSG DECLARE_MESSAGE_MAP() public: int m_Buttons; // how many buttons does the device have? ; extern CDIJoystick myJoystick1; //AFX_INSERT_LOCATION // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_METEORCONTROLDLG_H__53AA2313_BBB5_4D9D_AD57_0975B0CBBD49__INCLUDED_)
Project 06005 Page 79 of 93
Preliminary Design Review 5/12/2006
10.3 Bill of Materials (per launch)
Bill of Materials (BOM)
Quantity
Supplier
Part N
umber
Description
Price/U
nit
Total Cost
Order = 0
Inventory = I M
ake = M
Ordered = X
R
eceived = R
1universal-radio.com KPC-3 Plus Terminal Node Controller 189.95 189.95 O R
2universal-radio.com M-24M Cornet - Mobile Dual Band Antenna 37.95 75.90 O R
2universal-radio.com MFG-1702C MJF - Antenna Switch (2 position) 22.95 45.90 O R
1universal-radio.com FT-7800R 2m/440cm Communication Radio 249.95 249.95 O R
10 DigiKey 367-1037-ND PL-259 to RG-58 Connector Male 1.03 10.30 O R1 DigiKey A305-100-ND RG-58 Cable 100 ft 45.40 45.40 O R1 DigiKey WM5782-ND Terminal Strip/Barrier Block 5.57 5.57 O R2 DigiKey LM35CAZ-ND Analog Temperature Sensor 5.40 10.80 O R
2 DigiKey2SD24570QL
CT-ND Replacement for 440 Transmitter 0.94 1.88 O R10 DigiKey 67-1103-ND RED LED 2.63 26.30 O R10 DigiKey P330ACT-ND 330 Ohm drop RES 0.77 7.70 O R10 DigiKey P220ACT-ND 220 Ohm drop RES 0.77 7.70 O R
10 DigiKeyPCC1858CT-
ND 0.01 uF Cap 0.44 4.40 O R
10 DigiKeyPCC1848CT-
ND 1 uF Cap 0.72 7.20 O R
10 DigiKeyPCC1983CT-
ND 470 pF Cap 0.66 6.60 O R
Lowes Wood Supplies for 'Mobile Rig' 50.00 50.00 O R
2 Tigerdirect.com M501-1000 USB - Serial Adapter 9.99 19.98 O R
2LaptopPartsNow.
com Quantex TS201 Automotive Car Airline DC Adapter 52.95 105.90 O R
http://store.yahoo.com/laptoppartsnow/pncac100542.html2 Kaymont KCI 1500 O R
2 Dinsmore Sensor 1490 Digital Sensor 13.00 26.00 O R
1 Dinsmore Sensor 1525 Analog Sensor 37.00 37.00 O R
1 Dinsmore Sensor R1655 Analog Sensor 37.00 37.00 O R
1 Express PCB RXLY3573 PIC1 Express PCB VAUC35740 Flashing LED
20 BatteryMart.com BAT-U9VL-X 9 Volt Lithium Ultra Life Batteries 5.20 104.00 O R
Project 06005 Page 80 of 93
Preliminary Design Review 5/12/2006
10.4 Quality Function Deployment Michael Giannotti
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Batte
ry L
ife w
ill la
st ~
15
hour
s
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~10
0 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Plat
form
will
be a
ble
to d
eter
min
e in
stan
tane
ous
plat
form
sp
eed
(sam
ple
ever
y 30
sec
onds
)
Plat
form
will
cont
inuo
usly
con
sum
e ~3
00 m
a fo
r 15
hour
s
Bat
tery
con
sum
ptio
n w
ill be
less
than
x a
mp-
min
s
All a
nalo
g da
ta w
ill be
con
verte
d to
dig
ital w
ith x
reso
lutio
n an
d sa
mpl
ed e
very
x m
sec
Plat
form
sha
ll tra
nsm
it au
dibl
e an
d vi
sibl
e la
ndin
g po
sitio
n fo
r 100
mile
s
Mot
or C
ontro
ller w
ill ne
ed to
sup
ply
pow
er a
t x m
illiam
ps to
a
mot
or a
t 1x
RP
Ms
Plat
form
will
be a
ble
to s
tore
1 k
byte
s of
dat
a if
data
tra
nsm
issi
on is
lost
Pla
tform
sha
ll tra
nsm
it w
hen
the
plat
form
mem
ory
buffe
r be
com
es 9
0% fu
ll
Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 5 2 6 2 0 4Platform shall be able to reach height and land 0 0 0 0 0 5 0 0 0 0 3Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 5 7 3 7 5 5Platform shall warn pedestrians upon re-entry 0 9 0 9 0 1 9 0 9 0 0
Platform shall disclose its position throughout the flight, re-entry and on ground 2 9 8 9 0 0 9 8 9 0 5
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 4 7 0 7 1 4Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 4 7 8 3 3 4Ground Station will be able to transmit commands to Platform 4 7 8 8 0 5 7 8 8 0 5
Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 5 7 9 8 3 5
Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 7 6 8 1 0
Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 0 7 6 8 0 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 2 9 9 8 4 9Platform shall transmit all flight data 9 9 9 8 0 5 9 9 8 0 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 5 7 1 8 0 5Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 4 0 0 0 0 4Platform will illuminate during re-entry 5 9 0 8 0 3 9 0 8 0 3Platform shall be reusable 9 3 0 0 0 0 3 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 7 5 0 2
Specifications
96
86
6
0
56
8
5
5
99
94705
Project 06005 Page 81 of 93
Preliminary Design Review 5/12/2006
Rina Matoba
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~10
0 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
sp
eed
(sam
ple
ever
y 30
sec
onds
)
Sim
ulat
ion
resu
lts to
impa
ct d
esig
n
Tem
pera
ture
of e
lect
roni
cs s
hall
not e
xcee
d x
degr
ees
Def
ine
fligh
t the
rmo
sens
ors
to m
onito
r and
trac
k
Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 9 9Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 0Platform shall transmit all flight data 9 9 9 8 0 8 9Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0Platform shall be reusable 9 3 0 0 0 0 0Thermo-characteristics will be modeled during design and then measured during flight. 6 6 7 8 1 9 9
Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 0
Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0Radiation (i.e. heat build-up) will be measured during flight. 6 9 7 8 0 8 8Temperature Sensor monitoring internal and external temperatures (~20 C) 6 9 7 8 0 7 9
Specifications
80
0
07
0
9
0
08
8
Project 06005 Page 82 of 93
Preliminary Design Review 5/12/2006
Jennifer Indovina
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~10
0 m
iles
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
sp
eed
(sam
ple
ever
y 30
sec
onds
)
Pla
tform
sha
ll tra
nsm
it au
dibl
e an
d vi
sibl
e la
ndin
g po
sitio
n fo
r 100
mile
s
Pla
tform
will
be
able
to s
tore
1 k
byte
s of
dat
a if
data
tra
nsm
issi
on is
lost
Pla
tform
sha
ll tra
nsm
it w
hen
the
plat
form
mem
ory
buffe
r be
com
es 9
0% fu
ll
Pla
tform
sha
ll tra
nsm
it its
land
ing
with
in 2
0 m
eter
s fo
r 100
m
eter
dis
tanc
e
Pla
tform
sha
ll be
retri
evab
le o
n an
y te
rrai
n or
alti
tude
Gro
und
Con
trol s
oftw
are
- GU
I, flo
wch
art,
tele
met
ry d
ispl
ay,
and
long
term
sto
rage
Gro
und
cont
rol t
rans
mis
sion
sha
ll ha
ve a
rang
e of
x m
iles
Pla
tform
sha
ll tra
nsm
it ev
ery
~30
seco
nds
Platform shall remain powered and functional for the duration of the flight 9 6 0 2 4 9 5 0 3 3Platform shall be able to reach height and land 0 0 0 0 3 6 0 0 9 8Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 3 5 7 5 8 0 0 6 4Platform shall warn pedestrians upon re-entry 0 0 0 9 0 6 0 0 0 5Platform shall disclose its position throughout the flight, re-entry and on ground 2 8 0 9 5 6 9 9 8 3
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 0 1 7 4 0 0 8 7 8Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 8 3 3 4 5 0 0 7 9
Ground Station will be able to transmit commands to Platform 4 8 0 8 5 6 0 0 9 5Platform will be able to transmit to Ground Station real time video and digital data 4 9 3 8 5 8 0 0 9 5Platform electronics will apply standard interface protocols (i.e. USB) 4 6 1 8 0 5 0 0 9 5
Platform will ensure reliable operation and apply redundant circuitry where necessary 0 6 0 8 0 5 2 0 0 0
Platform shall store critical flight telemetry data until data transmission occurs 0 9 4 8 9 9 0 0 6 3Platform shall transmit all flight data 9 9 0 8 9 9 0 0 8 4Platform shall operate autonomously if communications with Ground Station is lost 4 1 0 8 5 9 0 0 0 5Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 4 4 0 0 0 0Platform will illuminate during re-entry 5 0 0 8 3 7 0 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 7 1 8 2 2 0 0 9 7Non-integrated beacon sucessful in platform retrieval 5 7 0 5 2 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 5 0 0 0 0Pre-flight Ground Station operator 0 3 0 3 9 0 0 0 9 9Flight Ground Station operator 4 3 0 3 9 5 0 0 9 8Post-flight Ground Station operator 4 3 0 3 6 0 0 7 9 9Ground Station data server Analyst 4 3 0 3 6 6 0 0 9 8pedestrians at landing zone 0 0 0 0 2 0 6 0 4 0Land owner at landing zone 0 0 0 0 2 0 0 0 1 0Chasers 4 0 0 0 5 0 6 0 1 3FAA Analyst (if pre-flight approval is needed) 0 0 0 0 0 0 0 0 1 0Equipment Transporters 0 0 0 0 6 0 0 0 1 0Equipment operators, maintained 0 0 0 0 6 0 0 0 0 0
Specifications
56
24
9
7
9
9
8
8
0
77
000
7004444000200
Project 06005 Page 83 of 93
Preliminary Design Review 5/12/2006
Richard Paasch
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~1
00 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
spe
ed (s
ampl
e ev
ery
30 s
econ
ds)
Pla
tform
sha
ll be
abl
e to
mov
e/re
posi
tion
itsel
f with
in
0.5
met
ers
of m
ax h
eigh
t
Mot
or p
ower
con
sum
ptio
n w
ill b
e 5
mill
iam
ps fo
r no
mor
e th
an m
ax. f
light
dur
atio
n
Mot
or p
ower
sha
ll be
sup
plie
d by
bat
terie
s
Pla
tform
sha
ll by
abl
e to
repo
sitio
n in
self
with
in 0
.5
met
ers
Pla
tform
sha
ll be
abl
e to
pos
ition
itse
lf us
ing
prop
elle
rs
with
a m
inim
um s
peed
of 1
0 m
/sec
for 1
20 m
ins
Pla
tform
will
with
stan
d la
ndin
g ve
loci
ty o
f x m
/sec
Pla
tform
sha
ll be
retri
evab
le o
n an
y te
rrai
n or
alti
tude
Platform shall remain powered and functional for the duration of the flight 9 2 6 2 0 0 9 9 0 0 0Balloon and platform shall be able to reposition itself for a safe re-entry and landing 0 7 3 7 5 7 0 0 7 9 0
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0 0 0 9Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 0 0 0 0 0Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 0 7 0 0 7Platform shall be reusable 9 3 0 0 0 0 0 7 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 9 7 7 9 9 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 7 9 9 7 7 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0 0 0 0Pre-flight Ground Station operator 0 3 3 3 0 0 5 0 0 0 0Flight Ground Station operator 4 3 3 3 0 9 0 0 9 9 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0 0 0 5Ground Station data server Analyst 4 3 3 3 0 0 0 0 0 0 0
Specifications
0
0
8
000
0
000070
Project 06005 Page 84 of 93
Preliminary Design Review 5/12/2006
Vivek Shah
0
90
90
0
09
00090
0
0920000
Specifications
Flig
ht D
urat
ion
will
last
at l
east
~3
hour
s
Bat
tery
Life
will
last
~ 1
5 ho
urs
Gro
und
Con
trol T
rans
mis
sion
sha
ll ha
ve a
rang
e of
~1
00 m
iles
Pla
tform
Pow
er s
ourc
e sh
all b
e ab
le to
sup
port
amp-
hour
s fo
r 20
hour
s
Pla
tform
will
be
able
to d
eter
min
e in
stan
tane
ous
plat
form
spe
ed (s
ampl
e ev
ery
30 s
econ
ds)
Pla
tform
sha
ll tra
nsm
it its
land
ing
with
in 2
0 m
eter
s fo
r 10
0 m
eter
dis
tanc
e
GP
S d
ata
gath
erin
g, s
tora
ge, a
nd tr
ansm
issi
on,
seco
ndar
y
LED
Fla
shin
g C
ircui
try/T
empe
ratu
re S
enso
r/Com
pass
OS
D-G
PS
Tex
t ove
rlay
METEOR shall meet all agency and safety requirements (i.e. weight, re-entry warning, …) 0 7 0 7 1 0 0 0Platform will transmit cc and experimentation data: position, temperatures and other critical data 4 7 8 3 3 0 5 0Ground Station will be able to transmit commands to Platform 4 7 8 8 0 0 0 0Platform will be able to transmit to Ground Station real time video and digital data 4 7 9 8 3 0 0 0Platform electronics will apply standard interface protocols (i.e. USB) 4 7 6 8 1 0 0 0
Platform will ensure reliable operation and apply redundant circuitry where necessary 0 7 6 8 0 2 9 0Platform shall store critical flight telemetry data until data transmission occurs 0 9 9 8 4 0 9 0Platform shall transmit all flight data 9 9 9 8 0 0 0 5Platform shall operate autonomously if communications with Ground Station is lost 4 7 1 8 0 0 9 9Weight restrictions shall be adhered to ( > 6 lbs) 0 0 0 0 0 0 2 0Platform will illuminate during re-entry 5 9 0 8 0 0 0 9Platform shall be reusable 9 3 0 0 0 0 0 9during flight. 6 6 7 8 1 0 0 0Platform positioning efficiency will modeled during design and then measured during flight. 6 9 7 8 1 0 6 0Power consumption will modeled during design and then measured during flight. 6 9 7 8 0 0 0 0Non-integrated beacon sucessful in platform retrieval 5 0 7 5 0 0 0 0Define other data gathering sensors or experiments. 3 0 0 0 0 0 0 7Pre-flight Ground Station operator 0 3 3 3 0 0 0 0Flight Ground Station operator 4 3 3 3 0 0 0 0Post-flight Ground Station operator 4 3 3 3 0 0 0 0Ground Station data server Analyst 4 3 3 3 0 0 0 0
Project 06005 Page 85 of 93
Preliminary Design Review 5/12/2006
10.5 Pugh Charts
ual C++ .NET Pugh Analysis
CriteriaImportance
RankingWeighted Ranking
Visual C++ Studio .NET JAVA
Visual Basic IDE
Purchase Cost 7 0.1061 0.1061 0.1061 0.1061Operating Cost 7 0.1061 0.1061 0.1061 0.1061Cycle Time 10 0.1515 0.1515 0.0606 0.0303Mean time between failures 7 0.1061 0.1212 0.0909 0.1364Operating Time 10 0.1515 0.1515 0.0758 0.1061Constant operation 4 0.0606 0.0606 0.0758 0.0303
Mean Time to repair 7 0.1061 0.0909 0.0455 0.0606Current system compatibility 10 0.1515 0.1515 0.1212 0.1000Startup time 4 0.0606 0.0455 0.0152 0.0455Best Option based on weighted Criteria 1.0000 0.9848 0.6970 0.7212
Vis
OSD System Pugh Analysis
CriteriaImportance
RankingWeighted Ranking
Video Amplifier
OSDµC with
OSDOSD Video Generator
Purchase Cost 10 0.1493 0.1493 0.0746 0.0299Operating Cost 5 0.0746 0.0746 0.0896 0.0746Response Time 4 0.0597 0.0448 0.0597 0.0597Failure Time 10 0.1493 0.1343 0.1493 0.1343Operating Time 5 0.0746 0.0448 0.0597 0.0746Constant operation 10 0.1493 0.1493 0.1493 0.1493
Mean Time to repair 8 0.1194 0.0896 0.1045 0.0896Current system compatibility 10 0.1493 0.0746 0.1045 0.0746Startup time 5 0.0746 0.0746 0.0746 0.0746Best Option based on weighted Criteria 1.0000 0.8358 0.8657 0.7612
Project 06005 Page 86 of 93
Preliminary Design Review 5/12/2006
Single Propeller Design Pugh Analysis
CriteriaImportance
RankingWeighted Ranking
Single Propeller
Gas Turbine
Purchase Cost 8 0.1096 0.0959 0.0959Operating Cost 7 0.0959 0.0959 0.0959Response Time 10 0.1370 0.1370 0.0548Failure Time 9 0.1233 0.1096 0.0822Operating Time 10 0.1370 0.1370 0.0685Constant operation 8 0.1096 0.0548 0.0685Mean Time to repair 7 0.0959 0.0822 0.0411Current system compatibility 10 0.1370 0.1370 0.1096Startup time 4 0.0548 0.0411 0.0137Best Option based on weighted Criteria 1.0000 0.8904 0.6301
Thermal Model Pugh Analysis
CriteriaImportance
RankingWeighted Ranking ANSYS ProE
System Stability 8 0.1290 0.1129 0.1129Ease of Use 7 0.1129 0.1129 0.1129Thermal Modeling Capability 10 0.1613 0.1613 0.0645Thermal Model 9 0.1452 0.1290 0.0968Correct results 10 0.1613 0.1613 0.0806Constant operation 8 0.1290 0.0645 0.0806
Mean Time to repair 7 0.1129 0.0968 0.0484Current system compatibility 1 0.0161 0.0161 0.1290Startup time 2 0.0323 0.0323 0.0161Best Option based on weighted Criteria 1.0000 0.8871 0.7419
Project 06005 Page 87 of 93
Preliminary Design Review 5/12/2006
10.6 Gantt Charts
Week 6 Week 7 Week 8 Week 9 Week 10Mike Code Reasearch METEOR 3 Launch METEOR 2005 Research PDR
CANCELLED Code ReasearchPeer Review
Vivek GPS research METEOR 3 Launch PDRCANCELLED 70cm Tx Research
Peer ReviewJennifer Basic GUI base METEOR 3 Launch Continue designing window PDR
Joystick and axis map CANCELLED Joystick applicationPeer Review
Rina Software research METEOR 3 Launch PDRTemperature Modeling CANCELLED Temperature ModelingPeer Review
Rich Determine reqs METEOR 3 Launch PDRfor propellor design CANCELLED Rotor Software SearchPeer Review
Fall 2005
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Team Add code to software to integrate Verify
Meeting GUI, joystick, propeller motor, backup GPS PDRChanges
Vivek Team VerifyMeeting Update Documentation for PDR PDR
PCB Express Layout/Board Redesign ChangesJennifer Team Verify
Meeting Redo PDR Documentation PDRChanges
Rina Team VerifyMeeting Review new software PDR
ChangesRich Team Verify
Meeting Learn XROTOR Software PDRChanges
Winter 2005
Project 06005 Page 88 of 93
Preliminary Design Review 5/12/2006
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Week 9 Week 10Mike Continue integration Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results
Launch Repair Platform Launch Documentation CDRAssist w/ assembly Rebuild Platform
Vivek Begin assembly Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultsof platform for launch Launch Repair Platform Launch Documentation CDR
Rebuild PlatformJennifer Integrate software Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Results
with ACS Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly
Rina Testing METEOR 3 Document Temp Data Testing METEOR 4 Review ResultsFluent / MATLAB Launch ANSYS Thermal Modeling Launch Documentation CDR
Rich Review software and Testing METEOR 3 Review Launch Results Testing METEOR 4 Review Resultstest with motors Launch Rebuild Platform Launch Documentation CDRAssist w/ assembly
Spring 2005
Project 06005 Page 89 of 93
Preliminary Design Review 5/12/2006
10.7 Functional Diagrams Diagram of OSD Functionality: Diagram of ACS:
InitializationPower Up Reset
Get Heading
Get Acceleration
Clear WDT
ScreenCount Done?
Reset OSD Template Screen
1 0
iAPRSLoopCount Done?
Send APRS Packet to TNC
1 0
Current Video Camera Counter
Done?
Roll Video Camera
1 0
Create OSD Template Screen
ScreenCount = 0
iAPRSLoopCount = 0
iCameraLoopCount = 0
igetDataCounter Done?
1 0
igetDataCounter = 0
Get Pressure
Get Temperature
Get GPS
Update OSD
Increment Counters
Print Heading onto OSD
Print Acceleration onto OSD
Project 06005 Page 90 of 93
Preliminary Design Review 5/12/2006
10.8 System Diagram
Motor
Actuator(Propeller)
70-cm Tx439.25 MHz
Video Overlay
Video Camera 1
GPS(Harris)
2 Internal Temp
Sensors
Pressure Sensor
3 Accelerometers
Digital Compass
RS232
/ 2Analog
TTL
RS232
Analog
/ 3Analog
Beacon
MAX232(RS232 Driver)
TTL
RS232
RS232
VIDEO MUX
Video Camera 2
Video Camera 3
Video Camera 4
DUAL UART MUX
TTL TTL
PIC
ADC
/ 3Select Lines
/ 3Select Lines
DEMUX
Power Control
2-m Tx/Rx
RTS Signal
TTL
/ 2Analog
2 External Temp
Sensors
TNCDuplexer
Analog Compass
Composite
Digital Compass
/ 4N S E W
Analog
Composite
Composite
Composite
Composite
/ 3Select Lines
GPS(Tyco)
FM Tx144.39 MHz
RS232 Driver
TTL
RS232
TNC
Tones
TTL
Driver(Joystick
Coordinates from 2-m Tx/Rx to PIC)
Photovoltaic Cells,
DC to DC Converter
Project 06005 Page 91 of 93
Preliminary Design Review 5/12/2006
10.9 Launch Preparation Diagram
Project 06005 Page 92 of 93
Preliminary Design Review 5/12/2006
Project 06005 Page 93 of 93