Project UFO: Autonomous Hovercraft

Project UFO: Autonomous Hovercraft

Michelle AngTeam NOM:

Trina Choontanom Raymond Yu

June 9, 2008

CONTENTS i

AUTHORSHIP NOTE: All group members worked on this document equally.

Contents

1 Introduction 1

2 Proposed Ideas 1

2.1 Initial Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.2 Initial Hovercraft Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Final Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3 Construction 3

3.1 Overview of Initial Hovercraft Architecture . . . . . . . . . . . . . . . . . . . 3

3.1.1 Lift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.1.2 Skirt Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.3 Thrust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1.4 Navigation and Obstacle Avoidance . . . . . . . . . . . . . . . . . . . 4

3.2 Detailed Discussion of Prototypes . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.1 Proof of Concept Prototype . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.2 Prototype I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.3 Prototype II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2.4 Prototype III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.5 Prototype IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Final Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

CONTENTS ii

4 Circuitry 9

4.1 Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.2 Beacon Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4.3 Steering and Control Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Testing 11

5.1 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5.2 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6 Management Plans 13

6.1 Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.1.1 Team Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.1.2 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.1.3 Continuity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

6.2 Group Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.3 Proposed Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

6.4 Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

7 Further Improvements 16

7.1 Obstacle Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.2 Path-Finding Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

8 Conclusion 18

8.1 Ethical Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

8.2 Environmental and Economical Discussion . . . . . . . . . . . . . . . . . . . 19

LIST OF FIGURES iii

List of Figures

1 Lift design example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Autonomous Light Air Vehicle exhibit at the UCI Beall Center for Art andTechnology. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3 Prototype I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

4 Prototype II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5 Prototype III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

6 Final Product/Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

List of Tables

1 Proposed parts list and cost . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Final Costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1 INTRODUCTION 1

1 Introduction

A hovercraft is a vehicle that is able to hover above the ground, carry the weight of itsfunctional components, and move. An autonomous hovercraft is defined to be an unmannedhovercraft that is able to maneuver around placed obstacles to arrive at its final destina-tion. The final destination in this project was chosen to be defined by a beacon. The au-tonomous hovercraft is inspired from already available remote control hovercrafts and pre-vious autonomous car projects. Hovercraft design mainly consists of a thrusting and liftingmechanism. The lift feature is achieved by using high air pressure ejected into a bag-likeskirt creating an air cushion on which the vehicle sits on. Figure 1 provides an example ofthe basic concept of creating lift. There are several variations on skirt design and air pres-sure creation. In this project, various methods are explored to create the optimal resultsfor lift and maneuvering.

Figure 1: Lift design example.

2 Proposed Ideas

2.1 Initial Concept

The initial proposal was inspired by an art exhibit displayed at the University of Califor-nia, Irvine - Beall Center for Art and Technology. The exhibit featured Jed Berk’s Au-tonomous Light Air Vehicle (ALAV) in which each blimp represented an intelligent andsocial “life-form” (shown in Figure 2). This exhibit combines art and social behavior con-cepts through sensor technology and computer science algorithms [1]. The blimps werealso able to communicate with its human prospectors through an interactive phone demo.

2 PROPOSED IDEAS 2

Figure 2: Autonomous Light Air Vehicle exhibit at the UCI Beall Center for Art andTechnology.

Initially the senior project proposal was an improvement on the ALAV exhibit by givingeach blimp more “intelligence” and emphasizing the social aspect through the creation ofa swarm effect. When a blimp is singled out it performs ordinary defined functions, butthe swarm effect occurs when it is attached to the swarm (or other blimps). It can performextra functions in which it could not while alone.

In order to create this swarm effect, floating vehicles needed to be produced which led intoour idea of an autonomous hovercraft.

2.2 Initial Hovercraft Concept

