ee 477 final report - purdue engineering · web viewspring 2005 team code name: _____ team id:...

ECE 477 Final ReportSpring 2005

Team Code Name: ____________________________________________ Team ID: ______

Team Members (#1 is Team Leader):

#1: ____________________________ Signature: ____________________ Date: _________

#2: ____________________________ Signature: ____________________ Date: _________

#3: ____________________________ Signature: ____________________ Date: _________

#4: ____________________________ Signature: ____________________ Date: _________

ECE 477 Final Report Spring 2005

REPORT EVALUATION

Component/Criterion Score Multiplier Points

Abstract 0 1 2 3 4 5 6 7 8 9 10 X 1

Project Overview and Block Diagram 0 1 2 3 4 5 6 7 8 9 10 X 2

Team Success Criteria/Fulfillment 0 1 2 3 4 5 6 7 8 9 10 X 2

Constraint Analysis/Component Selection 0 1 2 3 4 5 6 7 8 9 10 X 2

Patent Liability Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Reliability and Safety Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Ethical/Environmental Impact Analysis 0 1 2 3 4 5 6 7 8 9 10 X 2

Packaging Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Schematic Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

PCB Layout Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Software Design Considerations 0 1 2 3 4 5 6 7 8 9 10 X 2

Version 2 Changes 0 1 2 3 4 5 6 7 8 9 10 X 1

Summary and Conclusions 0 1 2 3 4 5 6 7 8 9 10 X 1

References 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix A: Individual Contributions 0 1 2 3 4 5 6 7 8 9 10 X 4

Appendix B: Packaging 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix C: Schematic 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix D: Top & Bottom Copper 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix E: Parts List Spreadsheet 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix F: Software Listing 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix G: User Manual 0 1 2 3 4 5 6 7 8 9 10 X 2

Appendix H: FMECA Worksheet 0 1 2 3 4 5 6 7 8 9 10 X 2

Technical Writing Style 0 1 2 3 4 5 6 7 8 9 10 X 5

CD of Website Image and Reports/Poster 0 1 2 3 4 5 6 7 8 9 10 X 2

TOTAL

-ii-

Comments:


TABLE OF CONTENTS

Abstract 1 1.0 Project Overview and Block Diagram 1 2.0 Team Success Criteria and Fulfillment 2 3.0 Constraint Analysis and Component Selection 3 4.0 Patent Liability Analysis 7 5.0 Reliability and Safety Analysis 12 6.0 Ethical and Environmental Impact Analysis 15 7.0 Packaging Design Considerations 18 8.0 Schematic Design Considerations 22 9.0 PCB Layout Design Considerations 2510.0 Software Design Considerations 2611.0 Version 2 Changes 3712.0 Summary and Conclusions 3813.0 References 38Appendix A: Individual Contributions A-1Appendix B: Packaging B-1Appendix C: Schematic C-1Appendix D: PCB Layout Top and Bottom Copper D-1Appendix E: Parts List Spreadsheet E-1Appendix F: Software Listing F-1Appendix G: User Manual G-1Appendix H: FMECA Worksheet H-1

-iii-


Abstract

MAVerick (Motorized Assault Vehicle) is a mobile gun platform controlled by a cellular

phone that has the ability to establish full-duplex communication with a command center in order

to transmit control and status signals. It contains a paintball gun attached to the platform which

fires at moving targets and has the ability to detect obstacles.

1.0 Project Overview and Block Diagram

The objective of our project was to design a vehicle capable of firing a paintball gun and be

controllable from a cell phone. Our initial customer base was the young adult but the

functionality of our project would make it useful for paintball enthusiasts of any age. We

imagined our project being used for entertainment purposes or another tool on the paintball field.

The design we decided to go with would give our project the ability to detect moving targets

using an ultrasonic/IR sensor, the ability to identify and detect obstacles, the ability to encode

and send control signals through a cellular phone to control the tank/gun, the ability to receive

and decode control signals from the cellular phone, and the ability to send status information

from the tank to the controlling device. To meet these criteria, we selected parts that gave us the

functionality we needed and then integrated them into our design using each individuals unique

set of skills.

- 1 -


Figure 1.1 Block Diagram

2.0 Team Success Criteria and Fulfillment

a. Ability to detect moving targets using an ultrasonic/IR sensorBy implementing an autonomous search mode with the use of an ultrasonic ranging sensor we accomplished this project specific success criterion.

b. Ability to identify and detect obstaclesBy the use of infrared proximity sensors, we were able to detect obstacles and turn off the motors before running into them.

c. Ability to encode and send control signals through a cellular phone to control the tank/gunWe used DTMF generator chips to create tones that could be sent to the tank giving us the ability to control it.

d. Ability to receive and decode control signals from the cellular phoneWe used DTMF decoder chips to interpret tones received over a cell phone. We used these signals to control the tank.

e. Ability to send status information from the tank to the controlling device

- 2 -


We used the control signals in c and d to send signals in order for us to light LED’s and alert the user to changing conditions around the tank.

3.0 Constraint Analysis and Component Selection

Analysis of Design Constraints

There are several key aspects that need to be considered when designing this

project. First is the computation requirements. There is a small amount of computation

needed. The microcontrollers are mainly used to read sensors and relay control data. To

conserve battery power, a microcontroller that has the ability to operate at low

frequencies will be used. Second, the interfacing requirements will be very important.

There will be several parts interfaced to the microcontroller including: motor controllers,

stepper motors, solenoid, multiple infrared sensors, ultrasonic sensor, DTMF encoder and

decoder chips, cell phone, LEDs, and a computer joystick. Each of these has special

needs, whether they need an analog to digital converter, a driver MOSFET, or level

converters. Much of the design will be the integration of each of these components. All

of these systems need power, which is the third important consideration. Everything will

run on rechargeable batteries. The cell phones will run on their own battery due to

special voltage requirements and ease of design. Linear voltage regulators will be needed

to take the battery voltage and convert it to the 5 volts required to run the logic devices.

The ultrasonic sensor can run at any voltage between 6 and 24 volts. Each sensor has a

shutdown transistor that is designed to turn off the sensor when not in use to save power.

The mechanical aspect also has to be considered. In order to move around a heavy

paintball gun, we will use a powerful stepper motor and a large wheel base. The air tank

will be mounted low to lower the center of gravity and make sure it will not tip over

easily. The last major consideration is cost. While keeping costs low is important, a

balance must be kept between cost and functionality. For example, the ultrasonic sensor

must be able to give accurate readings at relatively far distances. However, an industrial

sensor with a precision of 1 inch at 30 feet is not necessary. On the other hand, most

relatively inexpensive ultrasonic sensors do not have a range that would be effective to

achieve any potency on the paintball field. Thus a balance must be made between low

cost and high functionality. To achieve this goal, the tank and paintball gun were bought

at a low price on E-Bay and the sensors were well-researched over the internet. The

- 3 -


microcontrollers are commercially available, so as to be able to search many vendors to

find the cheapest price. The DTMF chips were researched to find the parts requiring the

least external components while still keeping the price low. Most other parts are

commonly available at most electronic supply stores.

Rationale for Component Selection

Microcontroller

The base of this project is the microcontroller. On the tank side, the most

computationally intensive task is to activate the ultrasonic sensor and determine the

distance returned. From this data and the knowledge of which direction the turret is

facing, the microcontroller can determine when and where targets appear. This requires,

however, little more processing than storing data to memory and comparing it to a

register. This computation only happens when MAVeric is in search mode. The only

other tasks that the microcontroller needs to do while in search mode is to control the

stepper motors, and occasionally activating the trigger solenoid. When the tank is in

normal operating mode, there are more tasks that need to be done. The main motors and

stepper motors need to be driven, the infrared collision sensors need to be queried, the

DTMF chips need to communicate, and the trigger solenoid needs to be activated. This

does not require much work by the microcontroller, but does require many I/O ports. The

DTMF chips alone require 10 port pins. For the tank microcontroller, it is required to

have four analog to digital converters, two independent pulse width modulation outputs,

and a multitude of standard I/O pins. The microcontroller on the command center has

slightly fewer interface needs. It needs to communicate with the DTMF chips, interface

with a joystick with four axis and four buttons, and several LEDs. It needs three analog

to digital converters, and many I/O ports. To simplify design, the same model

microcontroller will be used on the tank and the command center. Below is the

comparison of the Atmel Mega8 [3.1], Atmel Mega16 [3.2], and the Freescale 9S12C

[3.3].

- 4 -


Looking at the chart, we see that the Mega8 is a good fit except it does not have enough

I/O pins. The Mega16 fits all the criteria and is still a fairly inexpensive device. The

MC9S12C32MFU25 has more than enough of everything compared. The fact that it has

so many extra functions leads to extra power drawn that is wasted. It also is more

expensive than the other two. This comparison leads our group to pick the Atmel

Mega16 as the microcontroller we will use.

DTMF Encoder

The main goal of this component is integration. The fewer external parts needed,

the better. The below table compares the Rohm BU8307CS [3.4] and the National

Semiconductor TP5089 [3.5].

The TP5089 is clearly better than the BU8307CS. Not only does it require much fewer

external parts, it is also cheaper. We chose the TP5089 for our DTMF encoding.

DTMF Decoder

In the same fashion as the DTMF encoder, the goal of this category is to limit the

number of external parts. The table below compares the TDK Semiconductor 75T204

[3.6] and the California Micro Devices CM8870 [3.7].

- 5 -

Table 3.2 – DTMF Encoder Comparison

Table 3.1 - Microcontroller comparison


Although the 75T204 needs fewer parts, the two chips are very similar. The CM8870

was chosen because it gave us more options for debugging if we needed them.

Ultrasonic Sensor

Many factors go into choosing the correct ultrasonic sensor. Range, interface,

voltage, and price are the main aspects that need to be compared. Below is the

comparison between the Devantech SRF04 [3.8], Devantech SRF08 [3.9], and the

Senscomp 600 Instrument Grade Smart Sensor [3.10].

Initiate – Echo refers to setting a line high, then waiting for an echo (return sound wave

pulse) on another line. This is a simple and effective way to receive distance

information. The SRF04 is cheap and easy to interface with, but has a range that would

severely restrict operations of MAVeric. The SFR08 has a longer range, but a difficult

interface and a higher price. The 600 Smart Sensor has a long range, and easy interface,

but has a non-standard voltage requirement and a high price. The group has decided to

use the 600 Smart Sensor. The long range makes MAVeric much more potent in the

paintball field, giving it the ability to strike relatively distant targets and defend a large

area. These abilities are worth the extra cost.

Conclusion

In this project there were many design constraints. Ranging from varying voltage

needs to sensor detection range, each of these needs have been met in the various parts

chosen to be used. Each fulfills a specific need to the success of the tank and was chosen

- 6 -

Table 3.3 – DTMF Decoder Comparison

Table 3.4 – Ultrasonic Sensor Comparison


with great care. There was a balance between simplicity and functionality that was

always in the mind of the engineer during the design phase. This balance was kept

throughout the project in order to fulfill the requirements of the device.

.

4.0 Patent Liability Analysis

Results of Patent Search

A search at the United States Patent Office website, http://www.uspto.gov [4.1], was

conducted in order to determine possible patent infringements on our design. The following

patents were investigated for possible patent infringement:

Patent Number Title Filing Date of Patent

D425,140 Toy Tank May 16, 2000

4,596,900 Phone-line linked, tone-operated control device June 24, 1986

4,751,658 Obstacle avoidance system June 14, 1988

6,791,976 Mobile-to-mobile DTMF signaling in tandem

free operation

September 14, 2004

5,119,322 Digital DTMF tone decoder June 2, 1992

5,598,164 Vehicle obstacle avoidance system January 28, 1997

6,683,820 Method and apparatus for tracking sonar targets January 29, 2004

A search was also conducted on www.google.com [4.2] to look for commercial products

that are similar to our project. A product was found on

http://www.defensereview.com/modules.php?name=News&file=print&sid=657 [4.3], which is a

more advanced version of our product with more weapons and better navigation abilities.

Searching on www.uspto.gov concluded no patents for this product.

Analysis of Patent Liability

The patents listed above have similar designs to our own. The patents will be sorted by

literal infringements, doctrine of equivalents and no infringements in the discussion that follows.

- 7 -

http://www.uspto.gov/

http://www.defensereview.com/modules.php?name=News&file=print&sid=657

http://www.google.com/



Literal infringements:

Vehicle obstacle avoidance system (Pat. No. 5,598,164)

Abstract: A system for warning a vehicle driver of obstacles to the front, rear and sides of

the vehicle. If the vehicle is stopped and a front or rear obstacle is detected, the vehicle is

prevented from moving forward or reverse, respectively. The inhibition of movement can be

overridden by the driver once he acknowledges the obstacle. Similarly, the driver is warned of

front, rear and side obstacles while the vehicle is moving. In the case of side obstacles, only

when it appears that the driver will move the vehicle toward the obstacle is he warned. [4.5]

Analysis: The same functionality described by this patent is built into the Command

Center that controls MAVerick. Infrared sensors are used to detect an object that is in front,

front-left, front-right, and rear of the tank. Based on the sensor information, the tank sends

control signals to the Command Center which lights up LED’s based on the information. If a

sensor is tripped warning the Command Center that something is in MAVerick’s way, the

Command Center will prohibit the user from sending a signal to move toward the obstruction

unless the override button is pressed. This causes our design to have a literal infringement on

this patent because the patented idea is identifying obstacles and prohibiting movement in that

direction.

Infringements under Doctrine of Equivalents:

Mobile-to-mobile DTMF signaling in tandem free operation (Pat. No. 6,791,976)

Abstract: A wireless communication method and arrangement that facilitates and allows a

user at one end to send dual tone multiple frequency characters from one wireless unit to a

second wireless unit completely within tandem free operation mode without changing to tandem

operation mode. By remaining in tandem free operating mode during dual tone multiple

frequency signaling the delay and distortion of the CODECs used in tandem operation mode is

avoided, and the real possibility of missing bursts of dual frequency multiple frequency

characters that exists presently because of existing timing requirements is removed. [4.8]

Analysis: The above patent is similar to our design of sending and receiving DTMF tones except

for the tandem free processor that the patent uses. Our design just encodes and sends while the

above design uses a few more features. The idea is really close to what we do and a patent

lawyer would need to be consulted to determine if the patent is infringed. If our design does

- 8 -


infringe this patent it would be under the doctrine of equivalents because we have a very similar

setup that is done in the same way, just with a little less functionality than the patent.

No Infringements:

Phone-line linked, tone-operated control device (Pat. No. 4,596,900)

Abstract: A phone-line-linked, tone-operated control apparatus in accordance with the

invention comprises a detecting circuit coupled to a telephone line for detecting at least one

predetermined sequence of predetermined tone signals received on the telephone line and for

producing a corresponding sequence detection signal. An additional control circuit is responsive

to the sequence detection signal for producing a corresponding control signal. Preferably, a

break-in prevention circuit prevents access to the control apparatus unless a predetermined

access code is first given. [4.6]

Analysis: The patent above uses some similar functionality that we employ in our design

but the way in which it is designed is substantially different. Our design decodes a DTMF signal

which gets sent into a micro-controller to decode and decide which action to take. In the above

patent the DTMF output goes into a logic circuit comprised of flip flops and logic gates which is

a different implementation than a micro-controller therefore our design does not infringe on this

patent.

Obstacle Avoidance System (Pat. No. 4,751,658)

Abstract: A system for avoiding obstacles in the path of a vehicle including a sensor

assembly having a field of view with a plurality of sectors for detecting the distance of objects

within each sector. The system further includes an element for identifying obstructed sensors in

which objects are detected within a predetermined range and a device for selecting an

unobstructed sector close in alignment to the direction of the path to designate around the object

a clear path which is close to the original path. [4.7]

Analysis: The design presented in this patent is similar but much more complex than the idea

in the design of MAVerick. The patent above uses sensors to determine obstructions and based

upon those readings it maps out a new path that is unobstructed. The simple design of using

infrared sensors to detect objects is not novel enough for a patent; the real idea is the processing

in order to map out a new path and the different sectors. Therefore our design does not infringe

on this patent since our design does not map out a new path if obstructed.

- 9 -


Digital DTMF tone decoder (Pat. No. 5,119,322)

Abstract: A digital dual tone multi-frequency (DTMF) tone receiver having a detector circuit

for scanning incoming audio signals for possible presence of DTMF tones, and a verifier circuit

for verifying the presence of the detected DTMF tones. The detector circuit performs successive

discrete Fourier transforms on the incoming signal at a first level of accuracy, and in response

generates a tone verify flag signal for indicating whether or not a DTMF tone has been detected.

The verifier circuit is enabled in the event that the tone verify flag signal indicates detection of a

DTMF tone. The verifier circuit then performs further discrete Fourier transforms on the

incoming signal at the detected DTMF frequencies as well as frequencies adjacent thereto, at a

second level of accuracy greater than that provided by the detection circuit. The verifier circuit

generates a tone present flag signal for indicating whether or not the detected DTMF tone is

actually present. The detector and verifier circuits are preferably implemented algorithmically

within a digital signal processor. [4.9]

Analysis: Both MAVerick and the Command Center have the need to decode DTMF signals.

In our design, we do not perform any Fourier transform in order to determine the DTMF tone

like the patent above. The patent above states a specific algorithm using Fourier transforms in

order to determine the presence of a DTMF tone. Our design uses a simple IC that was

purchased so our design does not infringe on the patent.

Method and apparatus for tracking sonar targets (Pat. No. 6,683,820)

Abstract: A method and apparatus for analyzing newly acquired and faded or lost sonar

contacts. Initial processing identifies a list of possible associations between a newly acquired

contact and lost contacts. Subsequent processing of the possible associations reduces the number

of possible associations that a sonar operator must consider in determining whether an acquired

contact represents a new contact, a reacquired lost or faded contact. [4.10]

Analysis: MAVerick’s ultrasonic sensor performs a similar sweep as described by this

patent. Our ultrasonic sensor is going to take readings at different angles to measure distance to

potential targets and then store those distances. A trip on the infrared sensors will cause the

ultrasonic sensor to sweep the designated range of the infrared sensor to check if there are any

changes in distance. The patent describes a much more complex algorithm that is performed by

our design. The idea behind this patent is the algorithm used to determine if the contact

established is the same contact as before or if it is a different contact. Our ultrasonic sensor

- 10 -


doesn’t take into account anything as complex as that; it just sends values of distances back to

the micro-controller. Therefore our design does not infringe on this patent.

Toy Tank (Pat. No. D425,140)

Analysis: This patent is a patent of a model toy tank design. Shown below is one of the

model sketches from the patent website [4.4], which appears to be the same exact design as

MAVerick. Since we purchased the tank from a manufacturer of the patented model no patent

liabilities exist.

Recommended Action:

Since our design has one literal infringement on patent 5,598,164, we have to either

modify our design or license the patent. We would license the patent since we want our design

to perform the same actions that were patented in 5,598,164. There really is no way to get

around this patent. Since the idea of the patent is not novel we could argue that this patent does

not apply to our design because of its simplicity. If that does not work then we would need to

license the patent or take the functionality described in our patent out of our product.

The doctrine of equivalents patent would have to be reviewed by a patent lawyer in order

to determine if infringement exists. If infringement does exists, we would need to purchase or

license the patent since the transferring of DTMF signals is vital to our projects success.

5.0 Reliability and Safety Analysis

- 11 -


Reliability Analysis

The reliability of the MAVerick was determined using the military handbook “Reliability

Prediction of Electronic Equipment.” Two values were calculated for each of the components

analyzed, λP and the mean time to failure (MTTF). λP is the number of failures per component in

106 hours, and MTTF is 1/ λP or the number of hours before a failure occurs. [5.2]

Four components of the MAVerick’s design were selected for reliability analysis. First,

the ATMega16L microcontroller from the microcontroller block of the tank circuit was analyzed.

Second, the 3.58 MHz crystal oscillators from the DTMF blocks of the tank and command center

circuits were analyzed. The third components analyzed were the LM7805CT voltage regulators

from the power blocks of the tank and command center circuits. And finally, the DC motors from

the motor block of the tank circuit was analyzed.

These components were chosen for three reasons. First, all the components represent

different blocks of the MAVerick’s circuits. Second, they were chosen for criticality. If any of

these components fail, then their respective blocks will fail and the MAVerick will lose a major

portion of its functionality. Lastly, they are all different types of components and demonstrate

how different parts use their own unique variables, values, and equations to rate their reliability.

1. Microcontroller – Atmel AtMega16L [3]

λP = [C1 * ПT + C2 * ПE] * ПQ * ПL [5.1]

where:

C1 – Die Complexity Failure Rate = 0.14 (8 bit processor)

ПT – Temperature Factor = 1.5 (T < 100oC)

C2 – Package Failure Rate = 0.019 (40 pins)

ПE – Environment Factor = 4.0 (Ground, mobile)

ПQ – Quality Factor = 10 (Commercial, unknown screening level)

ПL – Learning Factor = 1.0 (>2 years in production)

Therefore:

λP = [0.14 * 1.5 + 0.019 * 4] * 10 * 1.0

λP = 2.86 failures per 106 hours

MTTF = 1/ λP

- 12 -


Mean Time To Failure or MTTF = 349,650 hours or 39.9 years

2. Crystal Oscillator – 3.58 MHz

λP = λb * ПQ * ПE [5.1]

where:

λb – Base Failure Rate = 0.019 (Using value for 5MHz)

ПQ – Quality Factor = 2.1 (Non-military spec)

ПE – Environment Factor = 10 (Ground, mobile)

Therefore:

λP = 0.019 * 2.1 * 10


MTTF = 1/ λP

Mean Time To Failure or MTTF = 2,506,265 hours or 286.1 years

3. Voltage Regulator – LM7805CT [4]

λP = λb * ПT * ПA * ПQ * ПE [5.1]

where:

λb – Base Failure Rate = 0.012 (MOSFET)

ПT – Temperature Factor = 3.7 (T < 100oC)

ПA – Application Factor = 1.5 (Linear amplification)

ПQ – Quality Factor = 8 (Plastic)

ПE – Environment Factor = 9 (Ground, mobile)

Therefore:

λP = 0.012 * 3.7 * 1.5 * 8 * 9


MTTF = 1/ λP


4. Motor – DC

λP = [(t2 / αB3) + (1 / αW)] * 106 [5.1]

where:

αB – Bearing Characteristic Life = 22,000 (T < 70oC)

αW – Winding Characteristic Life = 110,000 (T < 70oC)

- 13 -


t – Motor Operating Time Period = 5 (Hours at a time)

Therefore:

λP = [(52 / 61003) + (1 / 31,000)] * 106


MTTF = 1/ λP


The MTTF of three of these devices could definitely use improvement. The worst device

is the DC motor with 110,000 hours on average before the first failure. Because the device would

not harm anyone if it failed, this MTTF is acceptable, but there’s always room for improvement.

The main cause of this device’s unreliability is the temperature at which it operates. 70oC is a

conservative value. Also, the motor operating time period is a conservative value. Most times,

they will not be run for 5 hours at a time. In order to increase its reliability, though, heat sinks

could be added to the circuit and the actual tank could even be ventilated to allow air to pass over

the motors.

The voltage regulator is the next worst when it comes to reliability. It too has a very

conservative temperature factor, but the best way to improve its reliability is to simply buy a

better part with a much lower quality factor.

The microcontroller comes next on the unreliability scale. In addition to having a

conservative temperature factor like the rest, its quality factor is also conservative. Actually, it is

the worst value given in that category: the commercial, unknown screening level. Because of

these conservative values, in reality it will outperform its MTTF.

The crystal oscillator is very reliable and no change is needed.

FMECA Worksheet for the Entire Schematic

This FMECA worksheet examines different failures that may occur during operation of

the MAVerick. The failures are divided into nine blocks. These blocks are illustrated on the

circuit diagrams included. They are as follows: (A) Power, (B) DTMF, (C) Microprocessor, (D)

Status LEDs, (E) Joystick, (F) Sensors, (G) DC Motors, (H) Stepper Motor, and (I) Trigger.

Blocks A, B, and C are on both the tank schematic and the command center schematic. To avoid

confusion in these cases, the part labels on the tank schematic (not command center) were used

- 14 -


in the FMECA worksheet. The blocks perform the same function on both of the circuits, but have

different part labels which would get confusing. All of the failures will include failure mode,

possible causes, failure effects, method of detection, criticality, and remarks.

The criticality portion will be divided into high and low. High will represent failures that

have the most potential to cause injury to the user. Ideally a high failure rate should have a

10-9. These failures will deal with unpredictable power scenarios. Conversely, low will represent

failures that do not pose a risk to the user. Ideally a low failure rate should have a 10-6.

For the most part, the MAVerick is a safe product. There are always unpredictable

possibilities, but the failure modes defined as high criticality in the FMECA worksheet will

probably only damage the circuits and not the user. These modes deal with unpredictable

voltages and temperatures in the power supply, the DC motors, and the transistors controlling the

DC motors. The low criticality modes pose practically no risk at all to the user.

In order to increase the reliability and safety of the MAVerick, one could add some

hardware monitoring to the circuits. You would have to be sure that the reliability of the

monitoring hardware is high though, so that the circuit’s unreliability does not get out of control.

6.0 Ethical and Environmental Impact Analysis

Ethical Impact:

Our project faces some obvious ethical issues, most notably safety. The use of a paintball

gun alone allots for considerable safety measure but when used in conjunction with remote

control and autonomous usages, the possibility for malfunction and the magnitude of its

subsequent damage increase dramatically. To maintain a safe product we must ensure that our

electrical, mechanical and software systems are designed in the proper manner. Our ethical

responsibility doesn’t end there though. Misuse of the product could potentially cause much

more harm then a system failure. The following will discuss these ethical issues and the

measures taken to address them.

During our initial designs of the tank, safety was always at mind. When we designed the

circuits, we made sure that in their failure mode, they would fail to a safe state. For areas of our

circuit like the motors, it was important for us to have the circuit fail open because that allows

- 15 -


the device to turn itself off in the event of failure and prevent any possible arcing or excessive

heat buildup that could lead to burns as well as fire. [6.2] Some other measures we took were to

add pull down resistors on our motors, turret, and trigger. During reset, the signals to activate

those mechanisms could float high and cause harm to a user caught off guard. In the layout of

the PCB, considerations were made to place all heat generating parts such as the transistors far

enough apart so that excessive heat would not build up around them. Thick traces were also

created to ensure that current spikes could not flash them and cause unexpected problems. While

in design and normal operation our circuitry has been proven, for the product to be taken to

market we would have to make sure that we would not reach any hazardous states due to

different operating conditions such as heat, cold, or water.

For our mechanical systems, our design is fairly safe. Our tank operates at a very low

speed so there is no danger from collision. The turret rotates at a slow speed and upon impact

with an object, the stepper does not have enough torque to cause any harm. The only mechanical

danger that our tank poses is the gun. An accidental firing of the gun could occur in extreme

circumstances. To counteract this, the safety is readily accessible so when the tank is not in use,

it can be activated making it impossible to fire the gun. Also, the way the trigger is designed, if

for some reason the trigger is pulled and not released, only one shot will be fired instead of a

continuous stream.

Our software actually has the greatest potential for error and accidental harm. We have

taken great precaution to ensure that there is no way for the software to act in a harmful manner

other than what the user tells it to do. One of our biggest worries was the tank being put into

autonomous mode, losing a cell phone connection and not being able to connect again to turn it

off. While we initially thought it would be nice to be able to “set it and forget it,” the potential

of not connecting caused us to redesign that section of code so it continually checks for a

connection and if it doesn’t detect one, the tank will reset and wait to be dialed again.

Besides the safety issues with our product, there is the concern of improper usage by the

user. A device such as ours has the capacity to cause substantial harm to person and property

when used improperly. When selling our product to vendors, we must ensure that the tank only

be sold to people of ages 18 and above. The tank could still pose a danger though in the hands of

a person who doesn’t know how to use it so it is our responsibility to supply clear and concise

- 16 -


directions on how its proper use while placing warnings on the tank, command center, and

manual about the potential safety hazards.

Environmental Impact:

Like many of today’s advanced remote devices, we utilize a printed circuit board and a

rechargeable battery. If not disposed of properly, these components can have a negative

environmental impact. It is our responsibility to take the necessary steps in alerting the public as

to their affect and how to properly dispose of them.

Our design called for the use of two printed circuit boards, one in the tank and one in the

Command Center joystick. Printed circuit boards contain lead contain hazardous materials such

as Lead, Mercury, Arsenic, and Cadmium. [6.3] “Typical wastes generated by the PC board

industry are: industrial wastewater and treatment residues, spent process baths, e/acids used for

cleaning equipment, copper sulfate crystals, and re-flow oil.” [6.4] The boards we used for our

current design contain these hazardous materials and were most likely created in plants that

produce that waste. If we were to ever go into production, we could select a manufacturer that

uses more environmentally friendly processes. Also, there are currently boards that exist that

don’t contain the harmful materials common in most boards. By utilizing both those options, we

could reduce the damage to the environment cause by our product and set an example for other

developers.

Our design also calls for the use of a rechargeable nickel-cadmium battery. These

batteries make use of harmful metals that can include Mercury and Cadmium [6.5] Like the

printed circuit board, these elements are harmful to the environment and cannot be simply

thrown out with the common trash. Contacting ones nearest recycling center to find if they

recycle batteries is an option as well as contacting local electronic stores as they often recycle

batteries for their customers. [6.6] While normal disposable batteries was also an option, the

amount of batteries a consumer would go through in the normal life cycle of our product would

be more harmful to the environment than simply using one rechargeable battery.

The remaining parts of the project should not pose any direct threat to the environment.

The motors could be salvaged and be reused in other devices or simply be broken down to be

recycled. The shell of the tank and even most of the sensors are almost completely made out of

- 17 -


plastic which could be recycled. The barrel of the gun is made out of aluminum which could

also be recycled. Any remaining paintballs should be fine to throw out as they are simply made

of a biodegradable shell and filled with a substance similar to vegetable oil.

It is our responsibility as the developer of this product to inform the public about these

hazards. Too often are these warnings left unmentioned or put someplace where the user will

never notice them. The user manual is an obvious place to put the warnings. It is important that

we make these visible and easy to understand. If they are simply placed on the last page with no

mention of them anywhere else, we are not doing much good. Another place where it would be

helpful would to place the warnings directly on the tank. Often, user manuals get lost or

misplaced, especially at the end of the products life cycle causing the warnings to go unnoticed.

While it may not be feasible to put all pertinent information directly on the tank, we could supply

a hyperlink to a document containing the proper disposal methods and maintain that link for as

long as we produce the product plus the products typical life cycle. It is not enough to simply

have the information; it is our job to make sure it is easily accessible to the user.

Overall this project does not pose a great threat to the environment or its users if operated

correctly. By taking the proper precautions, by both the producer and the end user, the product

can be used and disposed of safely. While disposal and proper usage rely on that of the user, the

necessary steps will have been taken to ensure that they are well informed of the hazards.

7.0 Packaging Design Considerations

Comparison to Commercial Products

The first product is a military vehicle called the SWORDS that is almost exactly the same

in design to the MAVerick. It is pictured in figure B.1. SWORDS stands for Special Weapons

Observation Reconnaissance Detection Systems. The SWORDS rides on tank treads and is fitted

with many devices to aid in detecting enemies including four cameras, night vision and zoom

lenses. The attached weapon is either a M249 or M240 machine gun and can fire 300 rounds

before needing to be reloaded. It can travel at a speed of around 4 mph and can overcome

obstacles like “barbed wire and rock piles” [7.1].

- 18 -


The design of the SWORDS is very similar to the MAVerick in that the operator Using a

video screen to identify and eliminate targets creates advantages for both the SWORDS and the

MAVerick if retrofitted with a real gun and used in a military sense. Using a robot instead of a

human soldier gives you better accuracy when firing a weapon and simplifies warfare. The lack

of a human holding the gun eliminates errors such as “trigger recoil, anticipation problems, and

pausing the breathing cycle while aiming a weapon” [7.1] . In addition, the SWORDS and the

MAVerick used in a military setting “don’t need to be trained, fed or clothed. They can be boxed

up and warehoused between wars. They never complain. And there are no letters to write home if

they meet their demise in battle.” [7.1]

The SWORDS and the MAVerick have obvious differences though. Although the designs

and functions of the two machines are virtually identical, the packaging of each must fulfill

different goals. Needing to brush off enemy fire and move through tough terrain, the SWORDS

is a much more rugged machine made of steel, having top of the line sensors, and employing a

live machine gun. The MAVerick lacks the overall strength of the SWORDS and is not designed

for mortal combat. These advantages come with a price, literally. The SWORDS cost $200,000 a

piece, more than 529 times the cost of the MAVerick. In order to compete with the SWORDS

the MAVerick would need a real gun, better armor, and a camera with a lot of zoom capability.

One possible benefit of using a MAVerick over the SWORDS is the MAVerick’s search mode

where it stops and automatically scans for enemies and fires upon them. The SWORDS only

fires when a human operator tells it to.

Having looked at the MAVerick’s potential from a military offensive point of view, let’s

now look at it from a home or commercial security point of view. This next product is made by

Rotundus, pictured in figure B.2. It’s exactly what it looks like, a huge ball. Inside is a pendulum

that is “lifted in the direction of travel which moves the ball's center of gravity and sends it

rolling.” [7.2] It can reach speeds of up to 20 mph and travel through mud, snow, and water. The

Rotundus ball can also be “mounted with cameras, microphones, gas and smoke detectors and

heat sensors on a central axis.” [7.2]

There are obvious design differences between the Rotundus and the MAVerick. The

Rotundus takes a basic design, a sphere, and turns it into a security robot by having it chase

would be criminals away. The simplicity of the concept is amazing compared to the complexity

of the MAVerick acting as a security robot in search mode.

- 19 -


In order to use the MAVerick as a non-lethal security robot, you could retrofit a taser gun

instead of the paintball gun. The Maverick could then sit in a strategic place in your home in

search mode and incapacitate an intruder when one is detected. This would be far more effective

than having a big ball chase the intruder away, although not as humorous. The Rotundus can also

cause damage to property in your home or commercial business, not to mention it cannot handle

stairs. If the Rotundus cannot catch the intruder in time, he could possibly escape. The

MAVerick on the other hand, would incapacitate him and stop any danger to your family. Plus,

with the built in cell phone, the MAVerick could dial 911 in the event it captures an intruder in

your home.

The Rotundus does contain some design advantages though. The MAVerick is superior in

closer quarters where it can sit and wait while not having to worry about needing room to

accelerate, but in open areas like a factory or other business, the fast Rotundus would be superior

to the MAVerick retrofitted with a short-range taser gun. It really isn’t realistic to try and

counteract this flaw and design the MAVerick with a real gun for a security use because of

ethical and legal issues.

As far as packaging goes, the Rotundus fares well again. A heavy, sturdy ball will not

easily be stopped by the unsuspecting intruder. The MAVerick still lacks with it’s weak armor

but this is not as glaring a flaw than with it’s military use because in a home security role it

would be incognito.

Design Specifications

The MAVerick’s packaging is shown in figure B.3. A number of modifications were

made to the original tank design. The turret was modified and integrated with the paintball gun.

The top of tank was smoothed down to eliminate some of the detailing that got in the way of the

turret’s rotation after all the extra weight was added. The Atmel microprocessor, the cell phone,

and the new circuit board are all placed inside the tank. All circuitry will be powered by a 9V

battery reduced to a usable 5V. This too will be packaged inside the tank. The new circuit board

allows for independent control of the two treads. That way, the tank does not have to stop in

order to turn. The existing motors were kept and are powered by the existing battery pack. Four

proximity sensors were mounted in order to detect obstacles and warn the user to avoid them.

- 20 -


The wireless camera was mounted atop the paintball gun so that wherever the turret points, the

camera will see. The actuator, used to physically pull the trigger of the paintball gun, was

mounted inside of the turret. It is powered by the existing battery pack in the tank. And finally,

the ultrasonic sensor was attached to the barrel to alert the microprocessor when a target is in

front of the tank.

None of the sensors are more than a few inches wide in any direction nor are they heavy,

so they were easily mounted to the tank with a hot glue gun. The stepper motor was screwed to

the top of the inside of the tank.

The turret was more complicated. The front was cut out so that the paintball gun and

actuator could be housed inside. The paintball gun and actuator are held down with zip ties, and

the actuator is screwed into the paintball gun. The CO2 tank rests on top of the turret secured by a

zip tie and the paintball hopper sticks straight up out of the top of the turret.

Materials List

Major Parts(cost over $1.00) Number Total Weight(1bs) Total Cost(US $)1. Atmel Mega16 Microprocessor 2 negligible 13.12

2. Remote Control Tank 1 8 59.003. Brass Eagle Marauder Paintball Gun 1 1.3 33.45

4. Top Gun Joystick 1 2 32.455. Motokata Wireless Reversing & Parking Sensor 4 .35 19.00

6. DTMF Encoder ICS5089 4 negligible 5.007. DTMF Decoder 4 negligible 16.008. Senscomp Ultrasonic Sensor 615088 1 .41 55.00

9. Senscomp Ultrasonic Housing 619395 1 negligible 7.50

10. Link Actuator 1 .3 5.5011. Linksys Wireless-B Internet Video Camera 1 .53 106.91

12. Stepper Motor 1 .6 30.00

Note: Listed prices for the 2 Atmel microprocessors and the Link actuator are for reference

purposes only as they were previously owned by a group member and thus did not affect our

total cost.

- 21 -


Total Cost To The Top Guns = $484.31

Total Cost If No Parts Previously Owned = $516.05

Total Weight = 14.54 lbs. (Goose the joystick included)

Tooling Requirements

The only tooling requirements needed were a drill, a soldering iron, a saw, a screwdriver,

and a hot glue gun for mounting of the sensors.

8.0 Schematic Design Considerations

Theory of OperationMicrocontroller

The base of this design is the microcontroller [8.1]. Because it is running on a battery,

the microcontroller will be set at a low frequency to conserve power. It will, however, run at 5

volts. This is the case because the DTMF decoder chip will not recognize 3.3 volts as a valid

high signal. Adding a level converter chip would add in unnecessary complexity and might end

up consuming more power than would be saved in the first place. Also, the power MOSFETs

used have a turn on voltage that is guaranteed to be as low as 4 volts. A microcontroller running

at 3.3 volts will not have enough voltage to control these transistors.

Power SupplyThere are several devices on each board that require 5 volts to run. The IR sensors have

an especially high current draw, which could be as high as 50mA each. With four running at the

same time, a possible 200mA alone limits our power supply choices. The team chose to use a

7805 voltage regulator [8.2]. It is a readily available chip that provides a simple circuit and high

current supply with low noise. During testing, it was found that a major obstacle that must be

overcome is noise in the DTMF chips’ power supplies. The 7805 provides this low noise

environment.

- 22 -


DTMF ChipsThe DTMF chips, which were chosen for their simplicity, require a relatively easy circuit,

which is included in the datasheet [8.3]. The only circuitry added was a 74HC139 decoder chip

to lessen the number of port pins required for the DTMF encoder and capacitors to remove noise

in the input voltage.

Motor ControllerThe H-bridge model was used to drive the motors. This is where two P-MOSs [8.4] are

above two N-MOSs [8.5] and two transistors (one P-MOS and one N-MOS) are turned on to

drive current either direction through a motor. The transistors were chosen on a basis of having a

very low on resistance and a reasonable price. An interesting problem occurs with this setup.

Because the motor controller is running directly from the battery voltage, a logic high is the same

voltage as the battery, 9.6 volts. Giving it a high from the microcontroller will not turn the P-

MOSs off. To fix this problem, a CD4069 [8.6] chip with a Vdd of 9.6V (the same as the

battery) was used to increase the voltage of the signals from the microcontroller. Now the motor

controller will understand logic high from logic low correctly.

Stepper Motor ControllerTo control the stepper motor, a simple circuit of power MOSFETs [8.7] and arc-

suppression diodes are used. Each transistor will power a coil in the stepper motor by providing

a path to ground for current to travel through. The transistors were chosen because of the low on

resistance and the commercial availability.

SensorsEach of the sensors are either powered by 9.6 or 5 volts and provide a simple output of 5

volts. The outputs on the IR sensors [8.8] are open collector, and thus require a pullup resistor to

give the correct output signal. The output on the ultrasonic [8.9] gives 6.5 volts when high, so a

transistor create an inverter circuit with an output of 5 volts, regular levels for the

microcontroller. In addition, each of the sensors has the ability to be shut off by means of a

transistor in order to save power.

- 23 -


JoystickThe joystick [8.10] came with poor documentation, so much experimentation was

required to learn how to interface with it. After much trial and error, it was found that the

directional hat connected different resistors to Vcc. So, by adding a known resistance in series,

creating a voltage divider, one can determine which resistance is presented by reading the

voltage between the resistors. The main directions, X and Y, are a function of voltage. There is

a potentiometer that slides one way or another when the stick is pushed from side to side. When

the potentiometer is connected to 5 volts and ground, the output is a linear range from 0 to 5

volts dependent on how far the stick is pushed in each direction. The buttons provide the easiest

circuit. When a button is pressed, a switch is closed which grounds the output pin. By simply

adding a pullup resistor to the output, one can read a 0 or 5 volts on the output pin depending on

whether the button is pressed or not. A value of 10KOhm was chosen for the pullups because

the port pins can easily sink the current flowing from them, and they would not pull the voltage

up too much when a zero voltage is applied to them.

LED Status DisplayTo give the operator the most information possible and the ability to debug any problems,

the status of the IR (obstacle) sensors and the motion sensors are displayed by LEDs in the

command center. LEDs also provide data on whether the tank is in search mode, and if it is

firing at the moment. Each of the LEDs is set in a configuration to allow the microcontroller to

sink their current in order to prevent the pins from burning up. 1KOhm resistors were placed in

series with the LEDs to limit the current flowing to protect the port pins on the microcontroller.

ConclusionIn conclusion, each component has its own special requirements. Many times, the most

difficult part of design is satisfying each of the part’s needs while not introducing many more. In

the case of this project, there are many unique challenges that needed to be overcome. Each has

been met in a way to try to maximize the strengths of the design.

.

- 24 -


9.0 PCB Layout Design Considerations

When designing the boards, placement was of foremost importance. On our tank board,

there is a large mixture of analog and digital circuitry. In order to reduce noise, it was necessary

for us separate the analog and digital parts as much as possible. Also, on both boards, our

circuits will be decoding and encoding signals that are sent vie cell phones, it is extremely

important for those signals to be separated from the large analog parts as well.

Once the placing was complete, a routing strategy was necessary. Power and ground

were done first as they are a large source of signal noise so it is important to route them as best

as possible. For our tank circuit, we needed to separate power levels, one that drove the digital

sources and some of the small sensors, and one the powered the motors, stepper, actuator and

ultrasonic sensor. The signals were separated as much as possible while also attempting to keep

them parallel. Since ground plays a large part in noise, we also made sure not to connect the two

grounds anywhere.

The traces on that tank board that led to our more current drawing sources were designed

much thicker than any of the other traces on the board. Since we needed to supply a large

amount of current to an entire side of our board, we used a 200 mil trace from our power supply

to about 2/3 the height of the board. From this line we sourced several high current drawing

devices. While nominally, we shouldn’t need a line that thick but there are cases where current

could spike high enough and it is safer to have the larger trace. Corresponding to the power

trace, there is an equally thick ground trace that flows parallel to the power. The ground trace

has several tiers in width as well to help reduce the amount of common impedance which is a

known cause of noise (1).

One of the drawbacks about using such large traces is an increased capacitance that could

ultimately lead to noise problems in traces nearby them (1). Also, since one of our large traces

runs up a fairly large portion of our board, it is inevitable that we would need to send traces

across it. To help avoid reduce the noise created by the power trace, all of the lines routed

underneath it, were done perpendicular. Doing so helps reduce the cross coupling effects (1).

Another consideration that was made to help reduce noise was the routing of our

oscillators. Each board contains two oscillators which, if placed poorly, could cause a lot of

noise (9-1). Therefore, we made sure to place and route those right after the power lines so as

they could be as close as possible to the ICs that are using them. In doing so we were able to

- 25 -


have very minimal trace lengths and avoid routing any other traces through or under those

oscillators.

As mentioned before, our signal from the cell phones is obviously important signal for us.

If it becomes too noisy, it is possible that the decoder chip will not be able to correctly identify

the DTMF tones that are sent to it. When placing the header that will attach to our cell phone, it

was difficult to get it close to both the decoder and the encoder. Because of us, it was necessary

for us to protect the signal as much as possible on the trace that we had to extend. One method

we used to do this was to simply increase the trace width. Another method was to run it in

parallel and next to a ground signal. These two methods should help the signal remain clear.

Decoupling capacitors is another obvious way to help reduce noise. They do however

tend to become a nuisance because the can be quite large and difficulty to find room for. Even

with these problems, placing them as close to possible to their respective IC is a must. We made

sure in our design that we placed the capacitors right next to the power and / or ground pins on

our ICs and micros. In prototyping, noisy power lines had already caused a failure in our circuit

so we made sure to make these a priority.

10.0 Software Design Considerations

Memory Models:

An Atmel Mega16 is used on both MAVerick and the Command Center. The Mega16 is

equipped with 16KB of flash memory for our program, 1KB of SRAM for data and stack, and

512B of EEPROM [1]. The chip provides more than enough flash and SRAM, only use 21% of

flash on MAVerick and 8% flash on the Command Center, for our needs and the extra space can

be used for future expansion if necessary. The EEPROM is not utilized in our product.

Memory Sections/Mappings:

The Atmel Mega16’s memory is split up into three parts: program memory, data

memory, and EEPROM memory [10.1].

Program Memory:

- 26 -


The program memory extends from the address $0000 - $1FFF. The first section of this

memory, show in Figure 1, is used for the application program code and the second half is used

for a boot loader.

Figure 10.1: Program Memory Model [10.1]

Data Memory:

The data memory space is used to hold all data and stack variables. As can be seen in

Figure 2, the lowest 32 addresses hold the values of 32 general purpose registers. The next 64

addresses are used to hold the I/O ports and peripheral registers. Lastly, the next 1024 address

are dedicated to SRAM which is used for data and stack purposes. [10.1]

- 27 -


Figure 10.2: Data Memory Model [10.1]

EEPROM:

The EEPROM is not explicitly used in our code but 512B of it exist if needed for future

expansion.

Startup Code:

The startup code for our project is automatically generated by CodeVision [10.2] and

programs the following tasks: initializing the stack pointer, allocating space for global variables,

copy values of initialized variables to data section, and jump to main().

Organization of Embedded Application Code:

The organization of the embedded application code follows the program-driven model.

The code is set up in infinite while loops in order to carry out tasks. On MAVerick, once the

calling device, either a phone or the Command Center, is established, an infinite while loop is

entered which checks for incoming tones and controls the search mode capability. In the case

- 28 -


under Command Center control, the loop has the added functionality of checking status signals.

The program mainly runs on receiving DTMF tones from either a phone or the Command Center

and performing an action based on the received tone. On the Command Center, an infinite while

loop is entered which continuously converts the position of the joystick and sends the position

via a DTMF tone and checks for status signals. Both designs do not utilize any interrupts to do

any processing. A better way of organizing the code would have been a combination of interrupt

driven and program driven, but the software design was not considered until after the schematic

was made which limited our ability to use the interrupt port pins.

Software Design Narrative:

Tank:

Function Name: void main( void )

Return Value: None

Parameters: None

Status: Completed/Tested

Description: This function is the entry point of our application. Main calls a function called init

which takes care of our all device initializations. After the call to init, main waits for a tone from

either the Command Center or a normal cell phone to identify which device is going to control

the tank. After receiving the control tone, an acknowledge tone is sent and main calls the

function joystick or phone depending on which control signal was received.

Function Name: void init( void )

Return Value: None

Parameters: None


Description: This function is called from main and sets all of our device initializations which are

summarized in the table below:

Port/Peripheral Register Settings Purpose

- 29 -


PORT A PORTA = 0x00

DDRA = 0x00

Port A is used for inputs from the infrared

sensors so the data direction register is set to all

inputs and the default values are 0 for all of the

sensors.

PORT B PORTB = 0x01

DDRB = 0xFF

Port B is used for sending DTMF tones and

controlling the power to the infrared sensors and

ultrasonic sensor. All pins on Port B are set to

outputs and pin 0 is defaulted to 1 because that

pin is an active low tone enable for sending

DTMF tones.

PORTC PORTC = 0x00

DDRC = 0xFF

Port C is used for controlling the turret

movement and motor movement. All of the port

pins are defaulted to 0, no movement, and all

pins are set as output pins.

PORTD PORTD = 0x00

DDRB = 0xA0

Port D is used for inputting a DTMF tone,

controlling the ultrasonic sensor, and controlling

the trigger mechanism. All of the port pins are

defaulted to 0 and the data direction register is

set so the DTMF tone pins are inputs and the

ultrasonic and trigger pins are set as outputs.

This function was generated by CodeVision. [10.2]

Function Name: void phone( void )

Return Value: None

Parameters: None


Description: This function is called from main if the tank is to be controlled from a phone. This

function checks to see if the tank is search mode and, if so, the function checks the appropriate

sensors and controls the ultrasonic sensor to determine if a target is present. The tank continues

- 30 -


to perform this function until the search mode is disabled. When search mode is disabled, phone

waits for a DTMF tone from the cell phone and when it recognizes a correct tone, it calls the

function action to take the appropriate action based on that tone.

Function Name: void joystick( void )

Return Value: None

Parameters: None


Description: This function is called from main if the tank is to be controlled from a joystick.

joystick checks to see if the tank is in search mode and if so, checks the appropriate sensors and

controls the ultrasonic sensor to determine if a target is present. The tank continues to perform

this function until the search mode is disabled. When search mode is disabled, joystick waits for

a DTMF tone from the Command Center and when it recognizes a correct tone, it calls the

function action to take the appropriate action based on that tone. The Command Center also

checks the sensor inputs and sends control signals to the Command Center if any of the sensor

inputs have been tripped. This allows the Command Center to light up LED’s based on the

status of the tank.

Function Name: void action( int tone )

Return Value: None

Parameters: int tone – this is a numerical representation of a DTMF tone


Description: This function is called from either phone or joystick and takes the appropriate

action depending on which tone is sent into the function. This function consists of a switch

statement which has cases for each possible action the tank performs. A global variable named

Direction is manipulated in this function when a direction tone is received in order to determine

the calculated direction. A function called motor is then called in order to control the movement

of the motors based on the global variable Direction.

Function Name: void motor( void )

Return Value: None

- 31 -


Parameters: None


Description: This function is called from action and controls the motors based on the global

variable Direction. The appropriate values on port C are set in order to control the correct

direction of the tank.

Function Name: void send_tone( int tone, int duration )

Return Value: None


int duration – this is the time in ms that the tone will be sent


Description: This function takes the variable tone and sends the corresponding DTMF tone to

the Command Center or cellular phone for the length of time specified by the second argument.

A switch statement is used to set the appropriate port pins on port B in order to send to encode

the correct DTMF tone. An active low tone enable pin is then set low for the duration specified

by the second argument. After the delay, the enable is set high and the function exits.

Function Name: int get_tone( void )

Return Value: int – the numerical representation of the DTMF tone that is received

Parameters: None


Description: This function checks the valid tone bit to see if the DTMF tone is valid, if a valid

tone is not present, the function will return -1, otherwise the function will decode the tone and

return it’s numerical representation.

Command Center:

Function Name: void main( void )

Return Value: None

Parameters: None


- 32 -


Description: This function is the start of our application. Main calls a function called init which

takes care of our all device initializations. After the call to init, main sends a control signal tone

to MAVerick identifying itself as being controlled by the Command Center and waits for an

acknowledged tone from the tank. After this is complete, an infinite while loop is entered which

decodes the joystick input and sends the control signals to MAVerick, checks to see if any

control signals are received from MAVerick, and lights up LED’s based on the control signals

received by MAVerick.

Function Name: void init( void )

Return Value: None

Parameters: None


Description: This function is called from main and sets all of our device initializations which are

summarized in the table below:

Port/Peripheral Register Settings Purpose

PORT A PORTA = 0x00

DDRA = 0x00

Port A is used for inputs from the joystick.

Since Port A has the analog-to-digital conversion

ability we used this port for the joystick input.

The port is initialized to 0 and all of the pins are

set to input pins.

PORT B PORTB = 0x00

DDRB = 0x1F

Port B is used for sending a DTMF tone. The

lower 5 bits of Port B are set to output pins

which provide the functionality of sending a

DTMF tone. The upper 3 bits are no-connects

and left as input pins.

PORTC PORTC = 0x00

DDRC = 0xFF

Port C is used for driving LED’s displaying

status information of the tank. All of the LED’s

are initialized to 0 and all of the port pins are set

as outputs.

PORTD PORTD = 0x00 Port D is used for driving LED’s on its upper 3

- 33 -


DDRB = 0xE0 bits, while the rest is used for receiving DTMF

tones. All port pins are initialized to 0 and the

upper 3 pins are set to output pins and the rest

are set to input pins.

This function was generated by CodeVision. [10.2]

Function Name: unsigned char read_adc( unsigned char adc_input )

Return Value: unsigned char – the result of the analog-to-digital conversion

Parameters: unsigned char adc_input – port pin for the analog-to-digital conversion

Status: Completed/Not Tested

Description: This function takes the port pin number as its argument and performs an analog-to-

digital conversion on that port pin. The value of the analog-to-digital is returned. This function

was generated by CodeVision. [10.2]

Function Name: void send_tone( int tone, int duration )

Return Value: None


int duration – this is the time in ms that the tone will be sent


Description: This function takes the variable tone and sends the corresponding DTMF tone to

the Command Center or cellular phone for the length of time specified by the second argument.

A switch statement is used to set the appropriate port pins on port B in order to send to encode

the correct DTMF tone. An active low tone enable pin is then set low for the duration specified

by the second argument. After the delay, the enable is set high and the function exits.

Function Name: int get_tone( void )

Return Value: int – the numerical representation of the DTMF tone that is received

Parameters: None


- 34 -


Description: This function checks the valid tone bit to see if the DTMF tone is valid, if a valid

tone is not present, the function will return -1, otherwise the function will decode the tone and

return it’s numerical representation.

Function Name: void set_led( int tone )

Return Value: None



Description: This function takes the variable tone and lights up the proper LED based on that

tone. A switch statement is used to identify the proper LED from the tone and then the LED

output gets toggled using the XOR function.

Software Documentation:

Flowcharts:

The following flowcharts are for the MAVerick and the Command Center respectively.

MAVerick starts out with initializations and waits for a start bit. When the start bit is received it

then checks to see if it is a correct identifying tone and if not it goes back to receive a bit. When

a bit is received it goes into an infinite loop depending on the start bit identifying joystick control

or cell phone control.

- 35 -


The Command Center flowchart starts off with some initializations and then it sends a

control code to the tank in order for it to know that it is being controlled by the Command

Center. After that it checks for an acknowledge tone to see if a connection exists. After that an

infinite while loop is entered to command MAVerick.

- 36 -


11.0 Version 2 Changes

Interrupt driven code instead of polling

Y-Axis turret movement

Faster motors

PWM for variable motor speeds

Infrared sensors for aiding target detection

Video broadcast over the cellular phone

Better cellular phone integration

Laser range-finder

- 37 -


12.0 Summary and Conclusions

At the beginning of the semester we set out to create a cell phone controlled, paintball

tank. There were always obstacles like burning out transistors or turrets that won’t rotate

smoothly, but we overcame them all. Now that the semester is over, there were lessons learned.

First, prototyping hardware is very important in order to avoid flywiring on your PCB. This kind

of forward thinking helps to avoid future problems. Another problem avoided was the ability to

in-circuit program the microprocessor. Anticipating problems is key to doing efficient work.

Reflecting on problems that we actually encountered, when it comes to high risk parts you

should always buy spares. Finally, think about your software while designing your hardware. In

our particular case, better pin placement would allow us to more easily transition into interrupt

driven software. The main lesson we learned is always think ahead.

13.0 References

[3.1] http://atmel.com/dyn/resources/prod_documents/doc2486.pdf

[3.2] http://atmel.com/dyn/resources/prod_documents/doc2466.pdf

[3.3]

http://shay.ecn.purdue.edu/~dsml/ece362/Refs/9S12C_Refs/9S12C128DGV1.pdf

[3.4] http://www.rohm.com/products/databook/com/pdf/bu8307cs.pdf

[3.5] http://www.national.com/ds.cgi/TP/TP5089.pdf

[3.6]

http://www.tdksemiconductor.com/push_file_for_download.cfm/75T204_ds.pdf?

file_directory=54%5DZCGIE%29H%28V%26K%3A%3A%2DJE7%21%405VC

%40%40BR%0A&file_name=%2D%28%2D%26KQ%3C%3C8BYF%20X8J

%3EJ1%29%3F%0A

[3.7] http://bgmicro.com/pdf/ics8870.pdf

[3.8] http://acroname.com/robotics/parts/R93-SRF04.html

[3.9] http://acroname.com/robotics/parts/R145-SRF08.html

[3.10] http://senscomp.com/specs/600%20smart%20sensor.pdf

[4.1] http://www.uspto.gov (United States Patent and Trademark Office)

[4.2] http://www.google.com (Google)

- 38 -

http://www.google.com/


http://senscomp.com/specs/600%20smart%20sensor.pdf

http://acroname.com/robotics/parts/R145-SRF08.html

http://acroname.com/robotics/parts/R93-SRF04.html

http://bgmicro.com/pdf/ics8870.pdf

http://www.tdksemiconductor.com/push_file_for_download.cfm/75T204_ds.pdf?file_directory=54%5DZCGIE)H(V%26K%3A%3A-JE7!@5VC@@BR%0A&file_name=-(-%26KQ%3C%3C8BYF%20X8J%3EJ1)%3F%0A



http://www.national.com/ds.cgi/TP/TP5089.pdf

http://www.rohm.com/products/databook/com/pdf/bu8307cs.pdf

http://shay.ecn.purdue.edu/~dsml/ece362/Refs/9S12C_Refs/9S12C128DGV1.pdf

http://atmel.com/dyn/resources/prod_documents/doc2466.pdf

http://atmel.com/dyn/resources/prod_documents/doc2486.pdf


[4.3] http://www.defensereview.com/modules.php?name=News&file=print&sid=657 (Defense

Review – Armed/Weaponized Infantry Robots for Urban Warfare and Counterinsurgency Ops)

