Micro-CART
Spring 2007 Status Report
Microprocessor-Controlled Aerial Robotics Team (Ongo-03)
Client
Iowa State University
Department of Electrical and Computer Engineering
Dr. Gregory Smith
Team Leader
Kito Berg-Taylor (2nd Semester AeroE)
Brian Baumhover (2nd Semester CprE)
Advisors
Dr. John Lamont
Prof. Ralph Patterson III
Dr. Gregory Smith
Second Semester Team Members
Bill Hughes
EE
Pankaj Makhija
EE
Hassan Javed
Bai Shen
EE
CprE
First Semester Team Members
Alyson Young
CprE
Todd Kreykes
CprE
Guillermo Hernandez
CprE
Ricardo Fonseca
CprE
Jim Christgau
Bret Staehling
Priyanka Singh
Matt Lichti
EE
EE
EE
EE
Byung Kang
Patrick Turner
EE
CprE
Secondary Team Members
Jeff Pries
Brett Pfeffer
Dennis Lund
ME
ME
ME
Sponsor
DISCLAIMER: This document was developed as a part of the requirements of an electrical and
computer engineering course at Iowa State University, Ames, Iowa. This document does not
constitute a professional engineering design or a professional land surveying document. Although
the information is intended to be accurate, the associated students, faculty, and Iowa State
University make no claims, promises, or guarantees about the accuracy, completeness, quality,
or adequacy of the information. The user of this document shall ensure that any such use does
not violate any laws with regard to professional licensing and certification requirements. This use
includes any work resulting from this student-prepared document that is required to be under the
responsible charge of a licensed engineer or surveyor. This document is copyrighted by the
students who produced this document and the associated faculty advisors. No part may be
reproduced without the written permission of the senior design course coordinator.
Spring 2007
-i-
March 30th, 2007
Table of Contents
1
Introductory Materials ............................................................................................................. 1
1.1
Executive Summary ....................................................................................................... 1
1.1.1
Need for the Project ............................................................................................... 1
1.1.2
The Project ............................................................................................................ 1
1.1.3
Results to date ....................................................................................................... 2
1.1.4
Present Accomplishments ..................................................................................... 2
1.1.5
Pending Work ........................................................................................................ 3
1.2
Acknowledgements ........................................................................................................ 3
1.3
Problem Statement......................................................................................................... 4
1.3.1
General Problem Statement .................................................................................. 4
1.3.1.1
IARC Background .................................................................................................. 4
1.3.1.2
Summary of Competition Rules ............................................................................. 6
1.3.2
General Solution Approach ................................................................................... 6
1.3.2.1
Micro-CART’s Solution .......................................................................................... 6
1.3.2.2
Micro-CART’s Approach ........................................................................................ 7
1.4
Operating Environment ................................................................................................ 10
1.5
Intended User(s) and Use(s) ........................................................................................ 11
1.5.1
Initial User(s) ....................................................................................................... 11
1.5.2
Future User(s) ..................................................................................................... 11
1.5.3
Initial Use(s) ......................................................................................................... 11
1.5.4
Future Use(s) ....................................................................................................... 11
1.6
Assumptions and Limitations ....................................................................................... 11
1.6.1
Assumptions ........................................................................................................ 12
1.6.2
Limitations............................................................................................................ 13
1.7
Expected End Product and Other Deliverables ........................................................... 16
2
Project Accomplishments and Current Status ...................................................................... 16
2.1
Previous Accomplishments .......................................................................................... 17
2.2
Present Accomplishments ............................................................................................ 28
2.3
Future Required Activities ............................................................................................ 32
2.3.1
Future Activities for Spring 2007 Semester ......................................................... 32
2.3.2
Ongoing Activities ................................................................................................ 32
2.4
Current Project and End-product Status ...................................................................... 33
2.4.5
Software Development and Testing .................................................................... 43
2.4.6
Order Spare Parts ............................................................................................... 45
2.4.7
Document all connectors and wiring with photographs ....................................... 45
2.4.8
Test Flight Control Software ................................................................................ 45
2.4.9
Fulfill Reporting Requirements for Senior Design Course .................................. 46
2.5
Recommendations for Continued Work ....................................................................... 46
3
Documentation of Current Efforts and Results ..................................................................... 46
3.1
Project Definition Activities ........................................................................................... 46
3.2
Research Activities ....................................................................................................... 46
3.2.1
Flight Controls Research ..................................................................................... 46
3.2.2
GPS Research ..................................................................................................... 47
3.2.3
Sonar Research ................................................................................................... 47
3.2.4
Ground Station System Research ....................................................................... 47
3.2.5
Secondary Vehicle Research .............................................................................. 47
3.3
Design Activities ........................................................................................................... 47
3.3.1
Flight Controls Design ......................................................................................... 47
3.3.2
Ground Station System Design ........................................................................... 48
3.3.3
Airframe Design ................................................................................................... 48
3.3.4
Secondary Vehicle Design .................................................................................. 48
3.4
Implementation Activities ............................................................................................. 48
3.4.1
Flight Controls Implementation ............................................................................ 48
Spring 2007
- ii -
March 30th, 2007
3.4.2
GPS Implementation Activities ............................................................................ 48
3.4.3
Sonar Implementation ......................................................................................... 48
3.4.4
Compass Implementation .................................................................................... 49
3.4.5
Ground Station System Implementation .............................................................. 49
3.4.6
Airframe Implementation ..................................................................................... 49
3.4.7
Secondary Vehicle Implementation ..................................................................... 49
3.5
Testing and Modification Activities ............................................................................... 49
3.5.1
Flight Controls Testing ......................................................................................... 49
3.5.2
GPS Testing ........................................................................................................ 50
3.5.3
Sonar Testing ...................................................................................................... 50
3.5.4
Compass Testing ................................................................................................. 50
3.5.5
Ground Station System Testing .......................................................................... 50
3.5.6
Airframe Testing .................................................................................................. 50
3.5.7
Secondary Vehicle Testing .................................................................................. 50
4
Resources and Schedules .................................................................................................... 51
4.1
Resource Requirements .............................................................................................. 51
4.1.1
Personnel Effort Requirements ........................................................................... 51
4.1.2
Financial Requirements ....................................................................................... 55
4.2
Schedules ..................................................................................................................... 57
4.2.1
Project Schedule ................................................................................................. 57
4.2.2
Schedule Status .................................................................................................. 63
4.2.3
Deliverable Schedule ........................................................................................... 64
5
Closure Material .................................................................................................................... 65
5.1
Lessons Learned .......................................................................................................... 65
5.1.1
What went well .................................................................................................... 65
5.1.2
What did not go well ............................................................................................ 65
5.1.3
What technical knowledge was gained ............................................................... 65
5.1.4
What would be done differently ........................................................................... 65
5.2
Risk and Risk Management ......................................................................................... 65
5.2.1
Anticipated Risks ................................................................................................. 65
5.3
Project Team Information ............................................................................................. 68
5.3.1
Client Information ................................................................................................ 68
5.3.2
Faculty Advisor Information ................................................................................. 68
5.3.3
Student Team Information ................................................................................... 69
5.4
Closing Summary ......................................................................................................... 74
5.5
References ................................................................................................................... 75
5.6
Appendices ................................................................................................................... 76
Spring 2007
- iii -
March 30th, 2007
List of Figures
Figure 1.3.2.1 IARC defined Level 1 behavior. ............................................................................ 7
Figure 2.1a Landing Gear ........................................................................................................... 22
Figure 2.1b Donated GPS circuit. ............................................................................................... 23
Figure 2.1c Constructed sonar circuit. ...................................................................................... 23
Figure 2.1d Compass Comm. Board to be integrated. ............................................................ 24
Figure 2.1e XTEND-PKG 900MHz wireless data-link. ............................................................... 24
Figure 2.1f The new head block. ................................................................................................ 26
Figure 4.2.1 Project task schedule for Ongo3a – Airframe Subsystem ..................................59
Figure 4.2.2 Project task schedule for Ongo3a – Controls Subsystem ..................................60
Figure 4.2.3 Project task schedule for Ongo3a – Sensors Subsystem...................................61
Figure 4.2.4 Project task schedule for Ongo3a – Ground Station ...........................................62
Figure 4.2.5 Project task schedule for Ongo3b – Secondary Vehicle .....................................63
Spring 2007
- iv -
March 30th, 2007
List of Tables
Table 4.1.1.1 Estimated and Actual Hourly Contribution – Team Leader ...............................53
Table 4.1.1.2 Estimated and Actual Hourly Contribution – Controls Subteam ......................53
Table 4.1.1.3 Estimated and Actual Hourly Contribution – GS Subteam ................................54
Table 4.1.1.4 Estimated and Actual Hourly Contribution – Sensor Subteam .........................54
Table 4.1.1.5 Estimated and Actual Hourly Contribution – Airframe Subteam ......................54
Table 4.1.1.6 Estimated and Actual Hourly Contribution - Secondary Vehicle ......................54
Table 4.1.2 Other Required Resources ......................................................................................55
Table 4.1.3 Estimated Financial Budget .....................................................................................56
Table 4.1.3b Actual Financial Requirements .............................................................................57
Table 4.2.1 Controls Subteam Deliverables Status ...................................................................64
Table 4.2.2 Sensors Subteam Deliverables Status ...................................................................64
Table 4.2.3 Ground Station Subteam Deliverables Status .......................................................64
Table 4.2.4 Airframe Deliverables Status ...................................................................................64
Table 4.2.5 Secondary Vehicle Subteam Deliverables Status .................................................65
Table 4.2.6 Project Status Chart For Senior Design Deliverables ...........................................65
Spring 2007
-v-
March 30th, 2007
List of Definitions and Acronyms
Attitude ............ The orientation of an aircraft's axes relative to a reference line
or plane, such as the horizon
AUVSI .............. Association for Unmanned Vehicle Systems International
FMC .................. Flight mission capable
GPS .................. Global positioning system
GSS .................. Ground station system
IARC ................. International Aerial Robotics Competition
IMU ................... Inertial Measurement Unit
IRQ ……………..Interrupt Request Line
Micro-CART ..... Microprocessor-Controlled Aerial Robotics Team
NMEA…………..GPS Communication Standard
PC/104 .............. A form factor for embedded computing
PIC .................... Programmable interface controller
PID……………...Proportional integral derivative
Pitch ................. Revolution of a vehicle forward and backward on a central axis
PWM ................. Pulse-width modulation
RC………………Remote control
Roll ................... Revolution around the longitudinal axis of a vehicle
UAV .................. Unmanned aerial vehicle
WIKI .................. (What I Know Is) A public documentation repository
DSL …………….A versatile 50MB Linux distribution
Yaw ................... Revolution around the vertical axis of a vehicle
Spring 2007
- vi -
March 30th, 2007
1 Introductory Materials
To get acquainted with the project, several sections have been written to give an
overview and conceptual description of the competition, the project problem, the
project itself, and the current semester’s efforts.
1.1 Executive Summary
The following section describes the project in short, gives some background, and
summarizes this status report.
1.1.1 Need for the Project
The College of Engineering at Iowa State University is on a mission to become
one of the top engineering programs in the nation. With this comes the need to
draw the brightest students and publicly display its quality of education at the
national level. The College of Engineering also works hard at giving their
students the best educational experience possible. To make this experience
affordable the university needs a way to minimize costs. Bringing in companies
to help finance projects makes this possible. A clear way to attract students and
display the quality of education, while bringing in financiers, is through
participation in well-known, highly technical competitions where current students
have a chance to demonstrate the abilities and experience they have gained at
the university. Since this project has such real world applicability and such
breadth it is a great learning experience and provides a indication of what
working in the real world is like. The Microprocessor-Controlled Aerial Robotics
Team (Micro-CART) was conceived as a senior design project in order to provide
Iowa State University one such opportunity.
The Micro-CART project is scheduled as an ongoing project aimed at developing
a robust and expandable system to compete in any future IARC scenarios. The
Micro-CART team is currently working to meet all necessary milestones to
compete in the July 2007 IARC, demonstrating Level 1 behavior which requires
fully autonomous hover and waypoint navigation capabilities.
1.1.2 The Project
The Micro-CART primary vehicle team is enhancing a pre-built RC helicopter to
serve as Iowa State University’s entry into the summer 2007 IARC. The end
product will be a vehicle capable of autonomous take-off and landing, as well as
flight through a series of up to five waypoints. Each year thereafter the helicopter
will be upgraded to exhibit more complex behavior.
To allow Micro-CART to compete in higher levels of competition, an additional
team has been established with the mission of designing a secondary vehicle.
This vehicle will be capable of autonomous navigation, communicating with the
primary vehicle, and image processing. By coordinating with the primary vehicle,
Spring 2007
-1-
March 30th, 2007
this secondary vehicle will eventually allow the team to compete in IARC
Competition levels that require indoor flight.
1.1.3 Results to date
The following tasks were completed prior to the current school session:
Primary Vehicle
 Designed and built several different mounting platforms for hardware
components
 Designed a sonar interface system with unknown accuracy
 Upgraded servos and rotor head block
 Specified, purchased and integrated a 2D compass
 I/O software existed. However, it needed to be updated and debugged for
the new PC/104 board.
 Software for communications between helicopter control board and
ground station was specified, but not written.
 Software for communications between helicopter control board and
ground station was specified, but not written.
 The kill switch was believed to be functional, but there was no transmitter
for triggering the kill switch.
 Electronic components were mounted to the helicopter system.
 System had a patchwork wiring system.
 Existing means for protecting the system included an aluminum test
harness and a skirt.
Secondary Vehicle
 Designed and build vehicle prototype
1.1.4 Present Accomplishments
The following tasks were completed during the current school session:
Primary Vehicle
 Integrated a 3D compass module into the system.
 Completed full performance testing on the sonar unit and determined that
the sensor is quite accurate over a range of 6 inches to 20 feet. Integrated
the sensor into the control unit software system.
 Ordered two new GPS’s and began testing.
 Acquired manual control battery.
 Purchased parts needed to make a low-cost USB-compatible barometric
pressure-based altimeter.
 Ordered a new PC/104 board and replaced servo.
 Successfully upgraded I/O software, which is now fully functional for all
