Jochoa_Bkempton_EE175_report_v14

Collision Prevention System
Dept. of Electrical Engineering, UCR
EE175ABC Final Report
6/12/2015 V1.4
1 of 107
EE175ABC Final Report Template
EE 175ABC Final Report
Department of Electrical Engineering, UC Riverside
Project Team
Member(s)
Jose Ochoa
ochoajose@live.com
Braden Kempton
bradenkempton@hotmail.com
Date Submitted 6/10/2015
Section
Professor
Nissim Amos
Revision 1.4
URL of Project
Wiki/Webpage
https://www.linkedin.com/in/bradenkempton
Summary
This report presents an outline of how our projects functions and is assem-
bled. It breaks down the project into several modules which are thoroughly
explained. Additionally, the report describes how we tested our project and
how our project responded to our tests.

6/12/2015 V1.4
2 of 107
Revisions
Version Description of Version Author(s) Date
Completed
Approval
1.1 First draft Jose Ochoa,
Braden
Kempton
04/20/15
1.2 Second draft Jose Ochoa,
Braden
Kempton
5/27/15
1.3 Final Draft Jose Ochoa,
Braden
Kempton
6/10/15

6/12/2015 V1.4
3 of 107
Table of Contents
REVISIONS......................................................................................................................2
TABLEOF CONTENTS ....................................................................................................3
1 EXECUTIVE SUMMARY ...............................................................................................7
2 INTRODUCTION ...........................................................................................................8
2.1 DESIGN OBJECTIVES AND SYSTEM OVERVIEW .........................................................8
2.2 BACKGROUNDS AND PRIOR ART ..............................................................................8
2.3 DEVELOPMENT ENVIRONMENT AND TOOLS .............................................................8
2.4 RELATED DOCUMENTS AND SUPPORTING MATERIALS.............................................8
2.5 DEFINITIONS AND ACRONYMS..................................................................................9
3 DESIGN CONSIDERATIONS ........................................................................................10
3.1 ASSUMPTIONS .........................................................................................................10
3.2 REALISTIC CONSTRAINTS........................................................................................10
3.3 SYSTEM ENVIRONMENT AND EXTERNAL INTERFACES ............................................10
3.4 INDUSTRY STANDARDS...........................................................................................10
3.5 KNOWLEDGE AND SKILLS .......................................................................................10
3.6 BUDGET AND COST ANALYSIS ................................................................................11
3.7 SAFETY ...................................................................................................................11
3.8 PERFORMANCE, SECURITY, QUALITY, RELIABILITY, AESTHETICS, ETC. .................11
3.9 DOCUMENTATION ...................................................................................................11
3.10 DESIGN METHODOLOGY .......................................................................................11
3.11 RISKS AND VOLATILE AREAS................................................................................11
3.12 UNDERSTANDINGOF PROFESSIONAL AND ETHICAL RESPONSIBILITY....................12
3.13 GLOBAL, ECONOMIC, ENVIRONMENTAL AND SOCIETAL IMPACT ..........................12
3.14 CONTEMPORARY ENGINEERING ISSUES.................................................................13
3.15 RECOGNITION OF THE NEED FOR AND ANABILITY TO ENGAGE IN LIFELONG LEARNING 14
3.16 IMPORTANCE OF TEAM WORK...............................................................................14
4 EXPERIMENT DESIGN AND FEASIBILITYSTUDY......................................................15
4.1 EXPERIMENT DESIGN ..............................................................................................15
4.1.1 C code for velocity detection.............................................................................15
4.1.2 Operation of 10m Ultrasonic Sensors ................................................................15
4.2 EXPERIMENT RESULTS AND FEASIBILITY................................................................16
5 ARCHITECTURE ........................................................................................................17
5.1 SYSTEM ARCHITECTURE .........................................................................................17
5.2 RATIONALE AND ALTERNATIVES ............................................................................17
6 HIGH LEVEL DESIGN................................................................................................19

6/12/2015 V1.4
4 of 107
6.1 CONCEPTUAL VIEW.................................................................................................19
6.1.1 Zone 1 monitoring:...........................................................................................19
6.1.2 Zone 2 monitoring:...........................................................................................20
6.1.3 Zone 3 monitoring:...........................................................................................20
6.1.4 Zone 4 monitoring:...........................................................................................21
6.2 HARDWARE.............................................................................................................21
6.3 SOFTWARE ..............................................................................................................21
7 DATA STRUCTURES ...................................................................................................22
7.1 INTERNAL SOFTWARE DATA STRUCTURE.................................................................22
7.2 GLOBAL DATA STRUCTURE......................................................................................22
7.3 TEMPORARY DATA STRUCTURE...............................................................................22
7.4 DATABASE DESCRIPTIONS .......................................................................................22
8 LOW LEVEL DESIGN.................................................................................................23
8.1 THE SENSOR MODULE: LV_MAXSENSOR_EZ4, XL_MAXSONAR_EZ4 ................23
8.1.1 Processing narrative for the sensor module........................................................23
8.1.2 Sensor Module interface description..................................................................24
8.1.3 Sensor Module processing details......................................................................24
8.2 MICROCONTROLLER 1 AND DATA PROCESSING MODULE: ARDUINO ......................24
8.2.1 Processing narrative for the Microcontroller 1 and Data Processing module.......25
8.2.2 Microcontroller 1 and Data Processing Module interface description..................25
8.2.3 Microcontroller 1 and Data Processing Module processing details.....................25
8.3 DISPLAY MODULE: LCD, BUZZER, LED, SHIFT REGISTERS ...................................25
8.3.1 Processing narrative for the display module.......................................................27
8.3.2 Display Module interface description ................................................................27
8.3.3 Display Module processing details ....................................................................27
8.4 POWER SUPPLY/SIGNAL CONVERSIONS MODULE ...................................................28
8.4.1 Processing narrative for the Power Supply/Signal Conversions...........................28
8.4.2 Power Supply/Signal Conversions Module interface description..........................28
8.4.3 Input Module processing details........................................................................29
8.5 GPS/MCU2 MODULE..............................................................................................29
8.5.1 Processing narrative for the GPS/MCU2 module................................................29
8.5.2 GPS/MCU2 Module interface description..........................................................29
8.5.3 GPS/MCU2 Module processing details..............................................................29
8.6 RELATIVE VELOCITYMODULE ................................................................................30
8.6.1 Processing narrative for the Relative Velocity module ........................................30
8.6.2 Relative Velocity Module interface description...................................................30
8.6.3 Relative Velocity Module processing details.......................................................30
8.7 FILTERING SCHEME MODULE...................................................................................30
8.7.1 Processing narrative for the Filtering Scheme module........................................30
8.7.2 Filter Scheme Module interface description .......................................................30
8.7.3 Filtering Scheme Module processing details.......................................................30
8.8 TIMINGSCHEME MODULE .......................................................................................30
8.8.1 Processing narrative for the Timing Scheme module...........................................38
8.8.2 Timing Scheme Module interface description .....................................................38
8.8.3 Timing Scheme Module processing details.........................................................38

6/12/2015 V1.4
5 of 107
8.9 STATE MACHINE OF OVERALL SYSTEM MODULE ....................................................38
8.9.1 Processing narrative for the S.M. of System module............................................40
8.9.2 S.M. of System Module interface description ......................................................40
8.9.3 S.M. of System Module processing details..........................................................40
9 USER INTERFACE DESIGN ........................................................................................42
9.1 APPLICATION CONTROL ..........................................................................................42
9.2 SCREEN ...................................................................................................................42
9.3 DEVELOPMENT SYSTEM AND COMPONENTS AVAILABLE..........................................43
10 TEST PLAN ..............................................................................................................44
10.1 DESIGN OF TESTS ..................................................................................................44
10.2 BUG TRACKING.....................................................................................................44
10.3 QUALITYCONTROL...............................................................................................44
10.4 PERFORMANCE BOUNDS ........................................................................................44
10.5 IDENTIFICATION OF CRITICAL COMPONENTS.........................................................45
10.6 ITEMS NOT TESTED ...............................................................................................45
11 TEST REPORT..........................................................................................................46
11.1 TEST ITERATION 1.................................................................................................46
11.1.1 Test 1: Power Circuit and Signal Conversion...................................................46
11.1.2 Test 2: GPS and MCU ....................................................................................46
11.1.3 Test 3: Sensor LV MaxSonar EZ4....................................................................46
11.1.4 Test 4: Sensor XL MaxSonar EZ01 ..................................................................46
11.1.5 Test 5: Display Module/shift registers..............................................................47
11.1.6 Test 6: Timing scheme ....................................................................................47
11.1.7 Test 7: Zone 1 monitoring...............................................................................48
11.1.10 Test 10: Zone 4 monitoring............................................................................48
11.2 TEST ITERATION 2.................................................................................................49
11.2.1 Test 1: Signal Conversion/Power Supply..........................................................49
11.2.2 Test 2: GPS and MCU ....................................................................................49
11.2.3 Test 3: Sensor LV MaxSonar EZ4....................................................................49
11.2.4 Test 4: Sensor XL MaxSonar EZ01 ..................................................................49
12 ADMINISTRATIVE AND OTHER DESIGN ISSUES......................................................52
12.1 PROJECT MANAGEMENT........................................................................................52
12.2 REQUIREMENTS TRACEABILITYMATRIX................................................................52
12.3 PACKAGINGAND INSTALLATION ISSUES................................................................52
12.4 DESIGN METRICS TO BE USED ................................................................................52
12.5 RESTRICTIONS, LIMITATIONS, AND CONSTRAINTS .................................................52
13 CONCLUSION AND FUTURE WORK.........................................................................53
13.1 CONCLUSION.........................................................................................................53
13.2 FUTURE WORK......................................................................................................53