[4.4] (US Patent Office site for patent no. D425,140)

[4.5] (US Patent Office site for patent no. 5,598,164)






[5.1] Military Handbook for Reliability Prediction of Electronic Equipment

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2005/Mil-Hdbk-217F.pdf

[5.2] ECE477 Class Notes Module 10: Design for Reliability, Maintainability, and Safety

http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod10.pdf

[5.3] Atmel AtMega16L Reference Document

http://shay.ecn.purdue.edu/~477grp11/datasheets/Atmega16L.pdf

[5.4] LM7805CT Voltage Regulator Reference Document

http://shay.ecn.purdue.edu/~477grp11/datasheets/7805.pdf

[6.1] Splitt, Frank G., Engineering Education Reform: A Trilogy, January 2003

[6.2] Fail-safe design

http://www.allaboutcircuits.com/vol_4/chpt_6/5.html

[6.3] Recycling electronics and computers

http://www.dnr.state.oh.us/recycling/research/ecycle/hazards.htm

[6.4] Envirosense – Fact Sheet: Printed Circuit Board Manufacturers (Oct., 1995)

http://es.epa.gov/techinfo/facts/vdwm/va-fs6.html

[6.5] Recycling electronics and computers


[6.6] How to Recycle Nickel-Cadmium Rechargeable Batteries

