ee 477 final report · web viewthe manufacturing process of the pcb makes use of many harmful...

ECE 477 Final ReportSpring 2007

Team Code Name: _Autocar____________________________________ Team ID: _13___

Team Members (#1 is Team Leader):

#1: _Greg Futia________________ Signature: ____________________ Date: _________

#2: _Greg VonFange____________ Signature: ____________________ Date: _________

#3: _Phillip Kasper_____________ Signature: ____________________ Date: _________

#4: _Anirudha Bhende__________ Signature: ____________________ Date: _________

ECE 477 Final Report Spring 2007

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 2Constraint 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: 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 8

CD of Project Website 0 1 2 3 4 5 6 7 8 9 10 X 1

TOTAL

-ii-

Comments:


TABLE OF CONTENTS

Abstract 1 1.0 Project Overview and Block Diagram 2 2.0 Team Success Criteria and Fulfillment 5 3.0 Constraint Analysis and Component Selection 6 4.0 Patent Liability Analysis 9 5.0 Reliability and Safety Analysis 13 6.0 Ethical and Environmental Impact Analysis 17 7.0 Packaging Design Considerations 20 8.0 Schematic Design Considerations 23 9.0 PCB Layout Design Considerations 2610.0 Software Design Considerations 2911.0 Version 2 Changes 3312.0 Summary and Conclusions 3413.0 References 35Appendix 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: FMECA Worksheet G-1

-iii-


Abstract:

The concept of the project chosen by the team is GPS Waypoint Navigation. The idea was

to buy an RC car and modify it in a way such that the car would travel autonomously through a

course of user programmed GPS waypoints. The car has an ultrasonic sensor in the front to

detect obstacles in its path. a GPS system to communicate with satellites and keep track of the

current position, and a digital compass to know the heading of the vehicle. There is an LCD

screen mounted on top of the car that displays the distance to an obstacle, current position,

heading and the number of satellites that the GPS is connected to. The user can program the GPS

coordinates of the intended course through a graphical user interface on a PC by connecting the

vehicle to the computer through a serial port. Once the course is entered and the power is turned

on, the car will autonomously drive and navigate itself along the programmed course. If it

encounters an obstacle, it will make attempts to navigate around the obstacle. The motivations

behind the project were both civilian and military uses. The basic goal was to save human lives.

In the civilian arena, this concept could be used to implement an automated roadway or delivery

system and in the military area, it could be used for reconnaissance to save the lives of soldiers

as well as civilians.

-1-


1. Project Overview and Block Diagram

The purpose of the Autocar project is to create an autonomous vehicle that will navigate a

course based on GPS waypoints. These waypoints are user programmable and can be entered by

a user via a graphical user interface on a computer that will communicate with the car through a

serial port. The car has a GPS unit installed on it to communicate with satellites and keep track

of its current position. It also has an ultrasonic sensor attached to the front to detect obstacles in

its path and a digital compass to provide the heading for the vehicle. In addition to these, there is

an LCD screen attached on the top of the vehilce that will display information such as current

position, the number of satellites that it is connected to and the current heading of the vehicle.

Using these peripheral devices the car will navigate through the course programmed by the user.

The primary motivation for doing this project was to create a concept that would help

save human life in vehicles. The uses for this concept could be civilian such as an automated

roadway or delivery service and also military such as reconnaissance missions. Also this is an

innovative idea that is not commercially available at this point in time.

-2-


Block Diagram:

-3-


Project Pictures:

Figure 2: Front View of the Vehicle

Figure 3: Side View of the Vehicle

-4-


2. Team Success Criteria and FulfillmentThe following is the list of the team success criteria.

1. An ability to determine position and heading of the vehicle.

2. An ability to enter and follow user programmable waypoints

3. An ability to control the steer angle and speed of an RC vehicle.

4. An ability to display route information on a local LCD.

5. An ability to detect obstacles and navigate around them.

The team has successfully fulfilled all the above success criteria. Criterion 2 is fulfilled by

having the user enter the waypoints of the desired course through a graphical user interface on a

computer which communicates with the vehicle through a serial interface. The vehicle then

navigates through the programmed waypoints successfully. The successful demonstration of

criteria 2 also demonstrates criteria 1 and 3 simultaneously as the car can follow the programmed

waypoints successfully only by correctly determining its position and heading and also by

correctly controlling its steer angle and speed. Criterion 4 is fulfilled as information such as

current latitude, longitude, the distance from the nearest obstacle and the numbers of satellites

that the GPS is connected to are displayed on the LCD. Criterion 5 is successfully demonstrated

as the car stops when it encounters an obstacle and then runs through a routine where it backs up

and turns and ultimately navigates around the obstacle. It then resumes its course to the next

waypoint.

-5-


3. Constraint Analysis and Component Selection

3.1. Introduction

This design requires the use of several peripherals as well as a microcontroller capable of

interfacing to the peripherals. The peripherals that will be required to achieve our project goals

are a GPS device, servos, motors, ultrasonic distance sensor, digital compass, and an LCD screen

to display the vehicles status. In order to communicate with this wide range of peripherals, it is

necessary to have a microprocessor that is capable of pulse counting, serial communication

protocol (specifically RS232), and accurate PWM output signals.

3.2. Design Constraint Analysis

Computation Requirements

The device needs to be capable of several mathematical computations. It is necessary to

have microcontroller capable of accurately measuring time intervals and capable of applying

appropriate scaling of the time values for the functioning of the sensor. Both the steering servo

and speed motors are controlled by a duty cycle. Therefore the device will be required to output

two PWM signals corresponding to the desired speed and direction of our device.

Interface Requirements

The first interface that our design must control is the front steering servo motors and the

rear speed control motors. The signal from the ultrasonic sensor [1] will occupy one I/O pin on

the device. Another use of I/O pins will come from interfacing with an LCD screen. [2]

Peripheral Requirements

The design requires a minimum of two channels of 8-bit PWM. These signals will be used

to control the front servo motor and the rear speed control motor. The project also requires two

channels of RS-232 in order to interface with both the GPS navigation unit and the digital

compass. The design will most likely require at least one input capture time channel [3] for use

with the ultrasonic sensor. [4]

Power Constraints

The battery that has been initially purchased for the RC vehicle is a 7.2V 3200 mAh battery.

The power supplied by it is adequate for the project.

Packaging Constraints

-6-


The main concern regarding the packaging is the limitation of space on the car for the

additional components and the additional weight that can be added to the car. The major

components added would be the PCB consisting of the microcontroller, compass and power

circuitry and the GPS unit.These components are not very heavy and will not add a significant

amount of weight to the car. Also they are fairly small and effort would be made to design the

board to be small enough to be able to fit on the vehicle.

Cost Constraints

Due to the desire of all group members to create a memorable senior design project that

accomplishes all of its goals, we have decided to be generous in the amount we are each willing

to personally spend on this project. We expect the design phase of the project to cost

somewhere in the neighborhood of $1000.

3.3. Component Selection Rationale

Potential Microcontroller: Selection of the microcontroller is one of the most important

decisions that our group will make during our design. Two of the microcontrollers that we

narrowed our search to were the PIC18F2410 [5] and the MSP430F167 [6] offered by Texas

Instruments.

Table 1 : Comparison of MirocontrollersName Bits Flash Ram I/O Price

PIC18F2410 8 16 KB 768 B 25 $4.51

MSP430F167 16 32 KB 1 KB 48 $6.75

The PIC device is capable of I2C, SPI, EUSART communication as well as having up to two

PWM outputs and four timer modules. The TI device is similar to the PIC except that it has

32KB of flash. The PIC device meets the majority of our specifications. It has plenty of extra

I/O pins for added functionality if necessary. In the decision was made to go with the

PIC18F2510 as it had 32KB of flash and it was much better supported by the software in the lab

than the TI part.

Potential GPS units: Our group’s ability to select a GPS unit was limited by the accuracy

available within a sensible price range. The best accuracy that could be achieved for below $200

is about three meters. We also had to choose whether we wanted to buy a chip that could be

-7-


integrated into the board or whether we wanted a separate device that could be connected

through a cable. We decided that it would be nice to mount the GPS device on the roof of the

vehicle; this could help us reduce noise and increase accuracy. The main question left is what

type of connection we want to use. Garmin is a main supplier of GPS devices and offers two

different GPS solutions. The Garmin GPS 18 OEM [3] series is available with several different

connection types including USB and DB-9 serial. The Garmin OEM 16A [7] model is a surface

mount with RS-232 communication. We decided to use the Garmin OEM 18A as the RS-232

seemed like a more common communication protocol and we had more confidence that we

would be able to communicate properly.

Potential compass units: Several models were considered ranging in accuracy to better than

one degree offered by the OS3000 [8], six degree accuracy of the Hitachi HM55B [9], and eight

total points offered by the Dinsmore 1490 sensor [9]. We decided to use the Hitachi HM55B, as

six degrees of accuracy should suit our design sufficiently. The price range of the Hitachi is also

very affordable as it costs only $29.95 compared to the price of $249 for the OS3000.

Potential Distance/Object sensors: The PING Ultrasonic Sensor [1] can detect objects

between 2cm and 3 m with enough accuracy to suit the needs of our design. The price per unit is

$29.95 per unit.

Potential LCD displays: Finally, an LCD will be needed that is able to display the status of

the vehicle such as its current GPS coordinates as well as its directional heading. Crystalfontz

offers two affordable models that would both suit the device well. The CFAH082A [10]

operates by connecting to I/O pins which specify address and code to create a text string and has

a cost of $20. The CFA632-NFA-KS [11] communicates via serial communication at a cost of

$35. Besides communication protocols each devices is capable of completing similar tasks. We

decided to use the CFAH082A.

3.4. Summary

To summarize the following components were chosen. The PIC18F2510, the Garmin OEM

18, the PING Ultrasonic Sensor, the Crystalfontz CFAH082A, the Hitachi HM55B parts were

chosen for the microcontroller, the GPS, the ultrasonic sensor, the LCD and the compass

respectively.

-8-


4. Patent Liability Analysis

4.1. Introduction

The project has employed control algorithms to move between waypoints and to avoid

object collision. The team has keep prior art and patent liability in mind, while designing

algorithms and hardware. In addition, due to the doctrine of equivalents, the team may be liable

for the system itself and must be cautious before manufacturing and selling the Autocar vehicle.

The following sections analyze the claims of existing patents and makes recommendations for

action to avoid patent liability.

4.2. Results of Patent and Product Search

4.2.1. Automobile Navigation, Guidance, Control, and Safety System [12]

Filling Date: Apr. 2 1996

Condensed Abstract: An automobile is equipped with an RF GPS satellite navigation unit and

local area digitized street map system for precise electronic positioning and route guidance

between departures and arrivals [12].

Claims with Potential for Infringement: Quoting from the introduction of claim 1, which is

quite long, “A vehicular guidance, control, and safety system within a vehicle for receiving GPS

signals transmitted from GPS satellites..” [12]. The system is comprised of a, “dynamic control

processor means connected to said navigation processor means for receiving said acceleration

and velocity formatted digital signals, connected to said vehicular electronic controls for

controlling the operation and sensing the condition of said vehicle, said dynamic control

processor means for sending control signals to said vehicle's electronic controls in response to

unstable conditions..”[12].

4.2.2. Automotive GPS control system [13]

Filled On: Jun. 30, 1993

Condensed Abstract: “This disclosure sets out a GPS receiver cooperative with a CPU having a

memory. The memory enables inputting of data defining an electronic fence, i.e., a set of

locations or a region where the vehicle is permitted to be operated. The electronic fence may be

cooperative with a set of permitted driving instructions defining a delivery pathway for a set of

stops, there being one or more delivery paths, which in conjunction with a clock, enables the

vehicle to make delivery trips of a different nature at different times.”[13].

-9-


Claims with Potential for Infringement: Claim 1: “A vehicle supported GPS system

comprising: (a) a GPS receiver for receiving signals in determining the location of a vehicle

supporting the GPS system; (b) a CPU with memory provided with vehicular permitted locations

and permitted times, the CPU further receiving the GPS receiver generated location of the

vehicle so that the CPU is enabled to compare vehicle location with vehicle permitted locations

from memory and forming an indication that vehicle location is permitted; and (c) a clock

providing a time signal to the CPU, wherein the CPU is enabled to compare the time signal with

the permitted times, thereby forming an indication that vehicle time is permitted.”[13]. Claim 2:

“The apparatus of claim 1 wherein said CPU is provided with a first memory storing an

electronic fence around a specific geographic area so that the vehicle is permitted within that

area, and said CPU compares the vehicle location with the area inside the electronic fence to

determine that the vehicle is permitted therein.”[13]. Claim 4: “The apparatus of claim 2 wherein

said permitted vehicle location is defined by a route on streets, and said vehicle is permitted to

drive the route on the streets, and said CPU forms a signal indicative of driving the routes

thereby permitted.”[13].

4.2.3. Waypoint navigation using exclusion zones [14]

Filed On: July. 19, 1995

Condensed Abstract: “A method is provided for navigating a vehicle. Waypoint exclusion

zones are defined as circles whose centers are known-position waypoints. The vehicle is steered

along a path that is tangential to the "current" waypoint exclusion zone.”[14].

Claims with Potential for Infringement: Claim 1: A method for navigating a vehicle consisting

of a) a plurality of waypoint exclusion zones, b) determining turn direction based on an ordered

sequences of waypoint exclusion zones, c) steering a vehicle along a path tangential to the i-th

waypoint exclusion zone, d) maintaining a path tangential to the i-th waypoint exclusion zone e)

advancing a vehicle along a circle of the i-th waypoint exclusion zone [14].

4.3. Analysis of Patent Liability

4.3.1. Analysis of Liability involving the invention of [12], Automobile Navigation,

Guidance, Control, and Safety System

[12] has invented a way to improve the safety of automobile transportation. In his patent he

describes a system that intervenes for the driver in unsafe conditions. The vehicle’s controls

-10-


system would nominally be controlled by a human. The Autocar project is not be literally

infringing on the patent described by [12].

For the question of infringement under the doctrine of equivalents remains, the system

specified in the drawings is a superset of the system being designed by the Autocar team. In

addition to a RF navigation system and vehicle control system, [12] also specifies using an

electro-optical obstacle detection system, an inertial navigation system (INS), and integrating

with the cellular telephone network. By being a subset of the ideas the Autocar team may be

walking a fine line with the patented designs of [12].

4.3.2. Analysis of Liability involving the invention of [13], Automotive GPS control system

The Autocar team is not literally infringing on claim 1 of [13]. The team has not designed a

system in which once one component is, “a clock providing a time signal to the CPU, wherein

the CPU is enabled to compare the time signal with the permitted times, thereby forming an

indication that vehicle time is permitted.”[13].

The Autocar team has not infringed on the claims of [13]. The team has not used an

electronic fence method to control the movement of the vehicle.

[13] also described a method of using a CPU with memory to store permitted locations for

the vehicle. Under the doctrine of equivalents, the waypoints and route information used to

control the Autocar vehicle could be infringing on this claim.

4.3.3. Analysis of Liability involving the invention of [14], Waypoint navigation using

exclusion zones

The Autocar team has not used a method involving exclusion zones for navigating the

vehicle.

4.4. Action Recommended

The Autocar team has not used algorithms in their design that involve a fencing system; and

is not infringing on the claims of [13], and [14]. Additionally, the claims of [12] are only

possibly being infringed on under the doctrine of equivalents. [12] has claimed a system that is a

major superset from what the Autocar team has designed. At most the Autocar team designs are

a component of [12]’s system. [12] has not claimed the invention of the subsystem components,