sensors.
Spring 2007
-2-
March 30th, 2007













Wrote PID software that works with the simulator. Control software can be
run on a PC computer or the new PC/104 board.
Simulator software is fully functional.
The team reviewed and revised the existing communications protocol
specification. Began coding.
Added a battery monitoring software module to the control software.
Revised GUI specification.
The mechanical structure is flight ready.
The engine is now flight ready.
Ordered and tested new kill switch transmitter
Wiring harness has been designed.
Code written for joystick control during manual override
Mounted a GPS to the helicopter.
Ordered and began construction on a Barometric-Pressure Altimeter
Ground Station laptop replaced with a desktop
Secondary Vehicle
 Evaluated the current vehicle design
 Tested existing motors and batteries
 Purchased and tested new concept vehicle
 Researched alternate vehicle designs
 Decided upon new vehicle design
1.1.5 Pending Work
The following tasks have yet to be completed:
Primary Vehicle
 Complete full performance testing of compass.
 Develop software and test Barometric-Pressure Altimeter
 Complete full performance testing of GPS.
 Pilot training for manual override.
 Code battery monitor.
 New ground station computer needs to be ordered.
 Parachute and/or airbags need to be finalized and installed.
Secondary Vehicle
 Complete vehicle design
 Determine and purchase necessary hardware components
 Fabricate vehicle body and mount components
 Develop and test flight control software
1.2 Acknowledgements
Micro-CART would like to give special thanks to the following people and
organizations for their assistance:
Spring 2007
-3-
March 30th, 2007






Professor John W Lamont, Assistant Professor Ralph Patterson III,
and Dr. Greg Smith for sharing their professional experience and
guidance throughout the course of this project.
Lockheed Martin Corporation for their generous financial contribution to
this costly endeavor. Without their assistance this project would not be
possible.
The Department of Electrical and Computer Engineering for creating
the Micro-CART project and providing the skills and knowledge required
for this project.
Eric Frana for volunteering his time to help calibrate the helicopter and fly
test flights.
Barry Buelow and Rockwell Collins for support and guidance in flight
control software architecture & flight control.
Dr. Jerald Vogel of the Department of Aerospace Engineering for his
guidance in the interpretation and application of the collected controls
data.
1.3 Problem Statement
The following sections describe the problem this system must solve; the general
problem statement outlines the competition itself, and the general solution
approach describes how Micro-CART plans to achieve the solution.
1.3.1 General Problem Statement
The International Aerial Robotics Competition (IARC) is an annual event
organized by the Association for Unmanned Vehicle Systems International
(AUVSI). The Microprocessor-Controlled Aerial Robotics Team (Micro-CART)
was formed to launch Iowa State University into this competition. The projected
entry date is summer 2007.
1.3.1.1 IARC Background
Founded in 1990 by Robert Michelson, a professor at the Georgia Institute of
Technology, the IARC draws collegiate teams from all over the world. Designed
to exercise the engineering skills of the participants, the competition rules have
changed to provide new mission parameters over the years. Competition
participants are to present an autonomous aerial vehicle designed to complete a
specified mission. The mission is performed in an arena-like setting in fair
weather conditions. Participants are then judged on their vehicle’s overall design
and performance.
The first competition required the aerial vehicles to identify, retrieve, and deliver a
small disk to a predetermined area. The completion of that mission brought about
another scenario and the IARC has thus progressed into its 4 th mission.
Past Missions:
Spring 2007
-4-
March 30th, 2007
1990 – 1995: Identify and retrieve a disk
1996 – 1997: Survey a toxic waste dump and identify hazards
1998 – 2000: Scout a disaster site and identify survivors
Current Mission:
Level 1: Autonomous flight must be demonstrated over a distance of 3 km
beginning at a designated starting point and ending in an autonomous
hover or orbit about a final waypoint. Up to four way points must be visited
along the path.
Level 2: Progression to Level 2 may only begin after Level 1 has been
successfully demonstrated. Level 2 will be completed when a team can
demonstrate that it has identified a designated target structure from an
autonomous aerial robot. Identification will be from cues given in the
example missions. Additionally at least one open entry into the structure
must be identified by the aerial robot. Judges must be able to determine
clearly that the robot has detected the target building and its openings
without human intervention.
Level 3: Level 3 may be attempted only upon completion of Level 2. To
complete Level 3, reconnaissance data taken from the autonomous aerial
vehicle (or subvehicle) operating from within the target environment must
be relayed back to the designated starting point, (or simulated starting
point 3 km away). Three mission scenarios will be available for selection,
these include: a hostage situation, a nuclear reactor failure, and a
biological contagion scenario. Prior to a run, a team must declare which
of the mission scenarios (and hence the target type) they will be
attempting. Sufficient image quality will be required for the judges to obtain
the desired reconnaissance information.
Level 4: Level 4 may only be attempted after team has demonstrated
Level 3 behavior. Level 4 is achievement of the complete mission profile in
under 15 minutes. The first team to achieve Level 4 will be awarded the
competition prize money if no other team is able to progress to Level 4. If
more than one team is able to complete Level 4, then the team able to
execute the mission in the least amount of time will be declared the
winner.
Note: No team has yet completed the final mission. Due to the nature of the
competition, no changes are made until the final level has been completed by at
least one team.
Spring 2007
-5-
March 30th, 2007
1.3.1.2 Summary of Competition Rules
The following is a summary of the basic rules governing vehicle entries for the
2001-2006 IARC competitions (which also serve as system functional
requirements):
1. Vehicles must be unmanned and autonomous. They must compete based
on their ability to sense the semi-structured environment of the
competition arena. They may be intelligent or preprogrammed, but a
remote human operator must not fly them.
2. The air vehicle and sub-vehicle(s) need not carry computational power.
Computers operating from standard commercial power may be set up
outside the competition arena boundary and uni- or bi-directional data may
be transmitted to/from the vehicles in the arena.
3. Data links must be by radio, infrared, acoustic, or other means so long as
no tethers are employed.
4. The air vehicles must be free flying, autonomous, and have no entangling
encumbrances such as tethers.
5. Sub-vehicles may be deployed within the arena to search for, and/or
acquire information or objects. Sub-vehicles must be fully autonomous,
and must coordinate their actions and sensory inputs with all other
components operating in the arena. Sub-vehicles may not act so
independently that they could be considered separate, distinct entries to
the competition. Any number of cooperating autonomous sub-vehicles is
permitted, however, none are required. If used, sub-vehicles must be
deployed in the air from an autonomous aerial robot. Sub-vehicles may be
airborne or multimode (able to operate in the air or on the ground). All
vehicles must remain within the boundaries of the arena.
6. Air vehicles and air-deployed sub-vehicles may be of any size, but
together must weigh no more than 90 kg/198 lbs (including fuel) when
operational.
7. Any form of propulsion is acceptable if deemed safe in preliminary review
by the judges.
1.3.2 General Solution Approach
The following sections describe conceptually how Micro-CART intends to solve
the IARC problem.
1.3.2.1 Micro-CART’s Solution
Micro-CART intends to enter the IARC 2007 competition. Taking into account the
limited time constraints and complexity of the air vehicle design, Micro-CART has
decided to initially enter the competition demonstrating only Level 1 behavior.
Demonstrating Level 1 behavior will require the aerial vehicle to perform the
following tasks, also shown in Figure 1, autonomously and in sequence.
Spring 2007
-6-
March 30th, 2007
1. Take off (this may be done autonomously or manually)
2. Take 5 GPS locations as input (the 5th input will be 3km away)
3. Pass through the first 4 GPS locations, en route to the final location
4. Maintain a standing hover at the 5th GPS location
Figure 1.3.2.1 Level 1 IARC Behavior Defined
Micro-CART has chosen an RC X-Cell model helicopter with a 0.60 in.3 2-stroke
gasoline engine as the basis for its aerial vehicle. The helicopter will have various
sensors and processing components mounted onboard. Onboard components
will include a sonar array, an IMU, a GPS unit, a magnetic compass, a wireless
datalink, a PC/104 board with an ARM9 processor, and a battery power supply.
Other components include a kill switch, manual override, wireless data link,
ground station, and crash protection system.
1.3.2.2 Micro-CART’s Approach
The Micro-CART team intends to have a complete aerial system capable of
exhibiting Level 1 behavior by April, 2007. The team has determined the
necessary components required for Level 1 and is working toward a workable
Spring 2007
-7-
March 30th, 2007
system implementation. At the system’s center, the PC/104 processor board
executes the flight control software, given inputs generated by the Micro-CART
system.
1.3.2.2.1
GPS Software Interface
The GPS software interface shall utilize a GPS unit to sense location information
from satellites and will be integrated into the flight control.
The work required includes:
 The software interface between the GPS unit, PC/104 processor board,
and accompanying subsystem must be tested and verified
 Test and verify GPS subsystem with flight control
 Add IMU/GPS location interpolation
1.3.2.2.2
Functional Sonar Array with Software Interface
The sonar array shall provide altitude readings for takeoff/landing purposes.
The work required includes:
 Test single transducer sonar board under target conditions
 Test the software interface between the sonar unit, PC/104 processor
board, and accompanying subsystems
 Integrate sonar subsystem with flight control
1.3.2.2.3
Magnetic Compass with Software Interface
The magnetic compass shall provide heading information and will be integrated
into the flight control. The work required includes:
 Research ability of compass to handle flight conditions
 Test the software interface between the compass, PC/104 processor
board, and accompanying subsystems
 Integrate compass subsystem with flight control
1.3.2.2.4
Flight Control Development
The on-board flight control shall process all sensor information and continuously
correct flight dynamics for a given heading and altitude. The work required
includes:
 Integrate GPS, compass, sonar and altimeter
 Develop Kalmann filters for preprocessing of sonar inputs
 Test flight control with test stand, and untethered
 Develop battery monitor
 Communicate with ground station
1.3.2.2.5
Wireless Data-Link
The wireless data-link shall provide sensor and flight control information to a
remote ground station. It shall also allow mission commands to be sent to the
helicopter. The work required includes:
Spring 2007
-8-
March 30th, 2007


Test communications subsystem with onboard flight control
Test communications subsystem with ground station
1.3.2.2.6
PC/104
The PC/104 processing board & serial expansion board shall handle data
collection & system control onboard the helicopter. The work required includes:
 All connections to subsystems must be checked for integrity
1.3.2.2.7
Ground Station Development
The ground station shall provide flight control information retrieval from the
wireless data-link and display the current status of the helicopter to the user. It
shall also allow entry of mission parameters to be sent to the helicopter.
 Test ground station with flight control to send/receive flight parameter
 Test commands and real-time PID updates
1.3.2.2.8
Center of Mass Determination
The center of mass determination will allow for adjustment of the flight control.
The work required includes:
 Complete mounting of onboard payload
 Identify the helicopter’s center of mass for the vehicle, with all of the
necessary on-board hardware mounted
1.3.2.2.9
Onboard Electrical System
The onboard electrical system shall provide power to all systems. The work
required includes:
 Program HESC 104 power supply
 Wire power to all systems
 Test battery systems
1.3.2.2.10
Landing Gear Modification
The landing gear will be designed specifically for the aircraft and to
accommodate its components. The work required includes:
 Redesign landing gear as needed
 Design electronics enclosure
1.3.2.2.11
Vehicle Onboard Payload Configuration
The aircraft and flight control will be specifically tuned for the aircraft’s electronic
systems and payload. The work required includes:
 Determine a lightweight mounting scheme for all systems and wiring
 Mount all systems and wiring
 Test kill switch and manual override
 Design system protection method
Spring 2007
-9-
March 30th, 2007
1.3.2.2.12
Financial Evaluation
The documentation shall include all expenses incurred, as well as projected
expenses for project completion. The work required includes:
 Estimate the travel costs and expenses involved in going to the summer
2007 IARC
 Determine all new equipment needed and estimate budget needed to
enter competition
1.3.2.2.13
Secondary Vehicle
The secondary vehicle shall fulfill the specific purpose of phases 2 and 3 of the
competition. The work will be done using current design methods used for the
primary vehicle. Additionally, the secondary vehicle shall be unequal to the
primary vehicle, thereby being dependent upon it and/or the ground station. Work
required includes:
 Complete vehicle airframe design
 Create non-hindering attachment/detachment mechanism to primary
vehicle
 Integrate software concepts into secondary vehicle flight controls