http://www.ehow.com/how_9164_recycle-nickel-cadmium.html

[7.1] Associated Press, “Army Readies Robot Soldier for Iraq,” [Online Document], 2005, Jan

24, [cited 2005 Feb 17] Available http://www.msnbc.msn.com/id/6852832

- 39 -

http://www.msnbc.msn.com/id/6852832

http://www.ehow.com/how_9164_recycle-nickel-cadmium.html


http://es.epa.gov/techinfo/facts/vdwm/va-fs6.html


http://www.allaboutcircuits.com/vol_4/chpt_6/5.html



http://shay.ecn.purdue.edu/~dsml/ece477/Notes/PDF/4-Mod10.pdf

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2005/Mil-Hdbk-217F.pdf

http://www.defensereview.com/modules.php?name=News&file=print&sid=657


[7.2] Sky News, “Rolling Robot Ball to Bowl Over Burglars,” [Online Document], 2005, Feb 14,

[cited 2005 Feb 17] Available http://uk.news.yahoo.com/050213/140/fcdd8.html

[7.3] http://www.rotundus.se

[7.4] http://209.114.244.105/specs/600%20Smart%20Sensor.pdf

[7.5] http://www.senscomp.com/specs/Enclosure%20spec.pdf

[7.6] ftp://ftp.linksys.com/datasheet/wvc11b_ds.pdf