some which do not exist, only the idea of putting them together into his super system.

-11-


4.5. Summary

This report analyses the liability for patent infringement, relative to three found patents, as it

relates to the products of the Autocar project team. In performing this analysis, a patent search

has been executed and relevant claims with potential for infringement have been described. This

report has suggested actions to avoid patent liability. Finally, if the Autocar team remains

concerned about infringing on the claims of [12-14], they should either contact the patent

owners or wait out their patent rights before manufacturing and selling the Autocar vehicle.

-12-


5. Reliability and Safety Analysis

5.1. Introduction

Safety and reliability are critical considerations for an autonomous vehicle. The vehicle

is equipped with an ultrasonic sensor that will prevent it colliding with objects to avoid both

damage to the vehicle and injury to people who may be in the vehicle’s way. Reliability is also

an important concern. A failure while the vehicle is in operation may strand the vehicle in a

potentially hazardous area, or in an unknown position. Also, failures may lead to the vehicle

colliding with an object or person.

5.2. Reliability Analysis

The linear regulator [15] and the microprocessor [5] were chosen to be analyzed for their

reliability. The linear regulator was chosen due to its operation at the highest temperature of any

component in the system. The microprocessor was chosen because it is the most complex

component in the system. It was assumed that the maximum ambient temperature is 50°C. This

is a worst-case estimate meant at factoring in high-temperature operating environments like the

desert. Each component will be discussed in detail with specific assumptions relating to those

components. All models and parameter values used can be found in Appendix C.

Microprocessor:

The model for microprocessors as given in section 5.1 of the MIL-HDBK-217F [16]

was used to calculate the number of failures per million hours of operation. The junction

temperature was assumed to be no more than 10°C higher than the ambient temperature. This

was deemed reasonable because the microprocessor does not get warm to the touch in lab

experiments. The actual thermal interface data for the microprocessor was not available. Also,

no testing specification could be found for this part, so was assumed to be 10. This may

unfairly rate the component with higher than actual failure rates. The failure rate was determined

1.108 failures per million hours of operation. This makes the mean time to failure (MTTF)

902,527 hours. The only parameter that can be realistically changed by the design of the project,

without changing microcontrollers, is the temperature. Adding an active cooling system for

vehicles operating in high-temperature environments would alleviate this restriction. If the

-13-


operating temperature is lowered to 40°C the failure rate becomes .786 failures per million hours,

a 31% reduction.

Linear Regulator:

The reliability specification does not have a model for power regulators, so the model

for a low frequency SI FET found in section 6.4 of the reliability handbook was used. This was

chosen because the output of the linear regulator is controlled by a P-channel JFET. The thermal

characteristics for this device are given in the data sheet, enabling close estimation of the

operating temperature. The regulator has a thermal resistance of 125°C/W when connected to a

PCB without heat sinking. With the assumed case temperature of 50°C and dissipating .44W of

power (from previous homework), the regulator will run at 105°C. This yields 1.895 failures per

million hours as well as a MTTF of 527,593 hours. A good way to improve this is to solder the

regulator to at least 1 sq. in. of copper on the PCB. According to the data sheet, this lowers the

thermal resistance of the part to 70°C/W. This would result in 1.312 failures per million hours, a

31% reduction. In addition, if the active cooling system discussed in the microprocessor section

was implemented, the resulting failure rate would be 1.118 resulting in an overall reduction of

41%.

Conclusions:

A low cost active cooling solution in the hardware enclosure could easily lower the

ambient temperature by 10°C. This would reduce the failure rate of all parts in the system

without having change components. The failure rates for the devices analyzed are between 1

and 2 failures per million hours of operation. This is acceptable for this project because none of

these failures would result in injury or death as discussed in the FMECA below.

5.3. Failure Mode, Effects, and Criticality Analysis (FMECA)

For the FMECA four levels of criticality were used. With an autonomous vehicle special

attention was placed on the vehicle’s ability to successfully return to the proper coordinates or a

‘home base’. The lowest criticality level, rated a ‘1’, is defined as any damage that does not

prevent the vehicle from returning from the field. The second criticality level is defined as a

failure that results in the vehicle not returning from the field, but the vehicle has no permanent

damage. The third criticality level is defined as a failure that causes permanent damage to the

vehicle and it does not return from the field. The reason behind separate levels for permanent

-14-


damage, and a temporary situation is to define levels that would require repair that could be

performed in the field by a technician, such as removing debris that causes a short and repair that

would require the system to be returned to the manufacturer, such as a failed microcontroller.

The fourth criticality level is defined as a malfunction that could cause harm to an individual

near the vehicle.

The method of detection column for this particular project was focused on diagnostics to

be performed after the vehicle is recovered or found to be faulty in an inspection. This is

because the vehicle is autonomous and most failure modes would not be noticed by the user

except in the case that the vehicle did not return to the proper place. The method of detection

assumes that if the vehicle did not return, it was recovered and can thus be analyzed.

Certain assumptions were made about the motors. Both motors are controlled by a servo

motor control signal. One of the devices being controlled is not a servo, but an electronic speed

controller. This part was in place on the vehicle and not selected by the team, and certain

information could not be determined. In particular the controller’s response to shorts to +5V and

ground is unknown. It was assumed that in these cases that the controller would have no output.

For the servo, this is known because a pulse width modulated signal is needed to move the

motor. The electronic speed controller may respond to a constant 5V input by giving the full

battery voltage to the motor. This condition was not tested because the team did not wish to

damage the part.

5.4. Summary

It is important in engineering to consider the reliability of the systems that are created.

This not only prevents unnecessary cost for the project’s success, but also fulfils a professional

responsibility to not harm innocent people. For this project, the focus was on not harming

bystanders of an autonomous vehicle. Only two failure modes resulted in this outcome, which

can be prevented by designing robust software and with redundant distance sensing technologies.

Redundant distance sensors will not be implemented on this vehicle due to limited resources, but

care will be taken to avoid any injuries. The reliability of the parts of vehicle was found to be

between 1 and 2 failures per million hours of operation. This was deemed acceptable because

none of the parts analyzed for failure could result in failure of the highest criticality level.

-15-


Unfortunately, the ultrasonic sensor could not be analyzed for reliability due to the limitations of

the military reliability handbook.

-16-


6. Ethical and Environmental Impact Analysis

6.1. Introduction

The purpose of this report is to focus on the ethical and environmental aspects related to

the product’s life-cycle. The first part of the report will focus on the ethical issues that will be

taken into consideration. It will list the issues and the solutions that will be implemented to deal

with those issues. The second part of the report will focus on the environmental aspects of the

product’s life-cycle such as disposal of the PCB and Nickel Cadmium battery. This is an

extremely important consideration as there are certain materials used in the manufacturing [17]

that are potentially hazardous to humans as well as the environment. Hence in the interest of the

safety of our planet and human life, certain procedures have to be followed in disposing of the

hazardous materials. These different procedures will be subsequently discussed.

6.2. Ethical Impact Analysis

Ethics is important as we are designing our project with a view that it will ultimately be

sold to customers. If the ethical analysis is not done, it could potentially lead to damaging

lawsuits in the future. One of the challenges that we would face would be to test the product and

the different components used under various conditions of temperature, humidity, altitude,

vibration and gravel bombardment. This is important as it would help define the limits of the

product usability. Also since the vehicle is an off road machine, these tests are especially

important. Another challenge would be to address the possibility of mounting lethal weapons on

top of the vehicle which could be used to kill people. This is not what we want our car to assist

in, but we realize that an autonomous vehicle could very well be used in these situations to

eliminate the possibility of loss of life of the killer. It could hence be used by military or even by

assassins. An autonomous vehicle could also potentially be at a risk of colliding with humans

and especially hurting small children if the speeds are high. Another issue could be the over-

heating of the motor of the car. This could be dangerous if someone were to come in contact

with the vehicle after it has overheated. This could cause burns.

There are several ways to deal with these ethical challenges. The Society of Automotive

Engineers (SAE) has publications [17] that explain in detail the procedures for tests that need to

-17-


be conducted to test the performance of a vehicle under the conditions of temperature, humidity,

altitude, vibration and gravel bombardment.

Regarding the possibility of mounting potentially lethal weapons on the vehicle, we

understand that this is a feasible task. As designers and potential manufacturers of the product,

the goal is to create a vehicle that will save lives of the driver and passengers. The intention is in

no way to make a killing machine or a military machine to be used in killing people. To enforce

this policy, the potential customers would have to sign legal documentation stating specifically

that the use of this vehicle will be for saving human lives only. This would help ensure to some

degree that the vehicle will not be used for killing purposes. Also it would remove the liability

from the designers and manufacturers if it is used as a killing machine.

Since the vehicle can technically reach speeds of up to 30 mph, it could harm small kids

in the event of the collision. This could be resolved by ensuring the accuracy of the sensors and

braking systems. Also cautions could be added to the user documentation clearing stating the

above fact. In addition some sort of foam material could be added to the front which would act

as a cushion in the event of a collision. To deal with the issue of over heating of the vehicle,

precautionary stickers could be attached to the enclosure stating the warning. Again cautions

could be added to the user documentation.

6.3. Environmental Impact Analysis

The environmental impact analysis is an extremely important focus of the design process

of the project, because the final product will contain a lot of electrical circuitry such as the PCB

and the Nickel Cadmium rechargeable battery. The manufacturing process of the PCB makes use

of many harmful substances such as Copper, Hydrogen Sulfate (H2SO4) and Hydrogen Peroxide

[18]. The PCB then in addition contains more copper and lead. These substances are extremely

harmful to humans and could cause widespread illness if they were to seep into the water supply.

Hence a lot of care must be taken to ensure that these substances are properly disposed or

recycled. Another concern is the Nickel Cadmium battery used. The cadmium from the battery is

again very harmful to living creatures and proper procedures must be followed to dispose it

correctly.

The disposal of a manufactured PCB is also a tricky process and a lot of care must be

taken while doing this. A PCB usually contains copper, solder, iron, nickel and small amounts of

-18-


silver, gold and palladium. Scrap PCBs are first sent to recyclers who determine if the board has

sufficient precious metal content that would make it economically viable to recycle. If that is not

the case, the PCBs are stripped of their parts and sent to specialized landfills. The majority of

PCBs that go in for recycling due to their precious metal content are subjected to Pyrolytic

treatment [19]. This process involves the ignition and melting of the boards in temperatures of

~1200 C via air injection. The organic components of scrap boards are destroyed at this

temperature and toxic emissions are addressed via afterburners that operate at ~1400 C. The

resulting metal produced is called ‘black metal’ and is generally a copper rich product. It is then

subjected to electro refining with the precious metals being recovered from the anodic sludge.

Finally there is a process that needs to be followed to dispose the Nickel Cadmium

batteries [20]. If they are kept in landfills, the cadmium will eventually dissolve itself and the

toxic substances could seep into the water supply causing serious health issues. The batteries

should also in no circumstances be incinerated as this will cause them to explode. The recycling

process starts by removing the combustible materials such as plastic and insulation by using a

gas fired thermal oxidizer. The gases are neutralized to remove pollutants. This leaves behind a

clean cell that contains valuable metal content. The cells are then chopped into small pieces and

are heated until the metal liquefies. The nonmetallic substances are burned off and the process

leaves behind a black slag that is removed by a slag arm. The different alloys settle according to

their weight and can be skimmed off in layers. Cadmium is light and easily vaporizes at high

temperatures. A fan blows the cadmium vapor into a large tube that is cooled by water mist. A

99.95 % purity level of cadmium can be achieved using this method.

6.4. Summary

It can be observed through this report that ethically certain precautions have to be taken

to ensure that the vehicle can be operated in the safest possible way. It has to be ensured that

sufficient user documentation is provided and warning symbols added wherever necessary. Also

the environmental implications of disposing the product after its lifetime can be extremely

serious and damaging to human life if care is not taken to ensure that the harmful components

are disposed or recycled correctly. The PCB and the Nickel Cadmium battery have to be

disposed off very carefully as they are the two most environmentally hazardous components of

the finished product.

-19-


7. Packaging Design Considerations

7.1. Introduction

The packaging of the Autocar project has been designed to protect the Autocar electronics and

provide a secure mounting for them to the Traxxas vehicle.

7.2. Review of Commercial Product Packaging

The Autocar project has developed, what can be viewed, as a advanced control system for an

R/C vehicle. No commercial products were found that are identical to the objectives of the

Autocar project. Prototype vehicles have been developed for automated vehicle competitions

such as the DARPA Grand Challenge [21], but these products have not been commercialized.

From the control system view, the most similar products that are on the market are the Radio

Frequency (RF) receivers used in R/C vehicles. The designs and requirements of the commercial

R/C RF receivers are so different in compared to the requirements for Autocar project packaging

that their designs had no influence on the Autocar Packaging.

7.3. Packaging Design Requirements

The Autocar team designed the packaging based on the requirements for what it must

accomplish. An enumerated list of what it must accomplish is presented below.

The packaging:

must attach securely to Traxxas Rustler Chassis.

must provide protection for the custom Autocar PCB, LCD board, and Ultrasonic

Sensor

must provide mounting points for Autocar PCB, LCD board, Ultrasonic Sensor, and

GPS unit

must provide a level mounting point for the Autocar PCB, due to the digital compass.

must have a port hole cut so that the LCD can be viewed by the user without

distortion.

must have a port holes for the Ultrasonic Sensor so that the sensors signal can

bounce off obstacles.

must allow the power, signal wires, and garmin GPS unit to connect to the PCB.

-20-


7.4. Packaging Design

To provide a secure attachment from the packaging to the Traxxas vehicle, the team designed a

base plate. The CAD drawing for the base plate is in Figure B-1. The base plate attaches to the

three mounting points previously used by the vehicle’s plastic cover shown in Figure 4. The base

plate was designed so that the GPS unit and the Autocar PCB could be mounted to it directly. A

jig was placed in the middle because the front mounting points are lower than the rear mounting

point, and the requirements dictate the Autocar PCB must be mounted level.

Figure 4: Traxxas Rustler Chassis

A box was designed to enclose the Autocar PCB. The drawings of the box are shown

in Figure B-2. On the inside of the box, two port holes were cut for the Ultrasonic sensor, and the

two screw holes we’re drilled so that the sensor can be mounted inside of the box. By mounting

the sensor inside the box, the box provides protection for its PCB. Another cut was made to the

top of the box for the LCD. Four holes were put into the design so that the LCD board could be

mounted to the inside of the top of the box. With this design, the box enclosure provided

protection for the Autocar PCB, Ultrasonic Sensor and LCD board, and mounting points for the

Ultrasonic Sensor and LCD board.

The final component of the packaging design is the mounting brackets. 4 L shaped

mounting brackets we’re designed for securely attaching the plastic enclosure to the metal base

plate.

-21-

Mount Points

Mount Points


7.5. Packaging Realization

Excluded from the design, was a way to connect to the Autocar’s USART, and a

method for bringing in the power and signal wires. Additionally, at the time of the packaging

design no previsions were made for the push buttons and switches that were needed.

After it was discovered that an inverter would be required in order to connect to the

USART, it wad decided to move the DB9 connector off the PCB and to embed it into the side of

the box enclosure, in-lining an inverter in between. On the opposite side of the packaging three

holes were drilled for two switches and a push button. To bring in the power, signal, and an

added debugging wire, we decided to drill a 1.5” diameter hole underneath the PCB in the base

plate, and run the wires up through that. With those additions, the packaging realization was

complete.

-22-


8. Schematic Design Considerations

Power Supply:

The power source for the Autocar project is a 7.2V RC car battery. This is the device

that was supplied with the base vehicle purchased by the team. It is also used to directly power

the electronic speed controller and drive motor, in order to prevent running power for these

devices through the PCB. The 7.2V supply is stepped down to 5.0V through a low dropout

linear regulator. A linear regulator is sufficient due to the board requiring only 143mA. The

5.0V output directly supplies all of the on-board components. The chip selected for this project

is the National Semiconductor LP2989 [22]. The input and output capacitance values used to

design the power circuit were taken directly from the datasheet.

Servo Motors:

The microprocessor interfaces with a steering servo motor, which controls the

vehicle’s steer angle, and an electronic speed controller, which controls the drive motor. Both of

these parts were included with the RC vehicle. Through lab work, it was determined that the

operation signals are identical for both devices. The signals are a PWM signal with a period of

20mS. The steering servo varies in duty cycle from 5% for the steering position to be full left to

10% for full right with 7.5% duty cycle being dead center. The drive motor is similar except 5%

duty cycle is full forward drive, 10% duty cycle is full reverse, and 7.5% is stopped. The motors

are controlled through GPIO pins triggered by the timer module of the microcontroller.

Digital Compass:

The Hitachi HM55B [4] digital compass module is used to determine the vehicles

direction. The module that is being used for this project integrates a 3V regulator for the IC

supply voltage. This module also converts the chip from SON16 packaging, which is outside of

the guidelines given in lecture, to an 8 pin DIP. The HM55B module has a synchronous serial

data stream with 22 data bits and accepts 4 bit serial commands. This will be interfaced directly

to GPIO pins on the microcontroller. Originally, it was planned to use the SPI module of the

microcontroller, but timing issues and the difficulty of transmitting 4 bit instruction codes made

GPIO interfacing more practical. The data contains two 11 bit numbers stored in 2’s compliment

format. The numbers represent the direction of earth’s magnetic field in a Cartesian coordinate

system. An arctangent of the two numbers gives the direction of the compass.

-23-


Ultrasonic Sensor:

The ultrasonic sensor selected for this project is the Parallax PING))) 28015 [1]. The

device communicates by accepting a trigger pulse (sent by the microcontroller) then returning a

pulse on the same pin. The width of the return pulse determines the distance to an object. The

relationship between distance and pulse-width is linear. The microcontroller is interfaced on a

GPIO pin. This pin will use the tri-state buffer to set the pin to output the trigger pulse and then

be switched to an input before the sensor starts to drive the bus (750µS). See the Hardware

Design Narrative for information on the planned method to measure the output pulse.

GPS Unit:

The Garmin GPS 18 System [3] is used to determine the vehicle’s position. The unit

provides a user-selectable baud rate, RS232-C output which can be interfaced through an inverter

to the microcontroller’s SCI subsystem. The inverter is necessary because the GPS unit assumes

that a level translator, which inverts the signals, will be present on the receive and transmit lines

of the microprocessor. A level translator is not needed because both the GPS and

microcontroller use logic level signals. The same interface will be utilized to allow a PC to

program coordinates into the vehicle.

LCD:

A Crystalfontz model CFAH1604 [10] 16x8 LCD character display is used to display

heading and position data as well as provide debugging information. This LCD uses a built in

standard Hitachi HD44780 LCD controller/driver. This utilizes a 4 bit parallel interface with

three control lines (read/write, enable, and reset). These are directly connected to GPIO on the

microprocessor. Also, a potentiometer is included to adjust the contrast of the LCD. The

backlight of the LCD draws as much current as the rest of the system combined and will not be

utilized.

PIC18 Microcontroller:

The microcontroller selected for this project is the Microchip PIC18F2410 [5]. This

chip was selected, in part, due to its low cost, low complexity and flexibility.

The microcontroller is run at a frequency of 8MHz using its native internal clock.

This simplifies the operation and the hardware design by eliminating the need for an external

oscillator circuit. This saves complexity, board space and cost, while allowing the clock to run

-24-


up to 32MHz, if necessary, through the Phase Lock Loop (PLL). The processor is a 5.0V part

which prevents the need for any level translators and provides direct interfacing to peripheral

modules.

The timer module of the microcontroller is used control both of the motor outputs as

well as capture the time of the distance sensor pulse. The motor controllers will function on a

periodic timer interrupt of .05mS. This interrupt also allows for 10 discreet speed and steering

positions in a single direction.

-25-


9. PCB Layout Design Considerations

9.1. Introduction

The PCB layout will serve as an important step towards achieving the intended

functionality of the vehicle as the PCB will be the hardware platform on which all the different

external devices and interfaces will be integrated. The PCB will contain the microcontroller, the

linear voltage regulator and the digital compass as surface mount chips along with passive

elements such as resistors and capacitors. The external devices such as the GPS, the servo and

motor controller would be connected via headers on the PCB.

9.2. PCB Layout Design Considerations - Overall

The PCB layout is a major milestone towards the successful completion of the project.

Keeping this in mind, there are specific considerations that have to be taken into account before

laying out the PCB. The board for this project is fairly simple in terms of design. The major

components on the board are the PIC18F2410 Microcontroller[5], the LP38690 Low Dropout

Voltage Regulator[15] and a few decoupling capacitors. In addition to these components, the

external devices will be integrated with the PCB through connectors. There will be a 3 pin

header for the Servo control, a 3 pin header for the Motor control, 2 x 8 pin headers to ribbon

cables for the Crystalfontz CFAH1604 LCD [2], a DB9 connector for Garmin GPS 18 [3] system

interfacing and programming, 3 pin header for the PING 28015 Ultrasonic sensor and a 6-pin

DIP for the Hitachi HM55B digital compass [4] which will be mounted on the board. The board

will also have a power input from a 7.2V RC car battery, a power switch and a reset button for

the microcontroller. For testing purposes, there will be 3 x 8 pin headers added for 7.2V,

regulated 5V and ground connection.

The size of the PCB was decided after taking into the account the intended placement of

the board on the car and the amount of components that would be placed on the board. The PCB

area will be 5 in x 4 in and it will be placed in a black box on the main chassis of the RC vehicle.

The microcontroller will be placed in the center of the board. This will help simplify the routing

of traces to the other components on the board. The Digital Compass will be placed in a position

such that it is as far away as possible from the servo and drive motors of the RC vehicle so that

EMI [23] will be minimized and will lead to more accurate heading information. The power

-26-


input from the battery and the DB 9 connecter for the GPS system will be placed along one side

of the board. The idea is to isolate the power circuitry so that there is absolutely no interference

with the part which is one of the most important for the functioning of the PCB and ultimately

the project. Also the traces to the different headers connecting the external devices will be well

spaced out. This increased spacing will reduce the likelihood of the traces being shorted out.

There are a few other considerations that will be taken into account before designing the

PCB. One of the major considerations is the trace widths. The idea is to have short and wide

traces in order to reduce the inductance of the conducting trace which in turn will reduce the

noise on the board. After some thought and consulting some PCB trace width calculators [24],

the trace widths for traces other than those for the power circuitry were determined to be 12 mils.

Also, instead of using 90 degree turns, 45 degree turns will be used to reduce transmission

reflections [23]. Both the above measures help to reduce noise in the system.

9.3. PCB Layout Design Considerations – Microcontroller

The microcontroller used in our design is the PIC18F2410. The microcontroller will run at a

frequency of 8 MHZ using its internal clock and hence there is no need for an external oscillator

circuit. Decoupling capacitors will be used to supply power to the microcontroller during

unexpected glitches in the power supply. The decoupling capacitors will be placed very close to

the microcontroller. In addition to the decoupling capacitors, a bulk capacitor will also be used.

The purpose of this capacitor is to recharge the decoupling capacitors once they have been

discharged. The power trace which will come from the voltage regulator will be wider than the

signal routing traces and will have a width of 40 mils. This will power the microcontroller. Any

unused pins on the microcontroller will be connected to resistor pads which in turn will be

connected to the ground plane. Hence if required in future the pins will still be available for use.

9.4. PCB Layout Design Considerations - Power Supply

The RC vehicle and all the additional components on it will be powered by a 7.2V RC

vehicle battery. In order to power the PCB, the microcontroller and other external devices, this

7.2V will have to be stepped down to 5V (see Appendix 1). To achieve this, a low Dropout

Linear Voltage Regulator will be used. The part chosen to perform this function is the LP2989

from National Semiconductor [22]. It has an input maximum voltage of 10V and a low dropout

-27-


of 0.45V. The maximum current that it can supply is 1000mA which is much greater that the

150mA required by our system (see Appendix 1). This power regulator circuit consists of an IC

which will be placed on the board and a couple of bypass capacitors. One of the capacitors will

be placed very close (no more than 1cm) to the input pin and the other capacitor will be placed

very close to the output pin. Both will be connected by traces to their respective pins in which no

other currents are flowing. The 5V power rail will be routed along the top edge of the PCB. The

thinking behind this is to move the power rail far from the other traces so that there is a very

minimal chance of short circuiting. Also any heat dissipated will not affect the other parts on the

PCB. Traces will be routed off this power rail to the headers of the respective external devices to

power them. Any unused areas of the board will be used as a ground plane. This will help to

reduce ground noise.

9.5. Summary

The PCB design for this project is fairly simple as it only involves the microcontroller,

the linear voltage regulator, the optical isolator IC and a few capacitors to be placed on the

board. All the other external devices such as the GPS, Servo control, Motor Control and Digital

Compass will be interfaced via connectors. Care will be taken to ensure that power traces are

separated from the other traces and adequate grounding be provided. The trace widths, the

routing and the placement of bypass capacitors will also be given careful thought.

-28-


10. Software Design Considerations

10.1. Introduction

The main consideration for the software is the ability to communicate with each of our

devices. The Garmin 18 GPS device [3] has a 5 Hz refresh rate. The PING ultrasonic sensor [1]

and the HM55B digital compass take around 20 ms to get a readings, and need to be told when to

start taking a measurement, and are able to make another reading immediately after. We attempt

to minimize the amount of time polling devices, by using interrupts to help perform distance

measurements and acquire GPS data. In order to poll each device we need the microcontroller to

be able to communicate properly with all peripherals. While our microcontroller did come with

special functionality for change on interrupt, SPI, and EUSART, we ended up only using the

EUSART functionality and creating our own code for the other modules.

10.2. Software Design Considerations

The software issues that the Autocar project has considered is the acquisition of

longitudinal and latitudinal coordinates and heading direction and using the information to

automatically drive to a user defined location without colliding with any obstacles. The modules

use to achieve this goals are the GPS, compass, distance sensor, LCD, and motor modules. Each

of these modules is responsible for communicating with its designated device and making

information available to the main routine. The information will be used to determine which

direction the vehicle should steer and whether it should proceed toward the target. The program

memory of the PIC18F2510 [5] is 32 kB which means that the user memory space lies between

18h and 7FFFh. The memory locations from 00h to 18h are reserved for the program counter,

stack and reset/interrupt vectors.

The software designed for this project uses a combination of polling and interrupt

handling to achieve its desired goals. Polling devices such as the compass and LCD will send

some command or signal to a device and then wait for a response if necessary. The ultrasonic

sensor, motor, and GPS modules will make use of timer interrupts in order to measure

waveforms, produce duty cycles, and receive data. Once each module has been read a decision

will be made by the main algorithm on whether the vehicle has reached its location within a

certain tolerance.

-29-


The Hitachi digital compass [4] and the GPS unit communicate using serial protocols and

will need to be connected through port C of the microcontroller. This port will allow the

microcontroller to communicate with the compass through SPI communication and will talk to

the GPS using EUSART (RS-232C) communication.

Another important software consideration is setup of the timer interrupt. Running at 8

MHz, the PWM module can not be used to generate the 20 ms duty cycle for drive motor and

steering control. The timer must be utilized instead. The clock rate of the microcontroller for

our project is 8 MHz with a TMR2 interrupt rate of .05 ms. To achieve this TMR2 uses no pre-

scalar but sets the a special register called PR2 to 100, this means that every 4 clock cycles a

value will increment until it matches PR2 and will produce an interrupt which is exactly .05 ms.

This interrupt is used to produce the proper duty cycles and to measure the width of the

Ultrasonic burst.

10.3. Software Design Narrative

Crystalfontz LCD Module

Serial communication is used to interact with the LCD module. This communication

protocol requires three control bits along with four data bits since we use an eight bit

communication scheme. Instead of using the special functionality of the microcontroller for

serial shifting we wrote our own shift in and shift out functions that were more suited to our four

bit interface needs. To communicate with the LCD we first initialize it and can then write to any

of the characters included into the 16x4 LCD by setting the address of the LCD and sending it a

character.

Drive Motor and Steering Control Module

The TMR2 interrupt is used to produce two PWM signals with duty cycles ranging

between five and ten percent. These output signals our produce onto Port B pins three and four.

For the servo motor 5% results in full right, 7.5% is dead center, and 10% is full left. For the

electronic speed control 5% is full reverse, 7.5% is stopped, and 10% is full forward. To

produce these signals we simply count the number of TMR2 interrupts up to 400 and set the

signal high for the first X% amount of time depending on the desired duty cycle. Using this

software implementation we can specify ten reverse speeds, ten forward speeds, ten left angles

and ten right angles.

-30-


Distance Sensor Module

The distance sensor requires only one signal (Port B pin 5) to operate. The

communication protocol works by the microcontroller sending a short pulse to the device and

then the device will send a pulse of its own. The width of this pulse represents the amount of

time required for the ultrasonic signal to bounce back to the sensor. This amount of time can

then be translated into distance. The TMR2 interrupt can also be used to time this pulse width

using a separate counter. This implementation requires first declaring Port B pin 5 as an output

pin by clearing the corresponding TRISB register bit and then after sending a short pulse to

initiate the sensor. Port B is then declared as an input pin and the counter is set to zero. Sound

travels at 13560 inches/sec, so for every .05 ms interrupt 0.678 inches were traveled by the

ultrasonic wave. Divide this distance by two in order to account for the return path.

Digital Compass Module

The digital compass module communicates using a serial communication protocol which

requires four I/O pins. Port C pins 2,3,4, and 5 support SPI communication with pin 2 providing

the enable signal, pin 3 providing the clocking mechanism, pin 4 providing the SPI data input,

and pin 5 providing the SPI data output. The enable signal will be high while no communication

is occurring but will be brought low right before transmission occurs in order to enable the

device. To take a measurement we shift in four bits correlating to a reset, shift in another four

bits correlating to a start measurement command, and after a short delay we shift in 22 bits the

first 11 of which are the x-axis measurements and the second 11 are the y-axis measurements.

GPS Module

The Garmin GPS 18 OEM device we are using communicates through an RS-232

communication protocol which is implemented using the serial data input and output ports of the

EUSART module. These pins are located on Port C of our microcontroller with pin 6 acting as

serial clock input/output and pin 7 acting as serial data input/output. Information is constantly

being transferred by the GPS and is read in using a receive interrupt which loads the data into a

buffer. The buffer is later parsed into a useful data structure containing important information

such as the number of satellites connected to, latitude and longitude.

-31-


10.4. Summary

This software design consideration and narrative has shown how the software is

organized in the Autocar project. We use a combination of polling and interrupt servicing to

receive data from our devices. This polling will continue in a loop receiving data and making

decision about speed and direction based on the information it receives to ensure it reaches its

target destination.

-32-


11. Version 2 Changes

The Autocar project successfully demonstrated all the Project Success Criteria in an

encompassing integration test. In retrospect, there are certain changes that could be made in the