After focusing on the basics of the original concept, building a proper vehicle was essen-tial. Since it was to improve the original ALAVs, the decision to create a hovercraft ver-sus a blimp was mainly contributed to the amount of hardware we can fit into each. On ablimp, the amount of surface area available to carry components was limited compared tothat of a hovercrafts base. The assumption that was taken was customized circuit boardsmight be too expensive and time consuming to produce, so components would be largerthan those on the ALAVs.

During the experimental and proof of concept stages, building a hovercraft had proven tobe more difficult than it had seemed. Again, the original concept was deviated and hadbecome an autonomous hovercraft. The reasoning in which the hovercraft became au-tonomous was due to the fact that it would be a necessary feature in having a more intelli-gent ALAV-like vehicle. An ability of the hovercraft was to autonomously navigate aroundobjects in its path or to locate others in its swarm.

Several options arose during the development of the original concept. The hovercraft candisplay autonomous features through a self navigating system in which it would include

2 PROPOSED IDEAS 3

the use of a path finding algorithm and sensor technology or by the detection of a destina-tion beacon.

2.3 Final Concept

The autonomous hovercraft was decided to have a beacon detection feature as its navi-gation means. The ability to detect a beacon relates back to the original concept of theswarm effect when a single vehicle would need to detect its companions in order to form aswarm. Through several experimental prototypes, the vehicle design and navigation sys-tem were improved. The final product is an autonomous hovercraft that navigates by de-tection of a beacon, producing a following hovercraft if the beacon itself is mobile. Thebeacon consists of an IR transmitter that is recognized by an array of IR receivers on thehovercraft base. This paper will discuss the research and development into this final con-cept of an autonomous hovercraft.

3 Construction

3.1 Overview of Initial Hovercraft Architecture

During the design phase of this project, several methods and architectural concepts wereconsidered. This section is a discussion of the planned architecture of our initial hovercraftconcept. The purpose of this discussion is to allow for a better understanding of certaindecisions during the design of the final hovercraft. Each subsection will discuss a specificportion of the initially planned architecture.

3.1.1 Lift

To allow the hovercraft to carry the weight of its functional components, we set a mini-mum of 88 cubic feet per minute (CFM) airflow requirement for the lift fan. This require-ment was figured through trial-and-error from previous prototypes and availability of CPUfans sold in the market. From Prototype I, the fan had a 108 CFM airflow which allowedus to carry about 2 pounds. After some research on manufactured fans, the range of air-flow was around 88 CFM to 138 CFM. We decided to keep our 108 CFM fan due to on-hand availability but we later planned to use an 88 CFM fan because of the lighter weight.The weight of the 88 CFM fan is about 0.49lbs which is lighter than our current fan whichis about 1.5lbs. Our decision to use computer fans instead of the standard propeller andmotor combination was inspired by another experiment that was conducted under hobby

3 CONSTRUCTION 4

purposes [2]. Due to the constraints of time and budget, the use of computer fans had pro-vided us with a good solution. Computer fans were items of which we had direct accessand was cost efficient. This was a good solution to our proof of concept build which wasneeded as quickly as we could produce it to continue our planning process.

3.1.2 Skirt Design

From experimenting with our prototype builds, we have found skirt design to be very criti-cal to how much friction and lift the hovercraft experiences. The skirt creates an air cush-ion underneath the vehicle base which causes the lift to occur. Different skirt designs con-tribute differently to its ability to create and maintain this air pocket. We choose to use abag skirt design. For our purposes, a bag skirt will be sufficient enough to allow our plat-form to operate in a stable manner. It also has the advantage of being simple to manufac-ture. Other choices were a C-skirt design and finger design. The C-skirt was opted out dueto more popularity and success with the bag skirt. The finger skirt was more difficult tocreate due to its design, although it had a better ability to move over objects in its path.

3.1.3 Thrust

Hovercraft movement does not only require a hovering effect but requires the ability tohave horizontal directional movement. To satisfy this functionality, we decided to also usecomputer fans. Again, due to computer fans being accessible and budget friendly it pro-vided a good solution. Trade-offs between fan speed and airflow will be further explored inthe Prototype discussion.