[8.1] http://shay.ecn.purdue.edu/~477grp11/datasheets/Atmega16L.pdf

[8.2] http://shay.ecn.purdue.edu/~477grp11/datasheets/7805.pdf

[8.3] http://shay.ecn.purdue.edu/~477grp11/datasheets/dtmf%20decoder%20ics8870.pdf

and http://shay.ecn.purdue.edu/~477grp11/datasheets/dtmf%20encoder%20ics5089.pdf

[8.4] http://shay.ecn.purdue.edu/~477grp11/datasheets/irf5210.pdf

[8.5] http://shay.ecn.purdue.edu/~477grp11/datasheets/irf540n.pdf

[8.6] http://shay.ecn.purdue.edu/~477grp11/datasheets/cd4069.pdf

[8.7] http://shay.ecn.purdue.edu/~477grp11/datasheets/irl530.pdf

[8.8] http://shay.ecn.purdue.edu/~477grp11/datasheets/ir%20sensors%20Sharp%20GP2Y

0D02YK.pdf

[8.9] http://shay.ecn.purdue.edu/~477grp11/datasheets/ultrasonic%20600%20Smart%20S

ensor.pdf

[8.10] http://shay.ecn.purdue.edu/~477grp11/datasheets/joystick.jpg

[9.1] Motorola App Note AN1259

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2005/AN1259.pdf

