SENG466 Project 3

Autonomous Hovercraft Design

Alejandro Erickson, Nathaniel Watt, Daisuke Yoshida

Spring
2011
Table of contents

1 Introduction ................................................................................................................. 5
1.1 Requirement Specifications ................................................................................ 5
1.1.1 Phase two requirements .................................................................................. 5
1.1.2 Phase three requirements ................................................................................ 5
1.1.3 Requirement modifications ............................................................................. 5
2 Components ................................................................................................................ 6
2.1 Hovercraft ........................................................................................................... 6
2.1.1 Remote Station ................................................................................................ 6
2.2 Base Station ........................................................................................................ 6
2.2.1 Wireless Controller ......................................................................................... 6
2.2.2 Gyroscope ....................................................................................................... 7
2.2.3 Potentiometer .................................................................................................. 8
2.2.4 Reset Button .................................................................................................... 8
2.2.5 Bluetooth and Android phone ......................................................................... 8
3 Mechanical Design...................................................................................................... 9
3.1 Hovercraft Theory............................................................................................... 9
3.2 Key components................................................................................................ 10
3.2.1 Decks............................................................................................................. 10
3.2.2 Skirts ............................................................................................................. 10
3.3 Evolution of design ........................................................................................... 11
3.3.1 Hovercraft One.............................................................................................. 11
3.3.2 Hovercraft Two ............................................................................................. 13
3.3.3 Hovercraft Three ........................................................................................... 13
3.3.4 Hovercraft Four ............................................................................................. 14
3.3.5 Final Hovercraft Design ................................................................................ 16
3.3.6 Alternate Designs .......................................................................................... 16
3.4 Lift system ........................................................................................................ 19
3.4.1 Brushless DC motors .................................................................................... 19
3.4.2 Electronic Speed Control (ECS) ................................................................... 20
3.5 Thrust system .................................................................................................... 20
4 Electrical Design ....................................................................................................... 21
4.1 High current fans and MOSFETS ..................................................................... 21
4.1.1 BJT ................................................................................................................ 21
4.1.2 MOSFET ....................................................................................................... 22
4.1.3 Calculations and summary ............................................................................ 23
4.2 Sonar ................................................................................................................. 24
4.3 H-Bridge ........................................................................................................... 26
4.4 Miscellaneous innovations ................................................................................ 28
4.4.1 Headers ......................................................................................................... 28
4.4.2 Broken servos................................................................................................ 28
5 Software Design ........................................................................................................ 29
5.1 BlinkM start up script ....................................................................................... 29
5.2 Arduino to Arduino Communication ................................................................ 30

2
 5.3 Autonomous control.......................................................................................... 30
5.3.1 Pulling fan ..................................................................................................... 30
5.3.2 Finite state machine ...................................................................................... 30
5.3.3 Wall following .............................................................................................. 30
5.3.4 Signal noise ................................................................................................... 31
5.3.5 Detecting stasis ............................................................................................. 31
5.3.6 Crashing state ................................................................................................ 31
5.3.7 Searching state .............................................................................................. 31
5.3.8 Turn at next junction ..................................................................................... 31
5.4 Real time operating system ............................................................................... 32
5.5 Microcontroller setup ........................................................................................ 32
5.5.1 RTOS for sensors .......................................................................................... 32
5.5.2 RTOS both boards......................................................................................... 33
5.5.3 RTOS for control .......................................................................................... 33
5.5.4 RTOS use ...................................................................................................... 34
5.6 Infrared sensor .................................................................................................. 34
6 Recommendations ..................................................................................................... 34
7 Results and Conclusion ............................................................................................. 35
8 Appendix ................................................................................................................... 36
8.1 Schematics ........................................................................................................ 36

3
Table of Figures
Figure 1: Remote Station Radio Communication ............................................................... 6
Figure 2: Wireless Radio Connections ............................................................................... 7
Figure 3: Bluetooth Diagram .............................................................................................. 8
Figure 4: Skirt Attachment................................................................................................ 11
Figure 5: Hovercraft One .................................................................................................. 12
Figure 6: Deck One ........................................................................................................... 12
Figure 7: Computer Fan .................................................................................................... 13
Figure 8: Duct Skirt .......................................................................................................... 14
Figure 9: Large Deck ........................................................................................................ 14
Figure 10: Hovercraft Four ............................................................................................... 15
Figure 11: Handmade Angle Limited Servo ..................................................................... 16
Figure 12: Alternate Hovercraft Dimensions .................................................................... 17
Figure 13: Alternate Design One ...................................................................................... 18
Figure 14: Lift System ...................................................................................................... 19
Figure 15: Propulsion System ........................................................................................... 21
Figure 16 ........................................................................................................................... 22
Figure 17: MOSFET Characteristics ................................................................................ 23
Figure 18: Motor Switch ................................................................................................... 24
Figure 19: Sonar Diagram ................................................................................................. 25
Figure 20: Sonar Connections........................................................................................... 25
Figure 21: H-Bridge System ............................................................................................. 27
Figure 22: MOSFET H-Bridge ......................................................................................... 27
Figure 23: Headers ............................................................................................................ 28
Figure 24: Inside Broken Servo ........................................................................................ 28
Figure 25: I2C Diagram .................................................................................................... 30
Figure 26:RTOS Timing ................................................................................................... 33
Figure 27: Infrared Diagram ............................................................................................. 34
Figure 28: Wireless Controller Schematic ........................................................................ 36
Figure 29: Hovercraft Schematic ...................................................................................... 37

List of Tables
Table 1: Deck Material Density ........................................................................................ 10
Table 2: Summary ............................................................................................................. 23
Table 3: H-Bridge modes .................................................................................................. 26
Table 4: Power Consumption............................................................................................ 35