3.1.4 Navigation and Obstacle Avoidance

Navigation includes the path-finding algorithm that will navigate around placed obstacles,as well as, the hardware sensors we decide to utilize to map out the physical environment.The algorithm will take into account not only the physical surrounding but the physics in-volved with the vehicle’s movements. Due to the hovering motion of the vehicle, movementphysics must consider the effects of air friction and turn precision. Another factor thatmust be considered is the accuracy of the vehicle’s location at any given time if we assumethat the hovercraft has drift. To model the physical movements of the hovercraft and de-termine its navigation accuracy, we will utilize a model documented by Lindsey Hines, astudent from the University of St. Thomas [3]. Hines utilizes concepts of rotational mo-tion and basic physics to define the basis of the hovercraft kinematics model. To determineequation coefficients, Hines physically tested a hovercraft. For example, to determine thehovercraft’s moment of inertia, Hines used a method described in Ogata’s System Dynam-ics [4]. This experiment involves suspending the hovercraft with two wires equally spaced

3 CONSTRUCTION 5

from the center of gravity and releasing the vehicle from suspension [3]. Once released,the rotation it creates is timed and allows Hines to calculate the moment of inertia coef-ficient with the equation that was provided. Hines also simulates the model and accountsfor stabilization of the hovercraft. The paper also includes copies of the simulation pro-grams used to define hovercraft positions.

Further detail on the technology we utilize in the design of obstacle avoidance and thepath-find algorithm will be discussed in later sections of this design document. Below isthe progression of prototypes from the proof of concept into the final hovercraft that waspresented.

3.2 Detailed Discussion of Prototypes

3.2.1 Proof of Concept Prototype

Materials: Cardboard, packaging plastic, tape, CPU fan

Model: Square base, C-skirt

Pros: Shown that it is possible to construct a home-made hovercraft.

Cons: Far from perfect, but only a proof of concept. The basis of this prototype was toprove the ability to create a feasible hovering vehicle. Materials were decided due to acces-sibility and the model was conceived through rough research. The decision to use com-puter fans was due to the immediate availability and inspiration from previous hobbyprojects done by other individuals. The base skirt design was roughly put together andno measurements were actually made.

From this prototype, we learned that the skirt design contributes to the amount of lift thevehicle provides and measuring the base properly will probably help the final design.

3.2.2 Prototype I

Materials: Cardboard, grocery bag plastic, glue, tape, CPU fan

Model: Rectangular base, bag skirt

Pros: More balanced; hovers slightly better.

Cons: Corners were too pinched off and rigid from all of the tape (did not fully inflate).Parts of the bag skirt touched the surface so it did not truly “hover”.

3 CONSTRUCTION 6

Figure 3: Prototype I

In this prototype, as shown in Figure 3, the skirt design was reconsidered due to the previ-ous experiment with the proof concept prototype. The bag skirt design allowed the vehicleto experience less friction. The same materials were used with this prototype for the samereasons as the proof of concept. Instead of the single layer cardboard used in the previ-ous prototype, we decided to use a duct system. This system required three layers of card-board, in which the middle layer was cut to create air ducts that allowed the air to flowthrough the bag skirt. While testing this design, we found that the air ducts inflated theskirt while also providing air pressure to create the air cushion under the base. Due to thismethod, we found that the vehicle had lifted more than the proof of concept prototype.

This prototype proved how important the skirt shape mattered to the design. The use ofless tape due to the pinched off corners was another lesson learned in this prototype. Dur-ing this prototype, we hypothesized that if the skirt inflates perfectly, the lift and fluidityof the vehicle will improve.

3.2.3 Prototype II

Materials: Foam board, packaging plastic, tape, CPU fan

3 CONSTRUCTION 7


Pros: Foam board gave a more durable working surface and was also able to hold up moreweight/load.