[10.1] Atmel Mega16 Datasheet:

http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf

[10.2] Codevision C Compiler: http://www.hpinfotech.ro/

- 40 -

http://www.hpinfotech.ro/

http://www.atmel.com/dyn/resources/prod_documents/doc2466.pdf

http://shay.ecn.purdue.edu/~dsml/ece477/Homework/Spr2005/AN1259.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/joystick.jpg

http://shay.ecn.purdue.edu/~477grp11/datasheets/ultrasonic%20600%20Smart%20S%20ensor.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/ultrasonic%20600%20Smart%20S%20ensor.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/ir%20sensors%20Sharp%20GP2Y%200D02YK.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/ir%20sensors%20Sharp%20GP2Y%200D02YK.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/irl530.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/cd4069.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/irf540n.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/irf5210.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/dtmf%20encoder%20ics5089.pdf

http://shay.ecn.purdue.edu/~477grp11/datasheets/dtmf%20decoder%20ics8870.pdf



ftp://ftp.linksys.com/datasheet/wvc11b_ds.pdf

http://rds.yahoo.com/S=2766679/K=ultrasonic+sensor+615088/v=2/SID=e/TID=F459_114/l=WS1/R=2/IPC=us/SHE=0/H=1/SIG=13ul405si/EXP=1108733714/**http%3A%2F%2Fwww.senscomp.com%2Fspecs%2FEnclosure%2520spec.pdf%23search%3D'ultrasonic%20sensor%20615088'

http://rds.yahoo.com/S=2766679/K=ultrasonic+sensor+615088/v=2/SID=e/TID=F459_114/l=WS1/R=1/IPC=us/SHE=0/H=1/SIG=143721rml/EXP=1108733714/**http%3A%2F%2F209.114.244.105%2Fspecs%2F600%2520Smart%2520Sensor.pdf%23search%3D'ultrasonic%20sensor%20615088'

http://www.rotundus.se/

http://uk.news.yahoo.com/050213/140/fcdd8.html


Appendix A: Individual Contributions

A.1 Contributions of Chad Bjorklund:

My individual contributions to the project have encompassed several different areas. At

the onset of the project, I was chosen as team leader. While in no way have I used this position

to assert an authority, I’ve always tried to lead by setting a good example. One of our first duties

as a team after selecting our project was to find parts that would fit our needs. I spent many

hours researching different parts that would fit our needs and always scavenging for the lowest

price. I sent out many emails to companies asking if we could get any parts donated or lent to us.

Along with searching vendors, I turned to eBay quite often to search for some of our other more

commercial parts such as the paintball gun, tank, and joystick. I was able to locate and purchase

all of those items at very reasonable prices, especially when compared to their retail equivalents.

Once the parts arrived, it was necessary for us to begin prototyping the different sections

of the project. I worked in tandem with Randy on the DTMF circuitry. I contributed in setting

up the initial breadboard circuit to test the DTMF decoding and encoding ICs. After studying the

datasheets and selecting the proper resistor and capacitor values, I was able to connect the two

chips together and generate and decode a tone exactly as we had planned.

Once everything was prototyped and a schematic was made, I got to work on the PCB

layout. Before I even began to layout the parts, I spent a lot of time with Paul on the schematic

making sure everything was setup properly and we made sure to choose all of the correct

footprints. Once I began the actual layout, I devoted many hours making sure everything was

not only connected correctly but laid out in a proper and efficient manner. Thankfully the boards

worked just as we had planned when we received them with the addition of only one minor

flywire.

Over spring break, I didn’t end up going anywhere so I brought the project home with me

to work on it. I spent a lot of time working on the turret and coming up with a method of

mounting the gun. I restrained from doing any fabrication to the turret because I didn’t have the

group’s approval but I began making other parts that we could use. One such part was a

A-1


connector for wires that we could use in the turret to allow it to spin 360 degrees without

tangling the wires inside. While we never implemented it, if we had more time or decided to

make this a commercial product, it could be a useful addition.

Once our PCBs arrived, software was my primary concern. Since Randy and I were the

computer engineers, we took it upon ourselves to do it. While I spent a lot of time after spring

break developing code, the majority of time was spent debugging it and fine tuning it.

Even though most of my time was devoted to software, I still always tried to help out in

other areas. With physical construction, I helped setup and mount the stepper for the turret. For

hardware, when we ran into a problem with encoding our DTMF tones, I help test different ways

of fixing it. For testing the tank, I was always the one with the pleasure of being shot.

A.2 Contributions of Paul Dulle

As one of the two electrical engineers of the group, I mostly worked on the hardware

circuit schematic. Along with that, I picked up various mechanical and physical construction

duties.

I chose the component rationalization homework as my professional component

homework. This assignment included doing research for many different parts that were essential

for the operation of the project. From which microcontroller to use, to DTMF selection, to

choosing which sensors are most suited for us, this homework made me really consider what we

needed and how to best achieve it. I took many factors into account including computational

requirements, interface requirements, power supply constraints, packaging, and cost constraints.

Before finalizing the circuit schematic, we decided that it would be best to prototype each

block of the circuit to catch any errors. By figuring out exactly what each component took to

work correctly, we almost eliminated the need to flywire on our PCB. I was a major contributor

in prototyping the motor control H-bridge, the joystick interface, the trigger actuator, power

supply, and the sensor integration. Each of these parts worked just as they were supposed to

when the circuit was on the PCB.

For my design component homework, I selected the schematic and hardware design.

This entailed bringing together all the knowledge and circuits that we had acquired during the

prototyping stage on to one coherent circuit. In this homework, I needed to check that what we

A-2


had tested would work with the rest of the project and add any features (such as pull-up / pull-

down resistors and power shutdown transistors) that would aid our project.

As the team’s expert in transistors, I was in charge of designing the interface to the

motors. I needed to design the H-bridge, stepper motor driver, inverters, and level translators.

I also populated the PCB of MAVerick (the tank). This required first learning how to

solder on practice boards, then putting my new found skills to work attaching all the components

to the PCB.

I assisted in the physical construction of MAVerick and Goose. Fixing the paintball gun

on to the turret required many modifications to the structure of the tank. We needed to cut holes

for screws and slice entire sections free of the turret. Painting the new joystick walls and hot

gluing them into place was also something that needed to be done. Along with this, there was a

multitude of cables that needed to be made. Whenever we needed a cable or debugging tool to

be made up, we would get it constructed.

Along with this, in the debugging stage, I assisted slightly in analyzing our software and

recommending changes to the computer engineers. Although I did not write the code, I would

try to follow along with the main ideas of each of the modules and make recommendations on

fixes where I could.

I think that I contributed greatly to the project, especially in the field of expertise,

hardware circuit design. However, in many cases, we worked together, each suggesting thoughts

that would improve on each other’s ideas. I feel that we really worked as a team to combine

each of our skills to successfully complete our objectives in the project.

A.3 Contributions of Patrick McLaughlin:

The first major individual contribution of mine to the project was the Packaging

Specifications and Design homework. This involved comparing the MAVerick to a couple of

commercial products, the SWORDS and the Rotundus. More importantly, a complete and

thorough design of the MAVerick’s packaging was done, including a CAD drawing, a materials

list with weight and part costs, and any tooling requirements that would be needed in completing

the physical construction of the MAVerick.

A-3


The next major individual contribution was circuit prototyping and testing. Paul needed

to complete the Circuit Design and Theory of Operation homework, and we wanted to make sure

all the circuits worked before they were officially designed. Most of the circuits and components

had datasheets and/or instructions on how to use them or what circuit to build around them for

their use. One exception to this was the joystick. I contributed a lot in prototyping this circuit and

seeing how all the pins for the buttons worked. Once it was determined which pins connected to

which buttons and how, pull-up resistors had to be assigned. Most important was assigning a

smart value for the pull-up resistor connected to the directional hat, so that when a voltage was

read by the microprocessor, the analog to digital converter had an easy job. With a good resistor

value, the differences in the voltages were greater. Also, I contributed in the building, testing,

and debugging of the power block, trigger block, and DC motor block of the circuit. Notable

mentions to these blocks include making sure enough voltage was provided to the actuator in