design in order to ensure that the final product is even more robust and accurate. One thing that

could be done is add additional ultrasonic sensors to the back and sides of the car. This would

help the car detect obstacles even when approaching them at an angle. Also it would facilitate

code that would enable the car to navigate around long obstacles such as walls. Also, a more

accurate GPS receiver would also enable the car to navigate more accurately, get closer to the

actual programmed waypoints and be less constrained by weather conditions such as excessive

cloud cover or rain. In terms of hardware, an additional capacitor had to be added between power

and ground on the PCB to prevent the processor from resetting when the GPS powers up. Also

an inverter was externally added to the circuitry to invert the RS – 232 signals. This was because

the transmit and receive lines needed to be inverted between the microcontroller and the PC for

communication to occur. These changes could be incorporated into the hardware by adding a

MX3232 level translator which would invert the signals. In terms of packaging, the ultrasonic

sensor was pointing downwards as all the added weight was pushing the front of the car to tilt

downwards. Due to this the sensor was detecting the front bumper of the car as an obstacle. This

could be solved by tilting the sensor upwards to compensate for the downward tilt of the front of

the car due to the added weight. Also, the microprocessor used for this experiment lacked the

capability to program flash without connecting to a debugger. Due to this, user programmed

waypoints are stored in RAM. If the vehicle looses power, all of this information is lost. For a

future version a microprocessor with access to write to the flash would alleviate this issue.

Lastly, the digital compass calibration could be improved. For this project the compass was

calibrated by hand and the resulting values were hard-coded. These values were hard-coded

because the values could not be stored in flash memory. If the capability to write to flash was

present, a calibration routine could be integrated into the car.

-33-


12. Summary and Conclusions

The experience of working on the Autocar project was a very challenging as well as a

rewarding experience. This project was chosen by the team collectively and the team took

responsibility of getting the project done on time. The team had 16 weeks to go through the full

design process of an actual engineering project and come up with a finished working model at

the end of it. Almost all of the design work was done by the team with guidance from the course

administrators when required. In general the team was given a lot of autonomy to get the project

done. The Autocar project was successful and the team successfully demonstrated all the Project

Success Criteria. The car was successfully able to navigate through the user inputted waypoints

and move around obstacles when encountered.

There were many things learned by working on this project. Firstly, the team learned how a

real life engineering project should be managed to take it from the stage of an idea to a working

finished product. Secondly, there were many technical skills that were learned such as the design

and layout of the PCB, researching and choosing design components such as the microprocessor

based on certain design constraints, designing packaging for the finished product, writing

software for commercially available peripheral devices such as GPS and LCD and also

integrating all the components finally using the custom designed PCB. Thirdly, the team learned

the value and importance of documenting the work done in the design process in a timely manner

by maintaining an online lab notebook. Lastly, the members of the team learned to work with

each other in an effective manner so that the final goal of the project would be achieved.

-34-


13. References

[1] Parallax, “PING))) Ultrasonic Distance Sensor (#28015)”, [Online Document], 05/2005,

[cited April 25, 2007], http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf

[2] Crystalfontz, “CFAH0802A-GGH-JP”, [Online Document], unknown publication date,

[cited April 25, 2007],

http://www.crystalfontz.com/products/0802a-color/CFAH0802AGGHJP.pdf

[3] Garmin, “GPS 18 Technical Specifications”, [Online Document], June 2005, [cited April

25, 2007], http://www.garmin.com/manuals/425_TechnicalSpecification.pdf

[4] Parallax, “Hitachi HM55B Compass Module”, [Online Document], June 2005, [cited April

25, 2007], http://www.parallax.com/dl/docs/prod/compshop/HM55BModDocs.pdf

[5] Microchip, “PIC18F2X1X/4X1X Data Sheet”, [Online Document], 2006, [cited April 25,

2007] http://www.microchip.com/downloads/en/DeviceDoc/39636b.pdf

[6] Texas Instrument, “MSP430x15x, MSP430x16x, MSP430x161x Mixed Signal

Microcontroller”, [Online Document], August 2006, [cited April 25, 2007],

http://focus.ti.com/lit/ds/symlink/msp430f167.pdf

[7] Garmin, “GPS 18 Technical Specifications”, [Online Document], June 2005, [cited April

25, 2007], http://www.garmin.com/manuals/425_TechnicalSpecification.pdf

[8] Ocean Server, “OS3000 3 Axis Digital Compass”, [Online Store], last updated date not

available, [cited April 25, 2007], http://store.oceanserver-store.com/os3axdico1.html

[9] Dinsmore Sensors, “1490 Digital Compass Sensor”, [Online documentation], last updated

date not available, [cited April 25, 2007],

http://www.dinsmoresensors.com/1490spec.htm

[10] Crystalfontz, “CFAH0802A-GGH-JP”, [Online Document], unknown publication date,

[cited April 25, 2007],


[11] Crystalfontz, “CFA-632 Data Sheet”, [Online Document], October 2005, [cited April 25,

2007], http://www.crystalfontz.com/products/632/632_data_sheet.html

[12] Schreder, D. K., “Automobile Navigation Guidance, Control and Safety System”, U.S.

Patent no. 5504482, Apr. 2, 1996

-35-

http://www.crystalfontz.com/products/632/632_data_sheet.html


http://www.dinsmoresensors.com/1490spec.htm

http://store.oceanserver-store.com/os3axdico1.html

http://www.garmin.com/manuals/425_TechnicalSpecification.pdf

http://focus.ti.com/lit/ds/symlink/msp430f167.pdf

http://ww1.microchip.com/downloads/en/DeviceDoc/39636b.pdf

http://www.parallax.com/dl/docs/prod/compshop/HM55BModDocs.pdf

http://www.garmin.com/manuals/425_TechnicalSpecification.pdf


http://www.parallax.com/dl/docs/prod/compshop/HM55BModDocs.pdf


[13] Kadonoff, B. M., Siberz K. J., Franklin A., George R. W. II, Peng, J. P,“Obstacle

advoidance system”, U.S. Patent no. 4751658, May 16, 1986

[14] Jones B. G., Shaw C., Hills J. S., “Waypoint navigation using exclusion zones”, U.S. Patent

no. 5646855, Jul. 19 1995

[15] National Semiconductor, “LP38690 Data Sheet”, [Online Document], 2005, [cited

April 25, 2007], http://cache.national.com/ds/LP/LP38690.pdf

[16] Department of Defense, “Military Handbook – Reliability Prediction of Electronic

Equipment”, [Online Document], 1990, [cited April 25, 2007],

http://cobweb.ecn.purdue.edu/~dsml/ece477/Homework/CommonRefs/Mil-Hdbk-

217F.pdf

[17] Jones B. G., Shaw C., Hills J. S., “Waypoint navigation using exclusion zones”, U.S. Patent

no. 5646855, Jul. 19 1995

[18] Think and Tinker, “Rinse Tanks”, [Online Document], January 2007, [cited April 25, 2007]

http://www.thinktink.com/stack/volumes/volvi/chemanal.htm#DO_DONT

[19] Shipley Europe, “End of life Printed Circuit Boards”, [Online Document], August 2002,

[cited April 25, 2007], www.intellectuk.org/download.asp?file=275

[20] Batteries, “Recycling your battery”, [Online Document], April 2001, [cited April 25, 2007]

http://www.buchmann.ca/Article16-Page1.asp

[21] “Welcome”, [Online Website], [2007 Jan 25], Available at HTTP: http://www.darpa.mil/grandchallenge/index.asp

[22] National Semiconductor, “LP2989 Data Sheet”, [Online Document], 2005, [cited

April 25, 2007], http://cache.national.com/ds/LP/LP2989.pdf

[23] Motorola, “Motorola Semiconductor Application Note”, [Online Document], 1995, [cited

April 25, 2007],

http://cobweb.ecn.purdue.edu/~dsml/ece477/Homework/CommonRefs/AN1259.pdf

[24] “ANSI Trace Width Calculator”, [Online Document], 2005, [cited April 25, 2007],

http://www.desmith.com/NMdS/Electronics/TraceWidth.html

-36-

http://www.desmith.com/NMdS/Electronics/TraceWidth.html

http://cobweb.ecn.purdue.edu/~dsml/ece477/Homework/CommonRefs/AN1259.pdf

http://cache.national.com/ds/LP/LP2989.pdf

http://www.darpa.mil/grandchallenge/index.asp

http://www.buchmann.ca/Article16-Page1.asp

http://www.intellectuk.org/download.asp?file=275

http://www.thinktink.com/stack/volumes/volvi/chemanal.htm#DO_DONT

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

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

http://cache.national.com/ds/LP/LP38690.pdf


Appendix A: Individual Contributions

A.1 Contributions of Gregory Futia:I was the project leader. I’ve categorized my contributions bellow.

Project Management and Planning:

I setup and maintained our project website at autocar.sourceforge.net . I initialized the ECN

website and setup the ECN web space for the individual notebooks. I registered our project on

SourceForge.net , which in addition to hosting our website, provided the team with a version

control system. I lead the team to using the version control system, and to setup a team calendar

for use in coordinating meetings. I scheduled all formal project meetings.

Component and Miscellaneous Research:

I researched and selected the GPS unit. I looked into what resources could be obtained though

the university, and tried to acquire a high accuracy RTK GPS receiver. I decided on using the

OEM Garmin GPS 18 unit for its accuracy, protocol, and price. I researched Open Source

development tools that we could use to develop the software for the PIC18 microcontroller. We

opted to use the tools provided by Microchip. I looked into using a GNU RTOS, developed by

FreeRTOS.org for providing real time functionality on the PIC. In the end, we used a cyclic

executive for simplicity and code size. I compiled the power requirements for the project and

selected the voltage regulator used based on the power requirements.

Hardware

After Phil’s initial revision of the schematic, I reworked and flushed it out so that a net list could

be generated and it made sure it passed DRC. With the teams’ ideas, I got the CAD drawings

completed, and submitted the CAD drawings to the machine shop for fabrication.

Software

Greg V. and I were the primary contributors to the software development effort. I developed the

software to parse the data coming from the GPS receiver. I wrote the software to configure the

serial port, and setup the microcontroller to operate at 8 MHz. In the beginning, GregV. And I

developed our software separately. After Greg V. got the find north program working, and I had

the parser operating on the target, we worked together in merging them. I lead the effort in

getting the software modularized. I developed the software to read in the user programmable

waypoints from the PC. I also developed the PC software to create the user programmable route,

and download it into the vehicle. I worked on the navigation portion of the software, and

A-1


specifically created the structures for the storing the route, and functions for moving between

waypoints.

Documentation & Professionalism:

I developed and block diagram. I made significant contributions to the Final Report, Users

Manual, and Poster. I completed the Patent Liability Homework, and help to create numerous

presentations requested by the course staff.

A-2


A.2 Contributions of Anirudha Bhende:The Autocar project has been something that I have really enjoyed working on. It’s an

innovative idea and a challenging one. I have had an opportunity to contribute in many aspects of

the project. In the beginning, I came up with ideas regarding what exactly we wanted our car to

be able to do in terms of functionality. I helped streamline our focus on the project to make it a

feasible one. I worked to choose the right car in terms of size and functionality. In terms of the

parts researching, I did a lot of researching on the sensors and ultimately determined that the

ultrasonic sensor was the most appropriate for our project. I also noted that we would need more

than one sensor to make sure that the car could avoid obstacles more effectively due to the

relatively narrow beam of the ultrasonic sensor but it would add complications to the software

and so the idea of additional sensors was scrapped.

In the design phase, I worked on the schematic after Phil had made the initial version

to include additional changes such as addition of test point headers, accurate mapping of the

LCD lines to the Microcontroller, etc. I contributed in a major way on the design of the PCB. I

initially did the PCB design consideration homework where I spent a lot of time thinking about

the most appropriate and effective method of placing the parts. I then came up with the initial

design and did the initial routing of the PCB. I also reworked it many times before Phil changed

and optimized it for the design review presentation. I also worked on the ethical and environment

aspects of our project and did research on ways that we could prevent the damage of the

environment during the manufacture, use and final disposal of the project. I also looked at the

ethical aspects and came up with certain procedures that the team could take to make sure that

we do not deviate from our ethical ground.

After we received our PCB, I placed all the parts on the PCB after Phil had put in the

power supply. I also designed a circuit that would test the power supply to make sure that the

voltage regulator could handle the loads that we were going to put on it. The design of such a

circuit was challenging as I was using 0.25 W resistors for testing and hence had to come up with

a design such that the power output through the test resistors wouldn’t exceed that amount. Also

I was testing for two current output values that we expected our regulator chip to be able to

handle to drive all our components on the board and external to the board. The circuit has been

A-3


more adequately explained in my design notebook. I also connected the output to the

oscilloscope to make sure that there was no significant noise in the circuit.

In the software design, I mainly worked on the route navigation. I worked with the

team observe, understand and determine why the car was running in certain ways such as

snaking on the southbound route and determine possible fixes to the problems.

Finally, I played a big role in the documentation which is a significant part of the

project as it is not only ethically important but also important towards the successful completion

of this ECE course. I edited most of the previous homework and put them altogether in the final

report. I also wrote up the other parts of the final report. In addition, I also worked on the user

manual, the poster and the senior design report with Greg V.

A-4


A.3 Contributions of Phillip Kasper:During the course of the project, I contributed in most aspects of the design. The first

major contribution I made to the project was to identify and research potential digital compasses.

From this, I selected the Hitachi part due to its price/accuracy ratio. This part has performed

above expectations and is an integral part of the project. Also, while defining requirements, I

assisted Greg V. in determining the timer module requirements to produce a PWM signal

capable of controlling the steering servo motor and the electronic speed controller.

After the requirements were defined, I created the initial version of the schematic. I

revised this schematic several times prior to Greg F. reworking it for the preliminary submission.

Since the preliminary submission, I have modified the schematic many times. I modified the

schematic to reflect all changes prior to the PCB being laid out and created. Since the PCB has

been manufactured, I have revised the schematic to reflect any hardware changes made to the

project.

I created the first PCB layout that was used for the preliminary submission. I

completely redid the PCB for the midterm design review in order to get the most accurate

feedback. I also reworked the layout with feedback from that review and with updates to reflect

the most recent changes in the design.

I also participated in the software design. During the 5th week of the project I was able

to create code to enable and respond to timer interrupts. From this, I created a signal that had a

20mS period that is required to control the vehicle’s motors. I also assisted Greg V. with the

code to control the ultrasonic sensor. Later in the software design, I created a new version of the

SetSteerAngle function in order to remove cases were a negative desired angle was present.

After the PCB arrived, I installed all of the components for the power supply. I then

tested the power supply for noise. After the rest of the components were installed, Greg V. and I

tested out a simple heartbeat program on the microprocessor. During this time, it was realized

that we could not get the car to move without mounting the PCB to it. I proposed the idea to use

a plate that attaches to the points of the car that the original body attached to.

While troubleshooting a problem with the ultrasonic sensor with Greg F, I discovered

that the port RB5 was shared with the low voltage program enable line of the microprocessor.

While attempting to disable this, Greg and I spent 6 hours developing a workaround.

A-5


A.4 Contributions of Gregory VonFange:I was involved in many aspects of the project. I first came up with the idea of

waypoint navigation only I had originally been considering a helicopter. Due to feasibility issues

the idea was later switched to a ground vehicle. I also played a big role in researching our

components including the selection of the PIC18f2410, although we later upgraded to the 2510.

I created a binder containing printouts of all of our documentation for easier readability

I created a block diagram using Visio which showed for the first time the actual pin

connection between each device and the microcontroller (Phil had previously shown which ports

each device was connected to). In conjuncture with Phil I also wrote code to control the speed

and steer angle of the vehicle using the timer2 interrupt. I also wrote the code that initiates

ultrasonic distance measurements and translates the devices response into a distance

measurement in inches. I wrote software to initialize and write characters to a Hitachi controller

LCD. I also wrote the interfaces to the digital compass which required serial communication. I

had to write my own shift in and shift out functions as the serial shifting of the micro was not

compatible with the compass. Once all of these four components were working together I wrote

software which integrated them all together. This was the Find North routine which used the

compass to control the steer angle of the vehicle and the distance sensor to turn the motor speed

to on or off, all the while updating info onto the LCD. I demonstrated this routine on a bread

board previous to completing our PCB.

I also spent time working with Greg F. to integrate the software I had wrote with the

GPS acquisition software he had written, and getting this software to work on the PCB. I aided

in realizing that we were missing a MAX3232 level translator in our circuitry and I was able to

determine that a 7404 inverter would provide the same functionality. This allowed us to

communicate via RS-232 on our PCB.

Once the GPS was integrated into our system, I came up with a method to determine a

target angle based on current and target GPS coordinate information. This method was later

modified by Greg F. and Phil. I played a role in finalizing the packaging including talking with

the machine shop workers downstairs to ensure the proper holes of proper sizes were made. I

also solved an intermittent problem with the distance sensor thinking it had seen an object when

it there was no object, by realizing that the distance sensor had a wide view angle, and came up

A-6


with the solution of adding spacers to the packaging that would give the distance sensor a slight

tilt up so that its own bumper would not be seen as an object. I was also worked along with Greg

F. on the final route navigation software including an obstacle avoidance routine for

maneuvering around obstacles.

Throughout every part of the project I was also very careful to document my work

including taking pictures and videos of the project throughout various stages of development.

Using this footage I created a final demonstration video that shows development and design

work in progress along with successful completion of all five of our PSSC’s.

I also spent a lot of time working on the final documentation. I worked with Ani to

create an initial version of the poster. I worked with the group to write the senior design report.

I also wrote the product use instructions and product troubleshooting instructions for the user

manual. I worked on adding portions of the project I was responsible for to the final report

including adding the code listings. I spent time with Greg F. doing final editing revisions and

ensure our overall formatting is correct.

A-7


Appendix B: Packaging

Figure B-1: Base Plate Drawing

B-1


Figure B-2: Box Drawing

B-2


Figure B-3: L-Bracket

B-3

“B” because this figure is in Appendix B


Appendix C: SchematicPower system and DB-9 Connections

C-1


Microprocessor System and Connections

C-2


Appendix D: PCB Layout Top and Bottom Copper

Top Layer with Silkscreen.

D-1


Bottom Layer

D-2


Appendix E: Parts List Spreadsheet

Vendor Description Part Number Cost

RC Hobbies + Vehicle, Motor, Batteries, Charger $281.93

Garmin GPS Receiver GPS 18 $206.00Parallax Digital Compass Module HM55B $29.95

ParallaxPING))) Ultrasonic Sensor $29.95