Cons: Skirt was a little unbalanced. Not enough tape (did not hold shape). Skirt was at-tached on top of the foam board instead of under.

Figure 4: Prototype II

From previous experience and research, the bag skirt provided a good design. PrototypeII concentrated on perfecting the design of the bag skirt by using less tape and makingthe skirt sections as even as possible. The packaging plastic did not provide a significantchange but was stiffer and used due to availability. A rectangular base provided morespace for mounting components later and served as a good weight balancing factor thatallowed the vehicle to hover slightly higher. The foam board’s weight was not significantlyheavier than the cardboard so it was a nice alternative.

In this prototype, the skirt was taped to the top of the base where as to previous designsit was underneath. There was no real reason to why the change was made and the signif-icance of the skirt being attached underneath was not apparent until this prototype. Byattaching the skirt to the top of the base, it interfered with the inflation and caused holesto appear. It eventually separated and caused the hovercraft to be a blimp-like craft in-

3 CONSTRUCTION 8

stead, as shown in Figure 4. The holes appeared also due to the fact that not enough tapewas used to attach the skirt to the base.

3.2.4 Prototype III



Pros: Better hovering. Used a lighter/cheaper foam board.

Cons: Corners were not inflating properly.

Figure 5: Prototype III

Learning from Prototype II, the structure and attachment of the bag skirt was improved.By placing the attachment of the skirt on the bottom of the base it helped inflate the skirtmore. This caused the movement of the hovercraft to experience less friction and carrieda bit more weight than our other models. In this implementation, a lighter and cheaperfoam board was used which helped with the increase in lift and keeping within the budget.

A problem that was encountered with this prototype was still the fact that the cornerswere not inflating properly which is seen in Figure 5. Through research and past experi-ence, we figured that the solution to full inflation of the corners would be to either changethe shape of the base to a rounded end which would eliminate the hard corners or to roundoff the corners by shaping the bag itself.

3 CONSTRUCTION 9

3.2.5 Prototype IV



Pros: Better hovering. Rounded corners. Bag fully inflated.

Cons: Did not carry enough weight.

From the issues in Prototype III, we improved the corners of the skirt to a rounded edge.This helped the fluidity of the vehicle and allowed the bag to fully inflate. This prototypewas also the first prototype in which weight limitations were tested. It was only able tocarry about two pounds before it caused the bag to drag across the testing surface.

During this experiment, we hypothesized that more air pressure was needed to help allevi-ate the weight mounted on the hovercraft.

3.3 Final Prototype

Materials: Thin plywood sheet, black trash bag, tape, RC motor, small metal strip (the“bridge” upon which the lift motor is mounted)

Model: Rectangular base, bag skirt with small holes.

Pros: Carried enough weight. More fluid and provided a better air cushion.

Cons: Needed to completely change design methods. Very loud.

This prototype, as seen on Figure 6, proved to be the best of the previous experiments. Itwas able to carry about five to six pounds and keep its fluid movements above the testingsurface. The change in design originated from advice given by an RC hobbyist. A hover-craft had previously been built with the same materials and model listed above. Many ofthe parts were donated and cheap to buy.

4 Circuitry

The circuitry consisted of an Atmel AVR microcontroller, IR receivers, a voltage regulator,LEDs, two switches, and two PNP transistors. All of this was powered by one 9V battery.

4 CIRCUITRY 10

Figure 6: Final Product/Prototype

4.1 Power

Since all our parts use a 5V power source except for our motors, the 9V battery is wiredto a 5V voltage regulator. A switch toggles the power to our system. When the system ison, one of our two status LEDs will light up. A red LED will be lit if the system is idlingwhile a green LED will be lit if the system is running.

4.2 Beacon Tracking

Five IR receivers mounted in a semi circuit array at the front of the hovercraft handlestracking of our beacon. Since the IR signal from our beacon is very directional, we candetermine where the signal is coming from by which receivers detect the signal. Also sinceour beacon sends the signal in pulses instead of one continuous signal, we implemented apulse detection algorithm in order to track our beacon.