Completing the above mentioned subsystems and tasks by April 2007 will allow
the team to field a level 1 entry into the summer 2007 IARC at the Georgia
Institute of Technology.
1.4 Operating Environment
The IARC is a continuously changing event. With every successful scenario
completion, the IARC creates new scenarios that are more complex and difficult
to accomplish. With the event locations changing every year and little specific
information in the rules describing the actual operating environment for the UAV,
the helicopter must be designed to operate over a diverse outdoor landscape and
be able to handle a variety of weather conditions.
The IARC rules do specify several guidelines that are related to operating
environment. Because this is a summer competition, there will be a low
temperature threshold of about sixty degrees that could extend up to
approximately one hundred degrees Fahrenheit. This allows designers to rule out
winter weather conditions such as snow and hail. It is also stated that human
observers will judge the competition. This statement allows for an assumption
that the UAV will not have to operate in extreme environments, such as fog or
rain, which would limit the visibility of the judges.
The IARC rules do not rule out the possibility of wind, light precipitation, varying
daylight levels, and adverse topography of the competition location. Because
such factors could seriously alter the performance of the UAV, the design must
take these factors into consideration. Both wind and light precipitation could
affect the orientation of the UAV in flight; therefore sensors for pitch, yaw, and roll
Spring 2007
- 10 -
March 30th, 2007
must be used to allow the helicopter to maintain its correct orientation. The
helicopter must also have a capability to detect and adjust to variations in terrain.
1.5 Intended User(s) and Use(s)
The following are brief overviews of the intended users and uses. Underlying all
of the depicted scenarios is an easy-to-use aerial vehicle that uses GPS
locations as input and then autonomously flies to those locations. This
functionality is the focus of this semester’s work.
1.5.1 Initial User(s)
The members of the Micro-CART project team, during the Spring 2007 semester,
will be responsible for entering and operating the aerial vehicle in the July 2007
IARC.
1.5.2 Future User(s)
Development of autonomous aerial vehicles has multiple motivations and
presents endless possibilities. The future users would probably include
individuals with a wide array of experience and technical knowledge, including
hobbyists, researchers, and industry representatives. The fact that the vehicle
will eventually be fully autonomous and carry its own power source makes the
user’s responsibilities quite manageable. It also reduces the technical knowledge
& training required to fly it. Such autonomous vehicles present the capability to
collect data or perform certain operations while not placing a human in harms’
way. Future Micro-CART teams will also modify and use the current vehicle in
future IARC competitions in order to improve its capabilities and gain experience
in the rapidly growing field of unmanned aerial vehicles.
1.5.3 Initial Use(s)
The initial use of the aerial vehicle will be to execute a specific mission in a
structured competition environment, as described in Section 1.3, which details
the general project problem.
1.5.4 Future Use(s)
The manufacturing of such an aerial vehicle could have multiple motivations and
result in a wide variety of different payloads and missions. For example, the
vehicle could be equipped for search and rescue missions, military and local law
enforcement reconnaissance, and/or environmental catastrophe control.
1.6 Assumptions and Limitations
Information regarding system constraints, usage, planning, or availability is
known and stated in the following section or unknown, in which case appropriate
assumptions are stated. The following design constraints simplify the problem by
providing limits to the project definition.
Spring 2007
- 11 -
March 30th, 2007
1.6.1 Assumptions
To maintain guidelines for project progress, the following assumptions have been
made:
1.6.1.1 IARC Competition Requirements May Change
Due to the nature of the competition, the requirements to complete a level and
advance do not change unless one or more teams complete the highest level. As
of July 2006, no team had yet demonstrated Level 4 capabilities, so the
competition requirements will be the same for the July 2007 event. However, this
may not always be the case and future competitions will likely add or modify the
level requirements.
1.6.1.2 Necessary Funding Remains Available
Even upon completion of the system, there remains a possibility for future
modification due to changes in the IARC requirements. Modifications may include
software, electronics and mechanical system upgrades. Funding must also
remain available for maintaining of the vehicle and competition expenses.
Replacement of components will require funding. The team has assumed a
reasonable amount of money will be available for project progress for the Spring
2007 semester.
1.6.1.2 Suitable Hardware and Software is Available at an Affordable Price
In order to accelerate the development process and increase the system’s
reliability, commercial off-the-shelf (COTS) hardware and software will be used
whenever possible.
1.6.1.3 Onboard Computing Systems Will Be Sufficient
An assumption has been made that the selected PC/104 board, CPU, and 128
MB of RAM will be sufficient to execute computations needed to control the flight
of the helicopter.
1.6.1.4 Current Vehicle is Able to Carry Necessary Equipment
Although the helicopter has been tested to determine its in-flight payload
capacity, the assumption has been made that the helicopter can safely and
stably carry all of the equipment necessary to exhibit IARC Level 1 behavior and
compete in future missions.
1.6.1.5 On-Board Memory Sufficient
The team is assuming that the current on-board memory will be sufficient to store
all the required data without having to add additional hardware.
1.6.1.6 Flight Algorithms Are Capable of Controlling the Vehicle
The hardware and software must be able to effectively fly the helicopter without
any costly accidents. It is assumed that the algorithms able to control the
helicopter in competition conditions can be developed and used effectively.
Spring 2007
- 12 -
March 30th, 2007
1.6.1.7 Sensor System Will Provide All Necessary Flight Software Inputs
The previously decided upon sensor system is assumed to be able to provide all
the necessary vehicle state inputs in order for the flight software to be capable of
maintaining flight stability.
1.6.1.8 Attachment of Secondary Vehicle to Primary Vehicle
The primary vehicle will be able to perform its assigned tasks while carrying
and/or instructing the secondary vehicle with minimal loss of performance.
1.6.1.9 Secondary Vehicle IMU Integration
Shared use of the IMU between both vehicles will be possible in the future.
1.6.1.10
Sufficient Available Processing Power
In addition to its own needs, the primary vehicle will be able to process data sent
by the secondary vehicle.
1.6.1.11
Sensors
Horizontal error is assumed to not be a factor, as the helicopter will not be
landing on a steep enough incline to affect the landing. Negligible inclines may
be assumed.
1.6.2 Limitations
The limitations to the system have been studied and documented as a guideline
for future development.
1.6.2.1 Physical Limits of Helicopter
The helicopter has a limited payload capacity, fuel capacity, travel speed, and
dynamic response, which must be taken into account when choosing
components and designing the system to effectively compete at the IARC. The
primary vehicle must be able to fly at least 3 km on a single tank of fuel at a
travel speed of at least 12 km/h, which will allow it to arrive at its destination in at
most 15 minutes. Though the original maximum speed and range of the
helicopter are 25 km/h and 8 km respectively, the fuel consumption and
maximum speed of the vehicle with additional onboard weight can only be safely
approximated as 50% of the original limitations. The speed would then be 12
km/h with a 4 km range. The maximum payload capacity for current thrust
capabilities has been determined to be 17 lbs. The time of flight for a single tank
of fuel has been estimated to be 20 minutes at current capacity. Although this is
adequate for the first level of competition, a larger fuel tank may need to be
installed in the future to allow for a longer running time.
1.6.2.2 Obstacle Detection and Avoidance
In order to avoid potentially costly damage to the helicopter from in-flight
collisions, a method of detecting and avoiding obstacles in the helicopter’s flight
path must be developed, implemented, tested and verified.
Spring 2007
- 13 -
March 30th, 2007
1.6.2.3 Power Consumption Limits
The combined aerial vehicle system needs to be designed to be able to sustain
electrical operations for at least an hour. Sub-systems must be designed and/or
purchased in order to minimize power requirements.
1.6.2.4 Competition Maximum Weight Limit
The competition rules dictate that air vehicles and air-deployed sub-vehicles may
be of any size, but together may weigh no more than 90 kg/198 lbs (including
fuel) when operational. At purchase, the stock helicopter had a wet weight of 12
lbs. As its lift capacity is limited, there is no concern of exceeding the maximum
weight requirement.
1.6.2.5 Competition Requirement That Vehicles Must Be Unmanned and
Completely Autonomous
The competition rules dictate that vehicles, in addition to being unmanned and
autonomous, must compete based on their ability to sense the semi-structured
environment of the competition arena.
1.6.2.6 Competition Requirement That There Be No Physical Connection to
the Vehicle
The competition rules dictate that the air vehicles must have no entangling
encumbrances such as tethers or cables attached to them.
1.6.2.7 Competition Requirement That All Vehicles Remain In the
Boundaries of the Arena
The competition rules dictate that if any vehicles leave the boundaries of the
arena, very strict point losses will be incurred and the team might even face
disqualification.
1.6.2.8 Hindrance of primary vehicle by secondary vehicle
Due to the size of the secondary vehicle, airflow characteristics around the
primary vehicle may change.
1.6.2.9 Secondary Vehicle Weight Constraints
Onboard electronics must not exceed the lift capability of the secondary vehicle
design. Additionally, the secondary vehicle must not exceed the available lift
capability of the primary vehicle.
1.6.2.10
Frequent Team Member Turnover
Team members are only assigned to this project for two semesters. This creates
obstacles such as a lack of skilled pilots, lack of experience with the project, and
increased possibility of loss of completed work, documentation, and specialized
knowledge. While documentation has been created, much time by new members
will have to be spent reviewing previous work and gaining the knowledge needed
to advance the project.
Spring 2007
- 14 -
March 30th, 2007
1.6.2.11
Poor Documentation
Poor documentation from previous Micro-CART teams has caused difficulties
with repeating previously accomplished work and determining the exact project
status. A new computerized documentation system (the WIKI) was established in
the Fall 2005 semester, but much more work is needed entering data. This will
be corrected as part of a major organization task that will take place throughout
each semester.
1.6.2.12
Limited Team Member Expertise
All of the team members have limited experience with most of the hardware used
and many of the tasks required to achieve the project goals. This leads to a
learning curve that can extend for significant periods of time and adversely affect
planned schedules and milestones.
1.6.2.13
Engine, Fuel Tank and Driveshaft
When empty, the fuel vapors in the gas tank are sufficient to cause a substantial
explosion, should they come in contact with a spark or flame.
1.6.2.14
Battery
Leads must be connected with the correct polarity. Also, the leads must be
covered with electrical tape or lead caps at all times or they may short against
stray metal and cause the battery to explode.
1.6.2.15
Wiring
Maximum allowed current traveling through power system AWG-22 wire is 0.92A.
1.6.2.16
Hardware Box for Component Protection
The hardware box must remain lightweight so as not to overload the helicopter,
while remaining robust enough to protect components in case of possible flight
failure.
1.6.2.17
Kill Switch
The circuit components should provide appropriate voltage and current inputs to
operate and trip under emergency situations upon receiving a signal from the
receiver.
1.6.2.18
Sensors
The vehicle may be flying over buildings at the end of the 3km course, requiring it
to fly higher than the 20 foot limit of the sonar. The GPS has an error of 7.5
meters in altitude calculations and these calculations will only tell the altitude
from sea level, which could prove problematic if there is a hill.
1.6.2.19
Spring 2007
GPS
- 15 -
March 30th, 2007
Through the course of the semester, there may not be enough funds to buy a
very accurate unit. Also, the GPS can’t interfere with other equipment. It may
also cause problems due to its low power design.
1.6.2.20
Sonar
The sonar is only accurate between 6 inches and 20 feet.
1.6.2.21
Ground Station
The RF modem supports transfer rates of up to 115.2kbps. However, a transfer
rate of 96kbps will be use to reduce signal attenuation and gain a more reliable
and stable communication channel between the ground station and the controls
system.
1.6.2.22
Weather
Flight testing of the helicopter must occur outdoors. Delays due to weather
cannot be avoided.
1.7 Expected End Product and Other Deliverables
Micro-CART will create a system capable of completing level 1 behavior in the
current IARC mission, and one that is easily modifiable for future missions. The
basis of this system will be an autonomous helicopter capable of taking GPS
locations as input, and flying to those locations. Modifications for future missions
will likely include image recognition, advanced obstacle avoidance, and subvehicle deployment systems.
2 Project Accomplishments and Current Status
This section identifies the work that has been accomplished in the past, the work
accomplished on the project this semester, the required activities for future
semester teams, the current project and end product status, and
recommendations for continued effort.
During previous semesters, Micro-CART has focused on completing tasks
intended to add functionality to the primary vehicle. The end result will be a
system capable of completing Level 1 of the current IARC mission by the end of
the spring 2007 semester. The following is an overview of the steps Micro-CART
needs to take in order to complete this goal.



Purchase initial system (the helicopter) and become acquainted with it
o Status: Complete
Research a method to make the existing system autonomous
o Status: Complete
Purchase or build necessary hardware components
o Status: 95% Complete
Spring 2007
- 16 -
March 30th, 2007






Document hardware components so they can be maintained by future
teams
o Status: Ongoing Commitment
Develop software to interface with hardware components and control the
helicopter
o Status: 90% Complete
Develop ground station software to interface with the helicopter
o Status: 95% Complete
Document software so it can be maintained by future teams
o Status: Ongoing Commitment
Test software and hardware in a comprehensive manner to verify design
and ensure competition readiness
o Status: 40% Complete
Register vehicle in the competition and plan for contingencies
o Status: 30% Complete
In order to achieve Level 1 capability by the end of the Spring 2007 semester,
most of the aforementioned tasks must be successfully completed by a strict
deadline of April 27, 2007 to ensure that the Micro-CART team members are not
struggling to complete any remaining tasks leading up to the competition.
2.1 Previous Accomplishments
Micro-CART has achieved the following milestones prior to the spring 2006
semester:
Fall 1999

Purchased RC helicopter
Micro-CART selected and purchased a 1/60 scale RC X-Cell model
helicopter as the basic aerial vehicle.

Purchased Dell PC
Micro-CART purchased a Dell Dimension XPS T500 PC for use in project
software development and storage.

Research (Ongoing)
Micro-CART researched a variety of project related topics in the past.
Much of this research led to the hardware purchases discussed above and
a compendium of information stored in the team cabinet for future use.
However, much valuable information has been lost due to frequent student
turnover and incomplete documentation.
Spring 2007
- 17 -
March 30th, 2007
Fall 2000

Pilot training (Through Spring 2002)
Pilot training was a focus for previous semesters. Micro-CART has since
terminated this program and seeks experienced pilots from the Iowa State
community for involvement in the project. This is intended to redirect effort
from pilot training to hardware and software development.
Spring 2002

Acquired security box
Micro-CART had a large security box built where the helicopter and all
hardware for the project can be stored. The box is padlocked on both
sides and used to protect existing hardware components.
Fall 2002

Acquired and set up Linux PC laptop
Micro-CART received an additional PC laptop from a retired faculty
member for project use. This laptop was originally used to test the flight
control software, but has since been modified to run the ground station
software.

Hardware acquisitions (Through Spring 2003)
Micro-CART researched and acquired the following hardware for the
project:


HESC104 power supply from Tri-M

NI2020 battery from Inspired Energy

Aaeon PCM5894 PC/104 processor board

144MB disk on chip memory

AMD K6-2 333 MHz processor

Crossbow IMU

Four Polaroid 6500 sonar modules

Several Microchip 16F877-04 PICs

A Pontech servo controller board

Miscellaneous components for the manual override switch.
Serial software development (Through Spring 2003)
Micro-CART developed serial communication software to interface the
various sensors with the PC/104 serial port module. The software was
found to be error-prone by the current team and was rewritten.
Spring 2007
- 18 -
March 30th, 2007

PIC programming (Through Spring 2003)
Micro-CART discovered the HITech PIC compiler after a period of
research and began working with the PIC programmer. The compiler
supported a wide variety of PICs, up to the 16-series. Because the GUI
was not user friendly, many problems were encountered before progress
was made. Nonetheless, the effort resulted in a system with which C
programs could be compiled and burned to PICs.
Spring 2003

Power system
A system to provide power to the PC/104 stack via a wall outlet or a
battery was developed and tested. A standard computer power supply
was used in conjunction with a wall outlet as the first option. The
previously acquired NI2020 battery and HESC104 power supply from TriM provided the second option.

