Sunteți pe pagina 1din 37

SENG466 Project 3

Autonomous Hovercraft Design

Alejandro Erickson, Nathaniel Watt, Daisuke Yoshida

SENG466 Project 3 Autonomous Hovercraft Design Alejandro Erickson, Nathaniel Watt, Daisuke Yoshida Spring 2011

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

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

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

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.

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.

The remote station connection diagram is shown in Figure 1. Figure 1: Remote Station Radio Communication

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.

Figure 2: Wireless Radio Connections 2.2.2 Gyroscope The IDG-300 gyroscope is a 3.3V device that

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.

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.

used in phase two as an additional method of manual control. Figure 3: Bluetooth Diagram The

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

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:

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.

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

Figure 4: Skirt Attachment The single piece of mylar also makes it easy to inflate

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.

Figure 5: Hovercraft One Figure 6: Deck One The lift system consists of fan blades

Figure 5: Hovercraft One

Figure 5: Hovercraft One Figure 6: Deck One The lift system consists of fan blades attached

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

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

high pressure and draw very little current (rated at 0.60A). Figure 7: Computer Fan We replaced

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.

Figure 8: Duct Skirt 3.3.4 Hovercraft Four Every hovercraft design so far has had a

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.

upper deck. This Hovercraft attempt used two stacked computer fans. The deck is shown in Figure

Figure 9: Large Deck

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

including payload of nearly five kilograms (Figure 10). Figure 10: Hovercraft Four This lift system met

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

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.

power we desired but other than that the design worked well. Figure 11: Handmade Angle Limited

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

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.

to avoid creating unnecessary force to rotate the platform. Figure 12: Alternate Hovercraft Dimensions Figure XX

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 2 nd 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

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

size of the platform and apply the changes described above. Figure 13: Alternate Design One 3.3.6.2

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

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

directly to PWM pin 4 on the Seeeduino board (Figure 14). Figure 14: Lift System 3.4.1

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.

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.

Figure 15: Propulsion System Initially we used our thrust fan to push the hovercraft. We

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

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 I B . Also the BJT must be saturated in order to pass the I C , that

is when V CE is larger than 1.7V. The relationship between I C vs V CE for a BJT is shown in

Figure 16. For our purposes we assumed that I C = I CEO = 0mA when I B = 0 micro.

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

The proper design for the inversion process requires the BJT operating point switch from the cutoff mode to the saturation mode. When I B = 0 A then V cc = 5V which is V out . Therefore in our implementation the MOSFET turns on fully when the BJT is in the cutoff region (I C = 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 I B , I C changes, eg. the higher the I B , the higher the I C can be drawn. Shown in

the I B , the higher the I C can be drawn. Shown in Figure 16

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 V GS is larger than V GS thresh . V GS thresh is 3.5V for IRZ44 and depending on the V GS the amount of current along I D can be controlled. Figure XX shows the MOSFET‟s transfer characteristics and it can draw more than 3A V GS values close to 5V.

Figure 17: MOSFET Characteristics From the transistor inverter graph it is seen that V C

Figure 17: MOSFET Characteristics

From the transistor inverter graph it is seen that V CE can be adjustable. Depending on V CE 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 I D .

4.1.3 Calculations and summary

4.1.3 Calculations and summary Arduino output BJT MOSFET Motor 5 V (PWM 100%)

Arduino output

BJT

MOSFET

Motor

5 V (PWM 100%) 4 V (PWM 80%)

On

Off

Off

On

On

On (slow)

2.5V (PWM 50%)

On

On

On (normal)

0 V (PWM 0%)

Off

On

On (fast)

Table 2: Summary

Figure 18: Motor Switch From the calculations shown above R T H was determined to

Figure 18: Motor Switch

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

Therefore R A = 100k and R B = 1k.

Finally, V C = V CC - I C R C = 15 (5m)(1k) = 10V

and 10V is sufficient to have the saturated voltage at V GS . 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.

Figure 19: Sonar Diagram After 4 sonar sensors were mounted on the hovercraft and were

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.

problem. The values on the serial output were not matched with the expected values. Figure 20:

Figure 20: Sonar Connections

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

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.

) The theory did not lead to a success. Figure 21: H-Bridge System Figure 22: MOSFET

Figure 21: H-Bridge System

theory did not lead to a success. Figure 21: H-Bridge System Figure 22: MOSFET H-Bridge The

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.

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 .

make as many pins available on the breadboard as possible . 4.4.2 Broken servos Figure 23:

4.4.2 Broken servos

Figure 23: Headers

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.

small tab on the gear on the right in Figure 24 is what limits the motion

Figure 24: Inside Broken Servo

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);

}

5.2

Arduino to Arduino Communication

5.2 Arduino to Arduino Communication Figure 25: I2C Diagram The boards are connected with an I2C

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

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

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

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.

on the sonar echo to dissipate before firing the next one. Figure 26:RTOS Timing 5.5.2 RTOS

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

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

so it should not cause confusion. 5.6 Infrared sensor Figure 27: Infrared Diagram 6 Recommendations 6.1.1.1

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

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:

8

Appendix

8.1 Schematics

8 Appendix 8.1 Schematics Figure 28: Wireless Controller Schematic 36

Figure 28: Wireless Controller Schematic

Figure 29: Hovercraft Schematic 37

Figure 29: Hovercraft Schematic