order to pull the trigger and adding bigger capacitors to the power block in order to deal with

multiple components running at the same time.

Next was board population. I populated almost all of the tank PCB. This included the use

of flux and a soldering iron, referencing the schematic for correct placement of all parts, and

testing to make sure solid connections were made in order to avoid burning out components.

Another major contribution was the Reliability and Safety Analysis homework. This

included a reliability analysis of four major components of the MAVerick’s circuitry using

military λP and the mean time to failure. Also, a failure mode, effects, and criticality analysis

(FMECA) worksheet was completed highlighting what happens when certain components fail

and how dangerous these effects are.

As the semester continued on, the technical need for the electrical engineers (Paul and I)

diminished while the technical need for the computer engineers (Chad and Randy) increased.

The circuits were all designed, built, and functional, while the microprocessor still needed to be

coded. Consequently, Paul and I turned to physical construction. As the team member that

completed the Packaging Design and Specifications homework, I had a major role in all

decisions made and implementation of those decisions. In fact, while the first half of the

semester was almost totally devoted to circuits, the second was definitely devoted to physical

construction. The highlights were making cuts to the turret many times, mounting the stepper,

mounting the actuator, mounting the paintball gun, and increasing the height of the joystick. In

A-4


addition to the major changes made to the tank and joystick, any minor task that presented itself

like the making of wires or fixing of burnt out parts was addressed by myself or Paul.

A.4 Contributions of Randall Scheifele:

Our group worked really well together throughout the entire semester to make a

successful project. Each member played a vital role in that success, and following is some of my

individual contributions that aided that success.

I was in charge of our patent liability analysis to satisfy one of our professional

component homework assignments. When producing a commercial project it is important to

investigate patents and other commercial projects that ours would resemble before going to

market. I split up my search into four subcategories: use of a toy tank, DTMF

encoding/transmitting/decoding, detecting obstacles using an array of passive infrared sensors,

and detecting moving targets using an ultrasonic sensor. In the analysis, our design would

literally infringe on one patent. This could be a major problem if our design went to market

without this knowledge.

I was also in charge of our software design considerations to satisfy one of our design

component homework assignments. In investigating the software design considerations I learned

that we should have thought about this a lot sooner in the semester. I would have liked to have

done some external interrupts but since our schematic and layout was done by the time I thought

about software design it was too late.

My most significant contribution to the project was software development for the

microcontroller. Chad and I handled all of the software for the entire project. We worked

together to create code for both MAVerick and the Command Center and created all of the

modules together and tested them to make sure they worked.

I was also involved in other aspects of the project but none as deeply as software. I

assisted in some physical construction by drilling holes, gluing sensors on MAVerick, and

soldering/connecting wires together. I also helped prototype our DTMF circuitry with Chad in

the early stages of our design. Since I was the only one with some HTML experience, I also

handled the website and kept that up to date as we turned in our homework assignments.

A-5


The success of this project wouldn’t have been complete without the hard work and

dedication from each team member. In our team atmosphere it is hard to identify individual

contributions because so much of our design was team oriented. Our team was constantly asking

for advice and getting help with one another we really functioned as one unit. I believe that our

team did an outstanding job and I am glad I was able to work with each of them this semester

A-6


Appendix B: Packaging

Figure B.1: Picture of the SWORDS

Figure B.2: Pictures of the Rotundus rolling ball

Figure B.3: Design package, tank and joystick view

A-1B-1


Appendix C: Schematic

C-1Figure C.1 Tank Schematic


Figure C.1 Tank Schematic

Figure C.2 Command Center Schematic


C-2


Appendix D: PCB Layout Top and Bottom Copper

Fig D.1 Command Center Top Copper

Fig D.2 Command Center Bottom Copper

D-1


Fig D.3 Tank Top Copper

Fig D.4 Tank Bottom Copper

D-2


Appendix E: Parts List Spreadsheet

Part Description Part Number Vendor QuantityUnit Cost Total

Atmel Mega 16 Microcontroller

ATMEGA16-16PC Digi-key 2 6.56 13.12

DTMF Encoder TP5089 BG Micro 2 1.25 2.5DTMF Decoder CM8870 BG Micro 2 4 8Ultrasonic Sensor 615088 Senscomp 1 55 55Crystal Oscillator CTX400-ND Digi-key 4 1.31 5.24Power NMOS MOSFET IRF540N Digi-key 4 1.74 6.96Power PMOS MOSFET IRF5210 Digi-key 4 1.91 7.64Power NMOS MOSFET IRF530 Digi-key 6 1.08 6.48Power PMOS MOSFET IRF9530 Digi-key 3 1.73 5.19Dsub 15 pin Female 152-3315 Mouser 1 0.99 0.99Linear Regulator 7805 Digi-key 1 1.16 1.16LDO Linear Regulator MIC5237 Mouser 1 1.37 1.37Remote Control Tank E-Bay 1 59 59Paintball Gun E-Bay 1 33.45 33.45Top Gun Joystick E-Bay 1 32.45 32.45Stepper Motor Jameco 1 30 30Linksys Wireless Webcam Amazon 1 106.91 106.91

Total 375.46

E-1


Appendix F: Software Listing

Tank:

/*********************************************This program was produced by theCodeWizardAVR V1.23.8d StandardAutomatic Program Generator© Copyright 1998-2003 HP InfoTech s.r.l.http://www.hpinfotech.roe-mail:[email protected]

Project : TankVersion : 1.0Date : 3/24/2005Author : ECE477 Group 11Company : Top GunsComments: That's right Ice Man.....I am dangerous

Chip type : ATmega16Program type : ApplicationClock frequency : 1.000000 MHzMemory model : SmallExternal SRAM size : 0Data Stack size : 256*********************************************/

#include <mega16.h> #include <delay.h>

// Declare your global variables here

#define ACKNOWLEDGE_TONE 1#define IMA_PHONE 1#define IMA_JOYSTICK 15#define UP 2#define DOWN 5#define LEFT 4#define RIGHT 6#define X_CENTER 13#define Y_CENTER 14#define TURRET_LEFT 11

#define TURRET_RIGHT 12#define TURRET_CENTER 3#define FIRE 10#define SEARCH_MODE 8 #define OVERRIDE 7

int Direction = 5; //global current direction of the tankint searchMode = 0; //boolean value of search mode or not search mode int overrideMode = 0;

F-1


char currAim = 's';int steps = 0;unsigned char stepPos = 0x33; unsigned char Distance[500] ={0}; /*

Function Signature: int get_tone( int tone )Return Value: int - numerical representation of a DTMF toneParameters: NoneAuthor(s): Chad and RandyDescription: This function checks port D pins 0-4 and

returns the number encoded or -1 if pin 0 is low

*/int get_tone(){

int tone = 0;if ( PIND.0 != 1 )

tone = -1; else {

if ( PIND.4 == 1 )tone += 1;

if ( PIND.3 == 1 )tone += 2;

if ( PIND.2 == 1 )tone += 4;

if ( PIND.1 == 1 )tone += 8;

}return tone;

}

/*Function Signature: void send_tone( int tone, int duration )Return Value: NoneParameters: int - numerical representation of a DTMF tone

int - time in milliseconds of the delayAuthor(s): Chad and RandyDescription: This function sets port B according to the input tone for the duration specified by the second argument

0 - tone enable 1,2 - col output 3,4 - row output*/ void send_tone( int tone, int duration ){

switch ( tone ){

case 1: PORTB.1 = 0;PORTB.2 = 0;PORTB.3 = 0;PORTB.4 = 0;break;

F-2













case 13: PORTB.1 = 1;PORTB.2 = 1;

F-3


PORTB.3 = 0;PORTB.4 = 0;break;




}PORTB.0 = 0;//delay_ms(duration);//PORTB.0 = 1;

}

/*Function Signature: void Motor( void )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription: This function checks the value of the global variable Direction and sets the value of Port C in order to drive the tank in that direction

*/void Motor(void){

if ( PINA.0 == 1 && Direction == 6 && overrideMode == 0 ) Direction = 5; //front

else if ( PINA.1 == 1 && (Direction == 3 || Direction == 2 || Direction == 7) && overrideMode == 0 ) Direction = 5; //left

else if ( PINA.2 == 1 && (Direction == 4 || Direction == 1 || Direction == 7) && overrideMode == 0 ) Direction = 5; //back

else if ( PINA.3 == 1 && (Direction == 9 || Direction == 8 || Direction == 1) && overrideMode == 0 ) Direction = 5; //right

switch(Direction){ /*

case 1: PORTC.0 = 0;PORTC.1 = 0;PORTC.2 = 0;PORTC.3 = 1;break; */

case 2: PORTC.0 = 0;PORTC.1 = 1;PORTC.2 = 1;PORTC.3 = 0;

F-4


break; /*case 3: PORTC.0 = 0;

PORTC.1 = 0;PORTC.2 = 1;PORTC.3 = 0;break; */

case 4: PORTC.0 = 0;PORTC.1 = 1;PORTC.2 = 0;PORTC.3 = 1;break;

case 5: PORTC.0 = 0;PORTC.1 = 0;PORTC.2 = 0;PORTC.3 = 0;break;

case 6: PORTC.0 = 1;PORTC.1 = 0;PORTC.2 = 1;PORTC.3 = 0;break; /*


case 8: PORTC.0 = 1;PORTC.1 = 0;PORTC.2 = 0;PORTC.3 = 1;break; /*


default: PORTC.0 = 0; PORTC.1 = 0; PORTC.2 = 0; PORTC.3 = 0;

}}

/*Function Signature: void stepper( char )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription:

*/void stepper( void ){

if ( steps >= 250 && currAim == 'r' )currAim = 's';

if ( steps <= -250 && currAim == 'l' )currAim = 's';

F-5


if ( currAim == 'r' ){

steps++; if ( PINC.7 == 1 && PINC.6 == 1 && PINC. 5 == 0 && PINC.4 == 0 ){

PORTC.6 = 0; PORTC.4 = 1;

}else if ( PINC.7 == 1 && PINC.6 == 0 && PINC.5 == 0 && PINC.4 == 1

){ PORTC.7 = 0; PORTC.5 = 1;} else if ( PINC.7 == 0 && PINC.6 == 0 && PINC. 5 == 1 && PINC.4 ==

1 ){

PORTC.4 = 0;PORTC.6 = 1;

}else if ( PINC.7 == 0 && PINC.6 == 1 && PINC. 5 == 1 && PINC.4 ==

0 ){


}else{

PORTC.4 = 0;PORTC.5 = 0;PORTC.6 = 1;PORTC.7 = 1;

} }else if ( currAim == 'l' ){

steps--;if ( PINC.7 == 1 && PINC.6 == 1 ){


}else if ( PINC.6 == 1 && PINC.5 == 1 ){ PORTC.4 = 1; PORTC.6 = 0;} else if ( PINC.5 == 1 && PINC.4 == 1 ){ PORTC.7 = 1; PORTC.5 = 0;} else if ( PINC.4 == 1 && PINC.7 == 1 ){


}

F-6


else{

PORTC.4 = 0;PORTC.5 = 0;PORTC.6 = 1;PORTC.7 = 1;

}} else if ( currAim == 's' ) PORTC = PORTC & 0x0F;

delay_ms(15); return;}

/*Function Signature: void action( int tone )Return Value: NoneParameters: int - numerical representation of a DTMF toneAuthor(s): Chad and RandyDescription: This function takes the input tone which is a numerical representation of a DTMF tone and performs an action based on that DTMF tone.

*/void action( int tone ){

switch ( tone ){

case UP: Direction++;if( Direction == 4 || Direction == 7 || Direction ==

10 ) Direction--; break;case DOWN: Direction--;

if( Direction == 0 || Direction == 3 || Direction == 6 ) Direction++;

break; case LEFT: Direction-=3;

if( Direction < 1 ) Direction+=3;break;

case RIGHT: Direction+=3; if( Direction > 9 ) Direction-=3; break;case Y_CENTER:

if( Direction % 3 == 0 ) Direction--; else if( Direction % 3 == 1 ) Direction++; break;case X_CENTER:

if( Direction > 6 ) Direction-=3; else if( Direction < 4 ) Direction+=3; break;case TURRET_LEFT: if ( currAim == 'r' ) currAim = 's';

else if ( currAim == 's' ) currAim = 'l';

F-7


break;case TURRET_RIGHT: if ( currAim == 'l' ) currAim = 's';

else if ( currAim == 's') currAim = 'r';break;

case TURRET_CENTER: currAim = 's';break;

case FIRE: PORTD.7 = 1;delay_ms(100);PORTD.7 = 0;break;

case SEARCH_MODE: searchMode = 1;break;

case OVERRIDE: overrideMode = overrideMode ^ 1;break;

default: break;} Motor();stepper(); return;

}

/*Function Signature: void joyAction( int tone )Return Value: NoneParameters: int - numerical representation of a DTMF toneAuthor(s): Chad and RandyDescription: This function takes the input tone which is a numerical representation of a DTMF tone and performs an action based on that DTMF tone.

*/void joyAction( int tone ) {

switch ( tone ){

case UP: Direction = 6; break;case DOWN: Direction = 4; break; case LEFT: Direction = 8;

break;case RIGHT: Direction = 2; break;case Y_CENTER:

if( Direction == 6 || Direction == 4 ) Direction = 5; break;case X_CENTER:

if( Direction == 2 || Direction == 8 ) Direction = 5; break;case TURRET_LEFT: if ( currAim == 'r' ) currAim = 's';

else if ( currAim == 's' ) currAim = 'l';break;

case TURRET_RIGHT: if ( currAim == 'l' ) currAim = 's';else if ( currAim == 's') currAim = 'r';break;

F-8


case TURRET_CENTER: currAim = 's';break;

case FIRE: PORTD.7 = 1;delay_ms(100);PORTD.7 = 0;break;

case SEARCH_MODE: searchMode = 1;break;

case OVERRIDE: overrideMode = overrideMode ^ 1;break;

} Motor();stepper(); return;

}

/*Function Signature: int Ultrasonic( int )Return Value: intParameters: intAuthor(s): ChadDescription: This takes the readings from the ultrasonicand stores the distance.

*/int Ultrasonic(int Readings){

unsigned int Counter, Counter2, Counter3, i;unsigned int Total = 0 ;Counter2 = 0; Counter3 = 0;for(i=0;i<Readings;i++){

Counter = 0;

PORTD.5 = 1;while( PIND.6 == 1 && Counter < 60){

delay_ms(1);Counter++;

}PORTD.5 = 0;if( Counter != 60 ){

Total+=Counter;Counter2++;

}else{

Counter3++; //Bad readings}

if( Total > Readings * 2 * 100 ){

i = 100;}if( Counter3 >= 5 )

F-9


{i=100;

}//delay_ms(10);

} //PORTB = (Total / Counter2) | 0x80;//PORTB = 0x01; if( Counter2 == 0 ){

return 0;}if( Counter3 > Counter2 ){

return 0;}return (Total / Counter2);

}

/*Function Signature: void Autonomous( void )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription: This function controls the autonomousmode.

*/

void Autonomous(void){

int tempDistance = 0;int Counter = 0; if( steps > 0 ){

currAim = 'l';}else{

currAim = 'r';}

while( steps != 0 ) {

stepper(); delay_ms(5);}

currAim = 'r';while( steps < 250 ){

Counter++;if( get_tone() == SEARCH_MODE ){

searchMode = 0;delay_ms(100);return;

}

F-10


if( Distance[steps+250] != 0 ){

if( Counter >= 10 ){

tempDistance = Ultrasonic(20);if( tempDistance != 0 ){

Distance[steps+250] = ( Distance[steps+250] + tempDistance ) / 2;

}else{

Distance[steps+250] = ( Distance[steps+250] + 60 ) / 2;

}Counter = 0;

}else{

delay_ms(5);}

}else{



Distance[steps+250] = Ultrasonic(20);}else{

Distance[steps+250] = 60;}Counter = 0;

}else{

delay_ms(5);}

}stepper();//delay_ms(10);

}currAim = 'l';Counter = 0;while( steps > -250 ){

if( get_tone() == SEARCH_MODE ){

searchMode = 0; delay_ms(100);return;

}Counter++;

F-11


if( Distance[steps+250] != 0 ){




}else{


}Counter = 0;

}else{

delay_ms(5);}

}else{





}else{

delay_ms(5);}


}currAim = 'r';Counter = 0;while( steps != 0 ){

if( get_tone() == SEARCH_MODE ){

searchMode = 0;delay_ms(100);return;

} Counter++;

if( Distance[steps+250] != 0 )

F-12


{if( Counter >= 10 ){



}else{


}Counter = 0;

}else{

delay_ms(5);}

}else{





}else{

delay_ms(5);}


}Counter = 0;do{

Counter++;if( steps >= 250 ){

currAim = 'l';}else if( steps <= -250 ){

currAim = 'r';}if( Counter >= 10 )

F-13


{ tempDistance = Ultrasonic(5);if( tempDistance != 0 ){

tempDistance = Distance[steps+250] - tempDistance;/*if( tempDistance < 0 ){

tempDistance*= -1;}*/if( tempDistance > 10 ){

tempDistance = Distance[steps+250] - Ultrasonic(5);

if( tempDistance > 10 ){

PORTD.7 = 1;delay_ms(100);PORTD.7 = 0;

}}

}Counter = 0;

} else{

delay_ms(5);} stepper();

}while( get_tone() != SEARCH_MODE );searchMode = 0;return;

}