6/12/2015 V1.4
6 of 107
13.3 ACKNOWLEDGEMENT............................................................................................53
14 REFERENCES ...........................................................................................................54
15 APPENDICES ............................................................................................................55

6/12/2015 V1.4
7 of 107
1 ExecutiveSummary
The purpose of our project is to prevent collision between cars. A very dangerous maneuver that causes
many vehicle accidents is lane change. The way we will tackle this problem is by using severalultrasonic
sensorsthat will monitor the blind spot and a couple carlengths behind it. These sensors will become active
when the side that they are faced is signal through the turn switch. Once this is done, the two sensors will
begin to operate and check for vehicles. If a vehicle is on the blind spot of the car, a warning will be
displayed in the form of a red light. If a vehicle is not on the blind spot, but is behind it and accelerating,
the driver will be warned in the form of a red light. As for the sensor that checks for head on collision, it
will always be on while the vehicle is moving forward. A warning will be given to the driver in the form of
a buzzer. In addition to this, our system will check the back on the car when the user is backing up. It will
display the distance to closest thing through an LCD module.

6/12/2015 V1.4
8 of 107
2 Introduction
2.1 Design Objectivesand System Overview
The name of our project is Collision Prevention. The purpose of it is to reduce the amount of collision of
four wheel motor vehicles. In specific, we hope to reduce the amount of accidents that occur while drivers
change lanes. Additionally, our system will monitor the front of the car to prevent head on collisions. This
will be accomplished through the use of ultrasonic sensors.
Our system is composed of six ultrasonic sensors, two Arduino Uno, GPS module, and several other elec-
trical components. We will have one sensor monitoring each blind spot of the car. Additionally, we will
have two sensors monitoring up to two cars length behind the car, called Zone 3. These sensors will check
if there is any incoming vehicle moving at speeds higher than the driver’s vehicle. These sensors will only
begin operating when their respective side is indicated through the turn signal. Another sensor will monitor
the front of the car and will inform the driver if he or she is too close to the car in front of it based on its
current speed. This sensor will always be running when the car is moving forward. The last sensor will turn
on when the driver is backing up and will inform the driver of the distance to the vehicle/object behind.
Jose is the group manager and, thus was responsible for ensuring that the team stayed on track and that the
deadlines were met. Additionally, he wrote the code for filtering the data taken in by the sensors and pre-
venting interference between sensors. Braden was responsible for working with the GPS module and writ-
ing code to extract data from it. Additionally, he was in charge of the hardware part of the project, which
included making a PCB and soldering.
2.2 Backgrounds and Prior Art
There are severalother systemsin the marketthat perform collision prevention. This type of system is being
adopted by most car manufacturer, but there are a few companies who offer an after-market product that
performs this. Car manufacturers are implementing both active and passive collision prevention system,
while after-market produces are only creating passive one. The difference between an active and passive
system is that active systems respond to collision warning and passive systems only warn the drier. An
example of this is Infiniti’s forward collision feature which gently applies the breaks when a forward colli-
sion is detected. All of the systems that we found are limited to only checking the front end of the car and
the blind spot. Our system will not only perform this, but it will also check a couple of car lengths behind
and determine if a car is approaching at a speed that might cause a collision. A drawback to our system is
that it is a passive system.
2.3 DevelopmentEnvironmentand Tools
For our system, the software that we used was the Arduino IDE, Design spark, Pspice. We used Arduino
IDE environment to program the Arduino Uno and also to tests parts of our system. Also, we used Design
Spark to create a PCB. Additionally, we used an oscilloscope, voltmeter, and dc voltage supply to test
different hardware modules.
2.4 Related Documents and Supporting Materials
G. Baddeley, 'GPS - NMEA sentence information', Aprs.gids.nl, 2015. [Online]. Available:
http://aprs.gids.nl/nmea/. [Accessed:26- Apr- 2015].
D. DePriest, 'NMEA data', Gpsinformation.org, 2015. [Online]. Available: http://www.gpsinfor-
mation.org/dale/nmea.htm. [Accessed:26- Apr- 2015].

6/12/2015 V1.4
9 of 107
B. Gross, 'MaxBotix® Inc., Wonderful Innovations', Maxbotix.com, 2015. [Online]. Available: http://max-
botix.com/articles/057.htm. [Accessed:26- Apr- 2015].
S. Wielenberg, '3 Sensor Multi-Sensor Test and Results', Maxbotix.com, 2015. [Online]. Available:
http://maxbotix.com/articles/063.htm. [Accessed:26- Apr- 2015].
S. Wielenberg, 'MaxSonar Sensor Acoustic Noise Tolerance Test', Maxbotix.com,2015. [Online]. Availa-
ble: http://maxbotix.com/articles/012.htm. [Accessed:26- Apr- 2015].
http://www.maxbotix.com/documents/XL-MaxSonar-EZ_Datasheet.pdf
http://maxbotix.com/documents/LV-MaxSonar-EZ_Datasheet.pdf
2.5 Definitions and Acronyms
Zone 1: region in front of the car. Up to 34 ft in front of the car
Zone 2: region that corresponds to the blind spot of the car
Zone 3: region behind the blind spot. Reaches up to 34 ft from the back of the car
Zone 4: region behind the car. Reaches up to 22 ft
Sensor 1: XL-maxsonar-EZ01 sensor monitoring Zone 1
Sensor 2: LV-maxsonar-EZ4 sensor monitoring left Zone 2
Sensor 3: XL-maxsonar-EZ01 sensor monitoring left Zone 3
Sensor 4: LV-maxsonar-EZ4 sensor monitoring right Zone 2
Sensor 5: XL-maxsonar-EZ01 sensor monitoring right Zone 3
Sensor 6: LV-maxsonar-EZ4 sensor that monitors Zone 4
Driver: Person driving the vehicle with our system.

6/12/2015 V1.4
10 of 107
3 Design Considerations
3.1 Assumptions
We assume that the consumer has this product installed by a qualified technician. Sensor positioning may
vary based on the size and shape of the vehicle in which it is installed. It is assumed the technician will
mount sensors appropriately and test to ensure the most accuracy. It is also assumed that the sensors used
for prototype are used in production. However, all the components of this product are potentially inter-
changeable if cost warrants it. Additionally, we are assuming that this product is used within the operating
temperature range specified in the sensor datasheets found in Section 8.
3.2 Realistic Constraints
Constraints of this product are sensor range and frequency and processor speed. Refer to experimental data
section and conclusion for notes regarding microcontroller and GPS chip selection.
3.3 System Environmentand ExternalInterfaces
This product follows IEEE GPS protocols. NFPA’s vehicle safety standards are also observed.
3.4 Industry Standards
The programming language that we will be using is C and the programing environment that we will be
working with is the Arduino IDE. GPS,RS232, and vehicle safetystandards were all important to the design
3.5 Knowledge and Skills
Jose Ochoa:
Courses taken:
1) EE1A/1B, 105, 100A/B. 110A/B, 116, 120A, 132, CS10, 61
2) CS13: C++ for science majors
3) EE128: data acquisition and instrument control
4) EE120B: introduction to embedded systems
Knowledge and skills learned:
1) Understand how proximity sensors work. The different types available in the market and in what
field they are used
2) Learned about the types of sensors used in automobiles industry
3) Work with another individual on a project
Braden Kempton:
Courses taken:
1) EE1A/1B, 100A/B, 105, 110A/B, 116, 120A, 132, CS10, 61
2) CS13: C++ for science majors
3)

6/12/2015 V1.4
11 of 107
4) EE128: data acquisition and instrument control
5) EE120B: introduction to embedded systems
6) EE123: Power Engineering
Knowledge and skills learned:
1) Became familiar with state functions, GPS data acquisition
3.6 Budgetand Cost Analysis
The budget for our project is set to $200 dollars. The LV sensors will cost $30 each and the XL sensors will
cost $40 each. The Arduino cost around $25 and the display actuators will cost in total of $5. Other miscel-
laneous components such as wires transistors and capacitors will add around $5 of cost. Added GPS chip
for $40.
3.7 Safety
This system is not an electrical hazard in any way if used in the manner instructed. Our system will be used
by consumers on motor vehicles that are in motion so roadway safety is a major concern. The system must
be mounted properly by a qualified technician and operating instructions must be followed by consumer
for reliable functioning of the system. With this system, like many systems that attempt to improve driving
safety by autonomous means, the driver is still expected to follow motor vehicle laws as well as be aware
of the his surroundings, including all vehicles in the driver’s vicinity.
3.8 Performance,Security, Quality,Reliability, Aesthetics,etc.
The product will be tested under various conditions to ensure quality and reliability. The system is intended
for outdoor use and so it will be mounted in a robust, weatherproof case. Quality control will be maintained
by having only engineers responsible for design and testing! If installed properly, product will be guaran-
teed to give reliable results.
3.9 Documentation
A log book of all project related design work will be maintained. In addition, a binder notebook will be
kept to house all weekly reports and presentations
3.10 Design Methodology
Initial research was conducted on sensors (types, availability, cost, performance). Initial testing was then
carried out to assess sensor performance. Next,an overall high level design for an embedded system (mi-
crocontroller) was created to assess overall system feasibility and design requirements. Preliminary soft-
ware/hardware design was then developed and tested. Finally, physical implementation of the system and
testing in the field was done, iteratively. Emphasis was given to qualitative over quantitative results to an
extent, as testability in the field was limited due to available resources.
Risks and Volatile Areas
The forward collision feature is mentioned here for two reason. First, due to the limited range of the sensor
used, the product is not effective in preventing all forward collisions. As a result, this feature may be more
effectively called a tailgate monitoring, or prevention feature. Second, due to risk of vehicle collision dur-
ing testing, extensive quantitative data was not documented.

