AUTONOMOUS UAV COMPETITIONPROJECT PLAN

----------------------------

Iowa State University Department of Electrical and Computer Engineering

Senior Design May 2011-Team 10

Date Submitted:October 14, 2010

0 | P a g e

Faculty AdvisorMatthew Nelson

ClientSpace Systems & Controls Laboratory

(SSCL)

Team MembersAnders Nelson Kshira NadarajanMathew Wymore Mazdee Masud

Table of Contents1. Introductory Materials. . . . . . 3

1.1 Executive Summary . . . . . 31.2 Problem Statement . . . . . 4

1.2.1 General Problem Statement . . 41.2.2 General Solution Approach . . 4

1.3 Operating Environment . . . . 51.4 Intended Users and Intended Uses . . . 5

1.4.1 Intended Users . . . . 51.4.2 Intended Uses . . . . 5

1.5 Assumptions and Limitations . . . . 51.5.1 Initial Assumptions List . . 51.5.2 Initial Limitations List . . . 6

1.6 Expected End Product and Other Deliverables . 62. Proposed Approach . . . . . . 7

2.1 Functional Requirements . . . . 72.2 Constraints Considerations . . . . 72.3 Technology Considerations . . . . 82.4 Technical Approach Considerations . . . 92.5 Testing Requirements Considerations . . 92.6 Safety Considerations . . . . . 102.7 Possible Risks and Risk Management . . 102.8 Project Proposed Milestones and Evaluation Criteria 112.9 Project Tracking Procedures . . . . 12

3. Statement of Work . . . . . . 143.1 Task No. 1 - Problem Definition and Solution Requirements 143.2 Task No. 2 - Technology and Implementation Considerations and Selection 143.3 Task No. 3 – End-Product Design . . . 143.4 Task No. 4 – End-Product Prototype Implementation 143.5 Task No. 5 – End-Product Prototype Testing . 153.6 Task No. 6 – End-Product Documentation . . 153.7 Task No. 7 – End-Product Demonstration . . 153.8 Task No. 8 – Project Reporting . . . 15

4. Estimated Resources . . . . . . 164.1 Personnel Effort Requirements . . . 16

1 | P a g e

4.2 Other Resource Requirements . . . 174.3 Financial Requirements . . . . 17

5. Project Schedule . . . . . . . 186. Closure Materials . . . . . . 19

6.1 Project Team Information . . . . 196.1.1 Client Information . . . 196.1.2 Faculty Advisor Information . . 196.1.3 Student Team Information . . 20

6.2 Closing Summary . . . . . 206.3 References . . . . . . 216.4 Appendices . . . . . . 22

6.4.1 Appendix I - Competition Rules . 226.4.2 Appendix II – Market Survey . . 246.4.3 Appendix III – Sensor Comparison . 27

FiguresFigure 1 - Conceptual System Block Diagram

Figure 2 – Project Schedule

TablesTable 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 a g e

1. Introductory Materials1.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 a g e

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

4 | P a g e

Figure 1 – System Block Diagram

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 a g e

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 on-

board 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 a g e

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 de-

signed 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 interdepen-

dence.

Communications capable of greater than 42 meters

o The competition field offers maximum distance of approx. 42m from base sta-

tion.

Communications must be JAUS-Compliant

7 | P a g e

o Platform status updates must be broadcast in JAUS format for judges to re-

ceive 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, mean-

ing 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 mea-

sures in 6 degrees of freedom. This is essential for platform stability.

Power

o LiPo Rechargeable Battery – Lipo offers the greatest energy per weight den-

sity. This is essential due to the weight constraints on this, and any, flying plat-

form. Battery must have power output to support platform for 10+2 minutes of

flight time.

8 | P a g e

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 con-

trollers. This unit will do all processing for stability control and communica-

tion 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 con-

straints 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 a g e

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 3rd,

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 Work3.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 SelectionThe 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 Resources4.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 LaborTeam Member Project Plan Plan Presentation Design Document Design Presentation Final Documentation TotalAnders Nelson 10 10 15 10 15 60Mazdee Masud 10 10 15 10 15 60Mathew Wymore 10 10 15 10 15 60Kshira Nadarajan 10 10 15 10 15 60

Total 40 40 60 40 60 240

Design Expected LaborTeam Member Past Competitor Research Parts Research&Selection Sensors Setup Power System Control System Communication System Software System TotalAnders Nelson 10 10 10 10 10 10 5 65Mazdee Masud 10 10 10 10 10 10 5 65Mathew Wymore 10 10 10 0 5 10 20 65Kshira Nadarajan 10 10 10 0 5 10 20 65