4.3 Steering and Control Logic

The steering and control logic is toggled on and off by our second switch. When this is off,the system is in idling mode. When this is on the system is in running mode. In eithermode, the AVR microcontroller will activate the lift fan and modulate the speed if nec-essary for the appropriate amount of lift. This is done by using pulse width modulation

5 TESTING 11

(PWM) on a PNP transistor that is wired to the lift fan.

Once the beacon’s relative location has been determined, our AVR microcontroller willsignal the servo the new desired steering angle. This involves sending a PWM signal at afrequency of 20ms. The angle of the servo is changed by changing the duty cycle of thePWM.

When the hovercraft cannot detect the beacon, the AVR microcontroller will signal thethrust fan to turn off so that the hovercraft will sit still until the beacon is detected again.This is to prevent the hovercraft from running into a wall or other obstacles. We imple-mented this by using PWM on a PNP transistor that was wired to the thrust fan.

5 Testing

Several methods of testing were involved in the process of building the hovercraft. Everycomponent on the hovercraft was individually tested.

Microprocessor To insure that the ordered microprocessors were in working order andits features were available for use, we made several small test scripts. For example,to test for the simple microprocessor functionalities, a blinking LED program wasimplemented.

Servo The servo used on the hovercraft was donated by a local hobby shop and camewith no specification sheet. Through the use of online resources, we were able to findan electronic version. In order to ensure that the servo was in working order and wasin accordance to the specification sheet, we connected it to the microprocessor andcreated a pulse width modulation script that allowed us to test the servo’s boundaryangles.

Motors In order to test and compare the thrust motor to its specification data, we hadconnected it to a bench power supply. Due to the limitation of the power supply,we were unable to test it at maximum power, but it was enough to verify that themotor was strong enough for our purposes. The lift motor was also donated by thelocal hobby shop and was not accompanied by a specification sheet. The model wasalso discontinued and no electronic version of the specifications was found. To testthe boundaries of this motor, we again connected it to the power supply. Since thepower supply was limited to the amount of current it can output, we were only ableto test it to this limit.

IR receivers and transmitters To test the IR receiver and transmitter pair, a scriptwas written and loaded onto a microprocessor. We arranged five receivers in a semi-circle with equal distance apart (as it is in the final product). Since a logic probe

5 TESTING 12

was not available, five LEDs were connected to another output set of the micropro-cessor and the script was changed to light the LED that corresponded to the receiverthat detects an IR signal.

During the integration of each component into the final hovercraft, the completed boardwas tested again. Problems did not arise until all the components had been mounted ontothe hovercraft itself. The batteries were not supplying enough power to all of the compo-nents on the hovercraft in order for the vehicle to run properly, specifically to the lift fan.By adding more batteries to the hovercraft, it was able to overcome this problem. Thenext few sections will continue with other drawbacks and solutions that arose during ourbuilding process.

5.1 Drawbacks

One problem we encountered while developing the final prototype was the underestima-tion of voltage needed to lift the hovercraft. Before finding a solution, the hovercraft couldbarely lift its own weight and did not move.

Another problem was the choice of BJTs over MOSFETs. The BJTs, which were to func-tion as the main power switch to all of the moving components (lift motor and thrust fan),overheated and could not be used for their intended purpose.

A third problem involved the IR receivers. While they were arranged to obtain a full 180degree range, there was a little bit of overlap between the individual ranges of two IR re-ceivers. This sent multiple messages to the steering control

5.2 Solutions

The solution to adding more voltage to the hovercraft was to add more batteries. Due totime constraints, we were forced to use electrical tape to tape two AA batteries in series toprovide an extra 3V. This provided a much larger cushion of air and was able to easily liftthe existing weight as well as the additional two batteries.