/*Function Signature: void joystick( void )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription: This function is an infinite while loop which checks the value of the sensor inputs and sends a tone to the Command Center based on the sensor inputs. It also receives tones from the Command Center and performs the appropriate action based on the DTMF tone received.

*/void joystick(void){

int tone, counter;unsigned char leds, comparison;

leds = 0x00;comparison = 0x00;

F-14


counter = 6; //send_tone(ACKNOWLEDGE_TONE, 80); while (1)

{ //This compares the current sensor inputs (PORTA) //with what they were on the previous loop iteration. //If any of the port pins are different than before, //that bit is set high in 'comparison'. 'comparison' //is then checked bit-by-bit and the appropriate tone //is sent.

//comparison = leds ^ PINA; counter++; comparison = PINA; comparison = comparison >> (counter-7) ; //for(i=7;i<11;i++) //{ if( comparison & 0x01 ) { send_tone(counter, 80); } if ( counter == 10 ) {

counter = 6; }

// comparison = comparison >> 1; //} if ( steps < -40 && steps > -63 && currAim != 's' ) //turret

left if ( currAim == 'r' )

send_tone(13, 80); else send_tone(11, 80);

else if ( steps > 40 && steps < 63 && currAim != 's' ) //turret right

if ( currAim == 'l' ) send_tone(13,80); else send_tone(12,80);

do //Loop until a tone is received{

tone = get_tone(); Motor(); stepper();

} while( tone == -1 ); joyAction( tone );

if( searchMode ){

Autonomous(); searchMode = 0;

} delay_ms(10); PORTB.0 = 1;

}

F-15


}

/*Function Signature: void phone( void )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription: This function gets a tone input and executes search mode if that is the current mode or performs actions based on incoming DTMF tones from a phone.

*/void phone(void){

int tone;

searchMode = 0; PORTB.0 = 1;while(1)

{ do{

tone = get_tone(); //tone = -1; // DELETE ME!!!!!!!!!!!!!!!!!

}while ( tone != -1 );

if( searchMode )

{Autonomous();

}else{ do //Loop until a tone is received

{

tone = get_tone(); Motor(); stepper();

} while( tone == -1 ); //send_tone( ACKNOWLEDGE_TONE, 80 ); action( tone );

} }}

/*Function Signature: void init( void )Return Value: NoneParameters: NoneAuthor(s): CodeVision

F-16


Description: This function sets all of our ports data direciton registers and initial values. It also sets some timer/counter functionality which we do not use.

*/void init( void ){

// Input/Output Ports initialization// Port A initialization// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=In Func6=In

Func7=In // State0=T State1=T State2=T State3=T State4=T State5=T State6=T

State7=T PORTA=0x00;DDRA=0x00;

// Port B initialization// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out

Func7=Out // State0=0 State1=0 State2=0 State3=0 State4=0 State5=0 State6=0

State7=0 PORTB=0x01;DDRB=0xFF;

// Port C initialization// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out


State7=0 PORTC=0x00;DDRC=0xFF;

// Port D initialization// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=Out Func6=In

Func7=Out // State0=T State1=T State2=T State3=T State4=T State5=0 State6=T

State7=0 PORTD=0x00;DDRD=0xA0;

// Timer/Counter 0 initialization// Clock source: System Clock// Clock value: Timer 0 Stopped// Mode: Normal top=FFh// OC0 output: DisconnectedTCCR0=0x00;TCNT0=0x00;OCR0=0x00;

// Timer/Counter 1 initialization// Clock source: System Clock// Clock value: Timer 1 Stopped// Mode: Normal top=FFFFh// OC1A output: Discon.// OC1B output: Discon.// Noise Canceler: Off// Input Capture on Falling Edge

F-17


TCCR1A=0x00;TCCR1B=0x00;TCNT1H=0x00;TCNT1L=0x00;OCR1AH=0x00;OCR1AL=0x00;OCR1BH=0x00;OCR1BL=0x00;

// Timer/Counter 2 initialization// Clock source: System Clock// Clock value: Timer 2 Stopped// Mode: Normal top=FFh// OC2 output: DisconnectedASSR=0x00;TCCR2=0x00;TCNT2=0x00;OCR2=0x00;

// External Interrupt(s) initialization// INT0: Off// INT1: Off// INT2: OffMCUCR=0x00;MCUCSR=0x00;

// Timer(s)/Counter(s) Interrupt(s) initializationTIMSK=0x00;

// Analog Comparator initialization// Analog Comparator: Off// Analog Comparator Input Capture by Timer/Counter 1: Off// Analog Comparator Output: OffACSR=0x80;SFIOR=0x00;

SFIOR |= 0x04; //disables internal pull-up resistors

searchMode = 0;Direction = 5;currAim = 's';steps = 0;stepPos = 0x33;

return;}

/*Function Signature: void main( void )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription: This function calls the function init

and then recevies a tone which tells the tank if it is going to be controlled

F-18


by a phone or the Command Center.*/void main(void){

// Declare your local variables hereint tone;

init();

PORTC = 0x00;currAim = 's';

do{

tone = get_tone(); } while( tone != IMA_JOYSTICK && tone != IMA_PHONE );

send_tone( ACKNOWLEDGE_TONE, 800 );delay_ms(800);

if( tone == IMA_JOYSTICK ){

joystick(); } else /*IM_A_PHONE*/ { phone(); }}

Command Center:

/*********************************************This program was produced by theCodeWizardAVR V1.23.8d StandardAutomatic Program Generator© Copyright 1998-2003 HP InfoTech s.r.l.http://www.hpinfotech.roe-mail:[email protected]

Project : Command CenterVersion : 1Date : 3/22/2005Author : ECE477 Group 11 Company : Top GunsComments: No, boys. There's two O's in Goose

Chip type : ATmega16Program type : ApplicationClock frequency : 1.000000 MHzMemory model : SmallExternal SRAM size : 0Data Stack size : 256

F-19


*********************************************/

#include <mega16.h> #include <delay.h>

#define ADC_VREF_TYPE 0x20// Read the 8 most significant bits// of the AD conversion result

// Declare your global variables here

#define ACKNOWLEDGE_TONE 1#define IMA_JOYSTICK 15#define UP 2#define DOWN 5#define LEFT 4#define RIGHT 6#define X_CENTER 13#define Y_CENTER 14#define TURRET_LEFT 11#define TURRET_RIGHT 12 #define TURRET_CENTER 3#define FIRE 10#define SEARCH_MODE 8#define OVERRIDE 7

void set_led( int tone );

/*Function Signature: unsigned char read_adc

(unsigned char adc_input)Return Value: unsigned char - the value of the analog-

to-digital conversionParameters: unsigned char - the value of the port pin to do the conversionAuthor(s): CodeVisionDescription: This function reads the port pin specified by the first argument and returns the result of the analog-to-digital conversion.

*/unsigned char read_adc(unsigned char adc_input){

ADMUX=adc_input|ADC_VREF_TYPE;// Start the AD conversionADCSRA|=0x40;// Wait for the AD conversion to completewhile ((ADCSRA & 0x10)==0);ADCSRA|=0x10;return ADCH;

}

/*Function Signature: int get_tone( int tone )

F-20


Return Value: int - numerical representation of a DTMF toneParameters: NoneAuthor(s): Chad and RandyDescription: This function checks port D pins 0-4 and

returns the number encoded or -1 if pin 0 is low

*/int get_tone(){

int tone = 0;if ( PIND.0 != 1 )

tone = -1; else {

if ( PIND.4 == 1 )tone += 1;

if ( PIND.3 == 1 )tone += 2;

if ( PIND.2 == 1 )tone += 4;

if ( PIND.1 == 1 )tone += 8;

}return tone;

}

/*Function Signature: void send_tone( int tone, int duration )Return Value: NoneParameters: int - numerical representation of a DTMF tone

int - time in milliseconds of the delayAuthor(s): Chad and RandyDescription: This function sets port B according to the input tone for the duration specified by the second argument

0 - tone enable 1,2 - col output 3,4 - row output*/ void send_tone( int tone , int duration ){

//int new_tone = -1; switch ( tone ){



case 3: PORTB.1 = 0;PORTB.2 = 1;

F-21


PORTB.3 = 0;PORTB.4 = 0;break;











case 14: PORTB.1 = 1;PORTB.2 = 1;PORTB.3 = 1;PORTB.4 = 0;

F-22


break;case 15: PORTB.1 = 1;

PORTB.2 = 1;PORTB.3 = 0;PORTB.4 = 1;break;


}PORTB.0 = 0;delay_ms(duration); PORTB.0 = 1;return;

}

/*Function Signature: void set_led( int tone )Return Value: NoneParameters: int - numerical representation of a DTMF toneAuthor(s): Chad and RandyDescription: This function sets LED's based on the following tones: On/Off Firing - 4

Search Mode - 5 Obstacle Override - 6

Obstacle Forward - 7 Obstacle Left - 8 Obstacle Behind - 9 Obstacle Right - 10 Motion Sensor Left - 11 Motion Sensor Forward - 12 Motion Sensor Right - 13 Connected - 14

*/void set_led( int tone ){ switch ( tone )

{case 4: PORTD.6 = /*PORTD.6 ^*/ 0;

break;case 5: PORTD.5 = /*PORTD.5 ^*/ 0;

break;case 6: PORTC.7 = /*PORTC.7 ^*/ 0;





break;

F-23


case 11: PORTC.2 = /*PORTC.2 ^*/ 0; //LEFT (11) PORTC.1 = 1; PORTC.0 = 1;break;

case 13: PORTC.1 = /*PORTC.1 ^*/ 0; //CENTER (13) PORTC.0 = 1; PORTC.2 = 1;break;

case 12: PORTC.0 = /*PORTC.0 ^ 1*/ 0; //RIGHT (12) PORTC.1 = 1; PORTC.2 = 1;break;

case 14: PORTD.7 = /*PORTD.7 ^ 1*/ 0;break;

default: break;}return;

}

