autonomous uav competition project plan - Senior Design

AUTONOMOUS UAV
COMPETITION
PROJECT PLAN
---------------------------Iowa State University
Department of Electrical and Computer Engineering
Senior Design May 2011-Team 10
Client
Faculty Advisor
Space Systems & Controls Laboratory
(SSCL)
Matthew Nelson
Team Members
Anders Nelson
Mathew Wymore
Kshira Nadarajan
Mazdee Masud
Date Submitted:
October 14, 2010
0|P age
Table of Contents
1. Introductory Materials.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
4
.
.
.
.
4
4
1.3 Operating Environment
.
.
1.4 Intended Users and Intended Uses .
.
.
.
.
1.1 Executive Summary
1.2 Problem Statement
.
.
1.2.1 General Problem Statement
1.2.2 General Solution Approach
1.4.1 Intended Users .
1.4.2 Intended Uses .
.
.
.
.
.
.
5
5
1.5 Assumptions and Limitations .
.
.
.
1.5.1 Initial Assumptions List
1.5.2 Initial Limitations List .
.
.
.
.
5
6
1.6 Expected End Product and Other Deliverables
2. Proposed Approach
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
.
.
.
.
3. Statement of Work
3.1 Task
3.2 Task
3.3 Task
3.4 Task
3.5 Task
3.6 Task
3.7 Task
3.8 Task
.
.
.
.
5
5
5
.
6
.
.
Functional Requirements
.
.
.
.
Constraints Considerations .
.
.
.
Technology Considerations .
.
.
.
Technical Approach Considerations .
.
.
Testing Requirements Considerations
.
.
Safety Considerations .
.
.
.
.
Possible Risks and Risk Management
.
.
Project Proposed Milestones and Evaluation Criteria
Project Tracking Procedures .
.
.
.
.
3
7
7
7
8
9
9
10
10
11
12
.
14
No. 1 - Problem Definition and Solution Requirements 14
No. 2 - Technology and Implementation Considerations and Selection 14
No. 3 – End-Product Design .
.
.
14
No. 4 – End-Product Prototype Implementation
14
No. 5 – End-Product Prototype Testing
.
15
No. 6 – End-Product Documentation .
.
15
No. 7 – End-Product Demonstration .
.
15
No. 8 – Project Reporting
.
.
.
15
4. Estimated Resources
.
.
.
.
.
.
4.1 Personnel Effort Requirements
.
.
.
16
16
1|P age
4.2 Other Resource Requirements
4.3 Financial Requirements
.
.
.
.
.
.
.
17
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
6.1.1 Client Information
.
.
6.1.2 Faculty Advisor Information .
6.1.3 Student Team Information
.
.
.
.
19
19
20
.
.
.
.
.
.
.
.
.
22
24
27
5. Project Schedule .
6. Closure Materials
.
.
6.1 Project Team Information
6.2 Closing Summary
6.3 References
.
6.4 Appendices
.
.
.
.
.
.
.
.
.
.
6.4.1 Appendix I - Competition Rules
6.4.2 Appendix II – Market Survey .
6.4.3 Appendix III – Sensor Comparison
18
19
20
21
22
Figures
Figure 1 - Conceptual System Block Diagram
Figure 2 – Project Schedule
Tables
Table 1 – Documentation Expected Labor
Table 2 – Design Expected Labor
Table 3 – Implementation Expected Labor
Table 4 – Labor Totals
Table 5 – Components Estimate
Table 6 – Financial Summary
2|P age
1. Introductory Materials
1.1 Executive Summary
The team will be working on developing the electronics on an unmanned autonomous
aerial vehicle for use in the International Aerial Robotics Competition. This competition
involves using the vehicle to penetrate and navigate an office environment to complete tasks
outlined in the competition rules.
Our team will be working with the Space Systems and Control Lab (SSCL) of Iowa
State University as well as a multidisciplinary senior design team from other departments.
The other senior design team will be in charge of developing the platform to put the control
electronics. In addition, they will be collaborating with our team regarding the flight
dynamics of the platform they deliver. The SSCL will act as an advising element to the senior
design teams and will be providing the funding for the development of the project.
In developing the electronics of the platform, we will be conducting research into past
competitions, competitors, and possible solutions. Using sensors such as laser range finder
and the inertial measurement unit (IMU), we will be collecting the data to be used by the
microcontroller to implement the stability and flight control. In addition to these sensors we
will also include a communication system to communicate sensor and control data to a base
station that will process the computation- intensive algorithms.
The expected end product of the project is a stable flying robot capable of mapping
itself relative to its environment and avoiding obstacles. The robot will be able to stabilize
itself using internal inertial measurements and behave accordingly. The product will also
include a basic communication module that will be able to communicate data to a base
station that will be able to request information and send control instructions. Since the
competition rules are not formally released yet, the platform shall be made adaptable for the
addition of extra modules like video streaming, object recognition, and extended
communication with the remote processing unit. The robot will be able to fly for greater than
or equal to 10 + 2 minutes without human interruption or complete loss of power. It shall
weigh less than or equal to 1.5 kg.
One of the major issues to be resolved is the flight dynamics itself. As computer and
electrical engineering students, the team shall work in collaboration with another team from
3|P age
Engineering 466 (Multidisciplinary Design) consisting of mechanical and aerospace
engineering students. Communication and co-ordination between the two groups will
definitely be a major issue that will have to be carefully worked on. There shall be a single
platform delivered by the end of this semester by the 466 team and sufficient care has to be
taken to ensure that the platform does not break during testing.
1.2 Problem Statement
1.2.1 General Problem Statement
The International Aerial Robotics Competition in its missions states that the main
motivation behind this competition is to promote and push the research and
implementation of efficient indoor navigation systems, flight control and autonomy in
aerial robots. The problem is that the robot must be capable of flying autonomously, that
is, without any real time human control, within an indoor environment without the aid of
GPS navigation techniques. The robot will also be expected to complete a basic set of
tasks, such as possibly identifying and replacing a USB drive (as in previous
competitions). This has to be completed within 10 minutes and the robot must weigh no
more than 1.5 kg.
1.2.2 General Solution Approach
Figure 1 – System Block Diagram
4|P age
Our solution to this problem is to build a platform that will be able to make most
of the important decisions required for stability control, communication, and power
management on the robot itself. It will send other information such as the range finder
and image/video data through a wireless link to a remote base station where the heavy
computations such as localization and search algorithms will be implemented. A control
system shall first be developed by which the base station will be able to wirelessly
command the robot to move according to the instructions based on an API developed for
this purpose. This API will allow future implementation of important mapping and search
algorithms to enable autonomy. The robot will be tested in a controlled environment
where the behavior can be observed and improved.
1.3 Operating Environment
The operating environment will be based on the competition set up which imitates the
interior of an office. The environment will be completely indoors as the main objective of the
competition is to achieve efficient indoor navigation. There will not be external factors such
as wind or rain since it will be completely indoors.
1.4 Intended Users and Intended Uses
1.4.1 Intended Users
The system will be used by the SSCL team for the IARC competition.
1.4.2 Intended Uses
The system will have a specific purpose of doing the mission outlined in the
competition i.e. getting inside the secured compound and bring the valuable information
that we need. However, the scope for this senior design team is to design the platform to
be capable of expansion, without implementation of the systems that will make it
autonomous, mainly, the object recognition and mapping systems in the base station.
1.5 Assumptions and Limitations
1.5.1 Initial Assumptions List
5|P age
1)
The platform delivered to us by the 466 group will be stable and capable of
flight.
2)
No additional money apart from that provided from the SSCL will be
required.
3)
This project will be picked up by another team after this year to expand it to
the full autonomy required for the competition.
1.5.2 Initial Limitations List
1)
The delivered platform will not be able to perform object recognition, but it
will enable future addition of an object recognition system.
2)
The robot will not be able to bear any additional weight other than the onboard components.
3)
There will be a single robot platform developed and there will be no backup
structure.
4)
Since majority of the 466 team will be gone after the first semester, no major
changes in the platform itself will be easily possible.
5)
Limited time for work due to other course studies
1.6 Expected End Product and Other Deliverables
For this project, our deliverable is a platform that is capable of stable flight and easily
expandable to enable autonomous navigation. This platform will hold power for a duration of
at least 10 minutes while operating in an indoor environment. The robot will be able to avoid
obstacles, detect and navigate through a window opening 1 square meter in area. The robot
will be able to communicate with a base station which will receive sensor data and send back
navigation commands.
A complete documentation manual along with the detailed API specifications will be
provided to the client for ease of control through the base station. The API will specify
functions required for the base station to command the robot to take necessary decisions
through a wireless RF communication link.
6|P age
2. Proposed Approach
2.1 Functional Requirements