4
1 Introduction
This report documents the development of a hovercraft course project designed for
SENG466 at the University of Victoria, Spring 2011. There are three phases of
development. The first stage was the development of a rotating platform with both
manual and autonomous control documented at the following link
http://webhome.csc.uvic.ca/~mcheng/466/spring.2011/nwatt.pdf. The second stage is
focused on prototyping a hovercraft design with manual control. The third phase is to
design an autonomous hovercraft. Phase two and three are combined into this single
document as the final stage is simply an extension of phase two. All phases use the
Arduino platform for development.

1.1 Requirement Specifications

1.1.1 Phase two requirements
The original requirements of phase two state that the goal is to design a hovercraft that
weighs less than 1.5 kilograms. Most of phase two focuses on mechanical design. The
hovercraft consists of three main components: lifting system, propulsion system, and
manual control. The lifting system must require fewer than 40W to operate and must
include a remote power switch. The horizontal propulsion system design is free of
restrictions and may consist of any number of DC motors and multiple servos. The
steering control system must not be physically connected to the hovercraft. The base
station from phase one can be reused here if desired. To control the hovercraft the
physical characteristics must be evaluated. Minimally the speed, stopping distance,
weight capacity, and power consumption must be reported.

1.1.2 Phase three requirements

Phase three focuses on the electrical and software components of an autonomous system.
The control system is to consist of two microcontrollers instead of the single
microcontroller used in previous phases. The two microcontrollers are required
communicate with each other. Further at least one of the microcontrollers must run a real
time operating system (RTOS). This is to ensure that our autonomous control is
guaranteed to update at a fixed rate. At all time the hovercraft must maintain wireless
communication with the base station to provide monitoring and debugging. The
hovercraft must have multiple sensors for feedback to the autonomous system. The
hovercraft is actually semi-autonomous as it is allowed to receive simple commands. The
allowed commands cannot steer the hovercraft while it is in autonomous mode but rather
give the autonomous system hints such as to turn left at next intersection.

1.1.3 Requirement modifications

The requirements as specified on the course website were bent in this project. The final
design of the hovercraft came in significantly overweight and with slightly more lift
power than specified in the requirements. These modifications were due to receiving new
hardware previously unavailable to other course offerings. New brushless DC motors
were used that provide much more power than any motor used prior to this offering.

5
2 Components
2.1 Hovercraft
The hovercraft is the most significant component of the project. The design of this
component is documented in the remaining sections of this report.

2.1.1 Remote Station

The hovercraft itself has a remote station attached to it. The final design used three
Arduino boards communicating with I2C. The remote station looks after receiving
wireless packets from the base station, sending wireless debug messages to the base
station, reading sensors, and autonomous control. The remote station connection diagram
is shown in Figure 1.

Figure 1: Remote Station Radio Communication

2.2 Base Station

In phase one a base station was attached to a PC with a usb cable and designed to accept
user input from the keyboard and a PS2 controller. We wanted a portable base station and
an opportunity of experiment with more sensors so we replace the attached base station
with two new designs.

2.2.1 Wireless Controller

We modified the original base station to run on a battery and use input from a
potentiometer and a gyroscope to control the hovercraft. The one disadvantage is there is
no debug terminal unless we attach the wireless controller to a PC. This is still a great
improvement over the phase one base station as it can act exactly like the phase one
station when attached to a PC and has the added feature of a portable controller.

6
 Figure 2: Wireless Radio Connections

2.2.2 Gyroscope
The IDG-300 gyroscope is a 3.3V device that reports the rate of change in the angle
around two orthogonal axes, X and Y. The datasheet is here
www.sparkfun.com/datasheets/Components/IDG-300_Datasheet.pdf .

The first application was to use the position around the X-axis to control the position of
the servo, and that of the Y-axis for the throttle. Both of these require that we keep track
of an absolute position, while adding the changes reported by the gyro.

The datasheet gives the output of the gyro in mV/degrees/s. The details given are mostly
irrelevant, however, because we have the map() function, which maps values in one
interval to another. At a high level, we read the rate of change of X with analogRead,
and multiply it by the time elapsed from the last time we sampled it. This gives us the
“distance” the gyro has rotated, assuming a constant over the time interval - a reasonable
assumption as long as we sample it often enough.

The gyro‟s absolute position, with respect to some reference point, is the sum of these
distances, as discussed in http://www.arduino.cc/playground/Main/Gyro. This introduces
some cumulative error, however, for which we introduce a reset button. The gyro is only
sampled when the button is depressed. The hovercraft pilot can see the position of the
servo and throttle, and orient the controller in a corresponding position before applying
the gyro.

7
One had to move the controller carefully, side to side, while making no fore and aft
motions, to maintain the throttle and turn the craft at the same time. We wanted better
control, and an opportunity to try the potentiometers

2.2.3 Potentiometer
http://sound.westhost.com/pots.htm#pots-knobs
Again, using the map() function, we mapped potentiometer values to throttle values, and
removed throttle control from the gyro. This version was much easier to control.

2.2.4 Reset Button

The reset button‟s function is described above. It gives a HIGH signal to an Arduino pin
when depressed and a LOW signal otherwise. The pin is pulled-down to ground with a
10k resistor, to ensure the LOW signal when the button is not depressed.

2.2.5 Bluetooth and Android phone

This is an extra feature outside of the initial project scope. The lab instructor provided us
with a BlueSmirf Bluetooh modem which we used in phase two as an additional method
of manual control.

Figure 3: Bluetooth Diagram

The Bluetooth modem interfaces with the Arduino board via a serial connection. This
requires very little setup. The effort involved here was the Android application
programming and the initial modem hardware settings.

2.2.5.1 Modem settings

The modem has two modes, a data mode and a command mode. In data mode the modem
receives data from one source and retransmits it to the destination. In command mode the
data sent to the modem is understood as commands to be run locally on the modem itself.
The modem uses the Haye‟s command set when in command mode. This is a very old
standard that is very low level and feels foreign at first. To enter command mode, first
establish a Bluetooth connection to the BlueSmirf, then open a terminal. In the terminal
enter „+++‟. The modem should respond with „OK‟ then it is ready for commands. An