Crystalfontz16x4 LCD character display CGAH1604ANYGJP $36.00

Digikey

Resistors, Capacitors, DB-9 Connector, RJ-11 Jack Various $34.97

Lafayette ElectronicsSwitches, Miscellaneous components Various $13.91

Home Depot, Radio Shack

Miscellaneous Screw Hardware Various $10.40

EE Machine Shop Steel Mounting Plate -EE Machine Shop Lexan Enclosure -EE Machine Shop Mounting Hardware -Advanced Circuits PCB -

E-1


Appendix F: Software Listing

/**************************************************************************************************** * The Autocar project software uses a combination of polling and interupt handling to perform its route navigation* routines. The code was made very modularized in order to simplify testing and debugging of each module’s code.* There is one main function which initializes all modules and then loops continuously gaining data from each module.* There are then 9 different modules each with there own .c and .h files. Each of these modules provides some unique* functionality or provides functions for other modules to use such as the util module.* This software listing includes code for main and all modules in the following order:* main.c, compass.h, compass.c, control.h, control.c, gps_parse.h, gps_parge.c, lcd.h, lcd.c, navigate.h, * navigate.c, rs232.h, rs232.c, timer.h, timer.c, ultrasonic.h, ultrasonic.c, util.h, util.c*****************************************************************************************************/MAIN.C#include <p18cxxx.h>#include <usart.h>#include <stdio.h>#include <stdlib.h>#include <math.h>

// Project Specific Includes#include "control.h"#include "compass.h"#include "gps_parse.h"#include "rs232.h"#include "lcd.h"#include "navigate.h"#include "ultrasonic.h"#include "timer.h"#include "util.h"

void Initalize(void);

#pragma config MCLRE = OFF // MCLR reset pin is Digital I/O#pragma config WDT = OFF // Disable the Watch dog#pragma config XINST = ON // Enable Extended Mode#pragma config PBADEN = OFF // Port B <4:0> are configured as digital I/O on reset

#pragma config IESO = OFF // use internal oscillator#pragma config OSC = INTIO67 // no oscillator on output pins#pragma config LVP = OFF // disable low voltage programming on portb pin 5

char *str;

void main (void){ float ActualAngle = 0; float TargetAngle = 0;

//These points represent the North East corner of engineering mall float dist_err; //The Square of the Difference Distances int Distance = 0;

// configure external LCD // We need to do this first, otherwise timer interrupts and // USART interrupts will mess up the initialization timing OpenXLCD();

Initalize();

/* Open the USART configured as

F-1


* 8N1, 19200 baud, in polled mode * Assumes Clock speed is 8 MHz */ Com_Init(); Configure_Sent();

gps_obj.position_obj.latitude[0] = '\0'; gps_obj.position_obj.longitude[0] = '\0';

//The car will perform this loop as long as it is powered on. while(1) {

//Send a pulse to Ultrasonic to Initiate measurementStartDistMeasure();Delay15ms();

//Update the LCD with fresh Data.RefreshLCD(ActualAngle, Distance);

ActualAngle = GetAngle();

str = Com_Rd_Term();update_gps_obj(str);

//Find target angle and approximate distance to target// TargetAngle = DetermineTargetAngle(&dist_err);

// Free the memory Com_Free_Mem();

//Distance is the distance of an object in inches * 100.Distance = GetDistMeasure();

Drive(Distance, ActualAngle); }}

// Initalizes the PIC18's internal oscillatorvoid Initalize(void){

//*** Initalize the Oscillator Settings ***// Configure internal oscillator for 32 MHz// Initalize Oscillator Settings with no prescallerOSCCONbits.SCS1 = 1;OSCCONbits.IRCF2 = 1;OSCCONbits.IRCF1 = 1;OSCCONbits.IRCF0 = 1;OSCTUNE |= 0x00; // Tune the oscillator to exactly 8 MHz

// wait for the oscillator to become stablewhile(!OSCCONbits.IOFS);

// Enalbe the PLL on the input channelOSCTUNEbits.PLLEN = 0;

/* Enable interrupt priority levels*/ RCONbits.IPEN = 1;

/* Enable all high priority interrupts */ INTCON = 0xC0; // Enable high and low priority interupts

// IPR1 Peripheral interrupt priority register

F-2


IPR1 = 0x02; // Set the Timer to high priority interrupt and all others to low

// Timer configuration registers PR2 = 100; //Sets PR2 register to 50t to compare -> .1mS interrupt T2CON = 0x04; //Turn Timer2 On //Sets prescaler to 1/16 ->.5Mhz,.002mS TMR2 = 0x00; //Clears TMR2 Register

// Port configuration registers TRISB = 0x00; //Sets Port B tristates to outputs PORTB = 0x00; //Clears PORTB

TRISC = 0xC1; //Sets Port bits 7,6 and 0 to inputs, other output PORTC = 0x00; //Clears PORTB

// PIR1bits.TMR2IF = 0; //Clears interrupt flag PIR1 = 0x00; // Clear all interupt flags // Enable the interupts // 0x22 to have the timer interrupt enabled PIE1 = 0x22; //Enables Rx interupt and TMR2 interrupt

CompassInit();}

COMPASS.H// Interface to the Compass Module

#ifndef COMPASS_H#define COMPASS_H

extern void CompassInit(void);extern float GetAngle(void);

#endif

COMPASS.C#include <p18cxxx.h>#include <delays.h>#include <math.h>

#include "compass.h"#include "util.h"

// Definitions#define Din PORTCbits.SDI#define Dout PORTCbits.SDO#define SCK PORTCbits.SCK#define S_EN PORTCbits.RC2#define cReset 0b0000#define Start 0b1000#define CheckStatus 0b1000#define Ready 0b1100

// variable declarationsint g_X; // g_X means global Xint g_Y;int xOffset = -2.5;int yOffset = -3;float xMag = 0; // magnitude of magnetic field in X directionint xSign = 0; // 0 corresponds to positive, 1 corresponds to negativefloat yMag = 0; // magnitude of magnetic field in Y directionint ySign = 0; // 0 corresponds to positive, 1 corresponds to negative

F-3


// Private Function Definitionsvoid Compass_Correct_Offsets(void);void Compass_Get_Axes (void);void CompassInit(void);float GetAngle(void);void GetAbsoluteX(void);void GetAbsoluteY(void);int ShiftIn(int length);void ShiftOut(int Data, int length);

/*****Subroutine - Compass_Correct_Offsets*********** This subroutine corrects cumulative magnetic field interference* that can come from sources such as the PCB, jumper wires, a * nearby battery, or a nearby current source. ***************************************************/void Compass_Correct_Offsets(){ g_X = g_X - xOffset; g_Y = g_Y - yOffset;}

void Compass_Get_Axes(void){

double pitch,roll; //x and y axis valuesint pitch_low, pitch_high; //the 8 low and 8 high bits of pitchint roll_low, roll_high; //the 8 low and 8 high bits of rollint temp;int x, y;

do{ S_EN = 0; ShiftOut(0b0000, 4); //Reset string S_EN = 1; Delay80clk(); S_EN = 0; ShiftOut(0b1000, 4); //Start measurement string

Delay15ms(); Delay15ms(); Delay15ms();

S_EN = 1; Delay80clk(); S_EN = 0; ShiftOut(0b1100,4); //Measurement status string temp = ShiftIn(4);} while (temp != 0b1100);

x = ShiftIn(11);y = ShiftIn(11);if (((x >> 10) & 0b00000000001) == 1)

g_X = x | 0xF800;else

g_X = x;

if (((y >> 10) & 0b00000000001) == 1)g_Y = y | 0xF800;

elseg_Y = y;

F-4


S_EN = 1;

}

float GetAngle(void){

float angle;float tmpX, tmpY;Compass_Get_Axes();Compass_Correct_Offsets();

tmpX = g_X;tmpY = g_Y;angle = atan2(-tmpY, tmpX) * 57.2957795;

if (angle < 0)angle += 360;

//Because car is turned s.t. the compass faces 90 deg left // of the front of the car, we want to add 90 deg to the angle

angle += 90; //Add 90 degreesif (angle > 360)

angle -= 360; //ensure that angle is not larger than 360

return angle;}

void GetAbsoluteX(void){

if (((g_X >> 15) & 0b0000000000000001) == 1){

xMag = ~g_X + 1;xSign = 1; //x is a negative number

}else{

xMag = g_X;xSign = 0; // x is a positive number

}

}

void GetAbsoluteY(void){

//Convert the Y value to format into LCDif (((g_Y >> 15) & 0b0000000000000001) == 1){

yMag = ~g_Y + 1;ySign = 1; //y is a negative number

}else{

yMag = g_Y;ySign = 0; //y is a positive number

}}

int ShiftIn(int length){

int ReceivedData = 0;int temp, i; for (i = (length-1); i >=0; i--)

F-5


{SCK = 1;temp = Din;ReceivedData |= temp << i;SCK = 0;

}return ReceivedData;

}

void ShiftOut(int Data, int length){

int temp, i; for (i = (length-1); i >= 0; i--){

SCK = 1;temp = (Data >> i) & 0b00000001;Dout = temp;SCK = 0;

}}

void CompassInit(void){ /*Digital compass related registers*/ TRISC |= 0x10; //enable SPI in SDO and SCK pins, set SPI as Input SSPCON1 = 0x00; //configure SCK,SDO,SDI as I/O port pins

S_EN = 1; //set the serial enable pin high.}

CONTROL.H// Interface for control module

#ifndef CONTROL_H#define CONTROL_H

extern void AdjustSteerAngle(float RealAngle, float TargetAngle);extern void Break(void);extern float DetermineTargetAngle(float f_targ_lat,

float f_targ_long,

float *dist_err);// sets the speed: -10 to -1 for reverse// 0 for stop// 1 to 10 for forwardextern void SetSpeed(int speed);extern void SetSteerAngle(int steer);

#endif

CONTROL.C#include <p18cxxx.h>#include <math.h>#include <delays.h>

#include "control.h"#include "timer.h"#include "gps_parse.h"

void AdjustSteerAngle(float RealAngle, float TargetAngle);void Break(void);

F-6


float DetermineTargetAngle(float f_targ_lat, float f_targ_long, float *dist_err);

void SetSpeed(int speed);void SetSteerAngle(int steer);

/************************************************** DetermineTargetAngle* This function will calculate the TargetAngle based* on the TargetLat, TargetLong compared with the * ActualLat, Actual Long ***************************************************/float DetermineTargetAngle(float f_targ_lat,

float f_targ_long, float *dist_err)

{ float LatDiff, LongDiff; float TargetAngle = 0; //Latitude is the Y component of coordinate LatDiff = f_targ_lat - gps_obj.position_obj.f_latitude;

//Longitude is the X component of coordinate LongDiff = f_targ_long - gps_obj.position_obj.f_longitude;

// 1/1.311 is 23.547/30.87 a correction factor to // convert the longitude to a distance. TargetAngle = atan2(-LongDiff,LatDiff) * 57.2957795;

if (TargetAngle < 0)TargetAngle = -TargetAngle;

elseTargetAngle = 360.0 - TargetAngle;

*dist_err = sqrt(pow(LatDiff,2) + pow(LongDiff,2)); return TargetAngle;}

void AdjustSteerAngle(float real_angle, float target_angle){

float AngleDiff;

AngleDiff = real_angle - target_angle;

// AngleDiff = target_angle - real_angle;

if(AngleDiff < 0.0)AngleDiff = 360.0 + AngleDiff;

/// left codeif((0.0 <= AngleDiff) && (AngleDiff < 180.0)){

if (AngleDiff < 10)SetSteerAngle(0);

else if (AngleDiff < 15)SetSteerAngle(-1);



F-7








elseSetSteerAngle(-10);

}else //Turn Right{

if (AngleDiff > 350)SetSteerAngle(0);

else if (AngleDiff >345)SetSteerAngle(1);

else if (AngleDiff >340)SetSteerAngle(2);

else if (AngleDiff > 335)SetSteerAngle(3);







elseSetSteerAngle(10);

}}

void SetSpeed(int speed){

if(speed >= 0){

if(g_speed < 30){

//If in reverse move directly to neutralg_speed = 30;

}else if(g_speed < (speed + 30)){

//If moving forward, incrementally increase speedg_speed++;

} else {g_speed = speed + 30;

}

} else if(speed < 0) {if(g_speed > 30)

Break();

F-8


g_speed = 30 + speed;}/* the following nested if checks if the vehicle is currently in a strong turning routine (left or right by more than 4. if so, the speed is maxed out to 33, this may help improve the snaking glitch *///Check if angle is turned hard to left or rightif ((g_steer_angle < 26) || (g_steer_angle > 34)){

//g_speed should be maxed outif (g_speed > 33)

g_speed = 33;}

}