Mounting platform
A mounting platform was designed and installed between the main body
and the landing skids. However, the design was deemed to be ineffective
and has since been removed.
Spring 2004

Magnetic compass acquisition and development
A magnetic compass was acquired in order to provide the necessary
vehicle heading measurements needed by the flight control software. The
software interface between the compass and the PC/104 serial port
module was developed and verified to operate correctly.

Flight control simulator
A simulator containing a very high fidelity model of the helicopter
dynamics was developed and verified. The simulator could be effectively
used to determine the suitability of any developed flight control software
with full confidence that the results would be the same in an actual flight
test.

Manual override switch
The previous design of the manual override switch was analyzed and
refined. It was then implemented on a breadboard and thoroughly tested
to ensure correct operation. After successfully completing the breadboard
testing phase, the circuit was constructed on circuit board for further
testing and eventual implementation onboard the autonomous vehicle.
Ultimately, the circuit was tested on the helicopter and verified to operate
correctly.
Spring 2007
- 19 -
March 30th, 2007

Emergency kill switch
A method to quickly shut off the helicopter engine was researched. After
devising a simple scheme to achieve this goal, the appropriate circuit was
designed and implemented on a printed circuit board. Finally, the circuit
was promptly tested on the helicopter itself and verified to operate
correctly.

Helicopter electrical system design
The onboard electrical system of the helicopter was designed and
assembled. A battery was load tested and determined to be capable of
providing approximately 70 W of power for an hour. In addition, the power
needs of all of the onboard hardware were measured and determined to
be approximately 50 W in the worst case scenario with all of the sonar
modules activated. Finally, the software on the HESC104 power supply
was researched, understood and refined in order to provide additional
available functionality and to turn off the internal counter to reduce power
loss.

Center of mass determination
An accurate test to determine the helicopter’s center of mass was
developed. It involved using a string to suspend the vehicle from various
chassis locations and then taking certain measurements. The results of
the test were very close to the predicted values for the helicopter without
any additional onboard hardware.
Fall 2004

Enclosure fabrication
The previous enclosure design was reviewed and then revised based on
the updated functional needs of the enclosure. The team decided that
having the enclosure professionally fabricated for improved quality and
reduced production time would be worth the additional cost.
This
enclosure has since been deemed ineffective due to weight
considerations, and has been replaced.

Flight control software system design
A complete onboard flight control system was created. The system was
multi-threaded and designed to make each subsystem an independent
module interacting with other subsystems only when needed. The system
used the existing hardware drivers with some minor modifications. The
flight control subsystem was completed, but the sensor subsystems were
only partially completed.
Spring 2007
- 20 -
March 30th, 2007

Helicopter reassembly
The helicopter was fully repaired after being damaged in a crash. All
servos and control linkages were reinstalled and re-calibrated. Broken
bearings in the main rotor assembly were replaced and corrections were
made to previous tail boom repairs. The clutch was identified as broken
and not salvageable; a replacement was purchased and installed. The
gyroscope was repaired and its functionality was verified. The R/F
receiver, battery, and gyroscope were mounted and secured to the nose
section.

Updated power requirements
Updated power information on existing documents and included GPS
information. Estimated length of operation based on needs and load test
results.

Designed and tested voltage regulators
A variable voltage regulator was designed as a contingency plan. It was
intended for newer components that usually consume less power and
required lower voltage input. (Current voltage outputs are 5 and 12
VDC).

Multiple module sonar unit
Previous issues with running more than one sonar module connected to
the PIC microcontroller were resolved. Resolution required changing
some of the PIC I/O settings and fixing connection issues. Two sonar
modules were successfully tested on the same circuit. Further testing of all
four modules was still required but estimates of any further problems were
low.

Single sonar board fabrication
A single sonar module was required for the hover test flight. All previous
test platforms operated on a breadboard circuit, thus a permanent fixed
circuit board was fabricated, tested, and verified.

Purchased replacement PC/104 processor board
While upgrading and updating the current PC/104 processor board, the
team encountered many errors and lockups, most notably PCI bus errors.
It was determined that these issues could not be fixed and a new ICP
Electronics WAFER-6820-733 PC/104 board was purchased. The team
was very pleased with the new board’s added features, reduced weight,
and reduced power consumption.
Spring 2007
- 21 -
March 30th, 2007

Helicopter simulator testing
Various testing was done to simulate signal noise, decreased sensor
accuracy, alter simulation inputs to more accurately reflect physical sensor
data, and sensor loss. In the case of sensor loss the controller would
maintain enough stability that it could be assumed that pilot would be able
take control and manually land with little difficulty. In all other cases the
controller proved very robust and was able to maintain flight stability and
complete the simulation.
Spring 2005

Landing Gear Fabrication
New landing gear made from aluminum piping was designed, built, and
mounted on the helicopter to allow for equipment enclosure to be attached
to the under body of the vehicle.
Figure 2.1a Landing Gear

Helicopter brought to Flight Mission Capable Status
Lockheed Martin rebuilt the XCell helicopter, replacing many significant
parts on the aircraft to bring it back to flight mission capabilities.
Spring 2007
- 22 -
March 30th, 2007

Developed, tested and verified GPS software interface
Lockheed Martin donated an Allstar 1200 GPS unit. The GPS unit should
be accurate enough for the needs of Micro-CART. A GPS software
interface has been developed and tested.
Figure 2.1b Donated GPS circuit.

Completed work on sonar circuit and software interface
Using a PIC16F877 microcontroller, four Polaroid 6500 sonar transducers,
and a MAX233A serial communications chip, the team designed and built
a sonar ranging system.
Although constructed, this unit was still not satisfactory, as later teams had
issues with the board burning up consistently. The system described here
has since failed and has been replaced.
Figure 2.1c Constructed sonar circuit.
Spring 2007
- 23 -
March 30th, 2007

Purchased and tested magnetic compass software interface
A V2Xe from the Precision Navigation Instruments (PNI) Corporation was
acquired and tested.
Figure 2.1d Compass Comm. Board to be integrated.

Acquired wireless data-link
An XTend RF Communications Module was purchased to serve as a
wireless data-link for communications between the air-vehicle and ground
station.
Figure 2.1e XTEND-PKG 900MHz wireless data-link.

Ground station development and implementation
The ground station system was intended to provide guidance to the flight
control system onboard the aerial vehicle. This system was not completed
this semester.
Spring 2007
- 24 -
March 30th, 2007

Designed, implemented,
electrical system
tested
and verified
onboard
vehicle
The power requirements of each component on the helicopter were
compiled and recorded. From this, a power regulation and distribution
circuit board was designed and manufactured. The board received a full
test and was implemented immediately.

Integration of subsystems into flight controller
All the separate subsystems were nearing completion and were intended
to be integrated into the flight controller once they were tested and verified
separately.

Updated the project website
An overhaul of the project website was completed this semester.

Future financial needs researched
The future financial needs of the team were estimated by evaluating the
cost of any remaining parts needed, the entry fee and travel expenses for
attending the IARC, funds for any repairs or emergencies, and predicted
financial needs as the team prepares to compete at higher levels of the
IARC.
Fall 2005

Created a WIKI
The team set up a WIKI as a centralized location for all documentation
with an easy web interface.

New Hardware Enclosure
A new hardware enclosure was created to address weight and size issues
of the old hardware enclosure. New materials were researched and
material for a lighter enclosure was acquired. Components were attached
to a carbon-fiber composite board and hang underneath the helicopter.
Note that the equipment was out in the open- ie: not really “enclosed”. It
was determined that this was acceptable for Level-1 competition.

Purchased Flight Test Stand
A test stand was purchased to let the team fly the helicopter with less fear
of crashing. After being purchased, it’s cradle was modified to allow for the
additional size of the helicopter after the computer systems were mounted.

New Head Block
Transportation of the helicopter to Eagan, MN in Spring 2005 left the
helicopter damaged. A new head block was obtained and installed in the
Fall 2005 semester. The old head block was plastic and had considerable
Spring 2007
- 25 -
March 30th, 2007
problems with vibrations. A new aluminum head block was purchased and
installed. This new head block was a higher quality part that fit better,
providing less room for vibrations to develop.
Figure 2.1f The new head block.
Spring 2006

Documented collective controls
The flight control subteam researched the collective controls of the
previous flight control code to create documentation for the new flight
control hover code.

Flight Control Hover Code
The flight control subteam worked on creating hover only flight control
software. This code was intended to allow the helicopter to maintain an
autonomous hover at a designated height.

Research and Replacement of Sonar
The Micro-CART team put a large amount of time and effort into
researching and repairing the current Sonar system. At the end of the
semester a decision was made to replace the whole sonar assembly with
an entirely new design.

Research and Replacement of GPS
The Micro-CART team spent a large amount of time and effort researching
and documenting possible GPS replacements. At the end of the Spring
2006 semester a donated GPS device was received from a fellow Senior
Design team.
Spring 2007
- 26 -
March 30th, 2007

Helicopter Flight with Test Stand
The Micro-CART team attempted to complete flight tests with the
helicopter using the newly remodeled flight test stand purchased in Fall
2005. Modifications were required and repairs were made for future
testing.

Manual Override Circuitry
The manual override circuitry was reviewed, tested and verified to be
operational.

Flight Simulator Repair
The flight control subteam spent a great deal of time repairing and
rewriting the flight simulation software to be used on a Unix system.

Updating Financial Records
The Micro-CART team spent time researching the financial status of the
Micro-CART project. Records including excel documents recording the
research were made available on the team WIKI.

Forum
The Micro-CART team implemented a team forum to communicate
questions and ideas in a secure fashion on the Internet. The forum also
facilitated cross-team communication and information sharing with the
secondary vehicle team (Ongo-03b).
Fall 2006

Fixed Component Mounting Platform
The original carbon fiber board used to mount hardware components were
damaged the previous semester. It was replaced with a nylon based
board.

Fixed Test Stand
The test stand’s cradle was bent out of shape after repeated test flights. It
had to be manually fixed twice to continue testing.

Created New Wiring System
A new wiring system was created to replace the old one. The wiring
system was made smaller and more scalable than the previous wiring
system and took into account future component additions.

Created New Sonar System
A new sonar array was researched and components for it were
purchased. The new system consists of a single 8 channel analog to
digital converter and an individual SensComp sonar transducer. This
board was intended to serve as an interface between the computer and up
to 7 more sonar transducers.
Spring 2007
- 27 -
March 30th, 2007

Moved Compass Mount
The helicopter was found to exhibit a large magnetic field surrounding the
engine block. It was determined to be enough to affect the compass
readings. As a result, the compass was re-mounted on the tail a safe
distance from the field.

Tested New GPS
The GPS acquired during the spring 2006 semester was tested with the
manufacturer’s proprietary software and found to be working correctly.

Developed New Flight Control Software
The current flight control software was determined to be incomplete and
not capable of flying the helicopter autonomously. The software was
almost completely rewritten but still used some pieces of the old code.

Tested Flight Control Software
The flight control software was tested onboard the helicopter using the test
stand and was found to be capable of maintaining basic autonomous
hover.

Fixed Ground Station Keyboard
The laptop used as the ground station had been suffering from keyboard
problems since the spring 2006 semester. It was completely replaced with
a new keyboard in an attempt to solve the problem once and for all.

Replaced Old or Damaged Components
The PC/104 power supply and PC/104 processor board were both
damaged during lab tests. The power supply was replaced with an
identical unit purchased from the manufacturer. The processor board was
replaced with a TS-7330 200MHz ARM board along with a backup x86
board in Spring 2007.

Operating System Modifications
The DSL operating system that runs the flight control software was
modified to start the flight control software automatically, as well as to
eliminate unneeded services while the helicopter was in flight. This was
also done to free up IRQs to be used with the serial port module.
2.2 Present Accomplishments

Compass Integration
Accomplishments: The team located, purchased, and integrated a 3D
compass module into the system. They developed the algorithms and
software needed to communicate with the sensor and determine compass
Spring 2007
- 28 -
March 30th, 2007

headings, using corrections from 3D data supplied by the compass
module.
Sonar Integration
The team completed full performance testing on the unit and determined
that the sensor is quite accurate over a range of 6 inches to 20 feet. They
developed a linear regression model of sensor altitude vs. sensor voltage
and have integrated the sensor into the control unit software system.

GPS Purchase and Integration
The team specified and purchased a new low-cost GPS unit. In testing,
the team has had difficulty with a cable that connects the GPS sensor to a
USB communications board. As a result, the team purchased new cables
for the unit and a second low-cost GPS unit. They will determine which of
the two units will perform best in a flight system.

Purchase of Barometric Altimeter
The team has located and purchased parts needed to make a low-cost
RS-232-compatible barometric pressure-based altimeter.

Replacement of Control Board
The team found a new PC/104 board with ten serial ports, adequate
memory and processing power, and adequate Linux support, purchased
the board, installed the Linux tool chain, and ported all the existing
software to the new board. In addition, the team tested the PC/104 power
supply and determined that it was still functional and useable.

Updating and Debugging of I/O Software
I/O software was successfully upgraded and is fully functional for all
sensors.

PID Controls Software Development
PID software has been written and works with the simulator. Control
software can be run on a PC computer or the new PC/104 board. The
software can fly a helicopter model in the simulator and is ready to be
tested with the helicopter hardware.

Simulator Software Development
Previously found simulator software was adapted for use with Micro-CART
control software. Simulator software is now fully functional.

Control System Software Development
The team reviewed and revised the existing control system protocol
specification. Coding is now in progress.

Battery Monitoring Software Development
Spring 2007
- 29 -
March 30th, 2007
The team decided to add a battery monitoring software module to the
control software. They have completed software design and specification.
Coding is yet to be completed.

Ground Station Hardware
The team installed Ubuntu Linux on the ground station laptop computer
and tested the system. They determined that the computer was not fast
enough to support needed ground station functions. As a result, the team
submitted a proposal to the College for a new laptop computer. The team
later learned that the proposal review will not be completed until July. As a
result, the team is considering other options for a capable laptop
computer. As a backup, the team will use a desktop computer for the
ground station.