/*Function Signature: void init( void )Return Value: NoneParameters: NoneAuthor(s): CodeVisionDescription: This function sets all of our ports data direciton registers and initial values. It also sets some timer/counter functionality which we do not use.

*/void init( void ){

// Input/Output Ports initialization// Port A initialization// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=In Func6=In

Func7=In // State0=T State1=T State2=T State3=T State4=T State5=T State6=T

State7=T PORTA=0x00;DDRA=0x00;

// Port B initialization// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=In Func6=In

Func7=In // State0=0 State1=0 State2=0 State3=0 State4=0 State5=T State6=T

State7=T PORTB=0x00;DDRB=0x1F;

// Port C initialization// Func0=Out Func1=Out Func2=Out Func3=Out Func4=Out Func5=Out Func6=Out


State7=0 PORTC=0xFF;DDRC=0xFF;

F-24


// Port D initialization// Func0=In Func1=In Func2=In Func3=In Func4=In Func5=Out Func6=Out

Func7=Out // State0=T State1=T State2=T State3=T State4=T State5=0 State6=0

State7=0 PORTD=0xE0;DDRD=0xE0;

// Timer/Counter 0 initialization// Clock source: System Clock// Clock value: Timer 0 Stopped// Mode: Normal top=FFh// OC0 output: DisconnectedTCCR0=0x00;TCNT0=0x00;OCR0=0x00;

// Timer/Counter 1 initialization// Clock source: System Clock// Clock value: Timer 1 Stopped// Mode: Normal top=FFFFh// OC1A output: Discon.// OC1B output: Discon.// Noise Canceler: Off// Input Capture on Falling EdgeTCCR1A=0x00;TCCR1B=0x00;TCNT1H=0x00;TCNT1L=0x00;OCR1AH=0x00;OCR1AL=0x00;OCR1BH=0x00;OCR1BL=0x00;

// Timer/Counter 2 initialization// Clock source: System Clock// Clock value: Timer 2 Stopped// Mode: Normal top=FFh// OC2 output: DisconnectedASSR=0x00;TCCR2=0x00;TCNT2=0x00;OCR2=0x00;

// External Interrupt(s) initialization// INT0: Off// INT1: Off// INT2: OffMCUCR=0x00;MCUCSR=0x00;

// Timer(s)/Counter(s) Interrupt(s) initializationTIMSK=0x00;

// Analog Comparator initialization// Analog Comparator: Off

F-25


// Analog Comparator Input Capture by Timer/Counter 1: Off// Analog Comparator Output: OffACSR=0x80;SFIOR=0x00;

// ADC initialization// ADC Clock frequency: 125.000 kHz// ADC Voltage Reference: AREF pin// ADC High Speed Mode: Off// ADC Auto Trigger Source: None// Only the 8 most significant bits of// the AD conversion result are usedADMUX=ADC_VREF_TYPE;ADCSRA=0x83;SFIOR&=0xEF;

SFIOR |= 0x04; //disables internal pull-up resistors

PORTC.1 = 0;

return;}

/*Function Signature: void main( void )Return Value: NoneParameters: NoneAuthor(s): Chad and RandyDescription: This function calls the function init

and then recevies a tone which tells the Command Center that it is connected. It then sets the conncted LED high and enters an infinite while loop which decodes the joystick input and sends an encoded DTMF tone to reflect that position and checks the incoming DTMF tones for status signals from the tank to display them on the LED's.

*/void main(void){

// Declare your local variables hereint tone;int x_axis,y_axis,hat;

int i;

init();

/*test code*/ /*while ( 1 ){

send_tone( 1, 100 );delay_ms(100);

send_tone( 2, 100 );delay_ms(100);

F-26


send_tone( 3, 100 );delay_ms(100);send_tone( 4, 100 );delay_ms(100);send_tone( 5, 100 );delay_ms(100);

}*/

do{

send_tone( IMA_JOYSTICK, 50 );tone = get_tone();

} while( tone != ACKNOWLEDGE_TONE );

//send_tone(ACKNOWLEDGE_TONE, 780); i = 0;

set_led( 14 ); //Connected //delay_ms(1500);

while (1){

//if ( ++i == 5 )//{ // i = 0;

//PORTC = 0xF8;//PORTC.7 = 1;PORTC.6 = 1;PORTC.5 = 1;PORTC.4 = 1;PORTC.3 = 1;//} //Get Status Signal from Tank//packet = get_status();

tone = get_tone(); //Light up proper LED set_led( tone ); //Generate DTMF output for Joystick/Buttons x_axis = read_adc(0); if( x_axis > 180 ) //715 { // PORTC.5 = 0; send_tone(LEFT, 50); } else if( x_axis < 125 ) //473 { // PORTC.3 = 0; send_tone(RIGHT, 50); } else { send_tone(X_CENTER, 50); //PORTC.7 = 0; }

F-27


y_axis = read_adc(1); if( y_axis > 141 ) //563 { // PORTC.6 = 0; send_tone(UP, 50); } else if( y_axis < 97 ) //389 { // PORTC.4 = 0; send_tone(DOWN, 50); } else { // PORTC.7 = 0; send_tone(Y_CENTER, 50); } hat = read_adc(2); if( hat > 65 && hat < 90 ) //500, 583 125 146 { // PORTC.2 = 0; send_tone(TURRET_LEFT, 50); } else if( hat > 125 && hat < 146 ) //716, 860 179 215 { // PORTC.0 = 0; send_tone(TURRET_RIGHT, 50); } else { // PORTC.1 = 0; send_tone(TURRET_CENTER, 50); } if( PINA.4 == 0 ) { // PORTD.6 = 0; send_tone(FIRE, 50); } if( PINA.3 == 0 ) { send_tone(SEARCH_MODE, 50); PORTD.5 = PIND.5 ^ 1; } if( PINA.6 == 0 ) { send_tone(OVERRIDE, 100); PORTC.7 = PINC.7 ^ 1; } //delay_ms(1000); // PORTD.6 = 1; // PORTC = 0xFF;

}}

F-28


Appendix G: User Manual

1.0 Product Description

Congratulations on your purchase of MAVerick, your personal mobile assault vehicle!

MAVerick is a mobile tank with a paintball gun that can be controlled from anywhere that has

cell phone service, practically anywhere in the world!

MAVerick’s mobility is unmatched, featuring high torque motors for climbing over

cumbersome obstacles. In addition to more power, MAVerick’s treads offer the lucky user more

turning options than simple wheeled vehicles. It is capable of the super-spin turn, spinning in

place.

MAVerick also features a 300 degree rotating turret providing a wide target area.

In manual mode, the user can sit at his computer and view first person video. The user

can see what MAVerick sees, all while controlling it from anywhere in the world with his cell

phone! But that’s not all. MAVerick wouldn’t be complete without its wingman, Goose.

Goose is a joystick option that allows for arcade-like feel when controlling MAVerick, as

opposed to pressing cell phone buttons. Goose’s easy and comfortable access to its buttons

allows for a more enjoyable and realistic targeting experience.

MAVerick is like having two different vehicles in one, featuring two modes of operation.

It isn’t just a manual vehicle that the user controls! It also has a mind of its own with its

autonomous mode.

Autonomous mode puts MAVerick in a search for targets. It will sit and make sweeps

with the turret until it detects motion, then it will fire at the moving target. It will continue firing

until the target is out of range, which is not good news for your enemies!

Whether you want to easily infiltrate your enemies’ territory in a friendly game of

paintball, defend your own territory in autonomous mode, enjoy a game of tank wars, or even see

who’s the best shot in a game of target practice, the Top Guns are certain MAVerick is the

vehicle for you.

G-1


2.0 Product Illustration

G-2

Paintball Hopper

CO2 Tank

Ultrasonic Sensor

IR Obstacle Detectors

Hands-free Connector

On/Off Switch

Turret Hat

Obstacle Override Button

Trigger

Power Switch

Connected LED

Autonomous Mode LED

Autonomous Mode Toggle

Firing LED

Turret Direction

Obstacle Warnings Power LED

Obstacle Override


3.0 Product Setup Instructions

1. Open the box and verify the following contents: (1) rechargeable battery pack with

charger, (4) AA batteries (for Goose Command Center), (1) paintball hopper, (1) pack

of paintballs, (1) barrel plug, (1) barrel squeegee, (1) CO2 tank, (1) Goose Command

Center, and (1) MAVerick.

2. The following contents must be supplied by the user: (2) cellular phones.

Goose Command Center Setup: (optional)

3. Open the bottom of the Goose Command Center and insert the 4 AA batteries as

shown in Figure 3.1.

Figure 3.1 Goose Command Center Batteries

4. Turn on the Command Center by flipping the switch and verify that the power LED

turns on. If the LED does not turn on, see the troubleshooting section.

Tank Setup:

5. Insert the rechargeable battery pack in the bottom of the tank as shown in Figure 3.2.

Figure 3.2 MAVerick Battery Pack

6. Insert the paintball hopper on the top of the tank as shown in Figure 3.3.

G-3


Figure 3.3 Inserting paintball hopper

7. Insert the CO2 tank through the fastened loop as shown in Figure 3.4.

Figure 3.4 Inserting the CO2 tank

8. Insert the paintballs into the paintball hopper as shown in Figure 3.5.

Figure 3.5 Insert paintballs into the hopper

Connection Setup:

G-4


9. Attach one cell phone’s hands-free input to the Goose Command Center (optional).

10. Attach the other cell phone’s hands-free input to MAVerick.

5.0 Troubleshooting

Tank doesn’t turn on: Check battery, Check the on/off switch.

Command Center doesn’t turn on: Check the polarity of the batteries. Check the on/off

switch. Make sure you are using non-rechargeable batteries. Make sure the batteries have a full

charge.

Tank will not connect: Make sure the tank is on. Make sure a strong cellular signal is present.

Turn device off then on, dial the phone on the tank. If you are using the Goose command center,

make sure it is properly plugged in to the hands-free socket on the dialing cell phone and that the

command center is on. Within a few seconds, the connected LED should light up. If you are

using the cell phone keypad, keep pressing the identify button (button 1) on the keypad until you

receive a confirmation tone on your cell phone. You can verify that the tank is connected by

pressing any of the keys that control the tank such as * or # to turn the turret.

Tank STILL will not connect : Unplug the cell phone on the tank and connect to it with the

dialing cell phone. If you are using the Goose Command Center, make sure that the dialing cell

phone is connected properly and that the Command Center is on. On the speaker of the tank cell

phone, you should here a tone being broadcasted. If you cannot hear anything from the tank cell

G-5


phone, verify that the command center is on and properly connected. If you are just using the

dialing cell phones keypad to control the tank, press buttons on the keypad and verify that a tone

is being generated from the tanks cell phone speaker. If not, verify the connection of the hands-

free connection on the dialing cell phone.

NOTE: Not all cell phones output a tone when a key is pressed. Most likely, the phone will have

a touch-tone or DTMF option that may need to be turned on.

Command Center does not control properly: Make sure the batteries have a strong charge. It

may be possible for the Command Center to still turn on but not have enough power to operate

correctly.

Turret will not turn: Make sure the tank battery has a full charge. Verify that there are no

obstructions in the path of the turret. Verify that the cell phones are properly connected.

Turret rotates an uneven amount in opposite directions: When the tank is first turned on, the

turret must be centered. Turn the tank off, center the turret and reconnect.

Tank will not move: Make sure the tank battery has a full charge. Verify that there are no

obstructions in the path of the tank as the IR sensors can inhibit movement to avoid running into

an obstacle. If the turret is able to move and not the tank, try using the override button to ignore

the IR sensors, it is the lower thumb button on the Command Center or button 3 on the cell

phone keypad. Verify that the cell phones are properly connected.

Tank will not fire: Make sure the tank battery has a full charge. Verify that the hopper has

paintballs in it. It is possible that the gun has become uncocked, pull back on the brown wire on

the back of the turret until you hear a click. A possible reason for the gun becoming uncocked is

because the CO2 tank is running low. Another sign of running out of CO2 is when a rapid

succession of shots occurs after shooting once. If either of these happens, you should refill or

replace the CO2 tank.

G-6


Appendix H: FMECA Worksheet

H-1

Failure No.

Failure Mode Possible Causes

Failure Effects Method of Detection

Criticality Remarks

A1 Voltage output = 0V

Shorted capacitors C7 or C8, or U4 is damaged

No voltage gets to rest of circuit

Cannot detect

voltage drop

anywhere

LowMAVerick becomes useless

A2 Voltage output > 5.0V

U4 does not work

Too much voltage

supplied to rest of circuit

Observation High

Possible damage to

microcontroller and other ICs, possible safety

issues

B1 Failure of U9 or U10

Oscillator damaged

No output from DTMF encoder

or decoderObservation Low

MAVerick loses

communication ability, if using cell phone then MAVerick will

get stuck in current mode

B2 Vdd = 0VC9 or C10

shorted

No output from DTMF encoder

or decoderObservation Low

MAVerick loses

communication ability, if using cell phone then MAVerick will

get stuck in current mode


H-2

C1 Microprocessor has no output

C14 shorted

Microprocessor constantly

resetsObservation Low

MAVerick becomes useless

C2 Voltage drop in microprocessor

Bypass capacitor

C15 shorted

Too little voltage output

from microprocessor

Observation Low

Unpredictable effects, some components

may not work, possible collision

D1Current

through status LEDs = 0A

R2 through R9, R15, R16, or R32 are shorted

Status LED will not work Observation Low

Won’t know the status of

your sensors or what mode you’re in

E1No input from

joystick buttons

R1, R2, R3, or R4

are shorted

Joystick buttons will not

workObservation Low

Command center will not

be able to control the MAVerick

E2 No input from directional hat

R5 shorted

Directional hat will not work Observation Low

Command Center will not

be able to move the turret

F1 Sensors constantly on

Q1, Q2, or Q3

damaged

Sensors will waste power by not turning off when not in use

Observation LowUnnecessary drain on the

battery


H-3

F2 Ultrasonic output = 0V

Q4 is damaged

Ultrasonic will not work Observation Low

Can’t determine

when a target is there to fire

at

G1

Inverter chip output stuck in current logic

state

Inverter chip is

damaged

Microcontroller can’t turn

PMOS transistors off

Observation High

Motors could potentially become too

hot, damaged, and a safety

hazard

G2N-channel transistor shorted

Q9, Q10, Q11, or Q12 is

damaged

Either motor does not turn off or Vcc is

shorted straight to ground

Observation High

Motors could get too hot, and

transistors could get too

hot

G3P-channel transistor shorted

Q13, Q14,

Q15, or Q16 is

damaged

Either motor does not turn off or Vcc is

shorted straight to ground

Observation High

Motors could get too hot, and

transistors could get too

hot

H1 Diode is open

D12, D13,

D14, or D15 is shorted

Arc-suppression protection is

gone and could damage circuit

Observation High

Arc suppression

could shock a human being

H2 Stepper motor does not work

Q6, Q7, Q8, or Q17 is

damaged

Stepper will get stuck in one

stateObservation Low Turret cannot

rotate


H-4

I1 Trigger does not work

Q5 is shorted

Trigger will get stuck in pulled

positionObservation Low

Trigger will get stuck, but the gun is not automatic so only one shot will be fired

ee 477 final report - purdue engineering · web viewspring 2005 team code name: _____ team id:...

Documents