void Break(void){

if(g_speed >= 31){

// First Breakg_speed = 20;// Wait 200 mSDelay10KTCYx(100);// set the throttle back to neturalg_speed = 30;// Wait ?? mSDelay10KTCYx(25);

}}

void SetSteerAngle(int steer){

g_steer_angle = 30 + -steer;}

GPS_PARSE.H#ifndef GPS_PARSE_H#define GPS_PARSE_H

// Put Public function prototypes hereextern unsigned char update_gps_obj(char []);extern void Configure_Sent(void);

// define the sentense types#define UNKNOWN (0)#define INVALID (0)#define GPRMC (1)#define GPGGA (2)#define GPGSA (3)#define GPVTG (4)#define ACPG1 (5)#define ACPG2 (6)

#define TRUE (1)#define FALSE (0)#define PASS (1)#define FAIL (0)#define SUCCESS (1)

F-9


#define VALID (1)#define INVALID (0)

// Quality Levels#define NO_FIX (0)#define NON_DIFF (1)#define DIFF_WASS (2)#define ESTIMATE (6)

#define NORTH (1)#define SOUTH (-1)#define EAST (1)#define WEST (-1)

struct position{ char latitude[11]; char N_S;

//double f_latitude; float f_latitude; char longitude[12]; // double d_longitude; char E_W; float f_longitude; char altitude[10]; // double f_altitude; char geodial_height[8];};

struct fix{ unsigned char valid; unsigned char mode; char quality; char num_sats; char hor_dilu[8]; // The Horizontal dilution of precision char date[8]; char time[9];};

struct telmetry{ char true_course[10]; char magnetic_course[10]; char speed_knots[7]; char speed_km_h[10]; char magnetic_var[10]; char magnetic_var_e_w;};

struct gps{ struct position position_obj; struct fix fix_obj; struct telmetry telemetry_obj;};

// Put Public data structures hereextern struct gps gps_obj;

#endif

F-10


GPS_PARSE.C#include <p18cxxx.h>#include <string.h>#include <stdlib.h>#include <usart.h>#include "rs232.h"#include "navigate.h"#include "util.h"#include "gps_parse.h"

struct gps gps_obj;

void parse_gprmc(char []);void parse_gpgga(char []);void parse_gpvtg(char []);void parse_acpg1(char []);void parse_acpg2(char []);unsigned char index_of_del(char str[]);unsigned char index_of_dec(char str[]);void Configure_Sent(void);

float Lat_To_Float(char str[], char n_s);float Long_To_Float(char str[], char e_w);

unsigned char ID_Type(char str[]);unsigned char VerifyCkSum(char str[]);

unsigned char update_gps_obj(char str[]){ unsigned char sentence_type; unsigned char index; // First verify the checksum if(!VerifyCkSum(str)) return (FAIL); // Checksum is valid // Identify the sent sentence type sentence_type = ID_Type(str); // get the index of the first comma // so that the parsers don't have to deal // with the leading identifier index = 1 + index_of_del(str); // the sentence passed the checksum // we will assume that it is valid switch(sentence_type) { case GPRMC: // parse the gprmc sentence parse_gprmc(&str[index]); break; case GPGGA: // parse the gpgga sentence parse_gpgga(&str[index]); break; // case GPGSA: // There is not parser written yet for this

F-11


// It could be useful for debuging but the // information will take up memory // break; case GPVTG: // parse the gpvtg sentence parse_gpvtg(&str[index]); break;

case ACPG1: // parse the acpg1 sentence // the acpg1 sentence is used to program the route parse_acpg1(&str[index]); break;

case ACPG2: // parse the acpg2 sentence // the acpg2 sentence is used to program the route parse_acpg2(&str[index]);

break;

default: return (FAIL); } return(SUCCESS);}

void parse_gprmc(char str[]){ // number of characters until the // delimiter unsigned char del = 0; unsigned char index = 0; char temp[13];

// Get offset of first comma del = index_of_del(str); // the first section is the time of fix s_strncpy(str, gps_obj.fix_obj.time, del); index += del + 1; // Get offset of 2nd comma del = index_of_del(&str[index]); // the 2nd string is position valid A, or V // if del is not 0 there is data here if(del) {

if(str[index] = 'A') gps_obj.fix_obj.valid = VALID;

elsegps_obj.fix_obj.valid = INVALID;

} index += del + 1; // Get offset of 3rd comma del = index_of_del(&str[index]); // third string is latitude s_strncpy(&str[index],gps_obj.position_obj.latitude,del); // ** s_strncpy(&str[index],temp,del); // covert this to a float will require changes later

F-12


// ** gps_obj.position_obj.f_latitude = atof(temp);

index += del + 1; // get offset of 4th comma del = index_of_del(&str[index]); // the 4th string is North of South // if del is not 0 there is data here if(del) { if(str[index] == 'N')

gps_obj.position_obj.N_S = NORTH; else if(str[index] == 'S')

gps_obj.position_obj.N_S = SOUTH; else

gps_obj.position_obj.N_S = INVALID; }

// Convert the latitude to a float gps_obj.position_obj.f_latitude = Lat_To_Float(gps_obj.position_obj.latitude,

gps_obj.position_obj.N_S);

index += del + 1;

// get offset of 5th comma del = index_of_del(&str[index]); // the 5th string is the longitude s_strncpy(&str[index], gps_obj.position_obj.longitude, del); index += del + 1; // get the offset of the 6th comma del = index_of_del(&str[index]); // the 6th string is East or West // if del is not 0 there should be data if(del) { if(str[index] == 'E')

gps_obj.position_obj.E_W = EAST; else if(str[index] == 'W')

gps_obj.position_obj.E_W = WEST; else

gps_obj.position_obj.E_W = INVALID; }

// Convert the longitude to a float gps_obj.position_obj.f_longitude = Long_To_Float(gps_obj.position_obj.longitude,

gps_obj.position_obj.E_W);

index += del + 1; // get the offset of the 7th comma del = index_of_del(&str[index]); // the 7th string is the speed over the ground in knots s_strncpy(&str[index], gps_obj.telemetry_obj.speed_knots, del); index += del + 1; // get the offset of the 8th comma del = index_of_del(&str[index]); // the 8th string is the course over the gound s_strncpy(&str[index], gps_obj.telemetry_obj.true_course, del); index += del + 1; // get the offset of the 9th comma

F-13


del = index_of_del(&str[index]); // the 9th string is the UTC date of fix ddmmyy s_strncpy(&str[index], gps_obj.fix_obj.date, del); index += del + 1; // get the offset of the 10th comma del = index_of_del(&str[index]); // the 10th string is the magnetic variation in degrees s_strncpy(&str[index], gps_obj.telemetry_obj.magnetic_var, del); index += del + 1; // get the offset of the 11th comma del = index_of_del(&str[index]); // the 11th comma is wether the magnetic variation is East or West // if del != 0 there is data if(del) { if(str[index] == 'E')

gps_obj.telemetry_obj.magnetic_var_e_w = EAST; else if(str[index] = 'W')

gps_obj.telemetry_obj.magnetic_var_e_w = WEST; else

gps_obj.telemetry_obj.magnetic_var_e_w = INVALID; }

// if the delmiter found was a * then there is no more data // otherwise the mode indicator is coming index += del; // no more data if(str[index] == '*') return; // still one more data index++; // Get the index of the terminating '*' // this has the same use as del so save the // variable del = index_of_del(&str[index]); // The last item is the Mode indicator if(del) { gps_obj.fix_obj.mode = str[index]; }}

void parse_gpgga(char str[]){ // We assume the caller has ripped the leading // $GPGGA, off the front of the string // number of characters until the // delimiter // thhis data is initalized when the first // comma is found unsigned char del; unsigned char index; char temp[13]; // ** double c_check;

// Get offset of first comma // the offset also eqauate to the number // of characters between delimiters del = index_of_del(str);

F-14


// The first item is the UTC position fix s_strncpy(str,gps_obj.fix_obj.time,del); index = del + 1;

del = index_of_del(&str[index]); // the 2nd item is the latitude s_strncpy(&str[index],gps_obj.position_obj.latitude,del); // **s_strncpy(&str[index],temp,del); // **gps_obj.position_obj.f_latitude = atof(temp); // ** c_check = gps_obj.position_obj.f_latitude;

index += del + 1; del = index_of_del(&str[index]); // the 3rd item is latitude N/S // if del is 0 there is no data if(del) { if(str[index] == 'N')

gps_obj.position_obj.N_S = NORTH; else if(str[index] == 'S')

gps_obj.position_obj.N_S = SOUTH; else

gps_obj.position_obj.N_S = INVALID; } else gps_obj.position_obj.N_S = INVALID;

// Convert the latitude to a float gps_obj.position_obj.f_latitude = Lat_To_Float(gps_obj.position_obj.latitude,

gps_obj.position_obj.N_S);

index += del + 1; del = index_of_del(&str[index]); // the 4th item is the longitude s_strncpy(&str[index],gps_obj.position_obj.longitude,del); index += del + 1; del = index_of_del(&str[index]); // the 5th item is the longitude E/W if(del) { if(str[index] == 'E')

gps_obj.position_obj.E_W = EAST; else if(str[index] = 'W')

gps_obj.position_obj.E_W = WEST; else

gps_obj.position_obj.E_W = INVALID; } else gps_obj.position_obj.E_W = INVALID;

// Convert the longitude to a float gps_obj.position_obj.f_longitude = Long_To_Float(gps_obj.position_obj.longitude,

gps_obj.position_obj.E_W); index += del + 1; del = index_of_del(&str[index]);

F-15


// the 6th item is the GPS quality // we are going to assume that the data is there // copy the data to temp for the conversion s_strncpy(&str[index],temp,del); gps_obj.fix_obj.quality = atob(temp);

index += del + 1; // the 7th item is the number of satellites del = index_of_del(&str[index]); // check that data is there s_strncpy(&str[index],temp,del); // covert the temp string to a byte gps_obj.fix_obj.num_sats = atob(temp); index += del + 1;

// the 8th item is the horizontial dilution del = index_of_del(&str[index]); s_strncpy(&str[index],gps_obj.fix_obj.hor_dilu, del); index += del + 1; // the 9th item is the antenna height(altitude) del = index_of_del(&str[index]); s_strncpy(&str[index],gps_obj.position_obj.altitude,del); index += del + 1; // the next character is a M just skip it index += 1 + index_of_del(&str[index]); // the 10 item is the geodial height del = index_of_del(&str[index]); s_strncpy(&str[index],gps_obj.position_obj.geodial_height,del); }

void parse_gpvtg(char str[]){ // We assume the caller has ripped the leading // $GPVTG, off the front of the string // number of characters until the // delimiter // this data is initalized when the first // comma is found unsigned char del; unsigned char index;

// Get offset of first comma // the offset eqauates to the number of characters // between delimiters del = index_of_del(str); // INITALIZES del // The first item is the True Course over ground s_strncpy(str,gps_obj.telemetry_obj.true_course,del); index = del + 1; // INTALIZES index

// Protocol specifies a T next, it's not wanted index += 1 + index_of_del(&str[index]);

// offset of the next delimiter del = index_of_del(&str[index]);

F-16


// The 2nd item is the magnetic course over gound s_strncpy(&str[index],gps_obj.telemetry_obj.magnetic_course,del); index += del + 1;

// Protocol specifies a M next, also not needed index += 1 + index_of_del(&str[index]);

// repeat the patern del = index_of_del(&str[index]); // The 3rd item is the speed over ground in Knots s_strncpy(&str[index],gps_obj.telemetry_obj.speed_knots,del); index += del + 1;

// Protocol specifies a N next, discard index += 1 + index_of_del(&str[index]); del = index_of_del(&str[index]); // The 4th item is the speed over ground in km_h s_strncpy(&str[index],gps_obj.telemetry_obj.speed_km_h,del); // there is potential for a 5th item is NMEA 0183 v. 2.30 is enabled // First a K, will come then the mode D = Diff, E = Estimate, N = INVALID }

// Finds the index of the comma delimiterunsigned char index_of_del(char str[]){ unsigned char del = 0; // we don't want to overflow if // the data is bad while(del != 255 && str[del] != ',' && str[del] != '*') del++; return (del);}

// Finds the index of a decimialunsigned char index_of_dec(char str[]){

unsigned char dec = 0;

// we don't want to overflow if the data is badwhile(dec != 255 && str[dec] != '.')

dec++;

return (dec);}

unsigned char ID_Type(char str[]){ char msg_str[7];

// copy the string, dest, source s_strncpy(str, msg_str, 6); // Throws warnings becuase of the large memory model

// Compare the sent string with the

F-17


// following four strings if(strcmppgm2ram(msg_str,"$GPRMC") == 0) return (GPRMC); if(strcmppgm2ram(msg_str,"$GPGGA") == 0) return (GPGGA); if(strcmppgm2ram(msg_str,"$GPGSA") == 0) return (GPGSA);

if(strcmppgm2ram(msg_str,"$GPVTG") == 0) return (GPVTG);

if(strcmppgm2ram(msg_str,"$ACPG1") == 0) return (ACPG1); if(strcmppgm2ram(msg_str,"$ACPG2") == 0) return (ACPG2);

return (UNKNOWN); }

unsigned char VerifyCkSum(char str[]) { unsigned char i = 0; // Index Var unsigned char cal_sum = 0; char c_byte1 = 0; char c_byte2 = 0; unsigned char in_sum = 0; unsigned char str_len = 0; char dbg_tmp[GPS_MAX_CHARS];

// Compiler won't optomize this out str_len = s_strlen(str);

// skip the $ character for(i = 1; i < str_len; i++) { if(str[i] == '*')

break; cal_sum = cal_sum ^ str[i]; }

// the index should now be on '*', move to first // byte of check sum i++; // Could do error checking here, assuming that c_byte1 = htoi(str[i]); c_byte2 = htoi(str[i+1]); // check that bytes were valid, return false // checksums didn't match, 1 was invalid if(c_byte1 < 0 || c_byte2 < 0) return (FALSE); // shift c_byte1 left 4, equivalent to multiplying by 16 c_byte1 = c_byte1 << 4; // the sent checksum in_sum = c_byte1 + c_byte2;

F-18


// check that they match if(in_sum != cal_sum) {

s_strncpy(str, dbg_tmp, GPS_MAX_CHARS);

return (FALSE); }

// the inputed checksums matched return (TRUE);}

// Configures the sentences sent by the Garmin GPS18 unitvoid Configure_Sent(void){

// Disable all output sentencesputrsUSART ((const far rom char *)"$PGRMO,,2\r\n");

// Enable GPGGA sentenceputrsUSART ((const far rom char *)"$PGRMO,GPGGA,1\r\n");}

// Convert the longitude sent by the GPS to decimal degrees and// and then into a floatfloat Lat_To_Float(char str[], char n_s){

// the latitude is of format// ddmm.mmmm with leading zeros

float f_lat; // the latitudeunsigned char dec_index; // the longitudechar str_deg[5];

// find where the decimal is in the stringdec_index = index_of_dec(str);

// 2 characters before this is the begining of the minutesdec_index = dec_index - 2;

// store the latitude in degree decimals// minutes need to be converted to degreesf_lat = (1/60.0)* atof(&str[dec_index]);

s_strncpy(str, str_deg, dec_index);

f_lat += atof(str_deg);

// sothern points are negativeif(n_s == SOUTH)