The work around for the BJT circuitry was just to completely bypass it. The motor andfan were wired directly to the batteries. However, only one extra switch was available. Theswitch was used to toggle the motor on and off, while the fan required a wire that had tobe plugged in. The drawback to this solution was that the motor and fan were no longercontrolled by the microcontroller.

The solution to the IR receiver problem was to give some IR receivers priority over others.

6 MANAGEMENT PLANS 13

Meaning if multiple IR receivers detected a signal from the transmitter, then the receiverwith the highest priority determined the steering angle.

6 Management Plans

This section discusses the management plans that had been made during the initial stagesof this project. The purpose of creating management plans was to ensure that the projectwould conclude successfully and to pace our progress. This management plan also includesthe proposed monetary cost of this project, as well as, the actual final costs.

6.1 Policies

6.1.1 Team Meetings

Team meetings were held when necessary, typically at least once a week. For every pro-totype made, we met and tested the new model. We would record the changes, pros, andcons of the new model in a shared wiki.

Meetings were also held at least once every week with our advisor to discuss implementa-tion, challenges, and future direction.

6.1.2 Documentation

All officially discussed matters (trade-off decisions, prototype conditions, etc.) were to berecorded on the shared wiki for future reference. Links, papers, and email discussions werealso included on either the shared wiki or on Raymond’s webpage [6]. Current location ofthe wiki and Raymond’s webpage will be integrated together and moved to a more stableserver in the near future.

6.1.3 Continuity

Every member of the team was given a task to complete each week. The task was usuallydelegated through volunteering for the task or given by the advisor. Due to the size andnature of our group, this delegation process was very effective and worked perfectly.


6.2 Group Interaction

The group tended to collaborate together on larger portions (such as building the hover-craft) of the project by meeting at least once a week for an hour or more to work specif-ically on the project. It helped that the group also shared a lot of the same classes andafter school activities (e.g., clubs) so communication between group members was a dailyaffair. Originally splitting the work three ways often ended up with having two or morepeople collaborating on the work depending on who was free.

As an example, Tri was assigned to be “secretary” and keep logs of experiments and pro-totypes; Michelle was assigned to build and work on a prototype of the hovercraft; Raywas assigned to test the IR range finder. Tri and Ray would make modifications to Michellesprototypes, Tri would help Ray on testing the IR range finder, and Michelle and Ray wouldhelp contribute to the logs.

Following with the trend of meeting at least once a week to work on the project, we wouldadditionally meet with our mentor once a week for half an hour to an hour.

6.3 Proposed Timeline

This proposed timeline was created during our planning process in order to pace our progress.

End of Fall/Before Winter Quarter 2007

• Have a working prototype of the hovercraft that is ready for mounting

components. Winter Quarter 2008 Week 1

• Test thrust controls

• Test IR range finder

• Rough implementation/simulation of a path-finding algorithm

Winter Quarter 2008 Week 2

• Have thrust controls ready and test steering controls

• Implement/simulate path-finding algorithm and integrate with the IR range finder

• Improve algorithm, if needed



• Create beacon

• Test beacon

• Continue to test or re-implement path-finding algorithm and integrate with IR

range finder Winter Quarter 2008 Week 4

• Integrate beacon with hovercraft

• Adjust algorithm if needed with the beacon implementation

• Test several obstacle courses


• If beacon and/or path-finding algorithm does not implement appropriately, starthard-coding a path

• Continue to perfect and implementation of current design, if beacon and/or path-finding algorithm works properly


• Test several corner cases to see the limitations of the implementation

• Continue to work on hard-coding a path, if needed (see above to week 5)


• Check implementation for accuracy and correctness

• Test hard coded path, if needed (see week 5)


• Implement on actual demo surface to test for accuracy and correctness

• Test hard coded path on demo surface, if needed (see week 5)



• Adjust any factors, if needed, to compensate for demo surface

• Adjust hard coded path, if needed, on demo surface


• Scheduled demo day