Total 40 40 40 20 30 40 50 260

Implementation Expected LaborTeam Member Control System On-Board Programming Sensor Integration Power System Communication System Parts&Integration Testing Final System Testing TotalAnders Nelson 20 5 10 10 15 40 60 160Mazdee Masud 20 5 10 10 15 40 60 160Mathew Wymore 5 35 10 0 10 40 60 160Kshira Nadarajan 5 35 10 0 10 40 60 160Total 50 80 40 20 50 160 240 640

Labor TotalsTeam Member Documentation Design Implementation TotalAnders Nelson 60 65 160 285Mazdee Masud 60 65 160 285Mathew Wymore 60 65 160 285Kshira Nadarajan 60 65 160 285Total 240 260 640 1140

16 | P a g e

Table 1 – Documentation Expected Labor

Table 2 – Design Expected Labor

Table 3 – Implementation Expected Labor

Table 4 – Labor Totals

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 EstimatePart Name Est. Cost per Unit Number of Units Total CostExternal SensorsLaser Range Finder $1,100 1 $1,100Camera $40 1 $40Internal SensorsIMU $100 1 $100Power6,500mAh Lipo Battery $150 1 $150Microcontrollers32-bit Controller $40 1 $40Communications90m Transmitter/Receiver $40 2 $80MiscellaneousMisc. 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 SummaryCost source Hours Cost per hour TotalLabor 1140 $20 $22,800Components $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

Table 5 – Components Estimate

Table 6 – Financial Summary

5. Project Schedule

18 | P a g e

Figure 2 –Project Schedule

6. Closure Materials6.1 Project Team Information

6.1.1 Client Information

The client for this project is the Space systems and Controls Lab. This is a multi-

disciplinary 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 Lab2362 Howe HallAmes, IA  50011-2271

mnelson at iastate dot edu515-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 EngineerDepartment of Aerospace EngineeringSpace Systems & Controls Laboratory

2271 Howe Hall, Room 2331Iowa State UniversityAmes, IA 50011-2271

Office: (515) 294-2640Fax: (515) 294-3262

mnelson@iastate.edu

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 MasudIowa State UniversityElectrical Engineering131 N. Hyland Avenue #14Ames, IA-50014319-431-5804mmasud@iastate.edu

Anders NelsonIowa State UniversityElectrical Engineering504 ½ Lynn AvenueAmes, IA 50014515-447-8359anelson7@iastate.edu

Mathew WymoreIowa State UniversityComputer Engineering1019 Delware Avenue #17Ames, IA 50014641-295-5522mlwymore@iastate.edu

Kshira NadarajanIowa State UniversityComputer EngineeringAddressAmes, IAPhonekshira90@iastate.edu

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.angel-

strike.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 Entries1. 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 uni- or 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 opera-tion (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 compe-tition 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 solu-tions 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. Im-agery 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’ opin-ion, are about the leave the arena, will have their flight terminated by a Judge. Flight termina-tion actuation will be controlled by a Judge, not the team. Each team will supply the desig -nated Judge with its manually-actuated kill device as they enter the arena prior to their at -tempt(s), and must demonstrate that the kill switch is functional for the Judge. Either separate

22 | P a g e

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 equip-ment on a roll-cart similar to that shown in Figure 1.

Figure 1. Roll-Cart.

OperationsTeams 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 at-tempts 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 me -ter 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 as-sure that all kill switch functions are fully operational prior to flight. Competition AreaThe 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. Navi-gation 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.angel-strike.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.

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

24 | P a g e

Figure 1 - The SamarEye, courtesy of www.rdmag.com

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.

25 | 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.

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 multiple-UAV systems since at least 2004. The current project deals with swarm health monitoring in order to facilitate 24-7 mission capabilities.

26 | P a g e

Figure 3 - IIT Madras's quadrotor platform

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 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.

27 | P a g e

Figure 5 - Parrot AR Drone

6.4.2 Appendix III – Sensor Comparison

28 | P a g e

Sensors Advantages DisadvantagesIR Power Consumption is less Lower range

Low-cost Lower AccuracyEasy Interface Light InterfaceLight weightVersatile

Sonar Power consumption is less SpreadsLow-cost Lower AccuracyEasy Interface Lower RangeLight weight

Laser Range Finders At least 180 degrees sight coverage ExpensiveLonger range Heavy weightHigh Accuracy Power consuming

Interface