1.5kg Maximum Weight
o Platform with all electronic components

Battery Powered
o To Power 4 brushless motors at 11V

Capable of at least 10 minutes of flight time

Operate/Navigate in GPS-denied Environment

Operate Autonomously
o With commands sent from Base Station
o Stabilize itself without Base Station

Remote Manual Kill Switch

Remain Airborne if RF Link is lost
o RF Link capable of at least 42 meters
o RF Link must be JAUS-Compliant

Programming on Microcontroller
o Call functions for Base Station
2.2 Constraints Considerations

Total platform weight must be less than 1.5kg
o Included is both electronics by ECpE 491 Team as well as the platform
designed by the Engr 466 Team

Flight time capable of greater than 10 minutes
o Will be based largely on battery choice which in turn affects lift, then power.
This constraint will be very iterative with Engr 466 team due to
interdependence.

Communications capable of greater than 42 meters
o The competition field offers maximum distance of approx. 42m from base
station.

Communications must be JAUS-Compliant
7|P age
o Platform status updates must be broadcast in JAUS format for judges to
receive in competition.

Remain stable in flight during loss of communication with base station
o Platform must remain stable if the RF link with the base station is lost,
meaning no commands are received. This prevents loss of platform.

Limited time due to other course studies
o In implementation, this project will take a great deal of team member time to
complete. With other courses, the time allowed for this project may become
limited at points in the semester when other course projects take up member
time.
2.3 Technology Considerations