f_lat = -f_lat;

return (f_lat);}

// Convet the longitude sent by the GPS to decimal degrees// and then into a floatfloat Long_To_Float(char str[], char e_w){

// the latitude is of format// ddmm.mmmm with leading zeros

float f_long; // the latitudeunsigned char dec_index; // the longitude

F-19


char str_deg[5];

// find where the decimal is in the stringdec_index = index_of_dec(str);

// 2 characters before this is the begining of the minutesdec_index = dec_index - 2;

// store the latitude in degree decimals// minutes need to be converted to degreesf_long = (1/60.0)* atof(&str[dec_index]);

s_strncpy(str, str_deg, dec_index);

f_long += atof(str_deg);

// sothern points are negativeif(e_w == WEST)

f_long = -f_long;

return (f_long);}

void parse_acpg1(char str[]){

// the acpg1 string contains three items// <Point Num>,<Longitude>,<Latitude>*<CHKSUM>

// this data is initalized when the first // comma is found unsigned char del; unsigned char index;

char waypoint_num;char str_tmp[15]; // temporary string to hold the

// ASCI data before data type conversion

float f_lat;float f_long;

// Get offset of first comma // the offset eqauates to the number of characters // between delimiters del = index_of_del(str); // INITALIZES del // The first item is the waypoint number s_strncpy(str,str_tmp,del);

// convert the wapoint number to an integerwaypoint_num = atob(str_tmp);

// the waypoint number will be the indexer for the waypoint arraywaypoint_num--;

// advance the index to the next item// skip the comma, (+1)index = del + 1; // Initalize the index

// Get the offset of the second comma// this offset is relative to indexdel = index_of_del(&str[index]);

// the 2nd item is the latitudes_strncpy(&str[index], str_tmp, del);

F-20


// store the latitude for in the route objectf_lat = atof(str_tmp);route_obj.waypoint_obj[waypoint_num].f_latitude =

atof(str_tmp);

// advance the index to the next itemindex += del + 1;

// Get the offset of the 3rd commadel = index_of_del(&str[index]);

// the 3rd item is the longitude

s_strncpy(&str[index], str_tmp, del);

// store the longitude in the route objectf_long = atof(str_tmp);route_obj.waypoint_obj[waypoint_num].f_longitude =

atof(str_tmp);

// Send an ACK indicating that the transmission was successfulSend_ACK();

}

void parse_acpg2(char str[]){

// the acpg2 string contains three items// <Num Waypoints>,<Loops>*<CHKSUM>

// this data is initalized when the first // comma is found unsigned char del; unsigned char index;

char str_tmp[4]; // temporary string

// get the first comma indexdel = index_of_del(str);

// copy out the number of waypoinss_strncpy(str, str_tmp, del);

// convert the number of waypoints to an int// and storeroute_obj.num_waypoints =

atob(str_tmp);

// the index is where we will start from on the// next waypointindex = del + 1;

// get the index of the next commadel = index_of_del(&str[index]);

// next field is sets if the course loopss_strncpy(&str[index], str_tmp, del);

// set the 0 or 1 for if it loopsroute_obj.loops = atob(str_tmp);

Send_ACK();}

F-21


LCD.H// Interface for the LCD module

#ifndef LCD_H#define LCD_H

/* Interface type 8-bit or 4-bit * For 8-bit operation uncomment the #define BIT8 *//* #define BIT8 */

/* When in 4-bit interface define if the data is in the upper * or lower nibble. For lower nibble, comment the #define UPPER *//* USE THIS CODE WHEN CONNECTED TO PCB */

//#ifdef AUTOCAR_PCB#define UPPER // DATA_PORT defines the port to which the LCD data lines are connected #define DATA_PORT PORTA#define TRIS_DATA_PORT TRISA

// CTRL_PORT defines the port where the control lines are connected.// These are just samples, change to match your application.

#define RW_PIN PORTBbits.RB1 // PORT for RW #define TRIS_RW DDRBbits.RB1 // TRIS for RW #define RS_PIN PORTBbits.RB0 // PORT for RS #define TRIS_RS DDRBbits.RB0 // TRIS for RS #define E_PIN PORTBbits.RB2 // PORT for E #define TRIS_E DDRBbits.RB2 // TRIS for E

// CTRL_PORT defines the port where the control lines are connected.// These are just samples, change to match your application.///* Display ON/OFF Control defines */#define DON 0b00001111 /* Display on */#define DOFF 0b00001011 /* Display off */#define CURSOR_ON 0b00001111 /* Cursor on */#define CURSOR_OFF 0b00001101 /* Cursor off */#define BLINK_ON 0b00001111 /* Cursor Blink */#define BLINK_OFF 0b00001110 /* Cursor No Blink */

/* Cursor or Display Shift defines */#define SHIFT_CUR_LEFT 0b00010011 /* Cursor shifts to the left */#define SHIFT_CUR_RIGHT 0b00010111 /* Cursor shifts to the right */#define SHIFT_DISP_LEFT 0b00011011 /* Display shifts to the left */#define SHIFT_DISP_RIGHT 0b00011111 /* Display shifts to the right */

/* Function Set defines */#define FOUR_BIT 0b00101111 /* 4-bit Interface */#define EIGHT_BIT 0b00111111 /* 8-bit Interface */#define LINE_5X7 0b00110011 /* 5x7 characters, single line */#define LINE_5X10 0b00110111 /* 5x10 characters */#define LINES_5X7 0b00111011 /* 5x7 characters, multiple line */

#define PARAM_SCLASS auto#define MEM_MODEL far /* Change this to near for small memory model */

extern void RefreshLCD(float angle, int dist);/* OpenXLCD

F-22


* Configures I/O pins for external LCD */extern void OpenXLCD(void);

/* DefaultLCD * puts initial text onto lcd */

extern void DefaultLCD(void);

/* SetCGRamAddr * Sets the character generator address */extern void SetCGRamAddr(PARAM_SCLASS unsigned char);

/* SetDDRamAddr * Sets the display data address */extern void SetDDRamAddr(PARAM_SCLASS unsigned char);

/* BusyXLCD * Returns the busy status of the LCD */extern unsigned char BusyXLCD(void);

/* ReadAddrXLCD * Reads the current address */extern unsigned char ReadAddrXLCD(void);

/* ReadDataXLCD * Reads a byte of data */extern char ReadDataXLCD(void);

/* WriteCmdXLCD * Writes a command to the LCD */extern void WriteCmdXLCD(PARAM_SCLASS unsigned char);

/* putsXLCD * Writes a string of characters to the LCD */extern void putsXLCD(PARAM_SCLASS char *);

/* putrsXLCD * Writes a string of characters in ROM to the LCD */extern void putrsXLCD(PARAM_SCLASS const MEM_MODEL rom char *);

extern void Write_LCD_Str_RAM(unsigned char Daddr, const char str[]);extern void Write_LCD_Str_ROM(unsigned char Daddr, const rom char *str);

#endif

LCD.C#include <p18cxxx.h>#include <delays.h>#include <string.h>#include <stdlib.h>#include "lcd.h"#include "util.h"#include "gps_parse.h"

F-23


void DefaultLCD(void);void DisplayDistance(int dist);void DisplayX(float );void DisplayY(float );void DisplayAngle(float );void clear_lcd(int line);void putcXLCD(char data);void SetDDRamAddr(unsigned char DDaddr);void OpenXLCD(void);void RefreshLCD(float angle, int dist);

void Write_LCD_Str_RAM(unsigned char Daddr, const char str[]);void Write_LCD_Str_ROM(unsigned char Daddr, const rom char *str);

void RefreshLCD(float angle, int dist){

char NumSat[2];

DisplayAngle(angle);DisplayDistance(dist);Write_LCD_Str_RAM(0x55, gps_obj.position_obj.latitude);Write_LCD_Str_RAM(0x15, gps_obj.position_obj.longitude);Write_LCD_Str_RAM(0x0C, btoa(gps_obj.fix_obj.num_sats, NumSat));

}/********************************************************************* Function Name: DefaultXLCD ** Return Value: void ** Parameters: none

** Description: This routine place the initial start text ** onto the LCD display *********************************************************************/void DefaultLCD(void){

//Write the permanent characters to LCD (these will not change)Write_LCD_Str_ROM(0x00, "angle=");Write_LCD_Str_ROM(0x0A, "s=");Write_LCD_Str_ROM(0x40, "distance=");Write_LCD_Str_ROM(0x10, "Long=");Write_LCD_Str_ROM(0x50, " Lat=");

}

void DisplayDistance(int dist){

int value[5];value[4] = dist % 10;dist = (dist - value[4]) * .1; value[3] = dist % 10;dist = (dist - value[3]) * .1;value[2] = dist % 10;dist = (dist - value[2])* .1;value[1] = dist % 10;dist = (dist - value[1])* .1;value[0] = dist % 10;

SetDDRamAddr(0x49);putcXLCD('0' + value[0]);putcXLCD('0' + value[1]);putcXLCD('0' + value[2]);putcXLCD('.');putcXLCD('0' + value[3]);putcXLCD('0' + value[4]);

F-24


}

void DisplayX(float xMag){ //Convert the X value to format into LCD int value[4]; int temp;

temp = xMag;value[3] = temp % 10;temp = (temp - value[3]) * .1;value[2] = temp % 10;temp = (temp - value[2])* .1;value[1] = temp % 10;temp = (temp - value[1])* .1;value[0] = temp % 10;putcXLCD('0' + value[0]);putcXLCD('0' + value[1]);putcXLCD('0' + value[2]);putcXLCD('0' + value[3]);

}

void DisplayY(float yMag){ int value[4]; int temp;

temp = yMag;value[3] = temp % 10;temp = (temp - value[3]) * .1;value[2] = temp % 10;temp = (temp - value[2])* .1;value[1] = temp % 10;temp = (temp - value[1])* .1;value[0] = temp % 10;

putcXLCD('0' + value[0]);putcXLCD('0' + value[1]);putcXLCD('0' + value[2]);putcXLCD('0' + value[3]);

}

void DisplayAngle(float angle){ int value[3]; int temp;

temp = angle;value[2] = temp % 10;temp = (temp - value[2])* .1;value[1] = temp % 10;temp = (temp - value[1])* .1;value[0] = temp % 10;SetDDRamAddr(0x06);putcXLCD('0' + value[0]);putcXLCD('0' + value[1]);putcXLCD('0' + value[2]);

}

void OpenXLCD(void){ DATA_PORT &= 0xf0; TRIS_DATA_PORT |= 0x0f; TRISB = 0x00;

F-25


TRIS_RW = 0; // All control signals made outputs TRIS_RS = 0; TRIS_E = 0; RW_PIN = 0; // R/W pin made low RS_PIN = 0; // Register select pin made low E_PIN = 0; // Clock pin made low

// Delay for 15ms to allow for LCD Power on reset Delay15ms(); Delay15ms(); // Setup interface to LCD // 4-bit mode interface // Lower nibble interface TRIS_DATA_PORT &= 0x0f; //Data port pins set as output DATA_PORT &= 0x0f; DATA_PORT |= 0b00100000; // Function set cmd(4-bit interface)

E_PIN = 1; // Clock the cmd in Delay80clk(); E_PIN = 0;

DATA_PORT &= 0x0f; // Delay for at least 4.1ms Delay5ms();

// Setup interface to LCD// 4-bit interface

// Lower nibble interface DATA_PORT &= 0x0f; // Function set cmd(4-bit interface) DATA_PORT |= 0b00100000;

E_PIN = 1; // Clock the cmd in Delay80clk(); E_PIN = 0;

DATA_PORT &= 0x0f;

// Delay for at least 100us Delay80clk();

Delay80clk();Delay80clk();

// Setup interface to LCD // 4-bit interface // Lower nibble interface DATA_PORT &= 0x0f; // Function set cmd(4-bit interface) DATA_PORT |= 0b10000000;

E_PIN = 1; // Clock cmd in Delay80clk(); E_PIN = 0; DATA_PORT &= 0x0f;

//Display on/off control Delay5ms(); DATA_PORT &= 0x0f; DATA_PORT |= 0b00000000;

E_PIN = 1; // Clock cmd in Delay80clk(); E_PIN = 0;

F-26


DATA_PORT &= 0x0f;

Delay80clk(); Delay80clk(); Delay80clk();

DATA_PORT &= 0x0f; DATA_PORT |= 0b11000000; E_PIN = 1; // Clock cmd in Delay80clk(); E_PIN = 0; DATA_PORT &= 0x0f;


//Delay5ms(); //Entr Mode Set DATA_PORT &= 0x0f; DATA_PORT |= 0b00000000; E_PIN = 1; // Clock cmd in Delay80clk(); E_PIN = 0; DATA_PORT &= 0x0f;



//Write data to CGRAM/DDRAM Delay80clk(); Delay80clk(); Delay80clk(); Delay5ms();

//RS_PIN = 1; //RW_PIN = 0;




F-27


Delay15ms(); Delay15ms(); Delay15ms(); DefaultLCD(); Delay10KTCYx(100); //Waste .5 sec Delay10KTCYx(100); //Waste .5 sec

return;}