8
example of setting the baud rate to 115200 is with the command „ATSW20,472,0,0.1‟. A
good link explaining interacting with the BlueSmirf in command mode is here:
http://inst.eecs.berkeley.edu/~ee192/sp11/design/abe_setup_bluesmirf.pdf.

2.2.5.2 Android Application

All Android applications must be programmed in Java. To install the SDK visit
http://developer.android.com/sdk/installing.html for detailed instructions. The Android
platform uses a event messaging system that follows the observer design pattern. With
this pattern a sender entity sends a message without knowing if there are any other
entities listening for that message. Basically every possible subject is an object in itself.
Every subject object has a function that allows entities that are interested in the subject to
register an observer with the subject object. Whenever the subject is mentioned in a
message from a sender entity all the registered observers notify the receiver entities. This
pattern is very nice although it is very different from sequential programming.

The Andoid application code provided in the code borrows heavily from the sample
“BluetoothChat” provided with the SDK. The code was hacked together quickly and is
not a great place to start learning. In fact it is very unstable and crashes often. It does
work and controls our hovercraft but only for very short periods of time. The main error
is known. The main thread in any Android application is the UI thread. The UI is not
thread safe and any updates to the UI must be performed by the UI thread itself. During
development of the application this was not fully understood and the crashes are a direct
result of this. Instead what should be used is the Handler class which allows the threads
to communicate data between each other.

3 Mechanical Design
3.1 Hovercraft Theory
There are many basic hovercraft designs based on the same principles of air pressure and
flow. The goal of hovercraft development is to design a craft that is nearly frictionless.
This allows the craft to have a small propulsion system and glide over multiple surfaces
and clear drive over obstacles. A high pressure zone is created under the craft by pushing
air underneath the hovercraft deck with a lifting system. The high pressure then escapes
to the low pressure zone around the craft. The air escaping to the outside zone creates a
gap between the deck and the surface that it is operated on. To achieve a nearly
frictionless state with the surface the gap must exist under all areas of the deck. A non
uniform gap under the deck produces as little friction as a uniform gap. However, a
uniform gap reduces the air flow exiting from under the craft. With less airflow exiting
from under the craft the craft does not need as much airflow in the lifting system. The
ideal system has a high pressure airbed under the deck with a very small uniform gap
around the edges of the deck. This provides the most lift as efficiently as possible.
To increase the height the craft can hover without creating a huge gap a hovercraft skirt is
used. This skirt attaches to the deck and when inflated produces an air deep high pressure
bed of air under the craft. A small gap can be maintained under the skirt itself while the
actual deck hovers much higher. The skirt also provides the ability to deform around
obstacles which is key to the overall versatility of the hovercraft.

9
3.2 Key components
3.2.1 Decks
The size of the deck is very important in hovercraft design. The larger the deck the more
surface area the high pressure zone under the deck acts upon. The surface area over the
high pressure zone determines the overall lift force which is key to increasing the payload
capacity of the craft. The down side of a large deck is increased weight and material
expense. Another important feature of decks is how they are shaped. To maximize lift
force applied it is ideal to maximize surface area while minimizing the perimeter of the
deck. This indicates that a circular deck is the most efficient design. Another important
issue is attaching the skirt to the underside of the deck. This project uses the double deck
design specified in the Introduction to Engineering Design lab book.
The lab has three types of material available for deck construction. Table 1 shows the
density of each material. The pink Styrofoam provides much more rigidity than the white
Styrofoam. This rigidity is important for larger decks. Even though the density is nearly
twice that of the white Styrofoam it proved to be the proper design choice.

Material type Density (g/cm^2)

Dense pink Styrofoam: 0.0512
Light white Styrofoam: 0.0284
White corrugated plastic: 0.0795
Table 1: Deck Material Density

3.2.2 Skirts
Designing an even skirt is critical to ensure a uniform gap underneath the hovercraft. An
uneven seam in the skirt near the ground causes a non uniform gap and in the worst cases
no gap at all between the seam and the surface causing friction. Therefore, it is important
to ensure the area of the skirt closest to the ground is smooth. This is easiest to achieve by
designing the skirt to have no seams at any location that is near the ground when the skirt
is fully inflated. Our design fulfills this goal by using a single piece of mylar larger than
the footprint of the craft. We cut a small hole in the middle and reinforced it with a hem
of clear tape. The edges of the hole are then attached to the lower deck so the edge and
tape do not drag. The outer parts of the skirt are attached to the upper deck of the craft
(Figure 4).

10
 Figure 4: Skirt Attachment

The single piece of mylar also makes it easy to inflate the skirt evenly by keeping the
same amount of material between the center and the edges at every point.

3.3 Evolution of design

3.3.1 Hovercraft One
Hovercraft one (Figure 5) is constructed with a white Styrofoam deck reinforced with
pink ribbing (Figure 6), a nylon skirt, and two parallel lifting motors. The upper deck has
round holes to take air in from the lift fans. The air is pumped partly into the skirt
through the gap between the decks, and partly under the craft, through holes in the lower
deck.

11
 Figure 5: Hovercraft One

Figure 6: Deck One

The lift system consists of fan blades attached to two small DC motors. The fans were
setup to be counter rotating to avoid the craft spinning out of control. The fans were
mounted in a makeshift wind tunnel created out of Styrofoam. Six bladed fans were
fashioned from pairs of three blade fans. These were preferred because they reduced the
amount of back pressure relative to a single three blade fan. Building pressure under the
skirt is more important than increasing airflow as discussed in section 3.1. To further
reduce back pressure caused by the ground effect, a spacer is placed under the fans so

12
they do not push air right into a flat surface. This lets the air disperse into the skirt more
effectively.

3.3.2 Hovercraft Two

Thanks to a recommendation from another group, we bought two Scythe Ultra Kaze
120MM High Static Pressure Fan 38MM 3000RPM 133.6CFM 45.9DBA (Figure 7)
from NCIX. These provide high pressure and draw very little current (rated at 0.60A).