6.4 Cost

The amount the ICS department is contributing is $50.00. We were allowed to exceed thisamount by our own expenses. In the end we spent $141.55, putting us about $91 over the$50 funding we were given and about $53 over out proposed budget. Table 1 is our origi-nal proposal for our budget. Table 2 is our actual budget.

Table 1: Proposed parts list and cost

Part Details PriceSharp GP2Y0A21YK DistanceSensor

4-32 detection/analog/39 ms re-sponse time

$10.00

12V power source Multiple batteries $10.00Digital Compass $36.00Yate Loon 120mm Fan 88 CFM/12vdc/2200RPM 2x$3.99Atmel AVR 8-bit or 8051 micropro-cessor

A/D converter/12-16 I/O pins $2.15-$2.95

Servo 2x$10.00Foam Board $1.00PMOS transistors 2x$0.35

Total: $87.83 − 88.63

7 Further Improvements

The idea that derived the existing hovercraft project was originally an autonomous vehiclethat can intelligently communicate with its peers and mimic the ALAV project. An im-provement that could be implemented would be upgrading the finished hovercraft to have

7 FURTHER IMPROVEMENTS 17

Table 2: Final Costs

Part Details PricePower source Multiple AA and 9V batteries $15.00Yate Loon 120mm Fan 88 CFM/12vdc/2200RPM 2x$3.99Atmel AVR 8-bit micro-processor

3x$6.02

Atmel Flash Programmer $35.91Voltage Regulators IC REG LDO POS 5.0V 5.0A TO-220 — Part#:

LD1084V503x$2.64

555 Timer IC TIMER SINGLE BIPOLAR 8 DIP — Part#:NE555N

2x$0.55

556 Timer IC TIMER RC GEN PURP CMOS 14DIP — Part#:ICM7556IPDZ

2x$1.33

IR Receiver RECEIVER IR REM CTRL 3V 40KHZ — Part#:GP1UE26XK

6x$1.08

IR Transmitter LED IR EMITTING GAAS 940NM 3MM — Part#:QEC113

2x$0.37

Shipping costs $25.00Thrust Motor $6.00Lift Motor FreePlywood board $6.00Metal rod $3.00Battery holders $10.00PMOS Transistors 2x$0.35Servo FreeFoam Board $1.00

Total: $141.55Total out of pocket cost: $91.55

more “intelligent” features, such as peer recognition giving them a social interaction faade.This would involve creating second or several hovercrafts. Due to most of the research anddevelopment for the hovercraft presented here, it has been shown that it would not be ascostly to produce. Another improvement that could be made would be an inclusion of apath finding algorithm and collision detection functionality. The microprocessor on thehovercraft should be able to accommodate for these improvements and the addition of anyother necessary components would not be too difficult. Most of the components that arecurrently connected are hand soldered and there is still plenty of space to add more.

7 FURTHER IMPROVEMENTS 18

7.1 Obstacle Detection

A couple considerations that came to mind when we researched how our hovercraft woulddetect surrounding obstacles were IR range finders, LIDAR, sonar, GPS, and touch sen-sors/whiskers. The first two options that we dropped out of our considerations were LI-DAR and GPS due to the factor of budgeting and size. According to another roboticsproject, sonars consumed too much power [5]. We decided to eliminate this option becausewe can only stack so much power before the hovercraft can no longer carry the power sup-ply weight. Touch sensors/whiskers did not provide us with the long range detection weneeded but still remains as an option if the IR range finder becomes too great of a chal-lenge to integrate.

7.2 Path-Finding Algorithm

Considering the many factors that influence the path, an ideal algorithm would be onethat calculates the path before the hovercraft drifts too far from the original calculatedlocation. In order to compensate for the calculation time, we plan to have the vehicle stopits movements or anchor itself until the next step is ready. If we plan to implement thismethod, several path-finding algorithms can work as long as we allot for the drift factor.

8 Conclusion