External Sensors
o IR, Sonar, and Laser Rangefinder Options – The laser rangefinder is ideally
suited for this project due to the high accuracy and distance range it provides.
The sweep rate of the environment is also significantly greater than for IR or
sonar. The tradeoff is in weight and power consumption, which this is option
take up more of both.
o Camera – Although object recognition is not within the scope of the project,
the platform must be capable of taking images or video of the environment for
implementation of the vision system at a later time.

Internal Sensors
o Inertial Measurement Unit (IMU) – This gives acceleration and rotational
measurements along each of the three-axis of the platform to achieve
measures in 6 degrees of freedom. This is essential for platform stability.

Power
o LiPo Rechargeable Battery – Lipo offers the greatest energy per weight
density. This is essential due to the weight constraints on this, and any, flying
platform. Battery must have power output to support platform for 10+2
minutes of flight time.
8|P age

On-Board Processing
o Microcontroller – The microcontroller must be able to take inputs of internal
and external sensor data as well as control output for each of the 4 motor
controllers. This unit will do all processing for stability control and
communication output to transmitter.

Communications
o RF Transmitter/Receiver – Allows transmission of sensor data and receiving
of commands with the base station. Must be strong enough to match with
constraints of 42 meters. Must be robust.

Remote Kill Switch
o This kill switch must be safe and reliable. Immediate shut off of power at use
of the kill switch is required for safe operation.
2.4 Technical Approach Considerations
Design of the systems on the platform will be done with simulations and written
analyses. Upon receiving desired results in simulation, the system will be prototyped and
tested for matching the desired results, unattached to other systems. Success at this level
moves it forward to grouping systems together. The grouped systems will be tested in
conjunction to unsure no interference between systems occur.
2.5 Testing Requirements Considerations
All testing will occur following a set plan developed prior to the test. The plan will
establish the test parameters, method, and desired results that indicate a passed test. All tests
will be designed to minimize harm to the platform. Controlling external variables that could
affect the parameters being tested is necessary for every test. A record of all tests will be kept
to establish patterns between tested variables as well as for use in the final documentation.
9|P age
2.6 Safety Considerations
As a flying, moving object with rotating propellers, the UAV will present some
dangers to its operators, observers and environment. Dangers could include impact with
persons or equipment, as well as the possibility of an electrical fire due to the onboard
batteries. Proper physical protection of the propellers and batteries will be left to the 466
team. Testing will need to be performed in a carefully controlled environment.
Implementation of a remote kill switch will be a priority.
In terms of manufacture, the project should present no hazards greater than standard
electronics work.
2.7 Possible Risks and Risk Management
Three major risks are identifiable at the outset: expertise, team integrity and financial
risk. Expertise is a risk because our team is inexperienced at projects of this size and scope.
Also, most electronics projects we have previously worked on have stopped at the design
phase, and most software we have previously implemented has been on existing hardware.
None of us are experienced with flight mechanics or with some of the electronic components
that will be required, such as RF communication modules and laser rangefinders.
Fortunately, a vast amount of resources are available to us. UAVs are currently a
popular topic and much documentation on other projects can be found online. Our project
advisor and the other members of the SSCL are avionics experts. The 466 team will provide
information on flight mechanics and general use of the platform. And we feel confident in
our ability to apply to this project what we have learned in class and on other projects.
In terms of team integrity, the project at a whole is at risk because it is split between
multiple teams and the duration of each team’s commitment to the project is varied. For our
part of the project, the risk of the multi-team approach stems mostly from our dependence on
the 466 team to deliver a physical flight platform and our communication with the 466 team
on the aspects of the design that require cooperation, such as weight and power
considerations.
To mitigate these risks, we are holding weekly meetings with our advisor and the 466
team. We also communicate outside the meetings via email and share documents via
10 | P a g e
Dropbox. Additionally, our advisor is experienced in managing multi-team projects and has
good advice on how to proceed.
Finally, the financial risks come from two major sources. First is that, due to the
above risks or other issues, the UAV may not be completed in time for the competition, thus
wasting resources. However, the IARC is an ongoing and annual competition. If the UAV is
not ready this year, another team could potentially finish it in time for the following year’s
competition.
The second financial risk comes from damage to the platform or electronics due to
testing or operation. This risk will be mitigated by careful testing procedures and thorough
testing before any situations presenting considerable risk are attempted.
2.8 Project Proposed Milestones and Evaluation Criteria
The project will be divided into milestones, each which will be evaluated individually
for success or failure, based on the following points system.
Greatly exceeded milestone – 7 points
Exceeded milestone – 6 points
Met milestone – 5 points
Almost met milestone – 4 points
Partially met milestone – 3 points
Failed to meet milestone – 2 points
Did not attempt milestone – 1 point
For each milestone, 5 or more points will be considered a success, while 2 or less will
be considered a definite failure. The success of the whole project will be based on a weighted
average of the milestones, as follows.
Project documentation – 40%
Project plan – This document shall be finished, reviewed by the
project advisor and submitted by October 14th , 2010.
Design document – The design document shall be finished,
reviewed by the advisor and submitted by December 3 rd,
2010.
Design review presentation – The team members shall be properly prepared
11 | P a g e
for the design review presentation. The presentation shall be professional
and clean. Questions shall be handled knowledgeably and efficiently.
Final product documentation – The documentation/user manual for the final
product prototype shall be completed to the greatest possible extent, based
on the extent of the implementation of the prototype, reviewed by the
project advisor and submitted by the date specified in the spring semester.
Prototype implementation – 40%
Basic flight – The UAV shall be capable of hovering and performing basic
flight operations on command.
Communication – The UAV shall be capable of two-way communication with
a base station. The UAV shall also be capable of sending JAUS-compliant
telemetry data.
Remote kill switch – The UAV shall have a remote kill mechanism.
Sensor implementation – The UAV shall be able to receive data from sensors
and, at minimum, perform basic collision detection.
Project mechanics – 20%
Team mechanics – Team members shall communicate regularly, attend weekly
meetings and perform individual duties in a timely manner. Tasks shall be
delegated fairly and evenly. Team structure shall be respected.
Project requirements met – The project requirements shall be met as outlined
is this document.
Project kept on schedule – The project schedule, as outlined in this document,
shall be adhered to.
Project kept within budget – The project expenses shall be kept within the
budget, as outlined in this document.
2.9 Project Tracking Procedures
In order to keep the project moving forward appropriately, various tracking
procedures will be used. A weekly progress report shall be submitted, as well as posted on the
project website. Progress shall be weekly compared with the proposed schedule, and the team
members, in conjunction with the project advisor, shall decide upon and implement any extra
12 | P a g e
measures required to maintain the schedule. An itemized budget shall be kept up to date as
funds are used and compared bi-weekly with the proposed budget. Finally, as individual
system components are completed, they shall be reviewed to ensure they meet the project
functional and nonfunctional requirements as best as possible.
13 | P a g e
3. Statement of Work
3.1 Task No. 1 - Problem Definition and Solution Requirements
The competition rules shall be analyzed to determine the requirements for a
competition-worthy autonomous UAV. This analysis will result in an abstract system block
diagram and a list of requirements for individual components of the block diagram. This task
has been completed.
3.2 Task No. 2 - Technology and Implementation Considerations
and Selection
The field of autonomous UAVs shall be examined and a general solution that is
consistent with the system block diagram and requirements list and that is technologically
and economically feasible shall be chosen. Research shall be done into individual
components and the hardware implementations available. Finally, specific parts shall be
selected, again based on requirements and feasibility. This task has been partially completed.
3.3 Task No. 3 – End-Product Design
The selected parts shall be consolidated into a system design which shall be
documented and presented for review. Additionally, general software block diagrams for the
basic API-type functions of the platform, including mobility, collision detection and
communication, shall be included in the document.
3.4 Task No. 4 – End-Product Prototype Implementation
The design shall be implemented as a working prototype, using the platform supplied
by the 466 team. The software API-type functions for the onboard controller shall be
implemented as well.
14 | P a g e
3.5 Task No. 5 – End-Product Prototype Testing
The UAV shall be thoroughly tested for flight stability, reliability, responsiveness,
communication, and collision detection. All requirements set forth by this document that
pertain to the scope of the project shall be tested and verified to be functional. This task will
be an ongoing process.
3.6
Task No. 6 – End-Product Documentation
The prototype hardware shall be thoroughly documented, to the effect that replacing
parts, upgrading the hardware and expanding the capabilities of the platform shall be as easy
as possible. The software functions implemented on the controller shall also be documented
and the source code shall be well-commented. All documentation shall be readable and
include examples of use where appropriate.
3.7
Task No. 7 – End-Product Demonstration
The prototype shall be photographed and filmed in action. If practical, a live
demonstration shall also be made to the senior design committee. Expected demonstration
procedures include hovering, a pre-programmed flight pattern or the execution of commands
manually sent from a base station, and basic collision detection demonstrations.
3.8
Task No. 8 – Project Reporting
A poster describing the project shall be created for presentation. Further details on
project reporting will be available in the spring semester.
15 | P a g e
4. Estimated Resources
4.1 Personnel Effort Requirements
The requirements in labor that will be used for this project can be broken into 3 main
sections. The sections of labor are in Documentation, Design, and Implementation. These
sections can each be further divided into subtasks that must be accomplished for the overall
project. The figures below list out how the tasks will be split between members of the senior
design team as well as the totals for each section of labor.
Documentation Expected Labor
Team Member
Table 1 – Documentation Expected Labor
Project Plan Plan Presentation Design Document Design Presentation Final Documentation
Total
Anders Nelson
10
10
15
10
15
60
Mazdee Masud
10
10
15
10
15
60
Mathew Wymore
10
10
15
10
15
60
Kshira Nadarajan
10
10
15
10
15
60
Total
40
40
60
40
60
240
Table 2 – Design Expected Labor
Design Expected Labor
Team Member
Past Competitor Research Parts Research&Selection Sensors Setup Power System Control System Communication System Software System
Total
Anders Nelson
10
10
10
10
10
10
5
65
Mazdee Masud
10
10
10
10
10
10
5
65
Mathew Wymore
10
10
10
0
5
10
20
65
Kshira Nadarajan
10
10
10
0
5
10
20
65
Total
40
40
40
20
30
40
50
260
Implementation Expected Labor
Table 3 – Implementation Expected Labor
Team Member
Control System On-Board Programming Sensor Integration Power System Communication System Parts&Integration Testing Final System Testing
Anders Nelson
20
5
10
10
15
40
60
Mazdee Masud
20
5
10
10
15
40
60
Mathew Wymore
5
35
10
0
10
40
60
Kshira Nadarajan
5
35
10
0
10
40
60
Total
50
80
40
20
50
160
240
Labor Totals
Table 4 – Labor Totals
Team Member
Documentation Design Implementation
Total
Anders Nelson
60
65
160
285
Mazdee Masud
60
65
160
285
Mathew Wymore
60
65
160
285
Kshira Nadarajan
60
65
160
285
Total
240
260
640
1140
16 | P a g e
Total
160
160
160
160
640
4.2 Other Resource Requirements
This section includes the items needed for implementing our project. These are the
electronic components for the platform. This list does not include those items used for
implementing the platform that will be done by the Engr 466 Senior Design Team. This list is
an estimate of the ideal case. The exact items bought may differ depending on funding, which
is not currently set.
Components Estimate
Table 5 – Components Estimate
Part Name
Est. Cost per Unit Number of Units Total Cost
External Sensors
Laser Range Finder
$1,100
1 $1,100
Camera
$40
1
$40
Internal Sensors
IMU
$100
1
$100
Power
6,500mAh Lipo Battery
$150
1
$150
Microcontrollers
32-bit Controller
$40
1
$40
Communications
90m Transmitter/Receiver
$40
2
$80
Miscellaneous
Misc. Items (e.g.-wiring)
$40
1
$40
Parts Total without Platform:
$1,550
4.3 Financial Requirements
The following is the summary of the financial requirements for this project. This is
based on a labor cost estimate of $20 per hour.
Financial Summary
Table 6 – Financial Summary
Cost source Hours
Cost per hour Total
Labor
1140
$20
$22,800
Components
$1,550
Project Total
$24,350
Despite the total of $24,350, only the components cost will need to have funding for.
Therefore, the real financial cost without labor is $1,550 without the cost of the platform
designed by the Engr 466 Senior Design Team.
17 | P a g e
5. Project Schedule
Figure 2 –Project Schedule
18 | P a g e
6. Closure Materials
6.1 Project Team Information
6.1.1 Client Information
The client for this project is the Space systems and Controls Lab. This is a multidisciplinary lab in the aerospace department at Iowa State University which runs multiple
projects such as High Altitude Balloon Experiments in Technology, (CySAT) Cyclone
SATellite cubesat project and the Mars Analog Vehicle for Robotic Inspection &
Construction.
The Director of the Lab is Matthew Nelson and he is also the Advisor for our team.
The contact information for the client is:
Space Systems and Controls Lab
2362 Howe Hall
Ames, IA 50011-2271
mnelson at iastate dot edu
515-294-2640
6.1.2 Faculty Advisor Information
Our faculty advisor is Matthew Nelson, the Director of the Space Systems and
Controls Lab. His contact information is:
Chief Design & Operations Engineer
Department of Aerospace Engineering
Space Systems & Controls Laboratory
2271 Howe Hall, Room 2331
Iowa State University
Ames, IA 50011-2271
Office: (515) 294-2640
Fax: (515) 294-3262
[email protected]
19 | P a g e
6.1.3 Student Team Information
The ECpE 491 Senior Design Team website is located at
http://seniord.ece.iastate.edu/may1110/. This site will be updated as the school year
continues. The team members are:
Mazdee Masud
Iowa State University
Electrical Engineering
131 N. Hyland Avenue #14
Ames, IA-50014
319-431-5804
[email protected]
Mathew Wymore
Iowa State University
Computer Engineering
1019 Delware Avenue #17
Ames, IA 50014
641-295-5522
[email protected]
Anders Nelson
Iowa State University
Electrical Engineering
504 ½ Lynn Avenue
Ames, IA 50014
515-447-8359
[email protected]
Kshira Nadarajan
Iowa State University
Computer Engineering
Address
Ames, IA
Phone
[email protected]
6.2 Closing Summary
The autonomous Unmanned Aerial Vehicle project is a multi-disciplinary project in
which the problem involved is to build a robot weighing not more than 1.5 kg capable of
flying autonomously for at least 10 minutes, and complete a set of checkpoints as mentioned
in the competition rules such navigating through an office-like environment, identifying
objects of interest, and completing some espionage tasks.
The proposed approach is to use a quad rotor platform designed by the
Engineering 466 group, using micro controllers to process basic information relating to
stability and flight control, powers systems, and communication. Using this platform, a set of
functions will be programmed on the platform which will enable a base station to issue
commands and receive sensor data from it. An iterative approach shall be followed in the
beginning to reach an ideal compromise between the weight of the chassis and the weight of
the batteries so that the power system will be able to keep the robot flying for a minimum
duration of 10 minutes, along with providing the necessary lift.
20 | P a g e
The result of this project will be a 1.5 kg robot capable of flying autonomously
navigating itself in an indoor environment, avoiding obstacles, and stabilizing itself. It shall
also specify an API that can be used by a controlling base station that will make decisions for
the robot where heavy computations may be required; cases such as object recognition and
mapping algorithms.
6.3 References
International Aerial Robotics Competition (IARC) Site. Association for Unmanned Vehicle
Systems International (AUVSI). Web. Retrieved 10 October, 2010. <http://iarc.angelstrike.com/>
Acroname Robotics. R325-URG-04LX-UG01. Retrieved on 29th September,2010 from
http://www.acroname.com/robotics/parts/R325-URG-04LX-UG01.html
Atomic IMU 6 DoF Product Page. Sparkfun Electronics. Web. Retrieved 28 September,
2010. <http://www.sparkfun.com/commerce/product_info.php?products_id=9184>
LiPo 6500 3-cell 11.1V Battery Pack Product Page. Max Amps.com. Web. Retrieved 28
September, 2010. <http://www.maxamps.com/Lipo-6500-111-Pack.htm>
XBee Pro 60mW Chip Antenna. Sparkfun Electronics. Web. Retrieved 26 September, 2010.
<http://www.sparkfun.com/commerce/product_info.php?products_id=8690>
21 | P a g e
6.4 Appendices
6.4.1 Appendix I – Competition Rules
The following is an excerpt of the rules from the International Aerial Robotics
Competition (IARC) Mission 6 outline. Mission 6 is the current mission, being held in
August 2011.
“ General
Rules Governing Entries
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
pre-programmed, but they must not be flown by a remote human operator. Any number of air
vehicles may be deployed so long as the gross aggregate weight of each air vehicle does not
exceed 1.50 kg.
2. Computational power need not be carried by the air vehicle. Computers operating from
standard commercial power may be set up outside the Competition arena boundary and unior bi-directional data may be transmitted to/from the vehicles in the arena however there shall
be no human intervention with any ground-based systems necessary for autonomous
operation (computers, navigation equipment, links, antennas, etc.).
3. Data links will be by means of radio frequencies in any legal band for the location of the
arena.
4. The air vehicle(s) must be free-flying, autonomous, and have no entangling encumbrances
such as tethers. The air vehicle(s) can be of any type. During flight, the maximum dimension
of the air vehicle can not exceed one (1) meter. The maximum takeoff weight of the vehicle
cannot exceed 1.50 kg. The vehicle must be powered by means of an electric motor using a
battery, capacitor, or fuel cell as a source of energy. The vehicle must be equipped with a
method of manually-activated remote override of the primary propulsion system.
5. A maximum of two (2) non-line-of-sight (NLOS) navigation aids may be used external to
the designated flight area. It will be assumed that these navigation aids were positioned by a
mother ship around the building (but not on top) prior to a aerial robotic sub vehicle launch.
The navigation aids must be portable, and must be removed once the team leaves the
competition area. GPS is not allowed as a navigation aid.
6. The aerial robotic system is required to be able to send vehicle status and navigation
solutions to the Judge’s remote JAUS-compliant data terminal via the JAUS protocol. This
will be done according to the JAUS Standard Set which will be provided to all official teams.
Imagery may be delivered to a separate team-supplied terminal using JAUS protocols but
other signal formats will also be acceptable. Similarly, kill switch transmissions may use
JAUS protocols, but can be achieved by other means without penalty. If more than one aerial
robot is deployed simultaneously, intercommunication between the aerial robots may be by
any means and any protocol desired.
7. Upon entering the arena under autonomous control, aerial robots must remain within the
bounds of the arena or the attempt will end. Vehicles leaving the arena or in the Judges’
opinion, are about the leave the arena, will have their flight terminated by a Judge. Flight
termination actuation will be controlled by a Judge, not the team. Each team will supply the
designated Judge with its manually-actuated kill device as they enter the arena prior to their
attempt(s), and must demonstrate that the kill switch is functional for the Judge. Either
22 | P a g e
separate kill switches can be provided for each vehicle in multiple vehicle swarms, or a single
kill switch that disables all vehicles in the swarm simultaneously is deemed acceptable.
8. The ground station equipment other than the optional navigation aids, manual kill switch
mechanisms, and Judges’ JAUS-compliant terminal interface must be portable such that it
can be setup and removed from the arena quickly. A suggestion would be to setup the
equipment on a roll-cart similar to that shown in Figure 1.
Figure 1. Roll-Cart.
Operations
Teams will be given four (4) flight attempts. The team with the highest static judging score
will be given one (1) additional attempt. Each team will be given 15 minutes to setup their
system and adjust parameters. If the team is unable to launch an aerial robot within the 15
minute window, the attempt is forfeited. Each team is granted one (1) pass. Once a set of
attempts has been completed by a given team, the entire team will be required to leave the
arena. No hardware may be left in place.
During the static display of the vehicle(s), the vehicle(s) will be measured to verify the 1
meter maximum dimension constraint. The vehicle(s), in takeoff configuration will be
weighed to verify the 1.50 kg maximum weight restriction. The vehicle(s) will also be
examined to assure that all kill switch functions are fully operational prior to flight.
Competition Area
The competition flight area (arena) will be constructed within an area that is approximately
30 m long by 15 m wide, and 2.5 m high. This area will be divided into a number of rooms
and corridors with various obstacles of various heights. The launch location will be fixed at a
distance of 3m and oriented toward a 1 x 1 meter (minimum) opening into a corridor.
Navigation aids, if used, may be located anywhere in a 3 meter perimeter bounding the
outside of the arena (see Figure 2). A list of typical materials and construction notes
(which may be updated from time to time) is provided at http://iarc.angelstrike.com/IARC_Arena_Construction.pdf so that teams can construct similar practice
arenas for use in refining their aerial robotic systems prior to arrival on the Competition
day.”
23 | P a g e
6.4.2 Appendix II – Brief Market Survey
IARC Entries
The most succinct survey of the autonomous UAV field, in relation to the IARC, is the
Association for Unmanned Vehicle Systems International’s 2010 Symposium on Indoor
Flight Issues. The papers from the symposium, detailing seven teams’ entries in the 2010
competition, can be found online at http://iarc.angel-strike.com/symposium2010.php.
Embry-Riddle
Perhaps the most innovative entry was Embry-Riddle Aeronautical University’s
SamarEye monocopter.
To fly, the SamarEye rotates quickly about
its center of mass. Though interesting and
entertaining to watch, this design would be
both difficult to implement and impractical
in terms of an environment mapping or
object recognition platform.
Figure 1 - The SamarEye, courtesy of
www.rdmag.com
South Dakota School of Mines and Technology
SDSMT’s UAV, SERV, is a
more traditional, quadrotor
design, and likely similar to
the future platform of this
project. SDSMT began
development of the SERV
platform for the 2004
competition. The 2010
Figure 2 - SERV, courtesy of uav.sdsmt.edu
incarnation of SERV used a
Hokuyo laser range finder, CMOS camera and a Gumstix Obero Fire onboard computer.
24 | P a g e
Indian Institute of Technology Madras
The Indian Institute of Technology’s entry was
also a quadrotor platform powered by a
Gumstix onboard computer and using a Hokuyo
laser range finder. The UAV communicated
with a base station using a Wi-Fi link built into
the Gumstix board, but the symposium paper
suggests that migration of all processing to the
onboard computer is a future goal.
Figure 3 - IIT Madras's quadrotor platform
Non-IARC Considerations
Research into autonomous UAVs is hardly limited to the IARC. Other market
considerations include non-IARC university projects, off-the-shelf UAV platforms and
hobbyist sites.
MIT SWARM - http://vertol.mit.edu/index.html
Figure 4 - A UAV SWARM, courtesy of vertol.mit.edu
The Massachusetts Institute of Technology has been extensively researching multipleUAV systems since at least 2004. The current project deals with swarm health monitoring
in order to facilitate 24-7 mission capabilities.
25 | P a g e
Parrot AR Drone - http://ardrone.parrot.com/parrot-ar-drone/usa
The Parrot AR Drone is available for
consumer purchase $300 from
Amazon.com. This quadrotor platform
is controlled through Wi-Fi by an
iPhone or iPad. The platform also sends
video imagery to the controlling device.
An ultrasound range detector serves as
Figure 5 - Parrot AR Drone
an altimeter, and an ARM processor
running a Linux distribution takes care of the onboard processing.
www.diydrones.com
DIY Drones is “a site for all things about amateur Unmanned Aerial Vehicles.” With over
11,500 registered members, DIY Drones has an active community with forums, blogs and
several open-source Arduino-based autopilot projects with purchasable hardware.
Market Survey Conclusion
Quadcoptors are the most common platform in the competition. They offer the best
stability, maneuverability, and reliability that are needed for this type of competition. In
addition, the use of a laser rangefinder is also a very common sensor. Despite the higher
power consumption and weight than other options in sensors, the much longer range,
accuracy, and reliability makes it the standout option of use in the competition.
26 | P a g e
6.4.2 Appendix III – Sensor Comparison
Sensors
Advantages
IR
Power Consumption is less
Low-cost
Easy Interface
Light weight
Versatile
Sonar
Power consumption is less
Low-cost
Easy Interface
Light weight
Laser Range Finders At least 180 degrees sight coverage
Longer range
High Accuracy
Disadvantages
Lower range
Lower Accuracy
Light Interface
Spreads
Lower Accuracy
Lower Range
Expensive
Heavy weight
Power consuming
Interface
27 | P a g e