Ground Station Communications
The team reviewed and revised the existing ground station protocol
specification. Coding is now in progress.

Ground Station Navigation Software Development
The team decided to use a simple navigation approach to reach IARC
Level I performance. They will fly the helicopter at high altitude, to avoid
obstacles and give the helicopter control software room for variations in
altitude and course. The simple navigation software module has been
developed by the controls team and runs on the helicopter control board.
More complex navigation methods and software will be developed for later
phases.

Ground Station GUI Development
GUI software did not exist. Previous teams did complete a simple GUI
specification. The team has revised the GUI specification.

Mechanical Structure Inspection
The team inspected the mechanical structure and found the system flight
ready.

Engine Tuning and Testing
The team tested and tuned the engine. They purchased and mixed new
gas/oil, drained and filled the tank, started and ran the engine, and tuned
engine controls. The engine is now flight ready.

Manual Override Development
The team tested operation of the manual override switch and determined
that it was functional. They also determined that the manual control
battery was losing capability to hold charge. The battery should hold
charge for 4-5 hours, in operation, but only holds charge for about 40
minutes. A new battery was purchased.
Spring 2007
- 30 -
March 30th, 2007

Kill Switch Development
The team purchased and tested a transmitter. The transmitter was found
to be functional, but the kill switch failed in the first engine/system test.
The team resolved the problem and the kill switch is now flight ready.

Electronics Enclosure Development
The team considered several different options for shielding components
and decided to design a new platform with removable side and bottom
shields. The team completed enclosure design and construction.

Wiring Harness Development
The team designed a flight capable wiring harness and specified wire and
connectors for the new harness. Parts were ordered and the harness
needs to be built, installed, and tested.

Battery Systems Development
The team replaced the main system battery with a battery borrowed from
the Micro-CART secondary vehicle team. The damaged main battery was
taken to a local vendor to see if it could be recovered, by recharging, and
reused. The main battery was permanently damaged and could not be
reused. The team tested the communications battery and determined that
it was flight ready. The team tested the main controller battery and
determined that it needed to be replaced. The team decided to replace the
existing ground station computer. As a result, they did not extensively test
the ground station computer battery. However, the battery and computer
both appear to be functional.

System Protection Development
The current team decided to use a software simulator as a primary means
of protecting the system from crash damage. The team felt that simulating
sensor, control, and ground station software with a helicopter simulator
first would help avoid early crash risk. The system is now ready for early
hardware testing.
The team intends to use the existing test harness and the existing (or a
replacement) skirt during hardware testing. The team is also working on
an in-flight protection method that uses a parachute and air bag(s)
deployed by the kill switch transmitter. In the event of catastrophic in-flight
system failure, the team will trigger the kill switch and, simultaneously, the
parachute and air bag(s). The parachute will be used to orient the
helicopter for crash landing and slow helicopter descent. The air bag(s)
will cushion the helicopter during crash landing.
A parachute is currently being constructed, a method for deploying the
parachute has been identified, and an air bag was obtained and tested. Air
bag testing identified two concerns: magnitude of reaction force may
Spring 2007
- 31 -
March 30th, 2007
cause damage to the helicopter and air bags usually deflate in just a few
seconds. To address the issues, the team is considering using several
smaller airbags and blocking airbag openings that cause the airbags to
deflate.
2.3 Future Required Activities
To reach completion, the following activities must be accomplished.
2.3.1 Future Activities for Spring 2007 Semester
Before July 2007, the Spring 2007 team will:

Test the system’s ability to complete Level I behaviour
To ensure that the system is capable of performing reliably in the 2007
IARC competition it will be necessary to complete the flight test portion of
the project plan. This means that the system will need to undergo
extensive flight tests with appropriate documentation, and any necessary
changes will need to be made to the system.
2.3.2 Ongoing Activities
To maintain project understanding of subsystems as well as keep a working
system as a whole, the following tasks must be done in an ongoing fashion.

Sensor review and improvement
Once all sensor systems are completed, they should be constantly
reviewed to check for accuracy and ways to improve performance.

Flight control software review and improvement
Although significant progress has been made in the development of flight
control software, the process of refining and upgrading the software
should continue in perpetuity for the duration of the project.

Flight testing
The helicopter must be regularly test flown and maintained in nominal
operating condition. Test flights not only give team members a chance to
better understand the flight dynamics of the vehicle, but also provide
valuable experience to the pilots, should the need ever arise to manually
take control of the vehicle in the middle of an autonomous flight sequence.

Helicopter repair and maintenance
Regular maintenance ensures proper helicopter operation and familiarizes
the team with all of the equipment. The helicopter must be immediately
repaired should a crash occur and returned to a fully operational state.
Even after the vehicle is repaired, it must be regularly maintained in order
to ensure that the risk of in-flight failures is minimized.
Spring 2007
- 32 -
March 30th, 2007