6/12/2015 V1.4
12 of 107
3.11 Understandingof Professionaland EthicalResponsibility
The profession of Electrical Engineering, as well asall engineering fields, places a high importance
on public safety. This can be seen by examining the codes of conducts that each engineering field follows.
For example, the Institute of Electrical and Electronic Engineers follows the pledge “We the members of
the IEEE, … do hereby commit ourselves to the highest ethical and professional conduct and agree: 1. To
accept responsibility in making decisions consistent with the safety,health, and welfare of the public, and
to disclose promptly factors that might endanger the public or the government.” What is meant by this
statement is that members of this organization have a duty to ensure the safety of the public or government
in any project that they are involve in. Additionally, it states that they are responsible for informing the
public of any dangers that might result from their work.
Due to this code of conduct, we considered public safety in all our decisions. From the start of our
project to our current standing, we ensured that our product would not harm the user. For example, in the
initial phase of our system, we were considering taking control of the vehicle if a car was detected ap-
proaching it at high velocities. For the first two weeks,this was an additional feature that we were going to
include in our system. This was mostly because it added complexity to our system. Nonetheless, the more
we thought about this, the less we were convinced that it was worthwhile. Although it added a lot of com-
plexity to our system, it would not benefit the user. By taking control of the car, we would have put the
driver in danger. In order to take control of a vehicle traveling at speeds over 60 mph, our control system
would have to be very complex to account for all possible scenarios. Therefore,we ended up not including
this feature in our system. Another example of how we have put safety as the top priority is by informing
the user of the flaws in our system. Although our system will work very well, it will not be one hundred
percentaccurate.Making our system be extremely accurate would require yearsof development and testing,
which we do not have. As a result of this, we will notify the users of our product to the accuracy of our
system. Users of our product will know not to solemnly depend on our system for changing lanes or detect-
ing collisions.
As a result to designing our project, we have learned a lot in regards to the professional and ethical
responsibilities of Electrical Engineers. For example, we learned about the code that IEEEmembers follow,
which states that engineers should always consider public safety when designing and constructing any sys-
tem. Additionally, we learned how to work in a group. We were able to break our system in parts and
assigned different parts for each team member to work on. This allowed for work to be completed on time.
3.12 Global, Economic,Environmentaland SocietalImpact
If our project becomes a commercial product, it will have a significant impact on our society. Alt-
hough there are other products similar to ours in the market, ours will be relatively cheaper and more effi-
cient. This will allow for more people to be able to afford our product. If people use our product, collision
between vehicles will decrease substantially.
If collisions are reduced, people will benefit in two forms. First and most importantly, deaths due
to car collisions will decrease. Based on a study, it was discovered that on average,92 people in the US
die due to car accidents per day. On a yearly bases, this means that a total of around 31,000 people die
from car collisions. Our system will decrease this number by a considerable amount. Additionally, our
system will reduce the cost that results from collision. This will benefit the government and individuals.
For an average collision, the cost of damages is $50,000. This includes the damages of both cars and its
surroundings. Although insurance companies will cover most small damages,larger damages will not be
covered. In most cases,people can’t afford to pay for insurance that covers for all this and thus, end up
having to pay for the damages that are not covered. This can reach up to thousands of dollars in costs. Not
only do collisions cause damages between vehicles, but they also cause damages on its surroundings. If
collisions occur in freeways or highways, they can also damage side rails or posts. The repair of these
structures falls in the hands of the local government. Although these repairs may seem minor, they cost

6/12/2015 V1.4
13 of 107
the government a substantial amount of money. On average one of these repairs can cost up to several
thousand dollars. Thus, on a yearly base, a state like California can spend millions of dollars in repairs.
This takes away resources that could be allocated for other things.
In addition to reducing the number of collision, our system will help new drivers, such as teens,
gain experience in driving. Changing lanes while traveling at speed greater than 30 mph can be very terri-
fying for new drivers. This is something that I can say from experience. Adding our system to teen
driver’s vehicles will give them a little more confidence when driving. They will not be dependent on
their side view mirrors, which can be very misleading, confusing, and inaccurate. Additionally, most side
view mirrors do not cover every region of the side of the car. There is usually a region called the blind
spot, which is not visible to the driver. Since our system checks this region, teens will be able to make
more inform decision when changing lanes and therefore,will be more confident while driving.
3.13 Contemporary Engineering Issues
Engineering is interdependent withtechnology.Conceptually, engineering can be seen as inherent in
any field of study, as it is the creation of a new way to accomplish a given task or creating a solution
to current problem. In both cases, new technology is the outcome. At the same time, technology can
be then be used to engineer more new methods and technologies. It is an evolutionary process. It
seems then, that new technology will always be a constant in any field, and is germane to the idea of
engineering itself. In contemporary engineering, the twomost important themes are perhaps smart
technology and real-time systems. Smart technology and real-time systems are the driving catalysts
behind the development of autonomous navigation, and why we are seeing its development now on
the rise. Our senior design project falls into the category of autonomous navigation.
Smart technology canbe defined as technology that not only alleviates humans having to com-
plete a particular task, but can learn from our behavior and remember, in order to further facilitate
our lives. In autonomous navigation, several smart technologies are being explored and/or are al-
ready being implemented. Adaptive cruise control and Adaptive braking are examples. Considering
the requirements foradaptive braking, it is somewhat beyond the scope of an EE senior design pro-
ject. However,for our project we do wish to implement some form of adaptive cruise control. Adap-
tive cruise controlworks by slowing the velocity of a vehicle, as it approaches another from behind,
to match the velocity of the vehicle being approached, at such a rate that it accomplishes the task in
time for the twovehicles to still be a safe distance apart. For reasons of safety and scope, our system
will not attempt to physically control the velocity of the vehicle. However,our system will notify the
driver when it is too close to the vehicle directly in front. Also, as a compromise to controlling the
velocity directly, we hope to be able to implement a control feature that simply disengages cruise
control based on accepted tables of safe distance vs. speed measurements.
Another contemporary engineering issue related to autonomous navigation and our project
is real-time systems. The term real-time simply means that the system performs a function within
the time specified in the design. This time can be short or long as long as it is reliable. Autonomous
navigation systems must be real-time to ensure driver and passenger safety. Our project will have
specified time delays and/or requirements.
A final theme in contemporary engineering that relates to our project is one that is as old as
engineering itself: low power consumption. Minimizing power consumption is not only necessary
to help create new technologies, it also helps to preserve our natural resources. Improving effi-
ciency and discovering alternative energy sources are some waysof reducing power consumption.
Our project requires relatively little power consumption, yet is still a major design aspect since the
goal in engineering is alwaysoptimization. Consequently, we are leaning toward drawing power
from the alternator in the vehicle,as opposed to batteries whichmay be more wasteful and incon-
venient for the user to replace.

6/12/2015 V1.4
14 of 107
3.14 Recognition of the need for and an ability to engage in lifelong
learning
In designing our engineering project, the recognition of the need for lifelong learning has echoed
throughout the design so far. First, and foremost, this need is due to the factthat there is so much
to learn. The more youlearn, the more youcan do. Every part of the design process so far seems to
cause us to ask questions, research current and past technology and tools to find solutions and im-
plement the system. We have seen the need for understanding human nature, as wellas the need
for curiosity and repeated experimentation forthis project, and all projects, to “see what
happens.”
As stated above,the more you know,the more you can do. Knowledge is power. In practical
terms, one is more marketable and can earn a higher salary, the more education and experience
they have acquired. This means not only a bigger salary, but more opportunities emerge to choose
from.
On a final note, what is most important about engaging in lifelong learning is the benefit it
produces for mankind. Not only are there personal rewards and progress through individual effort,
but progress forall. Lifelong learning has given us nothing less than quality of life.
3.15 Importance of Team Work
Teamwork is important for many reasons. Perhaps the most significant reason is the ability to accomplish
more with a team than one could individually. We are always limited by the time we have. And, despite
any amount of time-management skills, one is still limited on what they can achieve in a given time pe-
riod. Related to this, is the fact that some tasks require more than one individual to complete.
Thus, a greater number of things are possible when individuals work together. We saw that in our own
project when it came to testing our system.
Yet, another reason teamwork is important is it increases the talent pool. Individuals have strengths and
weaknesses. These weaknesses can be mitigated by using another individual’s strength. It is a proven fact
that countries with the most women’s rights are among the wealthiest of nations. This can be attributed to
the fact that these countries have a greater resource of talent to draw from. For our project, Jose’s abili-
ties to write the code for control and state functions and my ability to handle the hardware and power sup-
ply design facilitated the overall design process.