Figure 7: Computer Fan

We replaced the hovercraft one fans with the new computer fans. Our first observation
was that we felt considerable back wind behind them, meaning that the hovercraft
required more than the maximum pressure differential that they were capable of
delivering. Our first solution to this problem was stacking the original fans on top of the
computer fans. This provided much more lift and less back pressure than in our first
design. The weight of the new fans was a major disadvantage. They each weigh just over
400 grams. This extra weight significantly reduced the effectiveness of this design.
Although the fans produced much more lift a lot of that lift was wasted on just countering
the heavy weight of the fans themselves. The 12 Volt operating requirement proved even
more problematic. To achieve 12 Volts an extra battery weighing 440g was required.
This caused even more weight difficulties.

3.3.3 Hovercraft Three

An experimental skirt made of air duct was designed and tested. The expectation was that
it would not work well on land. The air duct is semi rigid and holds its shape without
inflation. This is a useful feature for water based hovercraft as it provides some floatation
without power to the lift system. This hovercraft did not perform well at all and was
quickly scraped. The hovercraft is pictured in Figure 8.

13
 Figure 8: Duct Skirt

3.3.4 Hovercraft Four

Every hovercraft design so far has had a problem with lifting the weight of the
components. Since our final hovercraft is expected to be able to deliver a payload on top
of the weight of the components we needed to come up with a solution. The first attempt
with the new fans didn`t fully solve the problems so we turned to redesigning the deck.
As already discussed a larger deck provides greater lift force for the same pressure. The
disadvantage is that the deck weighs more and the air flow leakage is greater as the
perimeter is larger. The white Styrofoam was too flimsy to support itself with the
dimensions we desired. Changing to using the pink Styrofoam for the deck solved this
issue. The lower deck was designed extremely small and really is nothing more than
spacers holding the mylar away from the upper deck. This Hovercraft attempt used two
stacked computer fans. The deck is shown in Figure 9.

Figure 9: Large Deck

14
The lift system was designed with two computer fans in series blowing into a plastic
tunnel that funnels the air into a hole at the rear of the deck. The plastic tunnel was
created so that the fans could be moved away from the hole into a location that balances
the weight of the hovercraft. This design feature proved very useful for balancing the
craft with little effort. This lift system would have been the final lift system had it not
been for the brushless DC motors arriving in the lab. The idea to use the fans in series
proved extremely effective.
Computer fans have a pressure differential rating, so we hypothesized that by putting the
two fans in parallel, we would achieve the same pressure in the skirt, as we would with
just one fan. The second fan would only increase the airflow into the skirt. Since the ideal
system has high pressure and very small gap (related to low airflow) we put the fans in
series, to build higher pressure with the fans rather than higher airflow.
The vertical orientation of the fans prevents an angular moment, parallel to the ground -
this would have caused a rotation. The new orientation also helps prevent a “ground
effect”, where a pocket of high pressure builds between the fan‟s output side and another
surface. This is avoided as ample space behind the fans is provided. We did a quick test,
and found that the hovercraft supports and glides with a weight including payload of
nearly five kilograms (Figure 10).

Figure 10: Hovercraft Four

This lift system met our requirements and we moved on to the propulsion system.
Initially we attached a DC motor to a continuous servo motor (Figure 11). We used a
continuous servo as all the angle limited servos in the lab were broken. We designed a
angle detection system by attaching a potentiometer to the servo. The potentiometer was
held in place by a Styrofoam clamp. This clamp system caused too much torque on our

15
servo motor which caused it to turn fast in one direction and very slow in the other. We
purchased a angle limited servo for $13 from a local hobby store and everything work
much better. The propulsion motor didn`t provide us with the power we desired but other
than that the design worked well.

Figure 11: Handmade Angle Limited Servo

3.3.5 Final Hovercraft Design

The final design was motivated by brushless DC motors arriving in the lab. We saw the
motors as an excellent way to resolve our current issues with our hovercraft. In the
current design we required three heavy batteries due to the 12V requirement of the
computer fans. The brushless motors can be run off a single battery as they do not have
the high voltage requirement that the computer fans have. The amount of current our
system draws required us to use two batteries total which reduced the weight
significantly. The brushless motors themselves also weigh much less.
The lift fans were replaced with a single vertical brushless DC motor. A hood was
designed along the same principle as our plastic wind tunnel from the previous design.

3.3.6 Alternate Designs

There were initially three hovercraft designs attempted in the first week of project two.
So far this section has covered the evolution of the final hovercraft. Here we present the
two designs that were no explored past the initial design. The biggest problem with these
two designs is they were not created as early as the design chosen to be evolved. The
chosen design was already evolving as the alternate designs were pieced together.

3.3.6.1 Alternate Hovercraft One

16
In Project 1 the weight distribution on the platform was very inconsistent. All kinds of
devices such as the battery and Arduino boards were not balanced properly when they
were mounted. From the mistakes I made I created a larger platform for Project 2 to have
the better weight distribution. Figure XX shows the platform dimensions. I decided to
have the width to be 30cm and the length to be 48cm. The reason one side is larger than
the other is to avoid spinning when hovering. Also by having a propulsion motor
mounted vertically on the platform it was able to avoid creating unnecessary force to
rotate the platform.

Figure 12: Alternate Hovercraft Dimensions