Thorough documentation of project
The process of documenting the project status and technical details is one
that should be ongoing for the duration of this project. It is critical that
future teams have a comprehensive knowledge of exactly what work has
been done on this project in order to avoid the inefficiency of redoing
previously accomplished tasks. All found, previous documentation should
be added to the project WIKI, and the WIKI should be updated with every
change.
2.4 Current Project and End-product Status
The Micro-CART team is working hard to complete all of the deliverables that
were planned to be finished by the end of this semester, as outlined in previous
sections describing the expected end products. Despite setbacks due to
unexpected equipment failures and lack of experience with the project hardware,
significant progress is being made in getting the vehicle ready for entry into the
IARC. More detailed information about the status of each end product can be
found in the subsections that follow.
Subtask 1.1 – Establish Meeting Time
Subtask Objective: Determine a time to meet regularly as a team.
Subtask Approach: Compare schedules, select times that work for the
greatest number of team members.
Subtask Assignment: Kito Berg-Taylor
Subtask Time Allocated: 10 working days, starting on January 8, 2007.
Subtask Expected Result: A date and time is determined where most team
members can meet and this information is submitted to the advisors no
later than 12:00 PM on Friday, January 19, 2007.
Subtask Current Status: Complete
Subtask 1.2 – Update website
Subtask Objective: Keep the Micro-CART website up to date. This will
keep advisors, client, and others informed concerning project status.
Subtask Approach: Update website to contain the most recent team
information.
Subtask Assignment: Bai Shen
Spring 2007
- 33 -
March 30th, 2007
Subtask Time Allocated: 6 working days, starting on Jan 30, 2007.
Subtask Expected Result: Website is fully brought up to date no later than
2:00 PM on Tuesday, February 6, 2007.
Subtask Current Status: Complete
Subtask 1.3 – Project Plan
Subtask Objective: Create a document detailing project goals, including
description, approach, and resource considerations.
Subtask Approach: Use existing documentation from last semester as a
starting point, make updates to reflect changes for the current semester.
Subtask Assignment: Jeff Pries, Alyson Young, Kito Berg-Taylor
Subtask Time Allocated: 10 working days, starting on January 29, 2007
Subtask Expected Result: The project plan is completed and submitted to
the advisors no later than 12:00 PM on Friday, February 9, 2007.
Subtask Current Status: Complete
Subtask 1.4 – Finalize Project Plan
Subtask Objective: Revise the project plan. Print and bind a copy of the
project plan and post an electronic copy of it on the Micro-CART website.
Subtask Approach: Revise the project plan by following the
recommendations made by the advisors. Have the revised project plan
printed and bound using a third party printing service. Upload an electronic
copy to the Senior Design FTP site and modify the Micro-CART website to
link to it.
Subtask Assignment: Jeff Pries, Alyson Young, Kito Berg-Taylor
Subtask Time Allocated: 7 working days, starting on February 19, 2007.
Subtask Expected Result: The project plan is revised following the
advisors recommendations. A bound copy of the revised project plan is
submitted to the advisors no later than 12:00 PM on Tuesday, February
30, 2007. An electronic copy of the revised project plan is posted on the
Micro-CART website no later than 12:00 PM on Tuesday, February 30,
2007.
Spring 2007
- 34 -
March 30th, 2007
Subtask Current Status: Complete
Subtask 1.5 – Select Future Team Leadership
Subtask Objective: Select the team members who will perform
administrative duties during the spring 2007 semester.
Subtask Approach: Select the team members who will perform
administrative duties by way of popular vote. Positions to be determined
are team leader, communications coordinator, software subteam leader,
hardware subteam leader, and ground station subteam leader.
Subtask Assignment: Kito Berg-Taylor
Subtask Time Allocated: 15 working days, starting on April 2, 2007.
Subtask Expected Result: The team members who are to perform
administrative duties during the Fall 2007 semester are elected by popular
vote, and all agree to act in the positions they have been elected to. The
task is completed no later than Friday, April 20, 2006.
Subtask Current Status: Incomplete
Subtask 1.6 – Poster
Subtask Objective: To create a poster that is visually pleasing and
informative as part of the course requirements
Subtask Approach: Using information about the project including previous
documentation and pictures taken. Create a visually pleasing poster using
templates available. Try to change the color to make it pop. Update any
old data.
Subtask Assignment: Bill Hughes
Subtask Allocated Time: 1 week
Subtask Expected Result: A poster that is both visually pleasing and educational.
Subtask Current Status: Complete
Subtask 1.7 – Unbound Status Report
Subtask Objective: Create a document detailing the current status of the
project, including the current status of all tasks, and recommendations for
future work.
Spring 2007
- 35 -
March 30th, 2007
Subtask Approach: Use existing documentation from the previous
semester as a starting point and make updates to reflect changes for the
current semester.
Subtask Assignment: Brett Pfeffer, Jeff Pries, Alyson Young, Kito BergTaylor
Subtask Time Allocated: 15 working days, starting on March 12, 2007.
Subtask Expected Result: The project status report is completed and
submitted to the advisors no later than 12:00 PM on Friday, March 30,
2007.
Subtask Current Status: Complete
Subtask 1.8 – Finalize Status Report
Subtask Objective: Revise the project status report. Print and bind a copy
of the status report and post an electronic copy of it on the Micro-CART
website.
Subtask Approach: Revise the status report by following the
recommendations made by the advisors. Have the revised status report
printed and bound using a third party printing service. Upload an electronic
copy to the Senior Design FTP site and modify the Micro-CART website to
link to it.
Subtask Assignment: Brett Pfeffer, Jeff Pries, Beyong Kang, Patrick
Turner, Alyson Young, Kito Berg-Taylor
Subtask Time Allocated: 10 working days, starting on April 23, 2007.
Subtask Expected Result: The project status report is revised following the
advisors recommendations. A bound copy of the revised status report is
submitted to the advisors no later than 12:00 PM on Wednesday, May 2,
2007. An electronic copy of the revised project plan is posted on the
Micro-CART website no later than 12:00 PM on Wednesday, May 2, 2007.
Subtask Current Status: Incomplete
Subtask 1.9 – In-Class Presentation
Subtask Objective: Create a slideshow presentation outlining the project.
Have all team members present information to the Senior Design class
regarding their contribution to the project.
Spring 2007
- 36 -
March 30th, 2007
Subtask Approach: Prepare a slideshow presentation using Microsoft’s
PowerPoint application. Include general project information, descriptions
of the different hardware and software components, and an outline of the
current semester’s goals. Rehearse the presentation several times before
hand to minimize mistakes.
Subtask Assignment: Hassan Javed will discuss requirements. All team
members, primary and secondary vehicle, will present.
Subtask Time Allocated: 15 working days, starting on March 9, 2007.
Subtask Expected Result: A slideshow presentation is prepared using
Microsoft’s PowerPoint application. The slideshow includes general
project information, descriptions of the different hardware and software
components, and an outline of the current semester’s goals. All team
members have a part in the presentation and have rehearsed two times or
more with the rest of the team. The presentation meets the time
requirements set before hand and includes all required information as
dictated by the project advisors. The presentation is given to the Senior
Design class at 2:00 PM on Thursday, March 29, 2007.
Subtask Current Status: Complete
Subtask 1.10 – IRP Presentation
Subtask Objective: Create a slideshow presentation outlining the project.
Have all team members present information to the IRP judges regarding
their contribution to the project.
Subtask Approach: Utilize the slideshow created in subtask 1.8. Rehearse
the presentation several times before hand to minimize mistakes.
Subtask Assignment: Hassan Javed
Subtask Time Allocated: 16 working days, starting on April 6, 2007.
Subtask Expected Result: A slideshow presentation is prepared using
Microsoft’s PowerPoint application. The slideshow includes general
project information, descriptions of the different hardware and software
components, and an outline of the current semester’s goals and
accomplishments. All team members have a part in the presentation and
have rehearsed two times or more with the rest of the team. The
presentation meets the time requirements set before hand and includes all
required information as dictated by the project advisors. The presentation
is given in front of the IRP judges at 2:15 PM on Wednesday April 25,
2007.
Spring 2007
- 37 -
March 30th, 2007
Subtask Current Status: Incomplete
Subtask 1.11 – Team Evaluation Forms
Subtask Objective: All team members will evaluate the performance of
other people on the team.
Subtask Approach: Use the team evaluation forms provided on the Senior
Design website to evaluate team members.
Subtask Assignment: All Micro-CART team members
Subtask Time Allocated: 1 working day.
Subtask Expected Result: All team members have been accurately
evaluated and the evaluation is used in determining each student’s final
letter grade. All evaluation forms are submitted to the advisors by April 15,
2007.
Subtask Current Status: Incomplete
2.4.2 Task Set 2 – Power/Payload/Overrides
Task Objective: Test existing hardware components to ensure correct
functionality. Design, build, and test new hardware components if necessary.
Task Approach: Perform unit testing on each existing hardware component
before integrating it with the system. Design new components carefully and test
them thoroughly before fabrication and integration with the existing system.
Subtask 2.1– Get Batteries and Power to Ready Status
Subtask Objective: Make sure all batteries are operational, determine
battery life. Decide upon a battery for the ground station.
Subtask Approach: For all current batteries put a load on the battery and
see how long it lasts, to determine battery life. After running the battery to
minimum level, charge it and measure charge time. Check to make sure
all connections are sound to avoid discharge. For the ground station
battery determine the power needs of the RF modem then research
ground station battery so the battery lasts throughout the competition.
Periodically spot check the HESC power supply to determine working
condition and how power is distributed
Subtask Assignment: Hassan Javed, Pankaj Makhija, Bill Hughes
Spring 2007
- 38 -
March 30th, 2007
Subtask Time Allocated: 1 week
Subtask Expected Results: We have batteries that meet requirements and
specifications.
Subtask Current Status: Complete
Subtask 2.2 – Get Overrides Working on Individual Receivers
Subtask Objective: The kill switch is ordered and working on a separate
RF transmitter and receiver. Manual override is working and the helicopter
can be flown manually from up to 3km, the max distance competition
distance.
Subtask Approach: Test that the circuit components provide appropriate
voltage and current inputs to operate and trip under emergency situations
upon receiving a signal from the kill switch. Hook the manual override up
to a RF transmitter and try to control the helicopter. Before extensive
testing with the manual override someone should be a skilled “pilot.”
Subtask Assignment: Bill Hughes and Hassan Javed
Subtask Time Allocated: 2 weeks
Subtask Expected Results: if the engine is started and the kill switch is
triggered, the engine stops running. The kill switch operates over a
separate RF transmitter. Manual override can take control at any distance
under 3km and be used to fly the helicopter as desired, including
landing/takeoff.
Subtask Current Status: Complete
Subtask 2.3 – Assembling the Hardware, Wiring and Hardware Box
Subtask Objective: Update the helicopters existing framework, including
wiring. Make improvements by designing, building, and testing new
components, such as a hardware box, to protect wiring and components.
Streamline wiring. Test the stand for sturdiness and operational status.
Subtask Approach: Design and determine the number of wires and
connectors needed in the system. Draw a system diagram and figure out
the number of connectors to be used and the wires. Assemble and wire
the system by using different length wires and connectors so that the
wiring is streamlined and not hanging all over the helicopter. Research
and order new material that fits the requirements for a protective covering.
Spring 2007
- 39 -
March 30th, 2007
Plan and develop a shape that works with the material and the
components. Software tools like CAD can be used. Fashion the material
into the dimensions necessary for the design. Forming/bending, cutting,
and drilling may be necessary. Mount electronic components into boxes
as specified in design. Determine the best method to protect exposed
wires. Tests will be run to make sure the components behave as desired
while in the box. Visually inspect the current stand and manually check
connections. Research the requirements of a stand, both materials and
dimensions, and possibilities.
Subtask Assignment: Hassan Javed, Pankaj Makhija, Bill Hughes and
Dennis Lund
Subtask Time Allocated: 10 weeks
Subtask Expected Result: The helicopters wiring system is organized and
protected, along with the components by April 14, 2007.
Subtask Current Status: Complete
Subtask 2.4 – Engine Tuning, Payload Verification, Safety
Considerations
Subtask Objective: Engine is tuned to get rid of air bubbles and leakage.
The payload is known. Systems have been installed to cushion the
helicopter in case of crash or rough landing.
Subtask Approach: Padded landing gear and a parachute are the main
ideas. Look into materials and consider design alternatives in an
experimental way. Look into the mathematical and physical effect a
parachute, of a reasonable size, would have if a helicopter crashes at 60ft.
Determine whether or not a parachute will successfully reduce impact
damage on the helicopter.
Subtask Assignment: Jim Christgau
Subtask Time Allocated: 4 weeks
Subtask Expected Results: The helicopter is protected against
impact/vibrations due to crashing and landing/takeoff.
Subtask Current Status: Parachute Not Complete
2.4.3 Task Set 3 – Ground Station Tasks
Spring 2007
- 40 -
March 30th, 2007
Task Objective: Perform ground station related activities such as flight tests, test
stand maintenance, and mechanical work on the helicopter.
Subtask 3.1 – Order Upgraded Computer
Subtask Objective: Get a computer that runs the necessary programs with
higher efficiency and can meet specifications of the project.
Subtask Approach: Determine the constraints on the computer, find a
matching computer, and order.
Subtask Assignement: Guillermo Hernandez and Ricardo Fronseca
Subtask Allocated Time: 3 weeks
Subtask Expected Results: A computer that can run ground station.
Subtask Current Status: Incomplete
Subtask 3.2 – Communication Module Ready
Subtask Objective: To have the ground station exchange data with the
helicopter.
Subtask Approach: Design the protocol for the module, then implement
the module and define module interfaces. Research specifications by
looking at IARC website and helicopter requirements. Determine how to
parse data received and send it out in a manner the flight controls can
understand. Testing will be performed on the implementation.
Subtask Assignment: Guillermo Hernandez
Subtask Allocated Time: 5 weeks
Subtask Expected Result: The ground station can receive up-to-date data
from the helicopter and send up-to-date data to the helicopter.
Subtask Current Status: Incomplete
Subtask 3.3 – GUI at Ready
Subtask Objective: The GUI provides an interface between the helicopter
and the user.
Subtask Approach: Implements a GUI that has information as stated in the
requirements.
Spring 2007
- 41 -
March 30th, 2007
Subtask Assignment: Ricardo Fonseca
Subtask Allocated Time: 3 weeks
Subtask Expected Results: The GUI displays current status information for
the following systems GPS, sonar, compass, servo, and IMU. GUI allows
user to input waypoint information, edit flight path, and allows user to
specify how often the helicopter will provide sensor data back to the
ground station.
Subtask Current Status: Complete
2.4.4 Task Set 4 – Sensors Development and Testing
Task Objective: Develop and test sensors to ensure proper operation and
autonomy in flight.
Subtask 4.1 – GPS Ready
Subtask Objective: Get the GPS up and running and sending data to the
controls when asked.
Subtask Approach: Power up the GPS and hook it up to the USB port of a
computer. Read GPS data with hyperterminal. The GPS should be
situated in a way as that a signal can be acquired. Capture and analyze
captured data, GPS uses NMEA protocol. Create a program that has
functions that return desired information when called. The validity of the
GPS’s altitude information should be analyzed by looking at gathered
data. The affect of the blades in motion and the signal will be tested.
Subtask Assignment: Alyson Young
Subtask Allocated Time: 4 weeks
Subtask Expected Results: Data can be retrieved at the will of the control
software. Tests have been preformed verifying accuracy and interference
problems. Altitude reliability is known.
Subtask Current Status: Incomplete
Subtask 4.2 – Compass Ready, Including Data Retrieval Software
Subtask Objective: Compass returns heading when prompted by the
controls software.
Spring 2007
- 42 -
March 30th, 2007
Sub task Approach: Power up the compass and use hyperterminal on a
computer to read data. A way to understand the output will be needed and
a way to regulate the retrieval of data. Look at existing compass files for
ideas. Old files are based on a 2D compass. A new communications
board is needed, because the old board and compass only received 2D
data. Tests regarding magnetic field while engine is on should be
conducted, so the compass isn’t placed in an area that has an
overpowering magnetic field.
Subtask Assignment: Bret Staehling and Alyson Young
Subtask Allocated Time: 4 weeks
Subtask Expected Results: The compass sends data to the controls in
proper format when queried.
Subtask Current Status: Incomplete
Subtask 4.3 – Sonar Ready, Including Data Retrieval Software
Subtask Objective: The sonar returns altitude, for heights under 20ft, when
prompted by the controls software.
Subtask Approach: Power up the sonar and read values and use a device
to compare measured values. Determine percent error, based on a
derived formula for converting voltage to height. Create software that
returns altitude values when prompted. Run tests for interference
problems.
Subtask Assignment: Mat Lichti
Subtask Allocated Time: 4 weeks
Subtask Expected Results: Sonar returns valid data for altitudes no
greater then 20ft, when prompted by the controls system. The sonar
doesn’t experience any excessive interference, based on position on the
helicopter.
Subtask Current Status: Complete
2.4.5 Software Development and Testing
Task Objective: Develop and test software that will allow the helicopter to fly
autonomously.
Task Approach: Develop software incrementally and perform unit tests on the
different software subsystems.
Spring 2007
- 43 -
March 30th, 2007
Subtask 5.1 – Battery Monitor
Subtask Objective: Develop a program for monitoring battery levels, to
ensure the system will operate properly.
Subtask Approach: Determine the indicators and the cut off level for the
battery before it is non-functional. Determine the best way to monitor,
using software, and test to make sure accurate data is supplied.
Subtask Assignment: Todd Krekes
Subtask Allocated Time: 3 weeks
Subtask Expected Results: Monitoring software creates a warning when
battery power approaches minimum operational levels.
Subtask Current Status: Incomplete
Subtask 5.2 – Simulator Software
Subtask Objective: Autonomous flight is achieved in the simulator.
Subtask Approach: Find pitch, yaw, roll, collective, and throttle need for
takeoff and landing. Find pitch, yaw, roll, collective, and throttle needed for
forward flight. Look into the affect of wind and other elements. Look at
documentation from past successful projects at other schools.
Subtask Assignment: Brian Baumhover
Subtask Allocated Time: 6 weeks
Subtask Expected Results: The helicopter can fly autonomously in
simulation.
Subtask Current Status: Complete
Subtask 5.3 – Helicopter Autonomous Flying Achieved
Subtask Objective: Autonomous flight can be achieved outside of the
simulator.
Subtask Approach: Determine key differences between simulation and
real world flight. Look at the assumptions and ideals used in the simulator
and figure out how to replicate them and move them into the real world.
Use test stands and test skirts before trying for complete autonomous
flight. Determine tendencies and how to compensate for it. Run tests for
Spring 2007
- 44 -
March 30th, 2007
given flight patterns and look at responses of the helicopter while in test
stand and skirt.
Subtask Assignment: Brian Baumhover and Priyanka Singh
Subtask Allocated Time: 3 weeks
Subtask Expected Results: The helicopter can fly autonomously and is
ready for the three required flight tests for competition.
Subtask Current Status: Incomplete
Subtask 5.4 – Ground Station Interface Ready
Subtask Objective: Controls can both receive and send data to ground
station.
Subtask Approach: Determine communications protocol with the ground
station. Decode and encode messages to receive and send information to
the ground station. Pass navigation information to the navigation module.
Subtask Assignment: Todd Kreykes
Subtask Allocated Time: 2 weeks
Subtask Expected Results: Helicopter relays appropriate data, with regard
to heading, when prompted by ground station. Helicopter retrieves
necessary data to determine new heading from the ground station.
Subtask Current Status: Incomplete
2.4.6 Order Spare Parts
Spare parts will be needed in the event that a component fails during the
competition or during autonomous flight tests and needs to be replaced.
2.4.7 Document all connectors and wiring with photographs
The connections and wiring of the helicopter’s components need to be
photographed and documented for future teams because there have been new
components added and the wiring has been updated. This should eliminate
future confusion in the wiring of the system and prevent components from being
damage due to incorrect connections.
2.4.8 Test Flight Control Software
An autonomous hover has been achieved but due to persistent hardware failures
and malfunctions, complete testing of the software has not been accomplished.
Spring 2007
- 45 -
March 30th, 2007
2.4.9 Fulfill Reporting Requirements for Senior Design Course
The WIKI has centralized all knowledge pertaining to the project and is constantly
updated with new progress reports from the team. Logbooks are still maintained
for personal accountability and project plans and status reports are still
developed for presentation to those outside the project.
2.5 Recommendations for Continued Work
It is recommended that this project be continued as originally envisioned. MicroCART has a clear idea of the tasks that must be accomplished in order to field a
successful entry into the 2007 IARC and the future work to compete repeatedly
for the lifetime of the project. Despite the complexity of the problem at hand and
limited team experience, the project in its current state is a worthwhile pursuit,
due to its concretely defined goals and the experience it provides to the team
members. Any change in the direction of the project at this point will result in a
lengthy restructuring phase where very little will get accomplished. Although the
current schedule is ambitious and many unaccounted for problems are likely to
occur, the overall project as well as the present team members will benefit more
from staying the current course.
3 Documentation of Current Efforts and Results
This section describes all activities from Spring 2007 and their outcomes. A
stable hover has been achieved and full flight in the simulator. Yaw control and
forward flight have been added. Future steps will include hardware integration
tests.
3.1 Project Definition Activities
The current goal of Micro-CART has already been clearly defined as the
development of an autonomous helicopter capable of exhibiting IARC Level 1
behavior.
3.2 Research Activities
The following subsections document the details of the various research activities
performed this semester. A great deal of research has been done this semester,
partially to address equipment failures. Research has been conducted on the
compass, GPS, serial board, data logging, flight control algorithms, and battery
replacement.
3.2.1 Flight Controls Research
Research for the control systems focused on two areas. The first was to research
what methods were used by previous competition entries and then to determine if
they were suitable for Micro-CART. The second area of research focused on the
environmental conditions of the competition site and their impacts on vehicle
control.
Spring 2007
- 46 -
March 30th, 2007
3.2.2 GPS Research
Before development of the software interface for the GPS could begin it was
necessary for the developers to familiarize themselves with the NMEA-0183
communication protocol which is used for receiving data from the GPS module.
The team acquired a copy of a NMEA reference manual and located the NMEA
sentences that provide information which the flight control system needs. The
sentences were then analyzed and the best way of parsing them was chosen.
3.2.3 Sonar Research
The sensors team focused their research efforts for the sonar on the
manufacturer’s specifications and the requirements of the control team.
3.2.4 Ground Station System Research
The primary research activities of the ground station subteam were related to
system performance. The team researched the comparative advantages of a
multithreaded and single-threaded environment, eventually settling on a
multithreaded approach for better responsiveness and possible performance
increases. Research was also conducted into other areas relating to system
performance, including the choice of programming language used to develop the
ground station software.
3.2.5 Secondary Vehicle Research
Due to its current stage of development, research for the secondary vehicle
focused primarily on concept testing. First, gear design and possible drive
systems for the vehicle were researched. Next, options for vibration damping on
the test stand were considered. Research for other senior design projects was
also conducted by the secondary vehicle team.
3.3 Design Activities
This section describes each design task worked on during Spring 2006.
3.3.1 Flight Controls Design
Controls design was focused on two areas. Primary focus was on software
architecture. The software architecture was extended to encompass a
multilayered approach utilizing two PIDs for each of the roll and pitch axes, and a
single PID for the yaw and throttle axes. The program flow was split into a
navigation, movement and stability section, with the outputs from each segment
driving the input to the next lower-level segment.
The second design area focused on the simulator communication interface. A full
hardware-in-the-loop simulator was developed based on the autopilot project’s
simulator. The simulator was extended to feature sensor-level emulators for
microCART’s IMU and servo controller, allowing the flight control software to
interface directly with the simulator and fly its helicopter directly. The OpenGL
Spring 2007
- 47 -
March 30th, 2007
portions of the simulator were then re-integrated into a new program which
provided specific testing related information about the state of the vehicle as well
as real-time graphs of the system’s position and attitude.
3.3.2 Ground Station System Design
Flight control testing software was developed that proved to be a useful method
for assessing the health of the vehicle and performance of the controller, so the
interface developed for the simulator was used as a basis for design and layout
of the ground station GUI. The system’s control logic was then modified to
perform the ground station’s required tasks.
3.3.3 Airframe Design
The vehicle’s sensors were assigned permanent locations within the airframe,
which allowed the distances between each sensor and its necessary connections
to be documented. With this document it was then possible to develop a wiring
harness to connect all the sensors. The harness was developed, using vibration
resistant connectors going into each system for durability and convenient
maintenance.
3.3.4 Secondary Vehicle Design
Design efforts focused on creating a small, light-weight DC to DC converter for
power distribution.
3.4 Implementation Activities
Previously designed and tested systems which were or will be implemented
during Spring 2007 are described in the following sections.
3.4.1 Flight Controls Implementation
The flight control software went through an extended implementation and testing
phase which involved methodical implementation of functionality combined with
thorough testing of the new functionality. For more information on this process
refer to section 3.5.1.
3.4.2 GPS Implementation Activities
The GPS sensor interface was developed in two parts. Software was written to
initialize the GPS module and begin acquiring satellites. The software was then
augmented with a module responsible for parsing the NMEA sentences and
extracting the relevant data.
3.4.3 Sonar Implementation
Implementation of the sonar concentrated on determining a relationship between
signal voltage and object distance. The relationship is what will be responsible for
the sonar’s ability to detect changes in position.
Spring 2007
- 48 -
March 30th, 2007
3.4.4 Compass Implementation
Sensor interface code was developed in conjunction with the flight control team,
and was integrated into the flight control software. The software reads the raw
magnetic fields from the compass, and then processes the measurements down
into determine helicopter heading between -180 and 180 degrees.
3.4.5 Ground Station System Implementation
The ground station was implemented in two phases. First, the GUI was
developed and sent to the system’s operator for feedback. After a GUI was
completed that was acceptable to all parties, the underlying logic was
programmed, which allowed the ground station to meet its stated requirements.
3.4.6 Airframe Implementation
To protect the onboard payload in the case of a failure, a proctective box was
created. In the area of sensor overrides, an independent receiver and transmitter
for the kill switch was found.
3.4.7 Secondary Vehicle Implementation
Implementation activities for the secondary vehicle team included fabrication of a
co-axial contra rotation test stand, as well as work done on integrating the
secondary vehicle micro-processor and input/output boards.
3.5 Testing and Modification Activities
The following subsections highlight the testing procedures used and how the
results were used to make appropriate changes to the system.
3.5.1 Flight Controls Testing
During the initial software development phase it was essential to verify that all
inputs and outputs were received as expected and processed correctly. To help
automate the process the flight control subteam developed unit tests that could
be run at any time which could quickly and definitively verify the integrity of the
inputs and conversions.
The developed software generated large quantities of outputs that needed to be
checked for accuracy. For each run of the flight controller approximately one to
two hundred data points were generated each second. The outputs and
intermediate checkpoints were loaded, along with the sensor inputs, that
produced them, into a Matlab script, which then allowed a quick overview of the
flight profile, PID responses, and sensor responses.
Once the software was sufficiently developed to be able to control the helicopter,
the control system was tested and debugged in the safe environment of the
hardware-in-the-loop simulator. Simulation in conjunction with the Matlab test
suites, allowed for quick turnaround times between tests and data analysis, as
well as a much safer and lower-cost alternative to traditional flight testing.
Spring 2007
- 49 -
March 30th, 2007
As the flight control software matured in complexity and reliability it became
beneficial to have real-time feedback of the vehicle’s state. At this point the
helicopter was tested with the full simulator interface, which allowed the tester to
quickly gauge whether the vehicle’s responses were measured and smooth or
excessive. The flight controller then ran the vehicle through a full flight profile in
the simulator, with all of its responses carefully monitored in real-time graphs.
3.5.2 GPS Testing
The GPS was tested for functional performance in two key areas. The first step
was to determine the speed at which data could be acquired from the unit. The
GPS was tested for quick satellite fix and rapid, consistent output of location
information. After both had been established, the GPS sensor was further tested
against known positions to determine its accuracy and precision.
3.5.3 Sonar Testing
Sonar testing concentrated on determining the sonar’s range, accuracy with
increasing distance, and the allowable angle for accurate results. The sonar was
also tested to ensure proper A/D conversion and communication.
3.5.4 Compass Testing
Tests were conducted to determine the allowable amount of magnetic
interference before readings were no longer reliable.
3.5.5 Ground Station System Testing
As the ground station was being developed each module was tested to ensure
that it responded correctly to input. The individual modules were then assembled
and tested as a whole for proper functioning with prerecorded data and testing
modules. Once the ground station was working as a combined unit it was tested
with the helicopter in the target environment.
3.5.6 Airframe Testing
Testing of the power distribution system consisted of determining the secondary
battery discharge time and inspection of the wiring after the engine was tested.
For system overrides, the manual override was tested for normal operation. For
system protection, airbags were evaluated for their viability as a protection
option. Finally general testing included the vehicle engine being tuned and run
through its operating range, as well as an inspection of the frame for tight
connections.
3.5.7 Secondary Vehicle Testing
Testing for the secondary vehicle focused on component testing. Tests were
conducted to ensure the control board and input/output board were both within
proper operating parameters. Controllability testing was also conducted with the
test stand.
Spring 2007
- 50 -
March 30th, 2007
4 Resources and Schedules
This section describes the finances of the project as well as the schedule to
complete various milestones for the current semester.
4.1 Resource Requirements
The next few subsections provide data taken from hourly reporting and the
project plan to determine hourly contribution of team members, and project costs
both estimated and actual.
4.1.1 Personnel Effort Requirements
The Spring 2007 personnel effort summary is shown in the following tables.
Individual effort is broken down on a task-by-task basis. Some tasks have been
generalized to a specific category, as there is a wide-range of activities
surrounding each subsystem.
The effort summaries show the hours worked as well as what was originally
estimated in the semester’s project plan, after evaluating the complexity of the
tasks, each team member’s area of expertise, and each team member’s time
commitments outside of Micro-CART.
Upon examining the effort summaries, it should be noted that the hours worked
to date only represent approximately three quarters of the current Spring 2007
semester. A significant amount of time is left in the semester so the final amount
of actual hours worked will be unquestionably larger.
Though typically a single table, this section will be shown in separate tables to
more closely match this semester’s Project Plan. Also note that precise actual
totals for project deliverables are not available, due to limitations in the way in
which our required weekly reporting is required to be submitted. For this reason,
these cells have been grayed out in the tables.
Spring 2007
- 51 -
March 30th, 2007
Table 4.1.1.1 Estimated and Actual Hourly Contribution – Team Leader
Total
Administrative
Meetings
Development
Research
Documentation
Estimated
Hours
Name
Berg-Taylor
Actual
8
20
50
120
50
120
48
115
16
15
172
390
Total
Actual Total
172
390
Table 4.1.1.2 Estimated and Actual Hourly Contribution – Controls Subteam
Total
Administrative
Meetings
Development
Research
Documentation
Estimated
Hours
Name
Baumhover
16
12
100
48
12
188
Actual
Kreykes
30
20
23
30
232
30
91
30
23
10
399
120
Actual
Singh
20
20
25
30
80
30
60
30
5
10
190
120
Actual
10
20
65
56
8
159
Total
Actual Total
Spring 2007
428
748
- 52 -
March 30th, 2007
Table 4.1.1.3 Estimated and Actual Hourly Contribution –Ground Station
Subteam
Total
Administrative
Meetings
Development
Research
Documentation
Estimated
Hours
Name
Fonseca
5
20
40
40
10
115
Actual
Hernandez
6
10
24
20
48
40
48
40
0
10
126
120
Actual
13
26
52
48
0
139
Total
Actual Total
235
265
Table 4.1.1.4 Estimated and Actual Hourly Contribution – Primary Vehicle
Sensors Subteam
Total
Administrative
Meetings
Development
Research
Documentation
Estimated
Hours
Name
Lichti
15
20
35
50
0
120
Actual
Shen
5
15
22
20
37
35
45
50
0
0
109
120
Actual
Staehling
5
15
10
75
15
40
20
55
0
0
50
185
Actual
Young
5
10
25
10
50
30
40
50
0
0
120
100
Actual
20
5
15
45
0
Total
Actual Total
Spring 2007
85
525
364
- 53 -
March 30th, 2007
Table 4.1.1.5 Estimated and Actual Hourly Contribution – Airframe Subteam
Total
Administrative
Meetings
Development
Research
Documentation
Estimated
Hours
Name
Christgau
10
29
27
17
17
100
Actual
Hughes
5
25
30
20
60
28
42
50
0
0
137
123
Actual
Javed
20
18
15
30
40
20
40
75
5
40
120
183
Actual
Makhija
15
10
12
24
15
30
45
30
25
7
112
101
Actual
5
20
38
47
10
120
Total
Actual Total
507
489
Table 4.1.1.6 Estimated and Actual Hourly Contribution – Secondary Vehicle
Total
Deliverables
Administrative
Meetings
Development
Research
Documentation
Estimated
Hours
Name
Kang
Actual
Lund
Actual
Pfeffer
Actual
10
10
8
11
20
35.5
15
30.5
15
10
15
12
20
6
20
56
20
14.5
32
30
40
16.5
45
36
5
0
2
3
15
13.5
21
19
25
20
65
60
103
95.5
110
116.5
180
171.5
Pries
Actual
20
51.5
10
6
30
8
50
39.5
10
1
65
62
185
168
Turner
Actual
25
29
20
5
15
19
32
50.5
5
0
32
25
129
128.5
Total
707
Actual Total
680
Spring 2007
- 54 -
March 30th, 2007
4.1.2 Financial Requirements
Table 4.1.3 shows Micro-CART’s previously estimated financial requirements for
the Fall 2006 semester along with the estimated cost for the Spring 2007
semester. The second table shows the actual project costs for the current
semester.
Table 4.1.3.1 Estimated Financial budget for the Spring 2006 semester.
Item
Sensor Systems
GPS
IMU
Sonar
Magnetic compass
Wireless comm link
Ground station PC
Flight Controls
PC/104
Servo controller
Manual override switch
Emergency shutoff
switch/transmitter
Vehicle Configuration
Power supply / battery
Team
Helicopter / maintenance
Flight Augmentation Stand
IARC Entry fee
Transportation to IARC
Total Hours
Labor ($10.50 per hour)
Total Costs (w/o labor)
Total Costs (w/ labor)
Spring 2007
Fall 2006
Costs
Total
Project
Cost to
Date
Expected Cost for
Spring 2007
$31.00
$0.00
$172.78
$0.00
$0.00
$20.00
$5,031.00
$5,500.00
$790.78
$400.00
$500.00
$20.00
$89.00
$0.00
$0.00
$58.00
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$1,217.00
$100.00
$50.00
$59.85
$273.00
$110.00
$0.00
$70.00
$629.95
$1,789.95
$0.00
$69.00
$0.00
$0.00
$0.00
1553.75
$16,314.38
$6,506.00
$185.00
$0.00
$0.00
11,994.75
$125,944.88
$0.00
$0.00
$0.00
$2,000.00
2,773
$29,116.50
$922.73
$17,237.11
$22,149.58
$148,094.46
$2,600.00
$31,716.50
- 55 -
March 30th, 2007
Table 4.1.3.2 Micro-CART’s actual financial requirements for the Spring 2007.
Item
Sensor Systems
GPS
IMU
Sonar
Magnetic compass
Wireless comm link
Ground station PC
Altimeter
Miscellaneous
USB Interface Unit
Nylon Thread
6-Pin Adapter
Slice Connections
DC Barrel Connectors
3-Conductor Locking
Connectors
20 gauge hookup wire
Flight Controls
PC/104
Servo controller
Manual override switch
Emergency shutoff
switch/transmitter
Vehicle Configuration
Power supply / battery
Team
Helicopter / maintenance
Flight Augmentation Stand
IARC Entry fee
Transportation to IARC
Hot glue gun and glue
Secondary Vehicle
Gumstix/Robostix
Miscellaneous
Previous Expenses
Total Hours
Labor ($10.50 per hour)
Total Costs (w/o labor)
Total Costs (w/ labor)
Spring 2007
Fall 2006
Costs
Actual Cost
for Spring
2007
Total Project
Cost to Date
$31.00
$0.00
$172.78
$0.00
$0.00
$20.00
$0.00
$139.70
$0.00
$0.00
$16.91
$0.00
$0.00
$78.10
$5,170.70
$5,500.00
$790.78
$358.91
$500.00
$20.00
$78.10
$0.00
$0.00
$0.00
$0.00
$0.00
$0.00
$44.94
$23.06
$7.98
$27.80
$10.62
$26.50
$44.94
$23.06
$7.98
$27.80
$10.62
$26.50
$0.00
$4.99
$4.99
$0.00
$0.00
$0.00
$0.00
$273.00
$110.00
$0.00
$70.00
$1,217.00
$100.00
$50.00
$59.85
$629.95
$34.99
$1,824.94
$69.00
$0.00
$0.00
$0.00
$0.00
$160.12
$45.02
$1,000.00
$2,000.00
$12.48
$6,666.12
$230.02
$0.00
$2,000.00
$12.48
$0.00
$120.00
$0.00
1553.75
$16,314.38
$260.00
$100.00
$0.00
2,256
$23,688.00
$260.00
$220.00
$480.00
11,477.75
$120,516.38
$1,042.73
$17,357.11
$4,446.21
$28,134.21
$25,684.79
$146,201.17
- 56 -
March 30th, 2007
4.2 Schedules
The following figures are a timeline representation of activities planned or
achieved for Spring 2007.
4.2.1 Project Schedule
This subsection presents the detailed Micro-CART project schedules for the
Spring 2007 semester. The following schedules reflect the estimated time
needed for each task throughout the semester. The charts are divided into
separate work schedules by each subteam. The next section will further discuss
the current status of each task as well as the addition of any know problems that
were encountered during the semester.
Spring 2007
- 57 -
March 30th, 2007
Figure 4.2.1 Project task schedule for Ongo3a – Airframe Subsystem
Spring 2007
- 58 -
March 30th, 2007
Figure 4.2.2 Project task schedule for Ongo3a – Controls Subsystem
Spring 2007
- 59 -
March 30th, 2007
Figure 4.2.3 Project task schedule for Ongo3a - Sensors Subsystem
Spring 2007
- 60 -
March 30th, 2007
Figure 4.2.4 Project task schedule for Ongo3a – Ground Subsystem
Spring 2007
- 61 -
March 30th, 2007
Figure 4.2.5 Project task schedule for Ongo3a – Secondary Vehicle Subsystem
Spring 2007
- 62 -
March 30th, 2007
4.2.2 Schedule Status
The following tables indicate the current status of each subteam regarding their
respective deliverables for the semester. These percentages reflect the
estimated amount of completed, or amount left, of work relative to the expected
completion date.
Table 4.2.1 Controls Subteam Deliverables Status
Task
Replace damaged hardware
Upgrade I/O Software
Develop PID controls software
Develop Flight Simulator
Revise Communications Software
Develop Battery Monitoring System
Status
100%
100%
75%
100%
50%
75%
Table 4.2.2 Sensors Subteam Deliverables Status
Component
GPS
Sonar
Compass
Task
Write Software
Interface w/ Controls
Update Software
Interface w/ Controls
Connect & Calibrate
Interface w/ Controls
Status
75%
50%
100%
100%
100%
75%
Table 4.2.3 Ground Station Subteam Deliverables Status
Task
Communications Protocol
Ground Station Communications Module
Ground Station GUI
Data Logger
Status
100%
100%
90%
90%
Table 4.2.4 Power, Payload & Protection Subteam Deliverables Status
Task
Electronics Enclosure
Test and Tune Primary Vehicle Engine
Manual Control Override
Design Wiring Harness
Evaluate Battery Capabilities
Acquire Kill Switch
Spring 2007
- 63 -
Status
90%
100%
50%
100%
100%
100%
March 30th, 2007
Table 4.2.5 Secondary Vehicle Subteam Deliverables Status
Task
Integrate Gumstix/Robotix
DC to DC Converter
Test Stand Fabricatioin
Stop Sign
Parking Meter
Design SV Airframe
Tune PV Engine
Electronics Enclosure (PV)
Project Plan/Status Report
Status
50%
50%
25%
95%
25%
10%
100%
95%
100%
4.2.3 Deliverable Schedule
The following table shows the deliverable milestones. Although not all items
have been completed, an estimated percentage is given indicating the
approximate progress of the deliverable relative to its intended completion date.
Table 4.2.6 Project status chart for senior design deliverables.
Deliverable
Establish Meeting Times
Project Plan
Website and WIKI Updates
Poster
Select Future Team Leadership
Unbound Status Report
Final Status Report
In-Class Practice IRP
IRP Presentation
Student Peer Evaluations
Spring 2007
- 64 -
Status
100%
100%
50%
100%
0%
100%
75%
100%
75%
0%
March 30th, 2007
5 Closure Material
To summarize the current project status, several sections have been prepared.
5.1 Lessons Learned
A few important events occurred in Spring 2007 which provided invaluable
information for project success.
5.1.1 What went well
This semester was a big improvement over previous semesters, due to the
amount of testing that was done. The testing was complimented by much
progress with the flight control software, which really contributed to the team’s
overall morale.
5.1.2 What did not go well
A few of the things that did not go well include team motivation, team
inexperience, and missed deadlines. The lack of team motivation was seen in
some senior members who did not participate in team meetings, team learning,
or accomplishing individual goals.
The team inexperience was seen through
missed deadlines and lack of communication. Some missed deadlines could
have been prevented through communicating a need for help from other team
members, while other missed deadlines were caused by previously missed
deadlines. The problems experienced with deadlines were further compounded
by miscommunication among the team members about when components would
be needed for system testing.
5.1.3 What technical knowledge was gained
The project left team members with knowledge of helicopter flight characteristics,
model helicopter maintenance techniques, knowledge of how to test unknown
systems, knowledge of learning about existing large coding projects, and system
integration.
5.1.4 What would be done differently
In the future, it may be possible to mitigate the effect missed deadlines have on
the overall project by developing a more flexible schedule, such that small delays
in one area do not slow down the entire project. Also team leaders should be
kept up to date with realistic completion dates so that milestone slips can be
anticipated early and prepared for.
5.2 Risk and Risk Management
5.2.1 Anticipated Risks
The following project risks were identified and measures to manage them were
developed:
Spring 2007
- 65 -
March 30th, 2007
Risk:
Loss of funding
Management:
Use current funds cautiously
Seek additional funding
Risk:
Helicopter damage from crash or collisions
Management:
Only allow skilled pilots to fly the helicopter
A manual override switch shall be implemented
Only fly required equipment
Utilize test stand for simple flight testing
Use of the skirt while flying
Use of simulator to test software
Risk:
Helicopter can’t lift the current payload
Management:
Perform additional helicopter load tests regularly
Research increased engine power
Reduce component weight
Purchase a more powerful aircraft
Risk:
Loss of team member
Management:
Overlapping team member skills
Have extremely thorough documentation
Spring 2007
- 66 -
March 30th, 2007
Risk:
Slow turnaround
Management:
Many vendors may not act as quickly as is necessary
for project needs
Allow extra time for outside parties indirectly involved
with the project
Risk:
Injury from vehicle malfunction
Management:
Do the necessary safety checks before each flight
Only have essential team members at engine and
flight tests
Have barriers between the helicopter and team
Risk:
Equipment failures
Management:
Electronics must have vibration isolation
Keep funds available for equipment replacement
Risk:
Lack of commitment/effort
Management:
Some group members do not put in their fair share of
work to the project
Plan on working hard to motivate lazy team members
Use specific assignments and deadlines
Risk:
Damaged connectors within the system
Management:
Check all connections before each test
Spring 2007
- 67 -
March 30th, 2007
Keep funds available for equipment replacement
Perform frequent testing.
5.3 Project Team Information
The following tables show team-member contact information.
5.3.1 Client Information
Iowa State University Department of Electrical and Computer Engineering
5.3.2 Faculty Advisor Information
Dr. John Lamont
Prof. Ralph Patterson III
324 Town Engineering
326 Town Engineering
Ames, IA 50011
Ames, IA 50011
515-294-3600
515-294-2428
jwlamont@iastate.edu
repiii@iastate.edu
Dr. Gregory Smith
350 Town Engineering
Ames, IA 50011
515-294-1828
gsmith@iastate.edu
Spring 2007
- 68 -
March 30th, 2007
5.3.3 Student Team Information
Kito Berg-Taylor (Team Leader)
CprE 490
2925 Woodland St. #4
Ames, IA 50014
515-451-5433
kito@iastate.edu
Brian Baumhover (Team Co-Leader)
Bai Shen (Primary Vehicle)
CprE 492
CprE 492
2519 Chamberlain #217
1320 Gateway Hills #502
Ames, IA 50014
Ames, IA 50014
515-708-2650
515-292-2482
bbaumhov@iastate.edu
shenbai@iastate.edu
Spring 2007
- 69 -
March 30th, 2007
Bill Hughes (Primary Vehicle)
Ricardo Fonseca (Primary Vehicle)
EE 492
CprE 491
134 Hyland Ave #2
2505 Jensen Ave #412
Ames, IA 50014
Ames, IA 50010
402-676-0931
515-450-3080
brh68@iastate.edu
ricucho@iastate.edu
Hassan Javed (Primary Vehicle)
Jim Christgau (Primary Vehicle)
EE 492
EE 491
2132 Sunset Drive
1416 Mayfield Dr. #102
Ames, IA 50014
Ames, IA 50014
515-520-7975
507-219-0704
hassan@iastate.edu
Jim01@iastate.edu
Spring 2007
- 70 -
March 30th, 2007
Pankaj Makhija (Primary Vehicle)
Patrick Turner (Secondary Vehicle)
EE 492
CprE 492
114 S Hyland Appt #3
1215 Florida Ave Apt #417
Ames, IA 50014
Ames, IA 50014
515-441-1463
515-451-6950
pankaj@iastate.edu
pturner@iastate.edu
Byung O Kang (Secondary Vehicle)
Dennis Lund (Secondary Vehicle)
EE 491
ME 466
2213 Jensen Ave
1300 Coconino Rd. #148
Ames, IA 50010
Ames, IA 50014
715-441-9960
563-370-5110
bokang@iastate.edu
Lund511@iastate.edu
Spring 2007
- 71 -
March 30th, 2007
Jeff Pries (Secondary Vehicle)
Brett Pfeffer (Secondary Vehicle)
ME 466
ME 466
800 Pinon Dr Apt #102
905 Dickinson #109
Ames, IA 50014
Ames, IA 50014
563-505-1567
319-431-4546
jmpries6@iastate.edu
bapfef@iastate.edu
Timothy Gruwell (Primary Vehicle)
Alyson Young (Primary Vehicle)
CprE 491
316 Lafayette Ave
217 S. 5th St. #4
Story City, IA 50248
Ames, IA 50010
515-733-2279
847-846-4091
tgruwell@iastate.edu
ayoung@iastate.edu
Spring 2007
- 72 -
March 30th, 2007
Bret Staehling (Primary Vehicle)
Matt Lichti (Primary Vehicle)
EE 491
EE 491
1113 Fredricksen Ct.
1313 Fredricksen Ct.
Ames, IA 50010
Ames, IA 50010
515-572-7827
563-590-4678
bstaehli@iastate.edu
mlichti@iastate.edu
Priyanka Singh (Primary Vehicle)
Todd Kreykes (Primary Vehicle)
EE 491
CprE 491
3425 Fredricksen Ct.
1320 Gateway Hills #510
Ames, IA 50010
Ames IA, 50014
515-572-7954
515-326-0739
priya5@iastate.edu
tkreykes@iastate.edu
Spring 2007
- 73 -
March 30th, 2007
Guillermo Hernandez (Primary Vehicle)
CprE 491
1320 Gateway Hills #505
Ames, IA 50014
guillo@iastate.edu
5.4 Closing Summary
The Micro-CART project teaches students how to familiarize themselves with a
project that they were not part of from conception to deployment. Students must
quickly come up to speed with Micro-CART at its current state and determine
how they can actively contribute to the team for a relatively short period of time.
Many students will not experience projects in the workplace that they design,
implement, test, and maintain.
Micro-CART also poses another challenge: helicopter flight. Many electrical and
computer engineering students are familiar with algorithms to solve standard
computing problems, but this project requires unfamiliar and extremely complex
algorithms to control autonomous flight in a dynamic environment. These
algorithms are not clearly defined for smaller helicopters and must be
researched, developed, and customized by the students. This allows the team
members to apply computing knowledge to areas not usually experienced in their
field of work.
Spring 2007
- 74 -
March 30th, 2007
5.5 References
The following sources were used extensively to gain understanding of the
project.
Micro-CART “What I Know Is” WIKI site
http://ucart1.student.iastate.edu/index.php/Main_Page
Association for Unmanned Vehicle Systems (AUVS) International Robotics
Competitions
http://avdil.gtri.gatech.edu/AUVS/IARCLaunchPoint.html
IARC rules
Analog Devices, Inc.
http://www.analog.com
Signal processing devices
Microchip
http://www.microchip.com
Microchip homepage for PICs
Helicopter History
http://www.helis.com
J.C.I.B Electronic
http://www.jcibelectronics.com
X-Cell Helicopters
http://www.x-cellrchelicopters.com/Store/index.asp
A Comprehensive Study of Control Design for an Autonomous Helicopter
Shim, H.; Koo, T.J.; Hoffmann, F.; Sastry, S.;
Decision and Control, 1998. Proceedings of the 37th IEEE Conference on ,
Volume: 4 , 16-18 Dec 1998
Page(s): 3653 -3658 vol.4
Dynamic Model for X-Cell 60 Helicopter in Low Advance Ratio Flight
V. Gavriltes, B. Mettler, E. Feron;
Laboratory of Information and Decision Systems
Technical Report P-2543
Available online at http://web.mit.edu/gavrick/Public/helimodel.pdf
Spring 2007
- 75 -
March 30th, 2007
Development of a Real-Time Simulator for an Experimental Model
Helicopter
C. Munzinger;
Diploma Thesis, Georgia Tech University, 1998
Available online at http://controls.ae.gatech.edu/papers/munzinger_msthesis.pdf
PID Without a Ph.D.
Tim Wescott;
Embedded Systems Programming
Available online at http://www.embedded.com/2000/0010/0010feat3.htm
Path Planning and Flight Controller Scheduling for an Autonomous
Helicopter
M. Egerstedt, T.J. Koo, F. Hoffmann, S. Sastry;
Available online at
http://users.ece.gatech.edu/~magnus/images/PathHelicopter.pdf
Mathematical Modeling and Experimental Identification of a Model
Helicopter
S.K. Kim, D.M. Tilbury;
American Institute of Aeronautics and Astronautics, Inc., 1998
Available online at http://pdf.aiaa.org/downloads/1998/1998_4357.pdf
An Introduction to the Kalman Filter
Greg Welch, Gary Bishop;
Dept. of Computer Science, U. of North Carolina at Chapel Hill
Available online at
http://www.cs.unc.edu/~welch/kalman/kalman_filter/kalman.html or
http://www.cs.unc.edu/~welch/media/pdf/kalman_intro.pdf
Aerial Robotics at SPSU
http://a-robotics.spsu.edu/
5.6 Appendices
None.
Spring 2007
- 76 -
March 30th, 2007