6/12/2015 V1.4
15 of 107
4 ExperimentDesign and Feasibility Study
4.1 ExperimentDesign
Feasibility study has been done primarily with respect to sensor type that would yield long range reliable
data on a much more cost-effective scale than radar technologies. Also, of key importance is performance
in outdoor conditions and safe roadway operation. Similar models exist with shorter range than we are
trying to achieve. As a result, we have outsourced sensor design to Maxbotix and are only testing sensors
to confirm Maxbotix performance claims. Sensor accuracy is sufficient and system will use vehicle as
power source with added power supply filter. This makes power concerns negligible. Tradeoffs include
sacrificing quantity of data to reduce possible interference and junk readings. Interfacing between sensors
and control unit are negligible. Interfacing between vehicle and control unit/sensors will be with noise-
filtering weatherproof wiring harness to attach to vehicle. Experiments are detailed in section 10
4.1.1 C code for velocity detection
For lane change operation, two sensors are engaged, one of which is used to obtain the relative velocity of
an approaching vehicle in the desired lane. Calculating the relative velocity of an object requires several
tasks. First of all, a timing sequence has to be established. In order to accurately determine a velocity, this
sequence has to stay constant. A deviation by the slightest amount will cause the calculation of the velocity
to be wrong. To create the timing sequence, we had to range the sensor every other 100 ms or 150 ms,
depending on what sensor used. This was accomplished by making a state machine with a period of 10 ms.
The function of this state machine is to count to the sampling period and range the sensor.
The second task that needs to be accomplished is keeping track of the current and previous distance value
obtained by the sensor. This can be accomplished by creating an array. Every time a new distance is ob-
tained, the value can be pushed into the array.
The last task is to compute the velocity given the distance values and the timing period. To accomplish this,
we first had to compare the current distance with the previous distance. If the current distance is greater
than the previous distance, we know that the object is moving away from the sensor and vice versa. Once
we know the direction that the object is moving, we can compute the velocity. For our system, we obtained
a distance sample every 600 ms. Additionally, the distance units we were working with were in inches. To
obtain the speed in MPH,we had to convert our units to miles and hours. To perform the conversion from
seconds to hours, we had to divide our time by 3,600. As for the conversion between inches to miles, we
had to divide the distance traveled by 63,360. The distance traveled during the given period is the difference
between the previous distance and current distance.
4.1.2 Operation of 10 m Ultrasonic Sensors
The collision prevention system designed herein is to have six sensors overall. One in front, one in back,
and two on each side. Of these,three are chosen to be of the type having a detection range of 10 meters for
large objects, i.e. cars. The 10 m range sensors will occupy the front position and left/right rear positions.
They have a ranging frequency of 10 Hz. In normal, or default operation, forward collision monitoring
occurs via this front sensor as the front sensor is supplied with power when the car ignition is switched ON.
To filter out occasional noise, a median filter was added to reject any anomalies.
The other 10 m range sensors are located in the rear of the vehicle on both sides and are part of the lane
change (turn signal) operations described in the previous section.

6/12/2015 V1.4
16 of 107
4.2 ExperimentResults and Feasibility
For lane change operation (using relative velocity), some testing was devoted to qualitative performance
analysis, not quantitative. Jose and drove around the Canyon Crest area periodically engaging the turn sig-
nal while cars were approaching. Cars were most often detected during approach.
For quantitative measurements, we conducted tests in an empty parking lot with the car in park, while one
of us would walk towards the vehicle from the rear,asif approaching in an adjacentlane. We sawconsistent
detection per data table criteria and delay for data acquisition and synchronization.

6/12/2015 V1.4
17 of 107
5 Architecture
5.1 System Architecture
Fig.1
Microcontroller 1 handles the overall data processing and functionality of the system. It receives inputs
from the signal conversion and power supply module and from the sensors. It also controls the display
module. Microcontroller 2 receives data from the GPS module and processes it. Once the required data is
extracted,it sends it to microcontroller 1.the power supply module/signal converter module supplies power
to the system and steps down a 12 volt DC signal to 5 V.
5.2 Rationale and Alternatives
For our first model of our system, we were planning of using only LEDs and a buzzer to communicate with
the Driver, but we ended up deciding to use an LCD Screen in addition to the previous. Additionally, we
initially thought of implementing the front end monitor feature of our system using relative velocity, but
we decided that it would work better if we used a GPS module to obtain the vehicles velocity. By adding
the GPS module, we were able to determine the distance gap between the driver and the vehicle in front of
him based on the drivers speed. In order to add the GPS module, we had to add another microcontroller,
which processed the data sent by the GPS. The reason we did this was to speed up the processing of the
data received by the GPS and extract the speed value. For our system to work without an addition of a

6/12/2015 V1.4
18 of 107
second microcontroller, we would have had to increase the baud rate of the GPS and replace our current
microcontroller to one that has more serial pins, such as the Arduino mega.

6/12/2015 V1.4
19 of 107
6 High Level Design
6.1 ConceptualView
Fig. 2
Our system is composed of four features. These featuresare zone 1 monitoring, zone 2 monitoring, zone 3
monitoring, and zone 4 monitoring.
6.1.1 Zone 1 monitoring:
This feature starts when the system enters the checking forward state. During this feature,the sensor facing
zone 1 is turned on. Once the sensor starts ranging, it will keep a list of the distance between the car in front
of it and the driver. Additionally, the system will check the driver’s current speed and compare it to the
distance obtained. The system will warn the driver of a possible collision if the gap between the driver and
the car in front of it is smaller than specified in the chart below.

6/12/2015 V1.4
20 of 107
Speed (mph) Minimum distance (ft)
0 2
1 3
2 5
3 6
4 8
5 9
6 11
7 12
8 14
9 15
10 17
11 18
12 20
13 21
14 23
15 24
16 25
17 27
18 28
19 30
20 31
21 33
22 34
Table 1
This feature starts when the system enters the left/right lane checking state. The system turns on the sensor
facing zone 2. Afterwards,the system checks whether a car is detected in that region and informs the driver
in the form of a red light.
This feature starts when the system enters the left/right lane checking state. The system turns on the sensor
facing zone 3. The system then keeps track of the vehicle in zone 3. This is done by keeping a list of

6/12/2015 V1.4
21 of 107
distances. The system uses these values to compute the relative velocity of the vehicle in zone 3 to the
driver. If the velocity is positive and over 5 mph, a warning is given to the driver in the form of a red light.
This features starts when the system enters the checking back of car state. The system turns on the sensor
in zone 4. Once this is done, the system starts displaying the distance to the car or object behind the driver
in the LCD screen.
6.2 Hardware
Hardware Modules:
1) GPS/MCU2: Braden Kempton
2) Sensors: Braden Kempton
3) Power supply/ signal conversion: Braden Kempton
4) MCU1/data processing: Jose Ochoa
5) Display module/shift registers: Jose Ochoa
6.3 Software
Software Modules:
1) Relative velocity: Jose Ochoa
2) Filtering scheme: Jose Ochoa
3) Timing scheme: Jose Ochoa
4) State machine of Overall System: Jose Ochoa

6/12/2015 V1.4
22 of 107
7 Data Structures
NA
7.1 Internalsoftware data structure
NA
7.2 Globaldata structure
NA
7.3 Temporary data structure
NA
7.4 Databasedescriptions
NA

6/12/2015 V1.4
23 of 107
8 Low LevelDesign
8.1 The Sensor Module: LV_MaxSensor_EZ4,XL_MaxSonar_EZ4
Person responsible: Braden Kempton
Fig. 3
Fig. 4
8.1.1 Processing narrative for the sensor module
LV sensor will range for 50 ms and XL sensors will range for 100 ms. During the first 4 ms of ranging,
both sensors will release a 42 kHz ultrasonic wave. For the remainder of the time, both sensors wait for the
wave to bounce back of an object. The distance calculated is based on the time required for the wave to be
detected by the sensor. Since the XL sensors have a larger range time, they can detect a larger distance.
While the LV sensors can only detect an object 22 ft away,the XL sensors can detect an object 34 ft away.

6/12/2015 V1.4
24 of 107
Fig. 5
8.1.2 Sensor Module interface description
Both type of sensor can communicate with the MCU through pulse width modulation, analog voltage, or
serial communication. For our system, we used the analog voltage method. To accomplish this, we con-
nected pin AN to an Analog input of the Arduino. To control the sensors, we connected a digital pin from
the shift registers to pin RX of the sensor. To range the sensor, pin RX has to be set to low or left open and
to turn it off, pin RX has to be set to high.
8.1.3 Sensor Module processing details
The XL sensors are twice as slow as the LV. They take 10 readings per second as oppose to the 20 samples
that the LV takes. Additionally, when initially powered on, the sensors take over 100 ms to calibrate and
perform a test reading. This does not hinder us in any way because for our purposes, during the startup of
the system, the car will be warming up and thus, the reading taken during this time are not needed.
8.2 Microcontroller 1 and Data Processing Module:Arduino
Person responsible: Jose Ochoa

6/12/2015 V1.4
25 of 107
Fig. 6
8.2.1 Processing narrative for the Microcontroller 1 and Data Processing module
The Arduino runs on a 16 MHz processor. It can be powered through a dc voltage input between 5 V to 12
V. It has a flash memory capacity of 32 KB.
8.2.2 Microcontroller 1 and Data Processing Module interface description.
The Arduino Uno receives an analog voltage from the sensors. The pins that correspond to this are AN0-
AN5. Additionally, it receives serial data from the second Arduino Uno. This is done through pin RX.
Lastly, the Arduino communicates with the shift registers through digital pins, which include pins 5-10. It
receives inputs from the signal converter module through its digital pin as well.
8.2.3 Microcontroller 1 and Data Processing Module processing details
The microcontroller can perform an analog to digital conversion every 1ms. This satisfies our requirements
because the sensors can only produce a reading every 50 ms or 100 ms. Nonetheless, the fastest reading is
still higher than the speed of the microcontroller.
The overall functionally of the system is process by this microcontroller. It receives data from the sensors,
signal converter module, and the second microcontroller. It then interprets the data and writes to the display
module.
8.3 Display Module:LCD,Buzzer,LED,Shift Registers
Person responsible: Jose

6/12/2015 V1.4
26 of 107
Fig. 7
Fig. 8