/********************************************************************* Function Name: WriteDataXLCD ** Return Value: void ** Parameters: data: data byte to be written to LCD ** Description: This routine writes a data byte to the ** Hitachi HD44780 LCD controller. The user ** must check to see if the LCD controller is ** busy before calling this routine. The data ** is written to the character generator RAM or** the display data RAM depending on what the ** previous SetxxRamAddr routine was called. *********************************************************************/void putcXLCD(char data){// 4-bit interface#ifdef UPPER // Upper nibble interface TRIS_DATA_PORT &= 0x0f; DATA_PORT &= 0x0f; DATA_PORT |= data&0xf0;#else // Lower nibble interface TRIS_DATA_PORT &= 0xf0; DATA_PORT &= 0xf0; DATA_PORT |= ((data>>4)&0x0f);#endif RS_PIN = 1; // Set control bits RW_PIN = 0; Delay80clk(); E_PIN = 1; // Clock nibble into LCD Delay80clk(); E_PIN = 0;#ifdef UPPER // Upper nibble interface DATA_PORT &= 0x0f; DATA_PORT |= ((data<<4)&0xf0);#else // Lower nibble interface DATA_PORT &= 0xf0; DATA_PORT |= (data&0x0f);#endif Delay80clk(); E_PIN = 1; // Clock nibble into LCD Delay80clk(); E_PIN = 0;#ifdef UPPER // Upper nibble interface TRIS_DATA_PORT |= 0xf0;#else // Lower nibble interface TRIS_DATA_PORT |= 0x0f;#endif return;}

/********************************************************************* Function Name: SetDDRamAddr ** Return Value: void *

F-28


* Parameters: CGaddr: display data address ** Description: This routine sets the display data address ** of the Hitachi HD44780 LCD controller. The ** user must check to see if the LCD controller** is busy before calling this routine. *********************************************************************/void SetDDRamAddr(unsigned char DDaddr){// 4-bit interface#ifdef UPPER // Upper nibble interface TRIS_DATA_PORT &= 0x0f; // Make port output DATA_PORT &= 0x0f; // and write upper nibble DATA_PORT |= ((DDaddr | 0b10000000) & 0xf0);#else // Lower nibble interface TRIS_DATA_PORT &= 0xf0; // Make port output DATA_PORT &= 0xf0; // and write upper nibble DATA_PORT |= (((DDaddr | 0b10000000)>>4) & 0x0f);#endif RW_PIN = 0; // Set control bits RS_PIN = 0; Delay80clk(); E_PIN = 1; // Clock the cmd and address in Delay80clk(); E_PIN = 0;#ifdef UPPER // Upper nibble interface DATA_PORT &= 0x0f; // Write lower nibble DATA_PORT |= ((DDaddr<<4)&0xf0);#else // Lower nibble interface DATA_PORT &= 0xf0; // Write lower nibble DATA_PORT |= (DDaddr&0x0f);#endif Delay80clk(); E_PIN = 1; // Clock the cmd and address in Delay80clk(); E_PIN = 0;#ifdef UPPER // Upper nibble interface TRIS_DATA_PORT |= 0xf0; // Make port input#else // Lower nibble interface TRIS_DATA_PORT |= 0x0f; // Make port input#endif return;}

void Write_LCD_Str_ROM(unsigned char Daddr, const rom char *str){

char str_ram[17];strcpypgm2ram(str_ram, str);Write_LCD_Str_RAM(Daddr, str_ram);

}

void Write_LCD_Str_RAM(unsigned char Daddr, const char str[]){

int n = 0;

SetDDRamAddr(Daddr);while (str[n] != '\0'){

putcXLCD(str[n]);n++;

}

}

F-29


NAVIGATE.H#ifndef NAVIGATE_H#define NAVIGATE_H

struct waypoint{ float f_latitude;

float f_longitude;};

struct route{

unsigned char num_waypoints;unsigned char loops;struct waypoint waypoint_obj[16];

};

#define TRUE (1)#define FALSE (0)

// Define External Functionsextern void Drive(int dist, float f_actual_angle);

// Define External Data Structurs// the route_obj is used by the parser to set the waypointsextern struct route route_obj;

#endif

NAVIGATE.C#include <p18cxxx.h>#include <Delays.h>// Appication Header Files#include "compass.h"#include "control.h"#include "gps_parse.h"#include "navigate.h"#include "ultrasonic.h"#include "util.h"#include "timer.h"

#define ERR_RADIUS (.00002)

void Backup(void);void StraightenOut(void);void Drive(int dist, float f_actual_angle);

//Initialize structure for 0 waypoints, No loopingstruct route route_obj = {0, FALSE};

void Drive(int dist, float f_actual_angle){

static unsigned char i = 0;float f_target_angle;float f_dist_err;int i_dist;

//Find target angle and approximate distance to targetf_target_angle = DetermineTargetAngle(route_obj.waypoint_obj[i].f_latitude,

route_obj.waypoint_obj[i].f_longitude,&f_dist_err);

F-30


// if the run/stop switch is set to stop// set the motor speed to zeroif(PORTCbits.RC0 == 1 || (gps_obj.fix_obj.num_sats < 4)){

SetSpeed(0);return; // there is nothing left to do

}

// Avoid Obsticaleif(dist < 4200){

// Start a Distance MeasurementStartDistMeasure();Break();i_dist = GetDistMeasure();

// check if the obstacale is still thereif(i_dist < 4200){

// reverseBackup();StraightenOut();

}return;

}

// adjust steer angleAdjustSteerAngle(f_actual_angle, f_target_angle);

if(f_dist_err < ERR_RADIUS){

// increment to the next waypointi++;if(i == route_obj.num_waypoints){

// if loops is set to true go back to the first waypoint// otherwise stopif(route_obj.loops == TRUE){

i = 0;} else {

i--;SetSpeed(0);

}}

} else {// speed is only set to forward hereif(dist < 7200)

SetSpeed(2);else

SetSpeed(5);}

}

void StraightenOut(void){

int Distance = 0;

SetSteerAngle(0);

//reset global time out valueg_reverse_time_out = 0;

F-31


do{ if(PORTCbits.RC0 == 1)

SetSpeed(0);else

SetSpeed(5); StartDistMeasure();

Delay15ms();Delay15ms();Delay15ms();Distance = GetDistMeasure();Delay15ms();// If there is another object in path,

// return to original navigation code.if (Distance < 4200)

return;//time out increments every .05 ms} while (g_reverse_time_out < 45000);

SetSpeed(0);}

void Backup(void){

// if currently facing leftif (g_steer_angle >= 30){

//turn rightSetSteerAngle(9);

}else{

//turn leftSetSteerAngle(-9);

}//Reset the global time out value to zerog_reverse_time_out = 0;do{

if(PORTCbits.RC0 == 1)SetSpeed(0);

elseSetSpeed(-4);

Delay5ms();//time out increments every .05ms} while (g_reverse_time_out < 22500);SetSpeed(0);

}

RS232.H// Functions to interface with RS232

#ifndef RS232_H#define RS232_H

#define GPS_MAX_CHARS (85) // the maximum length of a sentence // from the GPS unit

void Com_Init(void);void Com_Close(void);char *Com_Rd_Term(void);void Com_Free_Mem(void);extern void Send_ACK(void);

F-32


#endif

RS232.C// Library Includes#include <usart.h>#include <p18cxxx.h>

// Application Includes#include "rs232.h"

static char gps_buf[2][GPS_MAX_CHARS]; // Store the '\r\n" terminated string // read from the GPS

receiverstatic char gps_mutex[2] = {0, 0}; // to prevent data modification when other processes are

// using itstatic unsigned char data_ready_flag = 0; // a flag to set when the data is readystatic unsigned char ready_index = 0; // which buffer the data is ready in

static unsigned char rd_index = 0; // the index the buffer is reading intostatic unsigned char rd_buf = 0; // the buffer the interupt is reading into// we need a counter to keep track of which buffer the parser is usingstatic unsigned char parse_index = 0;

void rx_handler (void);void Send_ACK(void);

// low priority interupt#pragma code rx_int = 0x18void rx_int (void){ _asm goto rx_handler _endasm}#pragma code // Return to default code section

// Declare the function rx_handler to be a high priority interupt#pragma interruptlow rx_handlervoid rx_handler (void){

// 0 indicates that the buffer has not yet been choosen// anything but 0 means it has// This code will only excute on a buffer switchif(rd_index == 0){

// the buffer was switched at the end of the last call// this tests if the mutex for the new buffer is taken// IF it is that means that the gps_parser is still reading from// the old buffer so write the data to the same buffer again// hopefully when this write is complete the gps_parser will// be ready to parse it... while(gps_mutex[rd_buf]){

// change back to the old buffer

rd_buf = !rd_buf;

/* we chould test if this mutex is taken, but if it is that would mean that the parser is reading from two buffers at once impossible or bug */

F-33


}

// take the mutexgps_mutex[rd_buf] = 1;

}

// most of the time the if statements will NOT execute// and this line does the bulk of the work

// read from the SCI into the buffergps_buf[rd_buf][rd_index] = ReadUSART();

// the following will cause the buffer to switch// in doing so the current buffer being read from// will be '\0' terminated an the mutex will be released

if(gps_buf[rd_buf][rd_index] == '\n' || rd_index == (GPS_MAX_CHARS)) {

// rd_index - 1 contains a '\r' set this to a '\0'// NULL terminating the stringgps_buf[rd_buf][rd_index-1] = '\0';// release the current mutex so reading can begingps_mutex[rd_buf] = 0;

// set the buffer flag to the buffer that is fullready_index = rd_buf;

// data is readydata_ready_flag = 1;

// reset the indxerrd_index = 0;// go to the next buffer// we don't need to do this it will cycle if the mutex is takenrd_buf = !rd_buf; // there is only 2; cool trick

} else {// increment the counter for the next byterd_index++;

}

}

// This will need to be modifed// for now just setup the mutex grap for testingchar * Com_Rd_Term(void){ // spin wait until one of the flags shows that

// data is ready; sping waiting is BAD while(!data_ready_flag);

// there is data, claim the mutex for the ready datagps_mutex[ready_index] = 1;// set the data ready flag to 0data_ready_flag = 0;// the index we are parsing is the same as the ready indexparse_index = ready_index;

// if the first buffer is full, grab its mutexif(!parse_index){

// data is in buffer 1return(&gps_buf[0][0]);

F-34


} else {// data must be in buffer 2return(&gps_buf[0][0] + GPS_MAX_CHARS*sizeof(char));

}}

void Com_Free_Mem(void){

// release the mutexgps_mutex[parse_index] = 0;

}

void Com_Init(void){ //*** Initalize the UART ***

// Even though the PLL is enabled the 25 is calculated// off the 8 MHz clock// this configures the UART for 19200 baud OpenUSART (USART_TX_INT_OFF &

USART_RX_INT_ON & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_HIGH, 25);

// Was 25, Oscillator is out of calibration so we now need 22}

void Com_Close(void){ // Close the file pointer // and the file discriptor CloseUSART();}

void Send_ACK(void){

// Write an ACK characterWriteUSART(0x06);

}

TIMER.H// Interface to the timer module

#ifndef RS232_H#define RS232_H

extern unsigned int g_reverse_time_out;extern unsigned short int g_steer_angle;extern unsigned short int g_speed_status;extern unsigned short int g_speed;extern unsigned int g_num_pulses;

#endif

TIMER.C// Module related to timer interupts#include "timer.h"#include <p18cxxx.h>

unsigned int count = 0; // Moved to Timer.c

unsigned int g_reverse_time_out;unsigned int g_num_pulses;

F-35


unsigned short int g_steer_angle = 30;unsigned short int g_speed_status = 0;unsigned short int g_speed = 30;

void TimerInterruptHandler(void);

#pragma code InterruptVectorHigh = 0x08void InterruptVectorHigh (void){ _asm goto TimerInterruptHandler //jump to interrupt routine

// this is a high priority interupt _endasm}#pragma code

// Main Timer Interupt#pragma interruptlow TimerInterruptHandlervoid TimerInterruptHandler(void){

// adjusts the PWM width(duty) for the steer angleif(count == g_steer_angle){

PORTBbits.RB3 = 0;}

// adjusts the PWM width(duty) for the electronic speed controllerif(count == g_speed){

PORTBbits.RB4 = 0;}

if (PORTBbits.RB5 == 1)g_num_pulses++;

// 400 represents the PWM period (20 mS)if(count == 392){

// end of PWM cycle, reset the countercount = 0;// set the output signals to highPORTBbits.RB3 = 1;PORTBbits.RB4 = 1;

}

g_reverse_time_out++;count++;

// Reset the interupt flagPIR1bits.TMR2IF = 0;

}

ULTRASONIC.H// Interface functions for ultrasonic module

#ifndef ULTRASONIC_H#define ULTRASONIC_H

extern void StartDistMeasure(void);extern int GetDistMeasure(void);

#endif

F-36


ULTRASONIC.C#include <p18cxxx.h>#include "timer.h"#include "util.h"

void StartDistMeasure(void);int GetDistMeasure(void);

//Get distance sensor readingvoid StartDistMeasure(){

// start first pulse for ultrasonic reading TRISB &= 0b11011111; // Set Port B pin 5 is outputPORTBbits.RB5 = 1;Delay80clk();PORTBbits.RB5 = 0;//Num pulses counts the number of .05 ms interupts receivedg_num_pulses = 0;TRISB |= 0b00100000; // 00100000 - set Port B pin 5 as an input

}

// Must be called 20 mS after cll to StartDistMeasure()int GetDistMeasure(void){

/* sound travels at 1130 feet per sec * each pulse is .05 ms

* (#pulses * .05ms * 1.130 ft/ms * 12 inch/ft) / 2 = distance of object* can be simplified as #pulses * .339 ~= .34* multiplier = 0x22;*/

return (g_num_pulses * 0x22);}

UTIL.H

#ifndef UTIL_H#define UTIL_H

// Put public function prototypes here// Delaysextern void Delay80clk(void);extern void Delay15ms(void); // minimum 15msextern void Delay5ms(void); // minimum 5ms

// String Related utilitiesextern char htoi(char );extern char s_strcmp(const char str1[], const char str2[]);extern void s_strncpy(char from_str[], char to_str[], unsigned char n);extern unsigned char s_strlen(char str[]);#endif

UTIL.C#include <delays.h>#include "util.h"

void Delay80clk(void);void Delay15ms(void); // minimum 15msvoid Delay5ms(void); // minimum 5ms

F-37


// String Related utilitieschar htoi(char );char s_strcmp(const char str1[], const char str2[]);void s_strncpy(char from_str[], char to_str[], unsigned char n);unsigned char s_strlen(char str[]);

// Performs an ASCII to int// converstion for a signle hex charchar htoi(char c){ c = c - 48; // C is less than 48, invalid if(c < 0) return (-1); // valid if(c <= 9) return (c); // C is between 58 & 63, invalid if(c < 17) return (-1); c = c - 7; // C is greater than 70 if(c > 15) return (-1);

// valid return (c);}

char s_strcmp(const char str1[], const char str2[]){ char str1_len; char str2_len; unsigned char i;

for(i = 0; i < 255; i++) {

if(str1[i] < str2[i])

{ return (-1);}

if(str1[i] > str2[i]){ return (1);}

// if str1 is 0 str2 must be zero // since they are equal if(str1[i] == 0)

return (0); } // the two strings are equal as far as this // simple function can tell return (0);}

F-38


void s_strncpy(char from_str[], char to_str[], unsigned char n){ unsigned char i;

for(i = 0; i < n; i++) { to_str[i] = from_str[i]; if(from_str[i] == '\0')

return; } // Null terminate the string to_str[i] = '\0';}

unsigned char s_strlen(char str[]) { unsigned char counter; for(counter = 0; counter < 255; counter++)

{ if(str[counter] == 0) { return (counter +1); }}

return(255);}

/*-------------------------------------------------------------------------*/

void Delay80clk(void){ Delay10TCYx(0x2); //delays 20 cycles return;}

void Delay15ms(void) // minimum 15ms{ Delay1KTCYx(0x10); // 1000TCY * 20return;}

void Delay5ms(void) // minimum 5ms{ Delay100TCYx(0x35); // 100TCY * 55 return;}

F-39


Appendix G: FMECA Worksheet

Power SubsystemFailure

No.Failure Mode Possible Causes Failure Effects Method of

DetectionCriticality Remarks

1 No output Shorted output by capacitors or wire, Open input, Regulator Failure

No damage Vehicle does not operate

2 Regulator calculated to have 1.895 failures per 10^6 hours

2 High Voltage Regulator Failure, short from input to output

Damage to all subsystems

Vehicle does not operate, smoke

3 Regulator calculated to have 1.895 failures per 10^6 hours

3 Noise Output capacitor failure, input capacitor failure, regulator failure

Unknown Unknown 2 Noise does not cause damage.

Sensor SubsystemFailure



1 GPS failure Inclement weather, Antenna/Receiver failure, open circuit, short circuit

Vehicle does not follow course

GPS coordinates incorrect/absent on LCD

2-3 2 if weather/antenna problems, 3 if device failure

G-1


2 Ultrasonic Sensor Failure

Device Failure, open circuit, short circuit

Vehicle does not stop for objects

Collision 4

3Digital Compass Failure

Device Failure, open circuit, short circuit, magnetic interference

Vehicle goes in incorrect direction or circles

Incorrect heading displayed

2-3 2 for temporary interference, 3 for all other cases.

Output SubsystemFailure



1 Motor Outputs connected to +5V

Wire shorts, software defect

Motors damaged Vehicle no longer moves

3 Assumed that 5V short will damage motors, internal protection unknown

2 Motor Outputs connected to ground

Wire shorts, software defect, processor defect

Unknown Vehicle no longer moves

2 Assumed that GND short will not damage motors and that after short is removed vehicle will function

3LCD Failure Wire Shorts,

Controller FailureLCD does not display information

LCD does not display information

1

G-2

ee 477 final report · web viewthe manufacturing process of the pcb makes use of many harmful...

Documents