Figure XX shows a rough design of the hovercraft. A fan sits on the hovercraft 7cm away
from one of the edges and 9cm away from the adjacent side and I created a housing for
the hovercraft to let the air pressure build up to hover. As for the skirt I used a table cloth
material and used a double deck design (http://svr225.stepx.com:3388/hovercraft). I
wrapped the entire hovercraft with a skirt and completely sealed it to avoid air leak. Then
I created 2 holes on the 2nd stack of the platform to let the air escape. After connecting a
motor to 7.5V, the hovercraft barely started hovering. On a floor it did not move after
applying a small amount of force to the hovercraft; there must be a zero friction to hover.
The following factors must have caused the hovercraft to not hover.

- Air pressure by the distance between the fan and the hole
- Air pressure by the double deck
- Weight of a skirt
- Power of the motor
- Dimension of the hovercraft

17
Initially the distance between the fan and the hole created on the platform was measured
to be 5cm but after mounting the fan far away from the hole the air pressure inside the
skirt increased and it became more stable yet it did not float in air. The doubledeck
design was not successful because the 2nd layer of the Styrofoam did not sufficiently
build up the air pressure. I created another hole at the bottom of the platform for the air to
escape; resulting in higher airflow. After a number of trials I decided to take the double
deck structure apart to make a simple single platform deck design. Unexpectedly the
hovercraft floated as long as any extra weight was not added. Instead of the table-cloth
skirt I used Mylar in the same dimension because the Mylar was much lighter and was
easier to seal, providing there is no air leak. As a result the hovercraft finally floated in
air.

There were a few more things could be done to make it work better, such as using a
different motor and changing the dimension of the hovercraft. I replaced the customized
7V 6 blades fan motor with a commercial computer fan, which can take 15V drawing
0.5A. This provided more air pressure inside the skirt and there was almost no friction
between the skirt and the ground.

The last thing that could be done to improve the hovercraft is to increase the size of the
platform and apply the changes described above.

Figure 13: Alternate Design One

3.3.6.2 Alternate Hovercraft Two

There was also a circular hovercraft deck designed with two parallel fan holes. This
design was inspired by reading the Introduction to Engineering Design lab book. After

18
creating the double circular deck a Mylar skirt was designed. This was the design that
started off the Mylar skirt craze that most groups followed. The first skirt was inspired by
a previous years groups project report:
webhome.csc.uvic.ca/~mcheng/samples/hawthorn/project2.pdf. Their skirt was left with
slits in the skirt itself and the air pressure self sealed the slits together. Further more the
slits acted like a semi finger skirt giving better obstacle clearance. Unfortunately this skirt
design did not work for our hovercraft. The second skirt was an eight part Mylar skirt that
was cut out but never assembled. The Mylar iron in the lab was broke before creating this
second skirt and the design died. Each part of the skirt was to be ironed together and then
flipped inside out before being attached to the decks. This would allow smooth seams
that hopefully would not drag or cause a non uniform gap. The design of a skirt for a
circular craft was much trickier than for rectangular craft. Although the circular deck
might be more efficient for lift the difficulty of designing the skirt accurately with the
tools available is prohibitive.

3.4 Lift system

The final lift system consisted of a single brushless DC motor and Electronic Speed
control connected directly to PWM pin 4 on the Seeeduino board (Figure 14).

Figure 14: Lift System

3.4.1 Brushless DC motors

A simple brushed DC motor has a rotating armature, and fixed permanent magnets. DC
power is transferred to the armature by rubbing on brushes. As the armature rotates, its
contacts switch brushes, and reversing the polarity and causing the motor to continue
rotating. (http://en.wikipedia.org/wiki/Brushed_DC_electric_motor)

A brushless DC motor has a fixed armature, and a rotating magnet

(http://en.wikipedia.org/wiki/Brushless_DC_electric_motor). The polarity reversal is
generated in a solid state circuit, and a sensor is used to detect the position of the magnet.

Some advantages of this are immediate:

 Fixed coils can be connected to power without brushes.
 No friction from brushes, and as a result, longer life and quieter operation.
 An accurate reading of the rpm.
 Higher efficiency.
 Reduced electromagnetic interference.

19
We describe three types of sensors which detect the position of the rotor. The hall effect
sensor (http://en.wikipedia.org/wiki/Hall_effect_sensor) is mounted on the armature, and
it reacts to changes in polarity as it reads different parts of the rotor. The rotary encoder
also mounted on the armature (because it is fixed and can therefore be powered), and
reads an encoding on the armature (http://en.wikipedia.org/wiki/Rotary_encoder).
Finally, the simplest solution is to read the back-EMF from the unused lead wire.
Because the motor is driven by a simulated sine wave, there is always one lead that is
unused. To start the motor, different phases are tested arbitrarily until the motor turns
and some back-EMF is read.

3.4.2 Electronic Speed Control (ECS)

http://en.wikipedia.org/wiki/Electronic_speed_control) is from hobby king, and it‟s job is
to read a servo signal, and simulate the sine wave for the motor (similar to this one
http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=15202 ). Be
sure to give the ECS a common ground with the micro controller. If this is not done, the
ECS will not see the servo signal. For our hardware, a servo signal of about 40 gave a
speed of 0, while 100 was the maximum speed. At maximum speed, with the four bladed
fan, the current draw of each motor was over 8. It was powerful enough to move the
lab‟s vise across the table. The following is partial test code.

#include “Servo.h”
Servo bldcMotor;

setup(){
bldcMotor.attach(10);
bldcMotor.write(40);
delay(1000);
int i;
for(i=40;i<101;i++){
bldcMotor.write(i);
delay(100);
}
delay(5000);
bldcMotor.write(40);
}

3.5 Thrust system

The final thrust system consists of a brushless DC motor mounted on the servo we bought
from the local hobby shop. The connections are shown in Figure 15.

20
 Figure 15: Propulsion System

Initially we used our thrust fan to push the hovercraft. We realized we could control the
hovercraft much easier if we changed directions and put a pulling fan at the front of the
craft.

This is a video demo of the hovercraft with remote control

http://www.youtube.com/watch?v=4cC-Ag5r3vc

4 Electrical Design
4.1 High current fans and MOSFETS
As for the electric circuit, we decided to use a bi-polar junction transistor and metal-oxide
semiconductor field effect transistor. After testing the propulsion motor with a DC power
supply we determined the required current is close to 1 amp when applying 15 volts so
the following criteria are needed to accomplish creating a circuit:

- The motor takes 15 volts from 15V battery (two 7.5V battery in series)
- The current drawn by the motor must be close to 3 amp.
- The motor needs to be controlled by PWM.

4.1.1 BJT
A BJT can act as a switch/inverter. The current at the collector varies significantly by
applying certain amount of IB. Also the BJT must be saturated in order to pass the IC, that
is when VCE is larger than 1.7V. The relationship between IC vs VCE for a BJT is shown in
Figure 16. For our purposes we assumed that IC = ICEO = 0mA when IB = 0 micro.

We used a BJT as a switch to turn on the MOSFET since IC cannot supply 1A and
therefore cannot drive the motor.

21
The proper design for the inversion process requires the BJT operating point switch from
the cutoff mode to the saturation mode. When IB = 0 A then Vcc = 5V which is Vout.
Therefore in our implementation the MOSFET turns on fully when the BJT is in the
cutoff region (IC = 0 mA). Similarly when BJT is in the saturation mode the voltage to
the gate of the MOSFET can be controlled by PWM from the Arduino depending on the
current IB, IC changes, eg. the higher the IB, the higher the IC can be drawn. Shown in

Figure 16

Also the advantage of the using a BJT is because it is current controlled unlike a
MOSFET there is no-unknown floating state.

4.1.2 MOSFET
The MOSFET turns on as long as VGS is larger than VGS thresh. VGS thresh is 3.5V for IRZ44
and depending on the VGS the amount of current along ID can be controlled. Figure XX
shows the MOSFET‟s transfer characteristics and it can draw more than 3A VGS values
close to 5V.

22
 Figure 17: MOSFET Characteristics

From the transistor inverter graph it is seen that VCE can be adjustable. Depending on VCE
the input voltage at the gate of the MOSFET changes and thus pulse width modulation
applied at the BJT still affects the MOSFET to control the current of ID.

http://www.datasheetcatalog.org/datasheet/SGSThomsonMicroelectronics/mXtyyvz.pdf

4.1.3 Calculations and summary

Arduino output BJT MOSFET Motor

5 V (PWM 100%) On Off Off
4 V (PWM 80%) On On On (slow)
2.5V (PWM 50%) On On On (normal)
0 V (PWM 0%) Off On On (fast)
Table 2: Summary

23
 Figure 18: Motor Switch

From the calculations shown above RTH was determined to be 860Ω and because we need
the resistor value for RA and RB , they can be calculated from the Thevenin‟s equation,
RTH = ( RARB )/(RA + RB )

Therefore RA = 100k and RB = 1k.

Finally, VC = VCC - ICRC = 15 – (5m)(1k) = 10V

and 10V is sufficient to have the saturated voltage at VGS. The power consumption of the
motor was:

P = 14V*2.8A(max speed) = 39.2 W.

4.2 Sonar
The hovercraft was fitted with two sonars on each side, firing in sequence once again,
using an OR gate setup similar to what we had in Project 1. This time, instead of
calculating the difference between front and rear readings in the interrupt service routine,
we simply saved the four readings to global variables. The differences between, and
average distances of a pair of sonars were calculated when needed.

24
 Figure 19: Sonar Diagram

After 4 sonar sensors were mounted on the hovercraft and were connected to the Arduino
Uno, we encountered a mysterious problem. The values on the serial output were not
matched with the expected values.

Figure 20: Sonar Connections

25
For example, when a sonar sensor is faced down to the surface of floor it is expected to
return very small values or theoretically zero, but often it retuned a large value such as
50cm. This problem interestingly occurred only from the front sonar sensors. Initially the
front left sonar and the front right sonar are both connected to the same OR gate. At first
we speculated the problem originated from the OR gate, so we expected to fix the
problem by swapping the wires of the front left sonar and the left rear sonar to the OR
gate to try different combination. Still the values were inconsistent and the problem was
clearly not from the OR gate. Secondarily, we swapped the front and rear sonar sensors to
make sure they weren‟t damaged. Lastly we tested just the front right sonar and it still
gave us wrong values. The only problem must be the wire and we noticed all the wires
from a sonar are tied together, which may create noise to the signal wire, but more
importantly there is a strong electromagnetic force created by the brushless motor which
must interfere with the signal wires for the rear sonar sensors. To shorten the wires and to
reduce the interference we mounted the Arduino UNO to the center of the hovercraft and
also separated the power wire from the signal and ground. Also we have the signal wire
placed parallel to the direction of wire it would cause electromagnetic interference the
wire needed to be placed perpendicular to the direction of motor. The original setup is on
the left of Figure 20 and the new setup is on the right.

Losing bits of data was probably caused by electromagnetic interference along the 2m
wires. The sonar sensors are triggered with a 10 micro seconds pulse and there may be
electromagnetic force created by other the brushless motor since the ECI draws 8 amps at
the maximum speed.

4.3 H-Bridge
After having created the circuit shown in Figure XX, we needed an H-bridge to turn the
motor in both directions. Because the L298 does not draw current more than 2A each, it
was necessary to construct our own H-Bridge circuit. Figure XX shows the H Bridge and
its logic. We had to design the logic to avoid short-circuiting between Q1 and Q2 or
between Q3 and Q4 (Q_NUM represents of an IRZ44n N-channel MOSFET). The logic
is very simple – if DO1 is ON and DO3 is also ON then the current draws from right to
left (from Q3 to Q2) and similarly if DO1 is OFF and DO2 is ON then the direction of
the current is left to right (from Q1 to Q4), shown in Table 3

DO1 DO2 DO3 MOSFET MOTOR

0 0 0 off off
0 0 1 off off
0 1 0 Q1, Q4 clock wise
0 1 1 Q1, Q4 clock wise
1 0 0 off off
1 0 1 Q2, Q3 counter clock wise
1 1 0 off off
1 1 1 Q2, Q3 counter clock wise
Table 3: H-Bridge modes

26
 In theory this H-bridge could take up to the current of 49A with the use of a large
heat sink. (http://www.datasheetcatalog.org/datasheet/philips/IRFZ44.pdf) The
theory did not lead to a success.

Figure 21: H-Bridge System

Figure 22: MOSFET H-Bridge

The logic worked fine as the motor spun clockwise and counter-clockwise
depending on the input. A significant voltage drop across a MOSFET(between
Drain and Gate), which was measured to be 3.6 V. The voltage at the drain of Q2
or Q4 was only 11.4V, yet the required voltage to run the motor was 15V. But we
had an alternative solution to this problem, and that was to use a brushless
motor.

27
4.4 Miscellaneous innovations
4.4.1 Headers
We wanted a smaller number of items connecting the microcontrollers and breadboard,
so we used a large header to make as many pins available on the breadboard as possible .

Figure 23: Headers

4.4.2 Broken servos

We opened a broken servo to see which part breaks when it is overturned. Pictured are
the gears inside. The small tab on the gear on the right in Figure 24 is what limits the
motion of a servo.

Figure 24: Inside Broken Servo

28
We also used the oscilloscope to view the PWM signals sent to a continuous servo.

5 Software Design
5.1 BlinkM start up script
We re-programmed the BlinkM‟s startup script so that it would run a custom light
sequence without receiving I2C commands. Commands are in the BlinkM
documentation. The script was written with the following code snippet by connecting the
BlinkM directly to the Arduino analog out pins A0 to A3.

#include "Wire.h"
#include "BlinkM_funcs.h"

int b = 9; // default address of a blinkm

blinkm_script_line script1_lines[] = {
{ 1, {'n', 0x21,0x22,0x23}}, // dim white
{ 1, {'f', 0x00,0,0}},
{ 60, {'c', 0,0,0}} // dim white
};
int script1_len = 3; // number of script lines above

void setup()
{
pinMode(A0,INPUT);
pinMode(A2,OUTPUT);
digitalWrite(A2,LOW);
pinMode(A3,OUTPUT);
digitalWrite(A3,HIGH);

BlinkM_beginWithPower();
BlinkM_writeScript( blinkm_addr, 0, script1_len, 0, script1_lines);
delay(100);
}

29
5.2 Arduino to Arduino Communication

Figure 25: I2C Diagram

The boards are connected with an I2C connection and with the RTOS board as the
master. This allows for easy expansion to more boards if desired.

5.3 Autonomous control

5.3.1 Pulling fan
The thrust fan was changed from a pushing fan to a pulling fan to give better control over
the craft. Using the single pulling fan on a servo made the control software more simple
than differential fans, because we did not have the problem of two fans with slightly
different amounts of thrust. It takes more thrust to pull the craft than it does to turn it, so
we applied a linear reduction in thrust, proportional to the angle of the servo from it‟s
middle setting. That conversion is as follows, where servoFanSpd is the full thrust value.

(map(abs((int)servoAngle-SERVOMIDDLE),0,abs(SERVOMIDDLE-
SERVOLEFTLIMIT),100,PERCENTOFPOWERONTURN)*(servoFanSpd-
SERVOFANMIN))/100 + SERVOFANMIN;

Autonomous control was implemented in a finite state machine, with four side-facing
sonars, and two IR proximity sensors on the front of the craft. There are three wall-
following states, two crashing states, one searching state, and one standstill state.

5.3.2 Finite state machine

The first iteration of our control algorithm was a simple polling loop and finite state
machine

5.3.3 Wall following

When following a wall, the craft should stay parallel to the wall, within a fixed distance,
both of these subject to given thresholds. This means that any correction made to the

30
heading may not exceed the heading threshold. The heading has priority over the
distance to the wall because losing the heading is very likely to cause the craft to lose
sight of the wall. When both walls are visible, the craft chooses a wall to follow, rather
than following both.

5.3.4 Signal noise

Signal noise in the sonars can cause unwanted state changes. If both sonars have an in-
range (about 2M) reading, a wall is detected on that side. Otherwise there is no wall.
Each time the state is updated, the microcontroller checks whether these readings change
the state. A state changing reading must appear during several consecutive updates to
induce the state change.

5.3.5 Detecting stasis

We want to vary the thrust to control the speed of the craft, and ensure continued
movement. This is done by monitoring the changes in sonar readings. If a long period
goes with little changes, the craft is probably not moving fast enough, and the throttle is
increased. The throttle is automatically decreased incrementally until it requires another
increase. This keeps the craft moving at a minimum speed, which is better for control,
but also allows the thrust to be adjusted for carpet, or pushing paper planes.

5.3.6 Crashing state

There are IR proximity sensors on the front left and front right bumper of the craft. They
output a digital high signal when they see something within six inches. When one of
them is activated, the fan turns nearly 90 degrees the other way to avoid the obstacle. If
they are both activated, the fan alternately turns 90 degrees to wiggle the craft out of a
corner. The rear sideways fan may also be activated to spin the craft.

5.3.7 Searching state

When no wall is in range and the craft is not crashing, it will move slowly forward until
another wall is reached.

5.3.8 Turn at next junction

This state, although currently unimplemented, fits nicely into the finite state machine.
When the command to turn left or right at the next junction is given, a flag is set. When
the hovercraft leaves a certain current (or next) wall following state, it begins a turn.
Some simple tests can be made to determine the appropriate thrust and direction for a
turn of a certain radius.

It only makes sense to turn towards the wall we were following, to avoid entering a
searching state after the turn. Therefore, if a turn command is given when we see both

31
walls, we should follow the wall on the side the turn will come. When that wall
disappears, the craft turns toward it until it sees the wall again.

5.4 Real time operating system

The addition of autonomous control requires more control of when events happen than
was needed in previous phases. To support this requirement an RTOS provided by the
course instructor was used.

The RTOS implementation assumes that Timer1 and software interrupts are reserved for
the RTOS and cannot be used by other parts of the system. The Arduino boards available
for the project all have multiple timers however only Timer1 is actually physically
exposed with a useable pin. Other timers are useable in software only but without easy
pin access they cannot be used for input capture which is used in this project. With only
slight modification the RTOS can be modified to use any 16bit timer as it only requires
output compare not input capture. This is a useful modification as it frees up Timer1 and
input capture for other tasks.

Another issue with the RTOS is that the Arduino servo library conflicts with the RTOS.
Both the servo library and the RTOS define an output compare interrupt vector for
Timer1. A slight modification to the Servo.h file solves this problem. Within Servo.h
there are macros named “_useTimerx” defined for each microcontroller that is supported.
To remove the conflict with the RTOS system, remove the “_useTimer1” define for the
appropriate microcontroller. The servo library requires timers as every PWM pin is
attached to a particular timer. The number of servos that can be attached is dependant on
how many timers are available.

5.5 Microcontroller setup

Only one board is required to have an RTOS running. Selecting which board should run
the RTOS and how the tasks should be divided required a few attempts.

5.5.1 RTOS for sensors

The course instructor suggested using two controllers as previous groups had run into
trouble with timing sensors with RTOS on only one board. The suggestion was to use a
single board that monitors the sensors in a polling loop and a second RTOS board that
updates control. Given the reason behind having two boards using an RTOS for just the
sensors seems counter intuitive however the reasons for attempting this seemed valid.

If the sensors are monitored in a polling loop the time that a particular sensor is read is
not deterministic. The problem with this is that the RTOS is requesting readings from the
sensor board at deterministic times that do not necessarily align with a recent reading. In
the worst cast the reading is requested just before it is read. This leads to the autonomous
control relying on stale readings. This problem could greatly affect the performance of
the autonomous control.

The idea to put the sensors on an RTOS board would allow the RTOS to monitor and
communicate readings at deterministic times. The other board would be event driven and

32
simply wait to receive a reading then act on the freshest sensor readings as soon as they
arrive from the RTOS board. Unfortunately this solution did not perform well in practice.
The problem experienced by other groups with timing sensors and the RTOS hindered
this design. Although we made many modifications to the sonar sensor timing the
interrupt capture readings were not guaranteed to occur within the time allotted for the
sonar task. Figure 26 shows the logic analyzer and the RTOS timing problems. The
yellow channel is the sonar interrupts and they should be occurring only when channel
top channel is pulled high. The problem seems to be with regard to how interrupts are
handled within the RTOS. The initial thought was that it was not conflicting with the
RTOS as interrupt capture is a hardware interrupt not a software interrupt. This problem
was not solved as the time spent was not paying off. It should be noted that if this
problem was solved it would be very easy to use just one Arduino since tasks can be
slotted to complete during the delay waiting on the sonar echo to dissipate before firing
the next one.

Figure 26:RTOS Timing

5.5.2 RTOS both boards

This obviously runs into the same problems as above so is equally unsatisfactory for our
project. The interesting problem we thought about was that this would seem to provide
worse performance than just one RTOS board. The reason the above solution was
attempted was to ensure fresh sensor readings by having event driven control and RTOS
readings. This solution would require that the two RTOS be synchronized in some
manner. A method to do this with the provided library is not evident.

5.5.3 RTOS for control

This is the solution that proved the easiest to implement. Currently it does suffer from the
stale sensor values although we propose a solution that should maximize freshness. Since

33
the RTOS tasks are deterministic the time that the next reading is required can be
determined. All that is required is a short task on the RTOS board that sends a signal to
the sensor board to start a reading. The short task is timed so that the control task that
requires a fresh sensor reading starts just after the sensor reading completes. For example,
if it is known that task A depends on a fresh sonar reading and a sonar reading takes fifty
milliseconds a new task A_trigger should be scheduled just over fifty milliseconds before
task A begins. This solution was not implemented due to time constraints but was on the
to do list.

The task division used in this project used one Arduino UNO with polling loop to read all
sensor values, and a Seeeduino Mega RTOS control board. In addition to autonomous
control the Seeduino Mega is responsible for I2C, wireless radio, and serial
communication.

5.5.4 RTOS use

The RTOS itself is easy to use. Every unique task must be specified in the „PPP[]‟ char
array. Each task entry consists of two bytes. The first byte uniquely identifies the task, the
second identifies the length of time the task should run. After all the tasks are completed
the RTOS loops around to the first task again. Each task is created with the Task_Create
function. Our Final RTOS setup included three boards. The master Seeeduino
communicating over I2C to two UNO‟s one controlling sonar readings and the other
connected to the wireless radio. This was a late change from two boards and not all
diagrams in this document have been updated to show this new connection. It is a trivial
change electrically so it should not cause confusion.

5.6 Infrared sensor

Figure 27: Infrared Diagram

6 Recommendations
6.1.1.1 Propeller connections
We encountered difficulties connecting props to motors several times, and found three
useful solutions. The first is the prop saver. A wing nut, or similar object, is fixed to the
shaft of the motor. The propeller is slipped onto the shaft as well, and elastic bands
attach it to the wing nut. The advantage

34
7 Results and Conclusion
The following diagram shows the power dissipation by the whole system on the
hovercraft. As a brushless motor alone draws 7.24 A from the 7.5V battery it produces
the power consumption of 54.3 W.

Power Dissipation
Electronic Devices (W)
Brushless Motor (Propulsion) 51.28
Brushless Motor (Lifting) 54.32
Other components 5.33
Table 4: Power Consumption

The maximum speed of the final hovercraft was clocked at 2.45m/s. This was calculated
by hand as at the time we were having wireless radio issues and could not report the
result of using sonars to detect changes in distance back to a base station. The
autonomous control worked in the fact it didn‟t crash if it was following a straight wall.
There is much work still to be done in this area.
Overall this project was an excellent learning experience and we hope that other students
can gain some insight and inspiration from reading our report.

The final demo video link can be found here:

http://www.youtube.com/watch?v=Si8dhDLzy60

35
8 Appendix

8.1 Schematics

Figure 28: Wireless Controller Schematic

36
Figure 29: Hovercraft Schematic

37