6/12/2015 V1.4
27 of 107
Fig. 9
8.3.1 Processing narrative for the display module
The LCD screen informs the driver of what the system is doing at the time. As for the LED and buzzer,
they are used to warn the drier of possible collisions. Lastly, the shift registers expand the number of pins
used to control the LCD screen.
8.3.2 Display Module interface description
The LCD has 8 data input pins and 2 control input pins. The data pins are connected to the 8 output pin of
one of the shift registers and the control pins are connected to 2 output pins of the second shift register. The
shift registers are not connected serially. Each of the shift registers are connected to 3 pins in the first
Arduino. Pin 14 of the shift registers take in serial data from the Arduino. As for pin 13 of the shift register,
it latches the bit pass in through pin 14. Pin 11 controls when the shifts register’s output byte is updated.
As for the RGB LED and the buzzer, it is directly connected to the first Arduino.
8.3.3 Display Module processing details
To control the LCD screen with the expanded output pins created by the shift registers, I created a function
which took in two parameters. The first parameter was the index of the byte to be changed and the second

6/12/2015 V1.4
28 of 107
was a boolean parameter which sets the index to high or low. This function was used to pass in data to the
shift registers. Afterwards,I created 5 functions which control the functionality of the LCD screen. These
functions included writeData(), cursor(), initialize(), and two other helper functions. The functions created
for the LCD were design to work with the function used to pass in values to the shift register.
8.4 Power Supply/SignalConversionsModule
Person responsible: Braden
Fig. 10
8.4.1 Processing narrative for the Power Supply/Signal Conversions
The two function of this module are to provide power to the system and convert a 12 V DC signal to 5 V.
The power component of the module is the circuit on the bottom of the Circuit 1 image and the signal
conversions component is the circuit on the top half of the Circuit 1 image.
8.4.2 Power Supply/Signal Conversions Module interface description
The power circuit will take in 12 V from the car’s battery and will output 5 V to the Arduino’s 𝑉𝑖𝑛 pin. As
for the signal conversion circuit, its inputs will come from the back end lights. The output of the conversion
circuit will be connected to the Arduino digital pins, which include pins 1, 2, and 3.

6/12/2015 V1.4
29 of 107
8.4.3 Input Module processing details
The power circuit is composed of a 7805 voltage regulator, bi-directional fuse, and 2 capacitors. The 7805
will step down the 12 V input to 5 V. This component operates successfully when the voltage input is
between 6 V and 40 V. The purpose of the bidirectional fuse is to prevent back flow of current. As for the
capacitors, their purpose is to filter ripples in the output voltages.
The signal conversion circuit is composed of a power transistor, diode, and 2 resistors. If a 12 V signal is
applied to the input, the output is set to 0. If a 0 V signal is applied to the input, it outputs 5 V.
8.5 GPS/MCU2 module
Person responsible: Braden
Fig. 11
8.5.1 Processing narrative for the GPS/MCU2 module
The GPS module is used to find the velocity of the driver. We used a second MCU (Arduino) to
extract this value.
8.5.2 GPS/MCU2 Module interface description
The GPS module is connected to the MCU2 through pins TX of the GPS and pin 3 of the MCU2. The type
of communication used is USART. There is no communication from the MCU2 to the GPS. The MCU2
and the MCU1 are connected through pins TX of the MCU2 and RX of the MCU1. The type of communi-
cation used is USART.
8.5.3 GPS/MCU2 Module processing details
The GPS module uses the NMEA 0183 standard for data transmission. The baud rate of the GPS was set to
9600.To extract the velocity value, we Parsed through the MRC string until the 3rd
value of type double.
This string was sent twice a second, which means that the velocity value is updated every 0.5 seconds.

6/12/2015 V1.4
30 of 107
8.6 Relative Velocity module
This module is code based. It is executed by microcontroller 1 and can be found in appendix H.
8.6.1 Processing narrative for the Relative Velocity module
The purpose of this module is to calculate the trajectory of an incoming vehicle and speed in zone 3.
8.6.2 Relative Velocity Module interface description
This module is activated by the timing module. It receives data from the Filtering Module and sends data
to the State Machine of overall System module.
8.6.3 Relative Velocity Module processing details
Once the module is activated, it will keep track of the two most recent distance values. It will then compare
these two values. To know if the vehicle is moving away from the driver, it checks if the most recent
distance is smaller than the previous distance. If this holds true, then the relative velocity is not calculated
because the vehicle is not a threat. If it does not hold true, it will subtract the previous distance from the
most recent distance. It will then divide the result by the filtering period. To get the result in MPH, we
divide by 63360 and multiply by (6/10)*3,600.
8.7 Filtering Scheme module
8.7.1 Processing narrative for the Filtering Scheme module
The purpose of this module is to filter out abnormal samples from the sensor modules.
8.7.2 Filter Scheme Module interface description
This module is activated by the timing module, which controls the ranging of the sensors. Its results are
sent to the Relative Velocity module.
8.7.3 Filtering Scheme Module processing details
This module is used by all Sensors. It creates an array that keeps track of the last 8 distance values. After
every 600 ms, the module traverses the array and finds the median value of the array. This Value is used to
represent the distance of the car for the given time. Although it works very well to filter out outliers, it
creates a respond delay of 600 ms.
8.8 Timing Schememodule
Initiation of timing scheme (left to right: Back end feature, Front end feature, Left Zone1/Zone2/Zone3
monitor, Right Zone1/Zone2/Zone3 monitor)

6/12/2015 V1.4
31 of 107
Fig. 12
Timing scheme of sensor 1

6/12/2015 V1.4
32 of 107
Fig. 13
Timing scheme of Sensor 2

6/12/2015 V1.4
33 of 107
Fig. 14

6/12/2015 V1.4
34 of 107
Fig. 15

6/12/2015 V1.4
35 of 107
Fig. 16

6/12/2015 V1.4
36 of 107
Fig. 17

6/12/2015 V1.4
37 of 107
Fig. 18

6/12/2015 V1.4
38 of 107
8.8.1 Processing narrative for the Timing Scheme module
The purpose of this module is to set up the duration time of each sensors and the specific time that each
sensor will be ranging in regards to the others. To avoid interference and keep a consistent ranging period
for each sensor,a scheme had to be implemented.
8.8.2 Timing Scheme Module interface description
The timing module controls the sensor module. It responds to inputs from the signal conversion module.
8.8.3 Timing Scheme Module processing details
When the driver is moving forward,the timing scheme module turns on the sensor in Zone 1. The sensor is
turn on every 150 ms. It is left in ranging mode for 100 ms and then turned off for the remainder of the
period. When the system enters the changing lane state,it temporarily turns off the sensor in Zone 1. It then
initiates the timing scheme for turning on the sensors in Zone 1, Zone 2, and Zone 3. The sensor in Zone 1
is turned on first and its period is set to 150 ms. It is set to ranging for 100 ms and turned off for 50 ms.
After the sensor in zone 1 is turned off, which means after 100 ms, the sensor in zone 2 is turned on. The
period for this sensor is set to 150 ms and its ranging time is set to 50 ms. Once the sensor in zone 2 is
turned off, the sensor in zone 3 is turn on. Its period is set to 150 ms and its ranging time is set to 100 ms.
The purpose of setting up the timing scheme is to prevent interference between sensors. By keeping the
ranging time different, we reduce the chancesofcrossinterference.Also, by creating a standardized ranging
time; we can ensure that the time between samples is kept the same. Therefore, we can use this period to
find the relative velocity of vehicles.
8.9 State Machine of OverallSystem module
Top level state machine

6/12/2015 V1.4
39 of 107
Fig. 19
Display state machine

6/12/2015 V1.4
40 of 107
Fig. 20
8.9.1 Processing narrative for the S.M. of System module
The purpose of this module is to set up the overall function of the system. It processes the data computed
by the relative velocity module, data received from the sensors, and inputs from the signal converter mod-
ule. It then sends the appropriate data to the display module.
8.9.2 S.M. of System Module interface description
The module is the center of the system. It communicates with all modules, both software and hardware.
8.9.3 S.M. of System Module processing details
The module first checks the digital inputs from the signal converter module. If the backing up pin is set to
high, the system initiates the timing and filter scheme for zone 4. It then waits for data to be processed and
it makes the LCD screen output the distance. If the system detects that the moving forward pin is set to

6/12/2015 V1.4
41 of 107
high, it initiates the appropriate timing and filtering scheme. Once the data has been processed,it writes to
the display module. Lastly, if the system detects that either of the changing lanes pins is set to high, it
initiates the appropriate timing and filtering scheme. Once the data is processed, the system writes to the
display module.

6/12/2015 V1.4
42 of 107
9 User Interface Design
9.1 Application Control
The screens are not meant to be interactive. They are meant to inform the driver of the state the system is
on and what feature is being executed. The screen will not display images, only texts.
9.2 Screen
Fig. 21
When the system is powered up, it will display the phrase “STARTINGSYSTEM”. After 2 seconds, it will
display “STOPPED”,which means that the vehicle is not moving. If the driver presses on the button to
move forward, the screen will display “MOVING FORWARD”. If a possible collision is detected, the
buzzer will go off. In this state,the driver can indicate that he wants to change lanes. If he flickers the turns
signal to indicate he want to move to the right, the screen will display “CHANGING LANE TO RIGHT”.
If he indicates that he wants to turn left, the screen will display “CHANGING LANES TO LEFT”. In both
these states, if a possible collision is detected from the front, the buzzer will go off. Also, if everything is
clear to make the lane change, the LED will turn green and if it is not, the LED will turn red. To transition
to the backing up state, the drier has to flip the switch used to indicate moving forward. Once the system
goes back to the stop state,it can transition to the backing up state. When in the backing up state,the screen
will display “MOVING BACK” on the first column and on the second, it will display “DISTANCE (ft):
#”. The variable # will show the distance in ft.