The final hovercraft design is very different from the original design. Instead of creatingan autonomous hovercraft that would navigate itself to a beacon via path finding and ob-stacle detection methods, the hovercraft simply follows a beacon without any path findingalgorithms or obstacle detection methods. If the beacon signal is blocked, then the hov-ercraft will slow to a stop. If the hovercraft runs into an object, it will stay there. Due tothe weight of the circuit board, additional circuitry, and power supply, CPU fans simplydid not provide enough lift or thrust. This led to changing the design to use an RC mo-tor and airplane propeller, which provided a significant amount more lift than CPU fans.The thrust fan, also an RC part, similarly provided more thrust and was able to push thehovercraft. The cost of the project is not as high it could have been, nor as low. By re-searching and choosing parts carefully, the cost was kept down. Through trial-and-errorprocesses and trying to emulate existing, lightly documented and explained projects on-line, the realization that CPU fans were not an option had come after the order for thoseparts. However, by trying out the CPU fans for lift and thrust, we proved for our projectand any future projects with similar design, that CPU fans are not a viable option.

8 CONCLUSION 19

8.1 Ethical Discussion

This autonomous hovercraft does not specifically have any ethical concerns. In a broaderview, hovercraft-type vehicles are not a very good choice for everyday use. This is due tothe fact that there is significantly less friction between the vehicle and the ground. Whenturning, the hovercraft continues on the path it was traveling in while spinning around tothe correct direction before assuming the new path. The lack of precise control is a safetyconcern and would not be ethical to use in place of cars. However, the autonomous aspectmay prove useful and has been worked on by the United States military. One project bythe Defense Advanced Research Projects Agency (DARPA) is challenging universities tobuild an autonomous car that can self-navigate and self-drive itself across a desert. Theuse of a car like this would be helpful in the battlefield to dispense aid to stranded soldierswithout the loss of a driver if the car is destroyed.

8.2 Environmental and Economical Discussion

This project is not a good choice for being environmentally friendly. The batteries for thelift and thrust fans only lasted 10 to 15 minutes before the hovercraft either failed to liftor move. The noise produced from the lift motor was also very loud. If the project wereexpanded to become a swarm, the combined noise would be too loud and considered to benoise pollution. Similarly, the numerous amounts of batteries to power a swarm would notbe ideal. Economically, the project, in its final form, is fairly cheap monetarily. The highcost comes in soldering the circuitry after it has been verified to work properly. There isa trade-off: if the circuit board were made into a printed circuit, then the time spent insoldering would be saved, but at the monetary cost of printing the circuit. If the projectwere turned into a toy or hobby kit, then the cost of a printed board may be balanced.

REFERENCES 20

References

[1] “UCI Beall Center + Technology — Calender: 2005-06”, Beall Center forArt+Technology, Available: http://beallcenter.uci.edu/calendar/0607.php. [AccessedOctober 7, 2007].

[2] “Zedomax DIY 112 - Zedomax Hovercraft version 2 - Asteroid!”, Zedomax.com, Avail-able: http://zedomax.com/blog/2006/10/03/zedomax-diy-112-zedomax-hovercraft-version-2- asteroid/. [Accessed October 21, 2007].

[3] L. Hines, “Hovercraft Kinetic Modeling”, Center of Applied Mathematics, University ofSt. Thomas, St. Thomas, MI, USA, 2005.

[4] K. Ogata, “System Dynamics”, Prentice Hall, 1997.

[5] “How to Built a Robot Tutorial”, Society Of Robots, [Online]. Available:http://www.societyofrobots.com/robot omni wheel.shtml. [Accessed November 5,2007].

[6] Raymond Yu, “Hovercraft Links”, November 2007. [Online]. Available:http://www.ics.uci.edu/rsyu/hovercraft/. [Accessed November 28, 2007].

Project UFO: Autonomous Hovercraft

Documents

Transcript of Project UFO: Autonomous Hovercraft