6/12/2015 V1.4
43 of 107
9.3 Developmentsystem and components available
The components that make up the user interface are an LCD screen, an LED, and a Buzzer. To cause a
change on the screen,inputs are passed through in the form of mechanical actions.

6/12/2015 V1.4
44 of 107
10 TestPlan
10.1 Design of Tests
The followingare the types of experiments/test areas we performed:
Sensor Accuracy/Range
Input Signal Simulation/Response
PowerSurge/Regulation
PrototypeField Testing
Sensor Accuracy/Range – Isolated testing of various all sensors in varying weather conditions to an-
alyze functionand performance.
Input Signal Simulation/Response – Prior to hardware development, input signals representing car
battery power, turn signal, and transmission were simulated to incorporate these inputs into pro-
gramming.
PowerSurge/Regulation – Whiledifferent powersupply designs wereconsidered, linear voltagereg-
ulation was chosen and subsequently tested in lab and in the field.
Comprehensive Field Testing – Prototypewas developed and tested in the field.
10.2 Bug Tracking
My partner and I being few in number, we developed, tested and investigated our own work for the most
part. However,for integrated testing, we worked together to troubleshoot problems and shared the respon-
sibility of fixing problems as they arose.
10.3 Quality Control
Debug tools and built-in performance indicators:
Arduino IDE programming environment
LCD Display – indicates correct mode of operation, warnings.
LED Array – sequential light sequence indicating system operation/speed
LED indicator – Vehicle in close proximity indicator also suggests sensor accuracy
10.4 Performancebounds
Forward collision monitoring range: 10 meters
Blind Spot monitoring range: 6 meters (0.6 s time delay)
Approach zone monitoring range: 10 meters (0.6 s time delay)
Backup zone monitoring range: 6 meters
Accuracy and frequency of 6 meter sensors are 1 inch and 20 Hz, respectively.
Accuracy and frequency of 10 meter sensors are 2 inches and 10 Hz, respectively.

6/12/2015 V1.4
45 of 107
Sensor positioning is criticalto system performance and accuracy
GPS signal required
10.5 Identification of Critical Components
Ultrasonic sensors are the critical components in this system. In particular, their positioning and protection
from harsh driving conditions.
10.6 Items Not Tested
Forward collision feature tested and deemed successful, although quantitative results are estimated.

6/12/2015 V1.4
46 of 107
11 TestReport
11.1 TestIteration 1
11.1.1 Test 1: Power Circuit and Signal Conversion
Braden Kempton
1. For the first round of tests, we tested the circuit using a function generator and observed the output
using an oscilloscope. The oscilloscope showed a triangular wave form between 5 V and 0 V.
2. The output that we observed from the oscilloscope when supplying a 12 V square wave was not what
we expected. We were expecting to see a 5 volt square wave as an output.
3. Since the output wasnot what we wanted,we went back to our schematic and figure out why our output
was not a square wave. We figured out that the reason was not due to our circuit. The reason that the
output was not a square wave was because the function generator could not produce a square wave that
transitions from 5 V to 0 V.
4. Tests the circuit using a voltmeter.
11.1.2 Test 2: GPS and MCU
Jose Ochoa/Braden Kempton
1. The persons who tested this module were both Braden and Jose. For our first test, we used the
Hollux 5000c and Arduino Uno. To test the module, we ran a simple program that would obtain
the current location of the GPS module in terms of longitude and latitude. These values were to be
printed to a computer monitor.
2. When we ran the program, we did not receive any values as expected. The system never printed
out any values on the computer monitor. The GPS LED indicator showed that it did have a fix on
its current location and thus, it was working fine.
3. Since everything seemed to be working, we assumed that the problem was with our code.
4. We rewrote the program to something simpler. Borrowed code from online source which we knew
definitely worked.
11.1.3 Test 3: Sensor LV MaxSonar EZ4
1. The people who performed this test were Bradenand Jose.The sensors were able to pick up objects
wider than 11 inches at distance less than 24 ft. Objects smaller than 11 inches were picked up, but
only at shorter distances. For examples, a cylinder of width 5 inches was only able to be picked up
by the sensors at distances shorter than 10 ft.
2. The results were as expected and specified in the datasheet. The sensors have a range of 24 ft and
ranging time of 50 ms.
3. Since the sensors work better with large objects, they are perfect for our system.
4. Test sensors with moving objects.
11.1.4 Test 4: Sensor XL MaxSonar EZ01

6/12/2015 V1.4
47 of 107
1. The persons involved in the testing of this module were Jose and Braden. The sensors were able to
reject objects smaller than 11 inches in diameter. For objects larger than 11 inches, the sensorswere
able to pick them up at distances less than 34 ft.
2. The sensors worked as expected. They have a range of 3 4ft and ranging time of 100 ms.
3. This means that we are able obtain 10 distance samples per second.
4. Test sensors with moving object.
11.1.5 Test 5: Display Module/shift registers
Jose Ochoa
1. For this module, the person involved was Jose. To tests the module, we used an Arduino Uno. To
ensure that the wiring and code worked properly, we made the LCD screen output a string,
“HELLO”. The LCD was able to output this string.
2. Since the LCD screen outputted the correct string, we knew that the wiring and the library that we
created worked properly.
3. The module worked perfectly.
4. Nothing had to be changed.
11.1.6 Test 6: Timing scheme
Jose Ochoa
1. The person involved in the testing of this module was Jose. To test the module I used an Arduino,
oscilloscope, and severalLEDs. To see that the correct signals were being sent by the Arduino to
control each sensor’s ranging time, I used a set of 8 LEDs. When the system was executing Zone
1 monitoring only one LED was actively blinking. When the system was checking zone 1, 2, and
3, three LEDs were actively blinking. When the system was checking zone 4, only the LED con-
nected to sensor 6 was actively blinking. To check that the timing was accurate,I connected each
control signal to an oscilloscope and measured the output waveform. For the control signal of sen-
sor 1, the period was 150 ms and a duty cycle of 66 %. For the control signal of sensor 2 and 4, it
had a period of 150 ms and its duty cycle was 33 %. For the control signal of sensor 3 and 5, it had
a period of 150 ms and its duty cycle was 66 %. As for sensor 6, it had a period of 100 ms and duty
cycle of 50 %.
2. Each control signal performed as expected.
sensor period Duty cycle
1 150 ms 66%
2 150 ms 33%
3 150 ms 66%
4 150 ms 33%
5 150 ms 66%
6 100 ms 50%
Table 2
3. Since the results of the tests were as expected,no additional testing was required.

6/12/2015 V1.4
48 of 107
4. No additional test needed
11.1.7 Test 7: Zone 1 monitoring
1. The persons involved in the testing of this feature were Jose and Braden. The system did not respond
to changes in velocity. At speeds of 20MPH, the buzzer did not go off when the driver was 15ft from
the vehicle in front. No matter what the speed of the driver was, the system never warned the driver
when a vehicle was too close.
2. The system should have warned the driver of a possible collision when it was traveling at 20 MPH and
at a distance of 15 ft from the vehicle in front of it.
3. The GPS module never got a fix on its location and therefore never updated the velocity variable.
4. Place GPS module in a more open location.
1. The persons involved in the testing of this feature were Braden and Jose. The system was able to pick
up vehicles that were on the back end of the driver’s vehicle. Vehicles that were next to the center of
the driver’s vehicle were not picked up by the sensor.
2. The sensor should be able to pick up all vehicles in the blind spot.
3. Since the sensor’sfield of view wasleaning to the rearend of the vehicle, we had to change the position
angle.
4. We decide to set the field of view angle to 45 degrees from the car.
1. The persons involved in this testing were Jose and Braden. To test the module, we passed in front
of the sensors are different speeds. For the first time, we did not move after being in the field of
view of the sensor. This represented a vehicle staying at a constant velocity relative to the driver.
Next, we moved into the field of view of the sensor and walked back. This showed a negative
velocity in relative to the driver. Lastly, we moved into the field of view of the sensor and moved
towards it. This simulated a positive velocity in relations to the driver.
2. When staying still, we saw that the sensors calculated a 0 velocity. When moving back, the system
calculated that the vehicle wasmoving away from the driver at its respective velocity. Lastly, when
moving forward,the system calculated that the vehicle was moving at a positive velocity.
3. The system worked properly and as expected.
4. No further testing required.
1. The persons involved in the testing of this feature were Jose and Braden. To test the feature,we backed
up to a car which was parked. We started from 20 ft away and moved closer to it. At 20 ft, we measured
the distance that the vehicle was from the driver’s rear end. After wards, we observed what the LCD

6/12/2015 V1.4
49 of 107
screen displayed. We did this for interval of 5 ft. At 1 ft away from the vehicle, the system stopped
working properly.
2. At 20 ft from the vehicle, the system displayed 21 ft.As the driver got closer to the vehicle, the accuracy
of the sensorsgot better.At 5ft from the vehicle, the system displayed 5 ft. Distance closer than 6 inches
were displayed as 1 ft.
3. A dead zone of 6 inches in front of the sensors was expected because it was specified in the datasheet
of the sensors.
4. No actions needed to improve the system.
11.2 TestIteration 2
11.2.1 Test 1: Signal Conversion/Power Supply
Braden Kempton
1. Instead of a function generator to simulate vehicle turn signals, this time we connected our system
to a Honda Civic. This was done by splicing into the left/right rear turn signal wiring in the trunk.
Power was supplied through the cigarette lighter to simulate the 12 V input
2. Signal conversion and linear power supply circuitry performed as expected.
3. This verified the system was operational in an actual vehicle
4. Testing the system while driving was now possible.
11.2.2 Test 2: GPS and MCU
1. The persons who tested this module were both Braden and Jose. For our second test, we used the
Adafruit X1 GPS chip and Arduino Uno. To test the module, we ran a simple program that would
obtain the current location of the GPS module in terms of longitude and latitude. These values were
to be printed to a computer monitor.
2. When we ran the program, we observed GPS string data on the serial window (Arduino IDE) as
expected.
3. We now had a working GPS chip by replacing with one compatible with the Arduino Uno (baud
rate).
4. We can now test system response time with GPS input during the forward driving state.
11.2.3 Test 3: Sensor LV MaxSonar EZ4
1. The people who performed this test were Braden and Jose. As before,the sensors were able to pick
up objects wider than 11 inches at distance less than 24 ft. Objects smaller than 11 inches were
picked up, but only at shorter distances. For examples, a cylinder of width 5 inches was only able
to be picked up by the sensors at distances shorter than 10 ft.
2. The results were as expected and specified in the datasheet. The sensors have a range of 24 ft and
ranging time of 50 ms.
3. Since the sensors work better with large objects, they are perfect for our system. Results of the
sensors were better than expected with false detection being negligible in our system.
4. Test sensors with moving objects.

6/12/2015 V1.4
50 of 107
11.2.4 Test 4: Sensor XL MaxSonar EZ01
1. The persons involved in the testing of this module were Jose and Braden. As before, the sensors
were able to reject objects smaller than 11 inches in diameter. For objects larger than 11 inches, the
sensors were able to pick them up at distances less than 34 ft.
2. The sensors worked as expected. They have a range of 34ft and ranging time of 100 ms.
3. This means that we are able obtain 10 distance samples per second.
4. Test sensors with moving object.
5. The persons involved in the testing of this feature were Jose and Braden. While driving with the system
hardwired to a vehicle, a front sensor was attached to the front bumper.
6. The system responded better during this round of testing. Qualitatively, vehicles in front were detected
>80% of the time.
7. It is hard to discern whether detection failure was due to processing time or sensor data.
8. System working in realworld situation.
5. The persons involved in the testing of this feature were Braden and Jose. In an empty parking with
vehicle stationary with side and rear sensors attached,turn signal operation was conducted to ascertain
detection of vehicles in adjacent lanes.
6. The sensors pick up objects successfully in the blind spot.
7. Viewing angle was maintained at 45 degrees.
8. Successfuloperation.
1. The persons involved in the testing of this feature were Braden and Jose. In an empty parking with
vehicle stationary with side and rear sensors attached,turn signal operation was conducted to as-
certain detection of vehicles in adjacent lanes WITHIN the approach. In other words, we tested
detection by rear sensor to detect vehicles.
2. Again, sensor performance was reliable up to 30ft.
3. The system worked properly and as expected.
4. No further testing required.

6/12/2015 V1.4
51 of 107
5. The persons involved in the testing of this feature were Jose and Braden. Repeat of iteration one test.
6. At 20 ft from the vehicle, the system displayed 21 ft.As the driver got closer to the vehicle, the accuracy
of the sensors got better. At 5ft from the vehicle, the system displayed 5 ft. Distances were rounded up
to the nearest foot.
7. A dead zone of 6 inches in front of the sensors was expected because it was specified in the datasheet
of the sensors.
8. No actions needed to improve the system.

6/12/2015 V1.4
52 of 107
12 Administrative and Other Design Issues
12.1 ProjectManagement
Jose Ochoa
For the project, work was divided evenly between the both of us. Each week, we would each tackle a
problem or aspect of our project. For the most part, I was in charge of the software part of the project. I
worked on finding a way to determine the velocity of vehicles and dealing with interference between sen-
sors. Although we each had severaltask for several weeks,other weeks we worked together to solve prob-
lems or decide on alterations. For example, when looking for what sensors to use, we both did research on
this. We would then meet and compare and contrast what we found. At this point, we would determine
which sensors would work better for our purpose. Also, when Braden couldn’t make our first GPS module
work, I had to step in and tackle the problem. Since I was not able to find a solution, we had to spend some
time to figure out what else we could do to fix the problem. What I learned from working on this project
was how to manage a project. To complete our project, we had to have a precise schedule of what had to
be completed each week. Additionally, I learned that one should always strive to finish a project ahead of
time in order to give oneself extra time to make necessary changes.
12.2 Requirements traceability matrix
NA
12.3 Packaging and installation issues
NA
12.4 Design metrics to be used
NA
12.5 Restrictions,limitations,and constraints
NA

6/12/2015 V1.4
53 of 107
13 Conclusion and Future Work
13.1 Conclusion
This project was intended to design a low-cost collision prevention system for motor vehicles and to de-
velop a working prototype of such a product. To that end, this project was a success. The design was fully
implemented in the field and performed reliably. Some extra features were also added due to the addition
of a GPS shield. However,this addition also resulted in slower processing times. As a result, new design
consideration needs to be given to the type of microcontroller used for the system. Overall, the project
was successfuland should be considered for production.
13.2 Future Work
More controlled testing in the field. Sensor housing design and mounting hardware.
13.3 Acknowledgement
The people who contributed to our project were Dr. Amos, and representatives from Maxbotix. Dr. Amos
gave us suggest problems that we might encountered such as interference between sensors and how the
sensors should be placed. Some classmates guided us on the type of sensors that we should use. Initially,
we were planning on using Infrared sensors,but some of our classmates pointed out that they are not very
reliable on long distances. Lastly, representatives from Maxbotix guided us to the most appropriate sen-
sors for our purpose.

6/12/2015 V1.4
54 of 107
14 References
[5]G. Baddeley, 'GPS - NMEA sentence information', Aprs.gids.nl, 2015. [Online]. Available:
http://aprs.gids.nl/nmea/. [Accessed:26- Apr- 2015].
[4]D. Calin, D. Calin , D. Calin, D. Calin and D. Calin, 'Types of sensors for target detection and
tracking | Into Robotics', Into Robotics,2013. [Online]. Available: http://www.intorobotics.com/types-sen-
sors-target-detection-tracking/. [Accessed:26- Apr- 2015].
[6]D. DePriest, 'NMEA data', Gpsinformation.org, 2015. [Online]. Available: http://www.gpsinfor-
mation.org/dale/nmea.htm. [Accessed:26- Apr- 2015].
[8] Goshers.com, 'How it Works', 2015. [Online]. Available: http://www.goshers.com/how-it-works/. [Ac-
cessed:26- Apr- 2015].
[1]B. Gross, 'MaxBotix® Inc., Wonderful Innovations', Maxbotix.com, 2015. [Online]. Available:
[10] Infiniti USA, 'Learn More About the Infiniti Forward Emergency Braking System', 2015. [Online].
Available: http://www.infinitiusa.com/now/technology/forward-emergency-braking.html. [Accessed: 26-
Apr- 2015].
[9]C. Lampton, 'Blind Spot Monitoring Technologies - HowStuffWorks', HowStuffWorks,2015. [Online].
Available: http://auto.howstuffworks.com/car-driving-safety/safety-regulatory-devices/cars-making-blind-
spot-less-dangerous1.htm. [Accessed:26- Apr- 2015].
[7]u. unknown, 'Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates [Version 3] ID: 746 -
$39.95 : Adafruit Industries, Unique & fun DIY electronics and kits', Adafruit.com,2015. [Online]. Avail-
able: https://www.adafruit.com/products/746. [Accessed:26- Apr- 2015].
[2]S. Wielenberg, '3 Sensor Multi-Sensor Test and Results', Maxbotix.com, 2015. [Online]. Available:
[3]S. Wielenberg, 'MaxSonar SensorAcoustic Noise Tolerance Test', Maxbotix.com,2015. [Online]. Avail-
able: http://maxbotix.com/articles/012.htm. [Accessed:26- Apr- 2015].

6/12/2015 V1.4
55 of 107
15 Appendices
Appendix A: Parts List
Part Name quantity Price $
1 GPS module: Adafruit
Ultimate GPS
Breakout X1
1 34.00
2 74hc959 2 2.00
3 10k potentiometer 1 0.50
4 Arduino uno 2 50.00
5 XL-Maxsonar-EZ4 3 90.00
6 LV-Maxsonar-EZ01 3 150.00
7 LCD Module 1 5.00
8 Transistor 3 4.00
9 Voltage regulator 1 1.00
10 Diode 3 2.00
11 Fuse 1 1.00
12 1000 ohms resistor 6 2.00
13 10 uF capacitor 2 1.00
14 12 gauge wire 50 ft 10.00
Table 4
Appendix B:
Oscilloscope
Voltmeter
Adjustable direct voltage power supply
Appendix C:
Arduino IDE
Spark Design
Pspice
Appendix D:
None

6/12/2015 V1.4
56 of 107
Appendix E:
None
Appendix F:
Full Schematic of system:
Fig. 23

6/12/2015 V1.4
57 of 107
Appendix G:
Physical Components:
Fig. 24
Appendix H: Code ofMCU 1
#include <TimerOne.h>
////////////////////////////////////////////////////////////
//2nd shift register, pin 0 to 5 controll sensors,pin 6 to 7 controll lcd(rs,e)
unsigned char sensor_lcd_data = 0;
void bit_control(unsigned char pinnum, unsigned char onoff){

6/12/2015 V1.4
58 of 107
if(pinnum <= 7){
digitalWrite(11,LOW);
//digitalWrite(10,LOW);
//digitalWrite(12,LOW);
//digitalWrite(10,HIGH);
unsigned char i;
if (onoff == 1){
sensor_lcd_data = sensor_lcd_data | (0x01 << pinnum);
}
else{
sensor_lcd_data = sensor_lcd_data & ~(0x01 << pinnum);
}
for(i = 0; i <= 7; i++){
if (sensor_lcd_data & (0x01 << i)){
digitalWrite(12,HIGH);
}
else {
}
}
digitalWrite(11, HIGH);
}
}
////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////
//lCD control
void write_bus(unsigned char data){
digitalWrite(8, LOW);

6/12/2015 V1.4
59 of 107
unsigned char i;
for (i = 0; i <= 7; i++){
if (data & (0x01 << i)){
}
else {
}
}
digitalWrite(8, HIGH);
}
void LCD_ClearScreen(void) {
LCD_WriteCommand(0x01);
}
void LCD_init(void) {
//wait for 100 ms.
delay(100);
LCD_WriteCommand(0x0f);
delay(10);
}
void LCD_WriteCommand (unsigned char Command) {
bit_control(6,0);
write_bus(Command);
bit_control(7,1);

6/12/2015 V1.4
60 of 107
asm("nop");
bit_control(7,0);
delay(2); // ClearScreen requires 1.52ms to execute
}
void LCD_WriteData(unsigned char Data) {
bit_control(6,1);
write_bus(Data);
bit_control(7,1);
asm("nop");
bit_control(7,0);
delay(1);
}
void LCD_Cursor(unsigned char column) {
if ( column < 17 ) { // 16x1 LCD: column < 9
// 16x2 LCD: column < 17
LCD_WriteCommand(0x80 + column - 1);
} else {
LCD_WriteCommand(0xB8 + column - 9); // 16x1 LCD: column -
}
}
/////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////
//lcd print functions
const unsigned char moving_array[] = {'M', 'O','V','I', 'N','G'};
const unsigned char forward_array[] ={'F','O','R','W', 'A','R','D'};
void print_movingforward(void){
int i;
for(i = 0; i < 6; i++){
LCD_Cursor(i+ 1);
LCD_WriteData(moving_array[i]);

6/12/2015 V1.4
61 of 107
LCD_Cursor(i+ 17);
LCD_WriteData(forward_array[i]);
}
LCD_Cursor(23);
LCD_WriteData(forward_array[6]);
LCD_Cursor(33);
}
const unsigned char dont_change_lane_array[] = {'C','H','A','N','G','I','N','G'};
const unsigned char lanes_arrayright[] = {'L','A','N','E',' ','T','O',' ','R','I','G', 'H','T'};
void print_changinglaneright(void){
int i;
for(i = 0; i < 8; i++){
LCD_Cursor(i+ 1);
LCD_WriteData(dont_change_lane_array[i]);
}
for(i = 0; i < 13; i++){
LCD_Cursor(i+ 17);
LCD_WriteData(lanes_arrayright[i]);
}
LCD_Cursor(33);
}
const unsigned char lanes_arrayleft[] = {'L','A','N','E',' ','T','O',' ','L','E','F', 'T'};
void print_changinglaneleft(void){
int i;
for(i = 0; i < 8; i++){
LCD_Cursor(i+ 1);
LCD_WriteData(dont_change_lane_array[i]);
}
for(i = 0; i < 12; i++){
LCD_Cursor(i+ 17);
LCD_WriteData(lanes_arrayleft[i]);

6/12/2015 V1.4
62 of 107
}
LCD_Cursor(33);
}
const unsigned char moving_back[] = {'M','O','V','I','N','G',' ','B','A','C','K'};
const unsigned char distance[] = {'D','I','S','T','A','N','C','E','(','f','t',')',':'};
void print_backdistance(void){
int i;
for(i = 0; i < 11; i++){
LCD_Cursor(i+1);
LCD_WriteData(moving_back[i]);
}
for(i = 0; i < 13; i++){
LCD_Cursor(i+17);
LCD_WriteData(distance[i]);
}
LCD_Cursor(33);
}
const unsigned char forward[] = {'S', 'T','A', 'R','T', 'I','N','G'};
const unsigned char backwards[] ={'S', 'Y','S', 'T','E', 'M'};
void print_initial(void){
int i;
for(i = 0; i < 8; i++){
LCD_Cursor(i+1);
LCD_WriteData(forward[i]);
}
for(i = 0; i < 6; i++){
LCD_Cursor(i+17);
LCD_WriteData(backwards[i]);
}
LCD_Cursor(33);
}

6/12/2015 V1.4
63 of 107
const unsigned char not_movingarray[] = {'S','T','O','P','P','E','D'};
void print_notmoving(void){
int i;
for(i = 0; i < 7; i++){
LCD_Cursor(i+1);
LCD_WriteData(not_movingarray[i]);
}
LCD_Cursor(33);
}
////////////////////////////////////////////////////////////////////////////////////////////
/////////////////////////////////////////////////////////////////////////////////////////////
//sensor 1, velocity function, filter of values, 2 most current distances (long distance sensor)
//global variables
unsigned short sensor1_samples[7] = {0, 0, 0, 0, 0, 0, 0};
unsigned short sensor1_dist[2] = {0, 0};
//push in new value to array of values
void sensor1_pushnew(unsigned short value1){
sensor1_samples[0] = sensor1_samples[1];
sensor1_samples[6] = (value1 * 2)/30; //values saved in ft
//Serial.println((2 * value1)/30);
}

6/12/2015 V1.4
64 of 107
//find the median value and add to stoarge array
void sensor1_median(void){
unsigned char i;
unsigned short array1[7] = {0, 0, 0, 0, 0, 0, 0};
for (i = 0; i <= 6; i++){
array1[i] = sensor1_samples[i];
}
unsigned short tmp;
unsigned char j;
unsigned char num = 7;
for(i = 0; i < num; i++){
for(j = 0; j < (num-i-1); j++){
if(array1[j] > array1[j+1]){
tmp = array1[j];
array1[j] = array1[j + 1];
array1[j + 1] = tmp;
}
}
}
//add mediam to array
sensor1_dist[0] = sensor1_dist[1];
sensor1_dist[1] = array1[3];
//Serial.println(sensor1_dist[1]);
}
//current speed of car
unsigned char currentCarSpeed = 15;
//retrun 1 for collision possible, 0 for safe
unsigned char sensor1_velocity(void){
if (currentCarSpeed == 0){
if (sensor1_dist[1] < 2){
return 1;

6/12/2015 V1.4
65 of 107
}
}
else if(currentCarSpeed == 1){
if(sensor1_dist[1] < 3){
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}

6/12/2015 V1.4
66 of 107
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}

6/12/2015 V1.4
67 of 107
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}
return 1;
}
}

6/12/2015 V1.4
68 of 107
return 1;
}
}
return 1;
}
}
else {
if (sensor1_dist[1] < 34){
return 1;
}
}
return 0;
}
/////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////
// sensor 2(blind spot), distance measuring, filter of values,
unsigned short sensor2_dist;

6/12/2015 V1.4
69 of 107
sensor2_samples[6] = value1 / 2;
//Serial.println(value1/2);
}
unsigned char i;
unsigned short array[7];
for (i = 0; i <= 6; i++){
array[i] = sensor2_samples[i];
}
unsigned short tmp;
unsigned char j;
for(i = 0; i < num; i++){
for(j = 0; j < (num-i-1); j++){
if(array[j] > array[j+1]){
tmp = array[j];
array[j] = array[j + 1];
array[j + 1] = tmp;
}
}
}
//place in sensor2_dist variable
sensor2_dist = array[3];
}
const unsigned short proximity_limit = 220; // distance limit
unsigned char sensor2_distance_check(void){
if (proximity_limit > sensor2_dist){

6/12/2015 V1.4
70 of 107
return 1;
}
else {
return 0;
}
}
///////////////////////////////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////
//sensor 3: median function, velocity function
//global variables
unsigned short sensor3_dist[2] = {0, 0};
sensor3_samples[6] = value1*2;
//Serial.println(value1*2);
}
unsigned char i;
for (i = 0; i <= 6; i++){

6/12/2015 V1.4
71 of 107
}
unsigned short tmp;
unsigned char j;
for(i = 0; i < num; i++){
for(j = 0; j < (num-i-1); j++){
tmp = array[j];
array[j] = array[j + 1];
array[j + 1] = tmp;
}
}
}
//add mediam to array
sensor3_dist[0] = sensor3_dist[1];
sensor3_dist[1] = array[3];
}
//retrun 1 for collision possible, 0 for safe
unsigned char sensor3_velocity(void){
unsigned short distance_diff = 0;
if (sensor3_dist[0] > sensor3_dist[1]){
distance_diff = sensor3_dist[0] - sensor3_dist[1];
if(distance_diff >= 134) { //velocity is greater than 5 MPH
return 1; //time interval is 6/10 s
}
else {
return 0;
}
}
else {
return 0;
}
}

6/12/2015 V1.4
72 of 107
///////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////
// sensor 4(right side blind spot), distance measuring, filter of values,
unsigned short sensor4_dist;
sensor4_samples[6] = value1 / 2;
//Serial.println(value / 2);
}
unsigned char i;
for (i = 0; i <= 6; i++){
}
unsigned short tmp;
unsigned char j;
for(i = 0; i < num; i++){
for(j = 0; j < (num-i-1); j++){

Jochoa_Bkempton_EE175_report_v14

Jochoa_Bkempton_EE175_report_v14

Recommended

Recommended

More Related Content

Similar to Jochoa_Bkempton_EE175_report_v14

Similar to Jochoa_Bkempton_EE175_report_v14 (20)

Jochoa_Bkempton_EE175_report_v14