CALVIN COLLEGE ENGINEERING DEPARTMENT
SENIOR DESIGN PROJECT
Project Proposal and
Feasibility Study
Team 13 – The Smart Dashboard
Andrew DeZeeuw, Micah Dykstra, Nathan Gelderloos
February 8, 2012
© 2013, Calvin College and Andrew DeZeeuw, Micah Dykstra, Nathan Gelderloos
Executive Summary
The proposed senior design project is to design multiple car safety systems that an automotive
manufacturer could easily install. The team has split the project into three sub projects: the rapid
deceleration warning, speed limit indicator, and driver awareness sensor.
The goal of the rapid deceleration warning is to warn other cars that the driver is stopping
suddenly and that the other drivers should apply their brakes to avoid an accident.
The goal of the speed limit indicator is to provide an easy way to determine the speed limit on the
current road to promote safe driving speeds and prevent impromptu meetings with an officer.
The goal of the driver awareness sensor is to monitor the driver and determine when the driver is
becoming less aware of the surroundings due to drowsiness. This system will then notify the driver
that corrective action is necessary to prevent possible accidents.
Table of Contents
1
Project Introduction ...............................................................................................................................................................1
1.1
Problem Statement .......................................................................................................................................................1
1.2
Project .................................................................................................................................................................................1
1.3
Team Members ...............................................................................................................................................................1
1.3.1
Andrew DeZeeuw ................................................................................................................................................1
1.3.2
Micah Dykstra .......................................................................................................................................................2
1.3.3
Nathan Gelderloos ..............................................................................................................................................2
1.4
2
3
4
Report structure.............................................................................................................................................................2
Project Management ..............................................................................................................................................................3
2.1
Team Organization .......................................................................................................................................................3
2.2
Schedule .............................................................................................................................................................................3
2.2.1
Milestones ...............................................................................................................................................................3
2.2.2
Work Breakdown Schedule............................................................................................................................4
2.2.3
Current Progress .................................................................................................................................................4
2.3
Method of Approach.....................................................................................................................................................4
2.4
Risk .......................................................................................................................................................................................4
System Overview .....................................................................................................................................................................6
3.1
Rapid Deceleration Warning ...................................................................................................................................6
3.2
Driver Awareness Sensor ..........................................................................................................................................6
3.3
Speed Limit Indicator ..................................................................................................................................................6
Objectives and Requirements ...........................................................................................................................................8
4.1
Common Objectives and Requirements ............................................................................................................8
4.1.1
Requirements ........................................................................................................................................................8
4.1.2
Objectives ................................................................................................................................................................9
4.2
Speed Limit Indicator ..................................................................................................................................................9
4.2.1
Requirements ........................................................................................................................................................9
4.2.2
Objectives .............................................................................................................................................................10
4.3
Driver Awareness Sensor .......................................................................................................................................10
4.3.1
Requirements .....................................................................................................................................................10
i
4.3.2
4.4
Requirements .....................................................................................................................................................12
4.4.2
Objectives .............................................................................................................................................................13
Caring .....................................................................................................................................................................13
4.5.2
Trustworthy ........................................................................................................................................................13
4.5.3
Transparency .....................................................................................................................................................14
System Architecture - Rapid Deceleration Warning ..........................................................................................15
Overall System .............................................................................................................................................................15
5.1.1
Determining Vehicle Deceleration ..........................................................................................................15
5.1.2
Comparing Data ................................................................................................................................................15
5.1.3
Flashing the Brake Lights.............................................................................................................................16
5.2
Hardware System Design .......................................................................................................................................16
5.2.1
Accelerometer ....................................................................................................................................................17
5.2.2
Microcontroller .................................................................................................................................................19
5.3
Initial Printed Circuit Board Design..................................................................................................................22
5.4
Software System Design..........................................................................................................................................23
System Architecture - Driver Awareness Sensor .................................................................................................24
6.1
Overall System Design .............................................................................................................................................24
6.1.1
Determining Prolonged Eye Closure ......................................................................................................24
6.1.2
Alerting Driver ...................................................................................................................................................24
6.2
Hardware System Design .......................................................................................................................................24
6.2.1
Camera ................................................................................................... Error! Bookmark not defined.
6.2.2
Microcontroller .................................................................................................................................................26
6.2.3
Speaker ..................................................................................................................................................................27
6.2.4
Facial Illuminator .............................................................................................................................................27
6.2.5
Voltage Regulator .............................................................................................................................................27
6.3
7
Design Norms ...............................................................................................................................................................13
4.5.1
5.1
6
Rapid Deceleration Warning ................................................................................................................................12
4.4.1
4.5
5
Objectives .............................................................................................................................................................11
Software System Design..........................................................................................................................................27
System Architecture - Speed Limit Indicator .........................................................................................................29
7.1
Overall System Design .............................................................................................................................................29
ii
7.1.1
Determining Vehicle Location ...................................................................................................................29
7.1.2
Finding the Speed Limit ................................................................................................................................30
7.1.3
Storing the Speed Limits...............................................................................................................................30
7.1.4
Outputting the Speed Limit .........................................................................................................................31
7.2
7.2.1
GPS ...........................................................................................................................................................................33
7.2.2
Microcontroller .................................................................................................................................................36
7.2.3
Memory .................................................................................................................................................................36
7.2.4
Outputs ..................................................................................................................................................................37
7.3
8
Hardware System Design .......................................................................................................................................32
Software System Design..........................................................................................................................................37
7.3.1
Criteria ...................................................................................................................................................................38
7.3.2
Alternatives .........................................................................................................................................................39
7.3.3
Decisions ...............................................................................................................................................................39
Integration and Initial Testing .......................................................................................................................................40
8.1
Common Tests..............................................................................................................................................................40
8.1.1
Testing Method..................................................................................................................................................40
8.1.2
Initial Test Results ...........................................................................................................................................40
8.1.3
Future Testing....................................................................................................................................................40
8.1.4
Current Integration .........................................................................................................................................40
8.2
Rapid Deceleration Warning ................................................................................................................................41
8.2.1
Testing Method..................................................................................................................................................41
8.2.2
Initial Test Results ...........................................................................................................................................41
8.2.3
Future Testing....................................................................................................................................................41
8.2.4
Current Integration .........................................................................................................................................41
8.3
Driver Awareness Sensor .......................................................................................................................................41
8.3.1
Testing Method..................................................................................................................................................41
8.3.2
Initial Test Results ...........................................................................................................................................42
8.3.3
Future Testing....................................................................................................................................................42
8.3.4
Current Integration .........................................................................................................................................42
8.4
Speed Limit Indicator ...............................................................................................................................................42
8.4.1
Testing Method..................................................................................................................................................42
iii
9
8.4.2
Initial Test Results ...........................................................................................................................................43
8.4.3
Future Testing....................................................................................................................................................46
8.4.4
Current Integration .........................................................................................................................................46
Business Plan ..........................................................................................................................................................................47
9.1
Business Strategy .......................................................................................................................................................47
9.1.1
9.2
Customer...............................................................................................................................................................47
Marketing Study ..........................................................................................................................................................47
9.2.1
Competition .........................................................................................................................................................47
9.2.2
Market Survey ....................................................................................................................................................47
9.3
Cost Estimate ................................................................................................................................................................48
9.3.1
Prototype Budget .............................................................................................................................................48
9.3.2
Production Budget ...........................................................................................................................................48
9.4
10
Estimated Profits ........................................................................................................................................................50
Conclusions .........................................................................................................................................................................52
10.1
Project Feasibility.......................................................................................................................................................52
10.2
Current Status ..............................................................................................................................................................52
10.2.1
Rapid Deceleration Warning ......................................................................................................................52
10.2.2
Driver Awareness Sensor.............................................................................................................................52
10.2.3
Speed Limit Indicator .....................................................................................................................................52
11
Credits and Acknowledgements ..............................................................................................................................53
12
References ...........................................................................................................................................................................54
iv
Table of Figures
Figure 1. RDW System Diagram .................................................................................................................................................6
Figure 2. SLI System Diagram......................................................................................................................................................7
Figure 3. Microcontroller Architecture [42] .....................................................................................................................16
Figure 4. RDW Hardware Diagram ........................................................................................................................................17
Figure 5. Initial PCB Layout. Parts listed in Table 6 ......................................................................................................22
Figure 6. RDW Software Diagram ..........................................................................................................................................23
Figure 7. DAS Hardware Diagram ..........................................................................................................................................25
Figure 8. DAS Software Diagram.............................................................................................................................................28
Figure 9. Breakdown of Road Types [17] ...........................................................................................................................31
Figure 10. Normal Speedometer [18]...................................................................................................................................32
Figure 11. Speedometer with Speed Limit of 40 Miles Per Hour [18] ................................................................32
Figure 12. SLI Hardware Diagram..........................................................................................................................................33
Figure 13. SLI Software Diagram ............................................................................................................................................38
Figure 14. GPS Accuracy Data for the First Test .............................................................................................................44
Figure 15. Second GPS Test, Mapped to Google Maps .................................................................................................45
Figure 16. Third GPS Accuracy Test, Mapped to Google Maps ................................................................................45
Figure 17. Third GPS Accuracy Test, Close-Up On Downtown Ann Arbor ........................................................46
v
Table of Tables
Table 1. Signals used in Figure 5.............................................................................................................................................17
Table 2. Accelerometer Alternatives ....................................................................................................................................19
Table 3. Accelerometer Decision Matrix .............................................................................................................................19
Table 4. Microcontroller Alternatives ..................................................................................................................................21
Table 5. Microcontroller Decision Matrix ..........................................................................................................................21
Table 6. Table of Components for Figure 5 .......................................................................................................................22
Table 7. DAS Microcontroller Alternatives ........................................................................................................................26
Table 8. DAS Microcontroller Decision Matrix ................................................................................................................27
Table 9. Signals Used In Figure 12 .........................................................................................................................................33
Table 10. GPS Alternatives .........................................................................................................................................................35
Table 11. Decision Matrix for GPS Selection .....................................................................................................................35
Table 12. Prototype Budget .......................................................................................................................................................48
Table 13. Expected Variable Costs for the Production Model .................................................................................49
Table 14. Expected One-Time Fixed Costs for the Production Model .................................................................49
Table 15. Amortized One-Time Costs ...................................................................................................................................49
Table 16. Fixed Annual Costs ....................................................................................................................................................50
Table 17. Estimated Profits for the Production Model ................................................................................................51
vi
1
Project Introduction
1.1
Problem Statement
According to a recent study by the National Highway Traffic Safety Administration, driver
distraction causes 80% of all automotive accidents [1]. However, most of the safety features that
automotive makers are introducing to vehicles today are doing nothing to address this staggering
statistic. In fact, new safety features often go the other way, encouraging more aggressive and
distracted driving because they make drivers feel invincible. More airbags will help to limit the
damage from an accident, but they will not help to prevent the accident from occurring in the first
place. In order to avoid accidents, drivers need to feel more responsibility and pay better attention
to their surroundings.
1.2
Project
The Smart Dashboard team proposes to address this problem by designing and building three
automotive safety functions designed to increase driver alertness and decrease the number of
accidents caused by driver distraction. The first function will be a system that flashes (or pulses)
the brake lights of the vehicle when the deceleration of the vehicle is above a certain rate. This
should decrease the frequency of rear-end collisions by alerting the following driver that the
vehicle ahead of them is decelerating rapidly. The second function will be a system that finds the
speed limit of the road the vehicle is currently on and display that information on the speedometer.
This should decrease speeding by displaying to the driver both their speed and the legal limit in the
same place. The third function will be a system that monitors the driver for signs of falling asleep. If
the system determines that the driver is falling asleep, the system will issue a warning to the driver
so that the driver can wake up.
1.3
Team Members
The senior design team is comprised of three engineering students in the electrical and computer
concentration.
1.3.1
Andrew DeZeeuw
Andrew is a senior engineering student in the electrical and computer
concentration at Calvin College. Andrew is also planning to minor in mathematics.
He is currently working at Calvin as a grader for the computer science department
and a tutor for calculus. Andrew has had research experience in each of the two
previous summers. In the summer of 2011, he worked in the AOSS department at
the University of Michigan, and in the summer of 2012, he worked in the ECE
department at Carnegie Mellon University. Andrew is involved with various music
groups on campus, from playing percussion in the Calvin Wind Ensemble to leading worship for
Calvin’s chapel services. In addition to music, Andrew also enjoys playing sports recreationally and
follows Michigan football. After graduation, Andrew hopes to attend graduate school studying
computer architecture.
1
1.3.2
Micah Dykstra
Micah is a senior engineering student in the electrical and computer concentration
at Calvin College. He is also pursuing a minor in computer science. Micah is
currently working at Calvin as a grader for a software engineering class. He has
worked as an intern at Shape Corporation in Grand Haven, Michigan in the
summer of 2012. There he gained a greater appreciation for the electrical
engineering design process. Micah especially enjoys writing code and designing
user interfaces for software applications and he hopes that he can apply these
skills to the project. In his free time, Micah also enjoys watching hockey and following the Detroit
Red Wings. Micah is unsure of his plans after graduation, but he is applying for a number of
computer engineering positions in the West Michigan area.
1.3.3
Nathan Gelderloos
Nathan is a senior engineering student in the electrical and computer
concentration at Calvin College. He is also pursuing a computer science minor.
Nathan has worked at GE Aviation Systems in Grand Rapids, MI as an engineering
intern. He has also created a widely used program for scheduling classes at Calvin
College, along with a handful of other colleges. In his free time, he enjoys playing
the guitar and squirrel hunting.
1.4
Report structure
This report explains in detail the project management, system overview, objectives and
requirements, system architectures, integration and initial testing, and business plan.
The project management section discusses how the team assigns tasks and operates. The system
overview section provides a brief overview of the project and background information on the
project areas. The objectives and requirements section contains the end requirements for the
project as well as any objectives that the team should achieve. The system architecture sections
discuss each function in depth, providing design criteria, alternatives and decisions at the system,
hardware, and software levels. The integration and initial testing section discusses the testing
process for each function and includes initial test results. The business plan section analyzes the
production model, with an anticipated budget for both the prototype and the production model.
The business plan considers the market as a whole, and identifies competition in the marketplace
for our product. The report concludes with a conclusion determining the feasibility of the project.
2
2
Project Management
2.1
Team Organization
Each team member is in charge of one function for the project. Micah is in charge of the rapid
deceleration warning, Nathan is in charge of the driver awareness sensor, and Andrew is in charge
of the speed limit indicator. The team expects each member to help with all three functions, but the
majority of their work will be on the function they are leading.
Micah is the team webmaster, Andrew is the content editor for written documents, and Nathan is
the style editor for written documents. The team uses Google Docs extensively to organize the team,
and allows multiple members to work on the same document on different computers
simultaneously.
2.2
Schedule
A large project like this needs a schedule so that the team meets deadlines and continues to make
progress. For the duration of the project, the team will give weekly status reports to their project
advisor, Professor Steve VanderLeest. These updates will help the team realize what each team
member has accomplished and hopes to accomplish in upcoming weeks.
2.2.1
Milestones
The major milestones of this project will be software development, prototype construction, and
final testing. These milestones will provide the team with motivation to accomplish tasks on time.
2.2.1.1 Software
The first milestone will be the development of the software for each of the three functions. The
initial iteration of this process is simply to achieve communication between the different
components of the system. The next step will be to test that the software meets the basic
requirements of the system. At this point, the team can integrate the software into a working
prototype of the system. The team hopes to accomplish initial software development by
1/31/2013.
2.2.1.2 Prototype
The second milestone will be the construction of the prototype for each of the three functions. The
initial iteration of this process is to achieve a simple ‘mock-up’ or bench-top model that provides
proof of concept. The next step will be to build a prototype that resembles the final product in both
aesthetics and its function. The team hopes to be at this stage of the project by 3/31/2012.
2.2.1.3 Final Testing
The third milestone will be the final testing of each of the three functions. At this time, the
prototypes of each of the systems should be complete. These tests will ascertain whether the safety
functions meet the requirements and objectives. The team hopes to begin final testing by
4/31/2012.
3
2.2.2
Work Breakdown Schedule
The team is utilizing a work breakdown schedule to schedule the time commitment required for
each individual aspect of the project. It is currently separated by the major headings of
‘Reports/Presentations’, ‘Design’, and ‘Testing’. Each of the project functions then further
subdivides each of these sections. Most of the tasks on the schedule are ten hours of work or less so
that each task is specific and manageable. The full work breakdown schedule of the project is
available at The Smart Dashboard’s website: http://www.calvin.edu/academic/engineering/201213-team13/docs.html.
2.2.3
Current Progress
As of 12/6/2012, the team has logged about 216 hours of work. The team has completed initial
research estimated at 17 hours per function. The team has also completed the feasibility study,
which they estimated to take approximately 130 hours. The team has also completed other
deliverables estimated to take 30 hours. Therefore, the total estimated time for the tasks
completed is 201 hours. Compared to the 216 hours of actual work to accomplish these tasks, the
error percentage in these estimates is only about 7%.
The team’s work breakdown schedule estimates that the total project will take a total of 627 hours
to complete. Therefore, the team’s estimation for percentage completion of the project is
approximately 34%.
2.3
Method of Approach
The team’s method of approach is an iterative process. Each member did initial research and
generated block diagrams for their system. Requirements for the system were determined based on
more in-depth research. Parts were determined through decision matrices, at which point the team
ordered a first round of parts. Initial testing of those parts helped refine the block diagrams and
requirements. That process repeats as the system becomes more refined with each iteration. The
team members have made sure to keep in contact with other team members on decisions made
throughout the project. Each member is aware of the other functions and will review the various
decisions that the team needs to make. This helps expand the knowledge base for the whole
function, as the group has a wide variety of talents and experiences.
2.4
Risk
The bulk of the work for this project is software that will analyze the data given by various sensors.
The risk in this project is limited, so long as the hardware communicates properly with the
microcontroller. The hardware communication is something that can be determined early in the
process. Therefore, the largest hardware risk is going over budget by purchasing too much
hardware that does not communicate with the microcontrollers selected. Once the hardware is
selected and functioning properly, the remainder of the work for this project consists of writing
code. A possible hardware risk is to purchase an underperforming processor. If the processor
cannot keep up with the demands of the software, the design will not work properly. This is
especially an issue with the Driver Awareness Sensor.
4
The largest software risk is that our software does not do what it is required to do. This is highly
unlikely, given the time that the team will spend developing the software. If this project does not
succeed, it is because the team did not spend enough time on the code, so the software can only
complete a fraction of the overall goals of the project.
There is a risk of the human-machine interface not working properly. If people do not intuitively
understand the function of our design, then the design is useless. The team means for this project to
help people, and this project can only help when people realize how to be helped. Further research
will ensure that the majority of the users will interpret our design properly.
5
3
System Overview
This section gives a brief look at the system architecture for each of the three functions.
3.1
Rapid Deceleration Warning
For a more detailed look at the Rapid Deceleration Warning (RDW) function’s system architecture,
refer to Chapter 5 (System Architecture - Rapid Deceleration Warning). The basic functionality of
the RDW is to flash the brake lights of a vehicle if it is decelerating at a high rate. The RDW system
has three distinct components, as shown in the basic system block diagram given in Figure 1.
Figure 1. RDW System Diagram
The accelerometer reads in values for position and sends that data to the microcontroller. The
microcontroller then processes this data, converting it to usable deceleration data, comparing the
deceleration to a certain threshold, and outputting a pulsed signal at the desired frequency if the
deceleration is above that threshold. This pulsed signal is sent to the brake lights to make them
flash at the same frequency. The exact interface with the current braking infrastructure is currently
unknown. The team will have a full analysis of this interface in the next report.
3.2
Driver Awareness Sensor
The Driver Awareness Sensor (DAS) will alert the driver to unsafe driving conditions due to
drowsiness of the driver. A camera will send real-time images of the driver to a microcontroller.
The microcontroller will analyze the images for signs of drowsiness and generate an alert to wake
the driver.
3.3
Speed Limit Indicator
For a more detailed look at the Speed Limit Indicator (SLI) function’s system architecture, refer to
Chapter 7 (System Architecture - Speed Limit Indicator). The basic functionality of the SLI is to
display the speed limit for the current road on the speedometer of the vehicle. The SLI has four
distinct components, as shown in the basic system block diagram given in Figure 2. The addition of
sound response to driver speeding was not considered in this report, but will be considered on
future reports.
6
Figure 2. SLI System Diagram
The GPS unit computes position data (latitude, longitude, and altitude), speed and direction and
sends this information to the microcontroller. The microcontroller then analyzes the input values
and determines the GPS coordinate of the nearest speed limit sign. The microcontroller then
accesses the speed limit database to determine the speed limit for the particular GPS coordinate.
The microcontroller then outputs a signal to the display on the speedometer.
7
4
Objectives and Requirements
4.1
Common Objectives and Requirements
Some of the objectives and requirements for this project are common among the three functions.
They are listed in the section below. The objective and requirements specific to each function are
listed in the subsequent sections.
4.1.1
Requirements
4.1.1.1 Power
Requirement 1: The 12-volt battery within the vehicle shall power each safety function.
Explanation: This allows the device to run on standard vehicles produced in the United States and
Europe.
Requirement 2: Each safety function shall be able to function with a power voltage in the range
from 9 volts to 15 volts.
Explanation: Batteries do not always operate at 12 volts. The voltage in batteries decreases over
time, while batteries can also be overcharged. A charged battery is generally 12.5 volts without the
engine. When the engine is running, a voltage regulator keeps the voltage between 13.5 and 14.5
volts [36]. Working within 3 volts of the standard allows operation with most battery conditions.
4.1.1.2 Climate
Requirement 1: Each safety function shall be able to operate with a temperature in the range from
(-20) to 70 degrees Celsius.
Explanation: From Requirement 1 in Section Error! Reference source not found., the components
will be housed inside the vehicle, so the device needs to function with all interior temperatures of
the vehicle. On startup, temperatures vary wildly, and the device still should function.
4.1.1.3 Reliability
Requirement 1: Each safety function shall have a minimum lifetime of 15 years.
Explanation: The average lifetime of a personal vehicle on the road today is just under 11 years and
trending upward [2], so 15 years seems like a reasonable minimum lifetime for this device.
Requirement 2: Each safety function shall not interfere with normal vehicle operation if it should
fail.
Explanation: The brake lights and speedometer of the vehicle should still operate normally if the
device is not present. This should also remain true if the device has failed yet is still present in the
vehicle.
4.1.1.4 System
Requirement 1: Each safety function shall not obstruct the view of the driver.
Explanation: As these functions are meant for driver safety, none of the functions should obstruct
the driver and make their normal operations unsafe.
8
4.1.1.5 Hardware
Requirement 1: The production model of the system shall operate on one microprocessor.
Explanation: This will keep the cost low enough to market the device, and will increase the
efficiency of the device by putting all of the components on one board.
4.1.2
Objectives
4.1.2.1 Power
Objective 1: Each safety function shall draw less than 200 mA from the vehicle’s battery.
Explanation: This is equivalent to 12V * 0.2A = 2.4 watts maximum per device, or approximately 7
watts total. We want to minimize the power consumption, so any value less than 7 watts would also
be acceptable.
4.1.2.2 Cost
Objective 1: The total project cost for the prototype shall be below $500.
Explanation: This satisfies the budget requirement as determined by the Senior Design faculty
advisors.
Objective 2: The total project cost for the production model will be below $100 per unit when
producing 25,000 units per year.
Explanation: While certain costs increase for production, the total production cost could go down
by using less expensive components purchased in bulk as well as using only one microprocessor.
4.2
Speed Limit Indicator
4.2.1
Requirements
4.2.1.1 System
Requirement 1: The Speed Limit Indicator shall have only the speed display visible to the user.
Explanation: The hardware components will be hidden from the user to ensure driver safety and
device lifetime. There must be some output to the user to tell them the speed limit of the road they
are currently on.
Requirement 2: The Speed Limit Indicator shall display different colors to the user depending on
the vehicle’s speed in comparison to the speed limit.
Explanation: If the driver is going more than 10 mph over the speed limit, the color of the LED
currently displayed will change color, to show the user that they are significantly over the current
speed limit.
4.2.1.2 Hardware
Requirement 1: The Speed Limit Indicator prototype shall contain sufficient memory to hold the
program and a database of local speed limits.
Explanation: For the prototype, only a 2-mile radius around Calvin College will be considered for
mapping purposes. A worst case scenario requires 8 kilobytes (see Sec 7.2.3.1) for 80,000 miles of
road. The memory necessary to hold that data is smaller than the production model.
9
Requirement 2: The Speed Limit Indicator production model shall contain sufficient memory to
hold a database of the United States speed limits.
Explanation: For the production model, the entire nation’s speed limit signs need to be stored. We
are only considering the United States since they use miles per hour, which is what our output to
the LEDs will be given in.
4.2.1.3 Software
Requirement 1: The Speed Limit Indicator shall identify the speed limit of the road the vehicle is
currently travelling within two seconds of entering that road.
Explanation: This is the basic requirement for this function. The code will take in a GPS coordinate
and find the nearest speed limit then make sure that it is from the road they are currently
travelling. Two seconds accounts for turns onto streets, where the reaction time may be slowed.
Requirement 2: The Speed Limit Indicator production model database shall self-update every
week.
Explanation: Speed limits change occasionally, so updates are necessary. However, if the function
were to change based on construction, more frequent updates would be necessary.
Requirement 3: The Speed Limit Indicator shall not change the speed limit if the system is unsure
what road the vehicle is currently travelling.
Explanation: If an unknown value comes in, the function should not change the speed limit. This
situation could occur at intersections or bridges, where the GPS signal is weak or nonexistent. The
function should assume that the vehicle is continuing on the same road until the function is
determines that the vehicle has changed roads.
Requirement 4: The user will have the option to turn off the Speed Limit Indicator function.
Explanation: This function is not necessary for driver safety, although it should improve safety.
However, if the function makes the driver more distracted, the driver should have the option to
turn it off and on as they please.
4.2.2
Objectives
4.2.2.1 System
Objective 1: The Speed Limit Indicator’s LED lights shall not be uncomfortable to see for the user.
Explanation: While the LEDs need to be visible to the driver at all times of the day, it must not be
uncomfortable to see, as this would be counterintuitive to the goal of the Speed Limit Indicator.
4.3
Driver Awareness Sensor
4.3.1
Requirements
4.3.1.1 System
Requirement 1: The Driver Awareness Sensor shall determine the following symptom of
drowsiness: prolonged eye closure.
Explanation: Prolonged eye closure is one of the primary symptoms of drowsiness [37].
10
Requirement 2: Prolonged eye closure is defined as the eyes being closed for more than one
second.
Explanation: The average blink is between 0.3 and 0.4 seconds [38]. Therefore, one second is much
longer than the average blink. At 60 mph, a vehicle travels 88 feet in one second, which is a
considerable distance not to be paying attention.
Requirement 3: The Driver Awareness Sensor shall generate an audible signal to alert the driver
that they are falling asleep.
Requirement 4: The Driver Awareness Sensor camera shall be located where the camera can
gather accurate data without obstructing the driver’s view.
Explanation: The team intends this device to improve the safety of the driver and the vehicle.
Causing any unnecessary distractions, such as obstructing the driver’s view, would defeat the
purpose of the device and could cause more safety concerns than it addresses.
4.3.1.2 Hardware
Requirement 1: The audible alert shall be a pulsing signal around 90dB.
Explanation: The alert must be loud enough to get the attention of the driver and overcome other
sounds from the environment. This sound level is very high and should be sufficient to get the
attention of most people [39].
4.3.2
Objectives
4.3.2.1 System
Objective 1: The Driver Awareness Sensor shall accurately report drowsiness at least 95% of the
time.
Explanation: The ideal case is to report all drowsiness events. However, this is not always possible
due to uncontrollable circumstances. Therefore, the system should be very reliable in general, such
that the user can trust the system to perform as intended.
4.3.2.2 Hardware
Objective 1: The Driver Awareness Sensor’s camera enclosure shall be water resistant.
Explanation: While it is unlikely the user will place the camera in a wet environment, if the camera
enclosure is exposed to water, the camera should continue to function properly.
4.3.2.3 Software
Objective 1: The Driver Awareness Sensor shall signal an alert within two seconds to notify the
driver of drowsiness.
Explanation: This should provide sufficient time for the driver to react before falling asleep as well
as preventing false alarms that could jeopardize the reliability of the system.
11
4.4
Rapid Deceleration Warning
4.4.1
Requirements
4.4.1.1 System
Requirement 1: The brake lights shall flash only when the vehicle is decelerating greater than 6
m/s2.
Explanation: This is a requirement of the ECE (Economic Commission for Europe) given as ECE
regulation 48 [3].
Requirement 2: The brake lights shall flash at a maximum rate of 4 Hz.
Explanation: This is another requirement of ECE regulation 48 [3]. The minimum rate of flashing is
0 Hz, or normal operation.
Requirement 3: The rapid deceleration warning production model shall comply with the United
States vehicle lighting regulations.
Explanation: Provision S5.5.10 from Federal Motor Vehicle Safety Standard 108 requires that all
lamps, including brake lights, must be steady burning [40]. Therefore, the rapid deceleration
warning system will simulate flashing by pulsing the brake lights from dim to bright so that the
lights are steady burning.
4.4.1.2 Hardware
Requirement 1: The rapid deceleration warning system shall be accurate and precise enough to
measure the deceleration to within 0.1 m/s2.
Explanation: This accuracy is important to make sure that the brake lights flash when they should
and that they do not flash when they should not.
4.4.1.3 Software
Requirement 1: The rapid deceleration warning system shall read the deceleration data in real
time.
Explanation: Real time means that it should operate read in data at the maximum clock speed
allowed by the microcontroller. There should be as little delay as possible between acquiring the
data and reading it into the system.
Requirement 2: The rapid deceleration warning system shall output a pulsed signal to the brake
lights at the required rate at least 50ms after it detects a deceleration above the required rate.
Explanation: A human is able to process an image astonishingly fast, usually within 150ms [41].
Therefore, a time of 50ms is required to allow the driver to begin processing and reacting to the
flashing stimulus as fast as possible.
12
4.4.2
Objectives
4.4.2.1 System
Objective 1: The rapid deceleration warning and its purpose shall be easily recognizable to a driver
behind the vehicle on which the system is installed.
Explanation: If the driver behind the vehicle does not understand why the brake lights are
flashing/pulsing, then there will be no improvement in reaction time and therefore no
improvement over the current operation of brake lights. The team will attempt to meet this
objective through user testing.
Objective 2: The Rapid Deceleration Warning shall not be disorienting to a driver behind the
vehicle on which the system is installed.
Explanation: The team will attempt to meet this objective through user testing and research of the
effects of different flashing frequencies.
4.4.2.2 Software
Objective 1: The rapid deceleration warning system shall relay the acceleration data to the driver
of the vehicle in some way.
Explanation: Presenting this information to the driver could help them identify and possibly stop
their own aggressive braking. The system could present this data through a screen on the
dashboard that tells the driver their deceleration or a simple LED that flashes/pulses at the same
rate as the brake lights themselves.
4.5
Design Norms
The design decisions of the team should not only be objective, but also take into account the impact
on society. This product will operate alongside humans and therefore the team must design it with
consideration for others in mind. The team will focus primarily on developing a product that is
caring, trustworthy, and transparent.
4.5.1
Caring
The team will design this product with care in mind because it is a safety device. Safety devices care
for others by providing an extra layer of safety for all those involved. The team is designing the
product so that the product will not affect normal car operations if the product fails. In this way, we
are caring about the safety of the user.
4.5.2
Trustworthy
It is important that the user can trust this product to accurately assist the driver and not cause a
hindrance. If the driver does not trust that this product will work as designed, there is no reason for
anyone to use this product. The team will be designing the product with a high minimum lifetime,
so the users will feel comfortable using the product for the lifetime of their vehicle.
13
4.5.3
Transparency
The team will design this product to improve the safety of the driver and those in nearby vehicles. If
this device is not intuitive and transparent, it can easily cause more distractions, in which case it
would be better if the driver did not use this device. The team will focus the design on the user, and
the team will perform extensive research to ensure that the product will work in an efficient and
intuitive way.
14
5
System Architecture - Rapid Deceleration Warning
5.1
Overall System
There are three main concepts that the RDW system must realize at a system level. The RDW
system must (1) quickly, accurately and consistently find the deceleration of the vehicle that the
system is installed within, (2) compare that deceleration to a certain deceleration threshold, and
(3) output a pulsed signal at the proper frequency if the measured deceleration is greater than this
threshold.
5.1.1
Determining Vehicle Deceleration
An accurate and cost effective way to monitor the deceleration of a vehicle would be to use an
accelerometer. The team briefly considered the alternative method of measuring deceleration by
measuring the depression of the brake pedal itself. However, the team dismissed this alternative
mainly because a brake-actuated system like this would also not work in the case of a collision,
when rapid deceleration can occur without the driver depressing the brake pedal [4].
Most accelerometers offer both an Inter-Integrated Circuit (I2C) and a Serial Peripheral Interface
(SPI) to communicate with a microcontroller. I2C uses a single line for data, while SPI uses two
separate lines for data in and data out. For this reason, I 2C is generally considered much more
complex to interface with than SPI. I2C also requires additional ‘pull-up’ resistors to pull the single
data line from low to high. Therefore, the team chose SPI because of its overall simplicity.
A one-axis accelerometer, which could measure the acceleration of the vehicle on one plane of
motion, seems to be sufficient for this system. However, the team decided to choose a three-axis
accelerometer for the prototype system as it would allow for much more flexibility in testing.
Three-axis accelerometer are also much more common and even tend to be less expensive than
their single-axis counterparts.
5.1.2
Comparing Data
It is necessary for the RDW system to compare the data found by the accelerometer to the
maximum deceleration threshold in real time. The team will write a program to accomplish this
task and that program will be stored in a microcontroller. Figure 3 provides a block diagram of a
typical microcontroller architecture. The Data SRAM memory will store the program, which the
team currently estimates to be fewer than 10 KB. The SPI unit will interface with the accelerometer
and the analog comparator will be used to compare the threshold against the vehicle’s deceleration.
15
Figure 3. Microcontroller Architecture [42]
5.1.3
Flashing the Brake Lights
When the program mentioned above has detected a deceleration value above the maximum
threshold, it will then use an unused pin of the microcontroller to output a signal to the brake lights
at the specified frequency. The team still needs to research exactly how this signal will override the
normal braking signal and how it will physically connect to the brake light ‘line’ within an actual
vehicle. While performing this research, the team must take into consideration the initial
requirement that the safety devices must not interfere with the normal operation of the vehicle.
The team also needs to research the optimum location for the system to be installed within the
vehicle.
5.2
Hardware System Design
The key pieces of hardware necessary for the RDW system are as follows: an accelerometer and a
microcontroller. Figure 4 shows a basic hardware diagram of the system, which focuses on the
interactions between the selected accelerometer and microcontroller components. The following
sections describe how the team chose these particular components. Table 1 describes the signals
between the components.
16
Figure 4. RDW Hardware Diagram
Table 1. Signals used in Figure 4
Signal
Explanation
GND
Ground
VCC
Power supply for accelerometer (3.3V)
CS
Chip select
SDO
Serial data output
SDI
Serial data input
SCLK
Serial port clock (5 MHz maximum)
D OUT
Data out (from microcontroller)
D IN
Data in (to microcontroller)
5V
Signal from the Voltage Regulator, stepping signal down to 5 volts
B IN
Input from the battery to be stepped down (9-15V, 50 mA max
current)
5.2.1
Serial
Peripheral
Interface
(SPI)
Accelerometer
This section defines the criteria that the team used to select an accelerometer for the Rapid
Deceleration Warning system production and prototype models, as well as the alternatives that the
team considered.
17
5.2.1.1 Criteria
The weights given to each criterion add up to 100 in every decision for the project. Therefore, they
are represented as percentages of importance for the specific function.
Unit Cost [30]
The team gave this criterion a high weight because the team wants to have a very inexpensive
production model. The team expects a yearly sales volume of 25,000 units so the accelerometers
are available at a much lower cost for this bulk purchase.
Breakout Board Cost [25]
The team gave this criterion a high weight because there is a limited prototype budget available and
the breakout board of the accelerometer will be used to build the prototype system.
Bandwidth [15]
Bandwidth is the rate at which accelerometers will output accurate readings. The team desires a
greater bandwidth in order to read the acceleration data as fast as possible so that the delay
between detection and response is as short as possible. A faster bandwidth ensures that the driver
will have as much time as possible to react to the Rapid Deceleration Warning stimulus.
Power Consumption [15]
The team gave this criterion a moderate weight because the team plans to draw power from the
vehicle’s battery for all three safety functions. This will depend largely on the current consumption
of the device.
Output Signal [10]
This is criterion evaluates the difference between analog and digital (I2C/SPI) outputs. Since
software will eventually need to modify the acceleration data, an analog to digital converter would
be required to convert an analog signal to a digital signal. However, since the microcontroller that
the team chose in the next section has a built-in analog to digital converter (ADC), the team decided
to give this criterion a lower weight.
Flexibility [5]
Flexibility takes into consideration the range of acceleration and supply voltage of each alternative.
For instance, an accelerometer with multiple acceleration ranges would receive a higher score. The
team gave this criterion a low priority because each alternative that the team considered fulfills the
acceleration and voltage range requirements for the system.
5.2.1.2 Alternatives
Table 2 shows the accelerometer options that the team considered for this system. The four
accelerometers were compared against each other because they all very popular in the field of
electronics. The team gathered the unit cost for each component from the electronic supplier
Digikey. The team used the electronic hobbyist retailer SparkFun Electronics to gather costs of a
breakout board for each accelerometer. The team gathered the other specifications by looking at
the datasheet offered by the manufacturer [43]. For the prototype, the team only considered
18
purchasing breakout boards because they are much easier to use with breadboards. The
temperature ranges for each accelerometer alternative is (-40) to 80 degrees Celsius.
Table 2. Accelerometer Alternatives
Manufacturer
Model
BB
Cost
($)
Unit Output
Cost Signal
($)
Supply
Voltage
(V)
Range
(+/- g)
BW
(Hz)
Current
Draw
(µA)
Analog Devices
ADXL335
27.95 2.89
1.8-3.6
3
0.5-1600
350
Analog Devices
ADXL345
24.95 3.70 I2C/SPI
2-3.6
2, 4, 8,
16
6.25-3200
145
Bosch
BMA180
29.95 3.10 I2C/SPI
1.6-3.6
1, 1.5,
2, 3, 4,
8, 16
10-1200
650
STM
LIS331HH
27.95 2.55 I2C/SPI
2.16-3.6
6, 12,
24
0.5-1000
250
Analog
5.2.1.3 Decisions
Table 3 shows the decision matrix that the team used to select the accelerometer. The Analog
Devices ADXL345 accelerometer is the clear winner mainly because of its superior power
consumption, breakout board cost, and bandwidth performance.
Table 3. Accelerometer Decision Matrix
Priority
ADXL335
ADXL345
BMA180
LIS331HH
Unit Cost
30
8
5
7
9
Breakout Board Cost
25
7
8
6
5
Bandwidth
15
5
9
4
3
Power Consumption
15
6
8
3
7
Output Signal
10
5
10
10
10
Flexibility
5
5
7
10
6
Total
655
740
615
675
5.2.2
Microcontroller
This section defines the criteria that the team used to select a microcontroller development board
for the Rapid Deceleration Warning and Speed Limit Indicator system prototype model, as well as
the alternatives that the team considered.
19
5.2.2.1 Criteria
Cost [20]
The team gave this criterion a high weight because there is a limited prototype budget available and
the development board will be used to build the prototype system.
Ease of SW programming [15]
This criterion mainly considers the programming language used to develop software on the board
as well as the availability of an integrated development environment (IDE). This will largely
depend on the team’s knowledge and familiarity with the language.
Functionality [15]
This criterion considers the ease of use or the ability to use the microcontroller “out of the box”.
One example is that some of the development boards already have built-in voltage regulators and
some require the user to buy and install voltage regulators.
Support Community [15]
This criterion considers the popularity and overall amount of documentation and that exists for a
particular microcontroller dev board.
Power Consumption [10]
The team gave this criterion a moderate weight because the team plans to draw power from the
vehicle’s battery for all three safety functions. This will depend largely on the current consumption
of the device.
Number of Pins [10]
This is the number of I/O pins that the microcontroller board has available. The RDW and SLI
systems each require five pins for digital input and output. The team has given this a lower priority
because all of the microcontroller options have a sufficient amount available.
Onboard Memory [10]
This is the amount of memory that the microcontroller board has available. The RDW system
requires an estimated 10 KB of memory. The SLI system requires an estimated 20 KB of memory.
The team has given this a lower priority because all of the microcontroller options have a sufficient
amount available.
Clock Speed [5]
A higher clock speed means more instructions of code will be executed per second. Since the team
does not expect the programs for the RDW and SLI systems to be overly complex, a faster clock
speed could provide a small boost in performance.
5.2.2.2 Alternatives
Table 4 shows the microcontroller options that the team considered for this system. All of the
options below are popular microcontroller development boards.
20
Table 4. Microcontroller Alternatives
Manufacturer
Model
Cost
($)
Current Clock
Draw
Speed
(mA)
(MHz)
Number
of Pins
Flash
Memory
RAM
Arduino
Uno
30
40
16
20
32KB
2KB
FEZ
Panda II
40
65
72
54
512KB
96KB
Pinguino
PIC32
30
5
80
24
256KB
32KB
PJRC.com
Teensy
2.0
16
15.7
16
25
32KB
2.5KB
Microchip
Ready
for PIC
29
20
16
28
32KB
1.5KB
5.2.2.3 Decisions
Table 5 shows the decision matrix that the team used to select the microcontroller. The Pinguino
and Arduino achieved the exact same score. However, the team selected the Arduino Uno as the
winner because team member Andrew DeZeeuw already had access to an Arduino Uno.
Table 5. Microcontroller Decision Matrix
Priority
Arduino
FEZ
Pinguino
Teensy
Microchip
Cost
20
7
4
7
10
7
Ease of SW Programming
15
10
3
9
7
6
Functionality
15
9
5
7
5
9
Support Community
15
10
5
6
2
5
Power Consumption
10
5
4
10
8
7
Number of Pins
10
6
10
7
7
8
Onboard Memory
10
5
9
7
5
5
Clock Speed
5
5
9
10
5
5
Total
760
550
760
635
665
21
5.3 Initial Printed Circuit Board Design
For the final project in May, the team would like to design a printed circuit board for the prototype
model. Figure 5 shows the initial PCB layout, using the components and dimensions listed in Table
6. This PCB layout includes the parts necessary for all three functions of The Smart Dashboard. The
overall size of the PCB is 1.75 inches x 1.5 inches. This is the minimum size that the team could be
produce. A reasonable estimate is a board that is 2 inches x 2 inches.
Figure 5. Initial PCB Layout. Parts listed in Table 6
Table 6. Table of Components for Figure 5
Component ID
Component
Dimensions (in)
1
Accelerometer
0.2103 x 0.1315
2
GPS
0.5512 x 0.4016
3
Memory
0.4331 x 0.3544
4
Demultiplexer
0.4134 x 0.6182
5
Processor
0.6575 x 0.6575
6
Resistors
0.1260 x 0.0630
7
Connector
0.7481 x 0.6154
22
5.4
Software System Design
Figure 6 shows a software flow diagram of the RDW system. The software must read in the data
from the accelerometer, filter the noise from this data, convert this data to usable deceleration data,
and compare the incoming deceleration to a fixed maximum deceleration threshold. It must also
tell the system to output a pulsed signal to the brake lights if the current deceleration of the vehicle
is greater than this threshold.
The system should have no control timing so that it is constantly running as fast as possible. The
team still needs to research accelerometer noise filtering and calibration techniques. Most
accelerometers need calibration before use. This is often done by examining the acceleration
output at a known acceleration and subtracting the offset from the output. The team also needs to
examine how faults will be detected so that we can uphold our design norm of trust if something
does go wrong.
Figure 6. RDW Software Diagram
23
6 System Architecture - Driver Awareness Sensor
6.1 Overall System Design
There are two main concepts that the DAS must realize at a system level. The DAS must detect
drowsiness due to prolonged eye closure and wake up the driver with an alert.
6.1.1
Determining Prolonged Eye Closure
The primary method of detecting the blinking rate and determining prolonged eye closure is
through video capture and processing. A camera is focused on the subject, capturing at least the
eyes. If the subject is still, this camera can be zoomed in closer than if it needs to allow for
movement of the subject. Most often, the face is included with some background. The software for
the system must then analyze the image and locate the eyes. Once this is done, the eyes are
analyzed further to determine their state, whether open or closed. Performing the analysis on only
the eye region greatly reduces the computations required. Therefore, it is important to accurately
locate the eye region and narrow it down as much as possible.
Other methods for determining prolonged eye closure include mechanical and electrical methods.
The mechanical methods attach to the subject and can sense muscle movements related to the
eyelid closing. The electrical methods attach electrodes to the subject and measure brain waves or
other signals to determine when the eye is closed. Both of these methods would not be appropriate
for this project, as they would require the user to wear some form of mechanism, which would be
intrusive and could possibly cause safety issues.
6.1.2
Alerting Driver
The final concept that the DAS must realize is alerting the driver to their drowsiness and waking
them up. There are many possible methods for providing feedback to the driver, including audible,
visual, and tactile. The audible methods range from an alarm sounding noise to a human issuing a
warning. The tactile methods could include vibration of the steering wheel or seat, or providing an
electric shock. Visual methods range from a simple light or notification to a strobe or blinding light
to get the attention of the driver. From the list of feedback methods, a simple audible warning
consisting of a beeping noise similar to an alarm clock should be the simplest method to implement
while still providing an adequate notification to the driver. This can be implemented with a simple
speaker connected to the microcontroller.
6.2 Hardware System Design
The pieces of hardware necessary for the DAS are as follows: a camera, a microcontroller, and a
speaker. Figure 7 shows a block diagram of the hardware with expected signal communications.
24
Figure 7. DAS Hardware Diagram
Signal
Explanation
From car battery
9V-15V DC
Power from Voltage Regulator
5V, capable of providing at least 700mA
Video from camera
USB 2.0
Power to Facial Illuminator
5V
Audio to speaker
Analog audio signal
The hardware for the Driver Awareness Sensor must possess the ability to capture quality real-time
imagery and process the images to determine driver awareness. The hardware must also be able to
notify the driver of unsafe driving conditions due to the drowsiness of the driver. Additionally, the
hardware must provide an illumination source so that the camera can capture accurate imagery in
varying lighting conditions.
25
6.2.1
Microcontroller
6.2.1.1 Criteria
Cost [25]
This is a very important criterion because the team has a limited budget with which to build the
prototype.
Clock Speed / Instructions per Second [25]
The microprocessor should feature a high clock speed and have a high number of instructions per
second. This is critical for the image processing to determine the state of the driver in real-time.
Availability [20]
The availability of the boards is important to reduce development time as well as cost of
production.
Ease of SW Programming [15]
Ease of software programming is defined as the ability to program the microcontroller “out-of-thebox.” This includes the development environment as well as the programming language knowledge
required to set up the board.
Support Community [10]
This criterion considers the popularity and overall amount of documentation that exists for a
particular microcontroller development board.
Functionality of Development Board [5]
This criterion considers the functionality of the development board relating to how well it
interfaces with the other components. The board should provide a sufficient number of connections
for the other components.
6.2.1.2 Alternatives
Table 7. DAS Microcontroller Alternatives
Board
Cost ($)
CPU
RAM
Other
BeagleBoard [44]
149.00
720 MHz
256 MB
HDMI, S-Video, 1 USB, SC,
Raspberry Pi [45] 35.00+
700 MHz
512 MB
HDMI, RCA, 2 USB, SD, Ethernet
OLinuXino [46]
58.35
1 GHz
512 MB
HDMI, 2 USB, microSD, SATA, Ethernet
Cubieboard [47]
49.00
1 GHz
512 MB
HDMI, 2 USB, SD, Ethernet
26
6.2.1.3 Decisions
Table 8 shows the decision matrix for the microcontroller. The Raspberry Pi is the microcontroller
of choice primarily due to the availability and cost, as the boards are similar in many
characteristics.
Table 8. DAS Microcontroller Decision Matrix
Priority
BeagleBoard
Raspberry Pi
OLinuXino
Cubieboard
Cost
25
2
9
6
7
Clock Speed
25
5
5
9
9
Availability
20
3
10
3
1
Ease of SW
Programming
15
4
8
8
5
Support
Community
10
5
9
7
3
Functionality
of Dev. Board
5
5
7
8
7
Total
370
795
665
560
6.2.2
Speaker
The speaker is not a critical component. A simple and inexpensive off-the-shelf component should
suffice. The team will determine the correct speaker to use next semester.
6.2.3
Facial Illuminator
The team will perform lighting tests with the camera to determine the level of lighting that is
required. Once this is determined, the team will select a lighting source.
6.2.4
Voltage Regulator
The voltage regulator is not a critical component. Microcontroller development boards generally
provide voltage regulators that work well with standard power supplies. The team will perform
research to determine what type of voltage regulator will be necessary to connect to a car battery,
which is less reliable in its output levels.
6.3
Software System Design
Figure 8 shows the software flow diagram of the DAS system. The software must read the image
from the camera and process it to determine the state of the driver. If necessary, the software must
alert the driver to wake up.
27
Figure 8. DAS Software Diagram
28
7
System Architecture - Speed Limit Indicator
7.1
Overall System Design
There are four main concepts that the SLI must realize at a system level. The SLI must (1)
accurately and consistently find the location of the vehicle that the system is installed within, (2)
take that position data and correctly find the road and speed limit for that location, (3) store the
speed limits and roads in an efficient and searchable manner, and (4) output the determined speed
limit to the user via the dashboard.
7.1.1
Determining Vehicle Location
An accurate and cost effective way to monitor the position of a vehicle would be to use a global
positioning system (GPS) device. However, GPS systems do not work well without a clear view of
the sky, which would be a problem in tunnels or other locations where the road is covered. In [6], a
standard is set for accuracy using 50 percent, 68 percent, and 95 percent. For example, the Garmin
eTrex was accurate within 2.7 meters 50 percent of the time, accurate within 3.8 meters 68 percent
of the time, and accurate within 6.7 meters 95 percent of the time. The average accuracy was
approximately 3 meters. This can provide challenges in areas where roads are very close to each
other, such as an urban setting or at intersections. From the software perspective, the code must be
able to handle expected errors and outlier data due to inaccuracies with GPS location data.
Others have attempted to counteract this accuracy problem by using another method in addition to
using a GPS. [7] considered an Inertial Navigation System (INS) implemented as a backup to the
GPS. There would be a control system on board that would determine which value should be used,
with the GPS used primarily if its data is reasonable. An INS system is also considered in [8], and is
tested and compared to other GPS systems being used, including an autonomous GPS system as
well as systems in which there are GPS substations located on the ground nearby. [13] also
considers inertial inputs in addition to GPS inputs, but considers a composite location that takes
into account both GPS data and inertial inputs data. Therefore, they base their location on both
systems all the time, as opposed to picking one system over the other. [11] uses the vehicle’s
odometer and a single-axis gyroscope as a secondary option to the GPS. This is an alternative to
using an inertial system and uses fewer sensors, which is more efficient. This system also uses
certain filters to determine if the information received by the sensors is accurate. [9] also uses invehicle sensors in addition to a GPS. In that case, they use another filter to analyze the information.
The majority of the systems considered receive data from the GPS and other sensors and filter that
data to determine position.
Other works focused on finding the error of the GPS device itself. The coordinates received by the
GPS can be analyzed using various techniques. [12] considers spatial bias techniques over a linear
path, then the system will use only a GPS if the vehicle is involved in a non-linear movement. [10]
follows a similar system, interpolating to find the expected deviations in the GPS readings. Both of
these systems do not have other sensors involved; they find the error by filtering the GPS readings
to determine their veracity.
29
7.1.2
Finding the Speed Limit
Once the microcontroller has received the position data from the GPS, the microcontroller must
analyze the data and find what the speed limit is for that location. In our implementation, GPS
coordinates will be stored for each tenth of a mile of road. While speed limit signs occur less often
than that, the increased resolution will make identifying road easier as there is more data to
compare. The code will identify the segment of road that the vehicle is on then find the speed limit
of that segment of road.
GPS navigation devices on the market today utilize mapping software that will take a GPS location
and find the road nearest to that location by using a map stored on the device. [14] discusses how
that process works. Mapping software is expensive to use or program from scratch, although the
production model may use such software. The team has not determined the exact costs of mapping
software at this time, as the companies found do not offer their databases to the public. There are
some free options available, such as wikispeedia [27]. The stated goal of wikispeedia is to document
the GPS coordinates of every speed limit sign on earth. The wikispeedia group has not
accomplished this goal yet, but future iterations of our design could incorporate this database,
assuming that the number of speed limit signs in the wikispeedia database increases to a sufficient
percentage. Another database is the open street map database. An overlay of the speed limits can be
visualized using itoworld.com. The resolution currently is not sufficient, as the only roads with
speed limits in the database are major roads and highways [28]. Currently, the free options for
speed limit databases do not offer enough detail for the scope of our project. The team will continue
development of the prototype while implementing our own database for the area around Calvin
College. The team will consider the other options given above for the production model of this
function.
7.1.3
Storing the Speed Limits
To store the speed limits, the system should use a nonvolatile storage device. A discussion of the
hardware differences for memory is given in Section 7.2.3. In our system, the speed limit signs are
being held in a database. Therefore, only four pieces of information need to be stored. The speed
limit, the GPS coordinates, and the direction need to be permanently stored and accessible. The
speed limit can be stored in as few as four bits, as the team is currently considering 10 speed limits
to display (see Sec. 7.2.4.2). The longitude and latitude both can be stored as long values, each
generally four bytes in size [15]. Long values allow the controller to do integer computations, which
can be performed faster than floating point operations. The decimal of the GPS coordinate is shifted
so that the full precision of the value can be stored in the long variable. The direction consists of a
value between 0 and 360 degrees. This can be stored in 12 bits, which would be enough to store the
direction with one decimal place stored as well. The value stored would be a multiple of ten greater
than the actual direction. The total space taken up by one data point would be 10 bytes.
With each speed limit location requiring ten bytes of data to be stored, the team needs to estimate
the number of locations that will need to be stored in the United States. According to the Federal
Highway Administration, there are approximately four million miles of roadways in the United
States [16]. Figure 9 shows the breakdown of road types. Approximately 35% of roads in the United
30
States are unpaved local roads, many of which may not even have a speed limit posted. If the team
stores data points for every tenth of a mile on every road in each direction, that would require
memory storage around 800 MB. Many memory options are available in that range.
Figure 9. Breakdown of Road Types [17]
7.1.4
Outputting the Speed Limit
The final concept that the SLI function must realize is to display the speed limit to the user. The
team considered transparency throughout this specific subsection, as displaying the speed limit is
the only part of this function that the user will see. We can implement the display of the speed limit
in many different ways. One option is to place component RGB LEDs around the speedometer and
display different colors depending on the driver’s speed in comparison to the speed limit. Other
options for displaying the speed limit could include displaying the speed limit separately from the
speedometer. Most cars today have a digital odometer, and the team could make that display larger
to display the current speed limit as well. The team could also use a separate seven-segment display
to output the speed limit in numerical form. Further research is needed to determine the most userfriendly way to output the speed limit.
Manu Kumar and Taemie Kim at Stanford University researched driver response to a dynamic
speedometer [18]. Their design displays an orange light for all speeds outside of the speed limit
range. Therefore, a speed limit of 40 miles per hour would show orange lights over all speeds
greater than 40 miles per hour. Figure 10 and Figure 11 show this concept. Their system would also
use various visual and audio warnings as the driver got over a certain threshold over the speed
31
limit. For example, a beeping sound from the dashboard would begin once the driver goes five miles
per hour over the speed limit. The amplitude and frequency of that signal would increase as the
driver went faster and faster over the speed limit. Their results show that drivers have the
tendency to decrease their speed when using a dynamic speedometer. The dynamic speedometer
also decreased the number of incidents of unintentional speeding.
Figure 10. Normal Speedometer [18]
Figure 11. Speedometer with Speed Limit of 40 Miles Per Hour [18]
7.2
Hardware System Design
The hardware necessary for the SLI is as follows: a GPS, a microcontroller, memory, and the LED
output. Figure 12 shows a block diagram of the hardware components, and Table 9 shows the
expected communication between those components. This section currently considers the
prototype components only. The team will develop criteria for the production model and include
those decisions in a future report.
32
Figure 12. SLI Hardware Diagram
Table 9. Signals Used In Figure 12
7.2.1
Signal
Explanation
TTL/RS-232
GPS has option to use either TTL or RS-232 communication
SD
SD Card. Signals include Vcc (3.3V), GND, Data In (MOSI), Data Out
(MISO), CLK, Card Select
4x D OUT
Digital output. Selector for the Demultiplexer, 4 leads
5V
Signal from the Voltage Regulator, stepping signal down to 5 volts
B IN
Input from the battery to be stepped down (9-15V, 50 mA max
current)
A IN
Analog input to the Demultiplexer (5V)
10x Display
10 outputs from Demultiplexer that will drive the display
GPS
7.2.1.1 Criteria
The team determined which GPS to use for the prototype based on several criteria. The criteria are
listed below with their weight for the decision matrix. All the devices that we considered had an
internal antenna, so the team could not use that as a design criterion. The sum of the weights is 100.
33
Cost [30]
The cost is a key criterion, as the team needs to operate under a budget as determined by the Senior
Design class instructors.
Start-Up Time [20]
There are different ways to determine the start-up time of the GPS. Most GPS modules list a hot
start, warm start, and cold start. The most important of those in this instance is the cold start-up
time. This is generally between 30 seconds and one minute. The other times are small enough (< 2
sec) that they are not as significant in the operation of the device. Many of the GPS modules
considered had update times of one second. The warm and hot start-up times are approximately
equal to the update rate; therefore, those start-up times may be noticeable but not detrimental to
the overall effect of the function. The team weighted the GPS’s cold start-up time higher within this
criterion than the other start-up times.
Ease in Communication and Software Control [15]
The team should be able to control the GPS easily from the microcontroller. Libraries and
documentation exist to prove compatibility between the GPS and the microcontroller.
Ease in Electrical Interfacing [10]
The GPS must be simple to implement into our prototype. The electrical interface should allow
simple communication between the microcontroller and the GPS.
Power Consumption [10]
Power consumption relates to the amount of current drawn by the device. The GPS should keep the
power consumption relatively low, as the team wants to be good stewards of the electricity in the
system.
Accuracy [10]
This refers to the reported accuracy in adverse conditions, such as areas with obstructions like
trees and buildings. This is important to consider as the code must be able to account for some
inaccuracies in the GPS data.
Number of Channels [5]
The number of channels in the GPS refers to how many satellites the GPS can acquire and read from
at the same time. This value is not very important, as the number of channels on all the devices
considered would be sufficient for this project, albeit with slightly different response times. More
channels does provide a vast array of benefits, as given in [29].
7.2.1.2 Alternatives
Given these criteria, the team considered four GPS modules for the prototype of this project, given
in Table 10. A decision matrix is given in Table 11, with each GPS rated in each criterion on a scale
34
from one to ten, with ten being the best in that particular area. The final scores are given for each
GPS module, with a percentage of the total possible given as well.
Table 10. GPS Alternatives
GPS
Seller
Model
Number
Cost
# of
Channels
Cold
Start-Up
Time
Voltage
Power Accuracy
Use
Temp
Range deg
C
Futurlec
[19]
EM406A
$40
20
42 sec
4.5V –
6.5V
220
mW
10 m
-40 to 85
Polstar
[20]
10-019
$15
12
50 sec
3.3V – 5V
120
mW
5m
-40 to 70
Sparkfun
[21]
Locosys20031
$60
66
35 sec
3V – 4.2V
135
mW
3m
-30 to 85
Parallax
[22]
PMB648
$40
20
42 sec
3.3V – 5V
325
mW
5m
-20 to 70
Table 11. Decision Matrix for GPS Selection
Priority
EM-406A
Polstar 10019
Locosys20031
PMB-648
Cost
30
5
10
2
5
Start-Up Time
20
6
2
9
6
Communication and
Software Control
15
7
2
2
9
Electrical Interfacing
10
7
2
2
9
Power Consumption
10
5
9
8
2
Accuracy
10
3
6
8
6
Number of Channels
5
3
2
10
3
Total:
540
550
500
590
7.2.1.3 Decisions
All four GPS devices had scores similar to the others, with the Parallax PMB-648 scoring the best.
The PMB-648 is very easy to implement, as documentation exists for connecting it to various
microcontrollers. This is reassuring, as other groups have been able to successfully read data from
this device using a simple microcontroller. The PMB-648 is in the middle price range, which is
reasonable for this project. This decision matrix proves that all of the options would be generally
sufficient for this project, as none of them scored significantly lower than the others. The team
selected the PMB-648 GPS for the benefits given above.
35
7.2.2
Microcontroller
Section 5.2.2 gives a detailed discussion of microcontroller selection. The design criteria all apply to
the SLI as well. The cost remains an important factor as both functions are being designed for the
senior design class. The ease of use is vital to the timely completion of the prototype. The support
community also helps accelerate progress through issues. The power consumption ties directly to
our desire for a positive societal impact, which applies to each function. The number of pins is a
factor as the microcontroller will be shared with the RDW system. The onboard memory
capabilities dictate the scope to which testing can be done without an external memory source. All
of the design criteria apply, so the decision made in Section 5.2.2 applies to the SLI function as well.
7.2.3
Memory
7.2.3.1 Criteria
As discussed in Section 7.1.3, the memory of this system should approximately one gigabyte (800
megabytes is a reasonable estimate). However, the prototype will only store speed limits for a small
area around Calvin College. Therefore, the amount of memory necessary drops by orders of
magnitude. In a worst-case estimate, a grid of roads 300 feet apart would fill the two-mile area
around Calvin College. Assuming a square around Calvin College that is 4 miles per side, this would
result in approximately 80,000 miles of road in the area. Taking data points every tenth of a mile
with ten bytes to store each location, which would take up 8 kilobytes of space. This is an
unreasonably high estimate, but it provides approximate upper bounds for our database. The
memory available on the selected Arduino microcontroller would be enough to do initial testing,
although it may not be enough for the final prototype. The additional memory needs to be able to
interface with a microcontroller very easily and be cost effective. The memory should also be fast
and fit within the temperature range considered in Section 4.1.1.2, Requirement 1.
7.2.3.2 Alternatives
Many surface mount memory devices are inexpensive and can store great quantities of information.
Unfortunately, they are difficult to implement with a development board. One example is 2 GB of
flash memory sold at DigiKey [23]. The most common memory addition to an Arduino
microcontroller is to use an SD card. Various Arduino shields on the market handle all of the voltage
regulation necessary to interface an Arduino and an SD card. SD cards can be inexpensive as well,
selling for under $10 for 4 GB.
7.2.3.3 Decisions
Surface mount devices can be less expensive, but are difficult to use with a microcontroller. The
cost to solder that memory device to a board and then use a microcontroller makes it more difficult
to implement. While an SD card system would cost more (including the cost of an SD shield), it
would be simple to implement and save time without sacrificing too much in terms of cost.
36
7.2.4
Outputs
7.2.4.1 Criteria
The output to the user must be easy to understand and not distract the driver. The team is
considering implementing a single light with two different states, depending on whether the driver
is exceeding the speed limit by ten miles per hour. The output system must be able to display both
conditions.
7.2.4.2 Alternatives
Section 12.1.4 discusses ways in which the system can display the speed limit. RGB LEDs can be
placed at each speed limit (25, 30, 35, 40, 45, 50, 55, 60, 65, 70) around the speedometer, and only
one LED would be lit at any given time. Using the method used by Kumar and Kim, a series of LEDs
again could be used, or perhaps an LED strip of some kind. A seven-segment display could output
the speed limit separate from the speedometer, but another indicator would be necessary to report
a case of speeding to the driver.
7.2.4.3 Decisions
With our current design, using RGB LEDs makes the most sense. LED strips and seven segment
displays would work better in other designs. The LEDs will be lit using a demultiplexer, which will
be controlled using an output from the microcontroller. The team will calculate resistor values after
the team finds the current output of the demultiplexer. The demultiplexer being considered
currently is given in [30], manufactured by Texas Instruments. The team can purchase the
demultiplexer in bulk, making it an attractive option for the production model as well. It functions
within the operating temperature specified for the system.
7.3
Software System Design
The software running on the microcontroller will receive data from the GPS, analyze that data to
find the nearest speed limit sign, then output that speed limit to the outputs. Figure 13 shows a
basic block diagram for the software system. The update rate of the GPS limits the abilities of the
software. The update rate for the GPS selected is one second. The software will run as fast as
possible given that constraint.
37
Figure 13. SLI Software Diagram
7.3.1
Criteria
The software needs to manage the following pieces: a database of speed limit signs with their GPS
coordinates, a GPS that outputs position, velocity, and direction, and an output that consists of a
demultiplexer and LEDs. The code must tie all three of those pieces together while also providing
sufficient noise reduction and error correction. After the initialization process, the code reads and
extracts the relevant data from the GPS. At that point, a noise filter analyzes the data. If an error
exists in the data, then the code will increment an error counter. If the code recognizes more than
three consecutive errors, then something significant has gone wrong so nothing is output to the
user. If no errors exist in the signal, the code searches for the location in memory. If the data cannot
be mapped to a speed limit, an unknown road counter is incremented. If the code recognizes more
than three consecutive unknown road signals, then the database does not understand where the
vehicle is located. In this case, the code displays nothing to the user. If the data can be mapped to a
speed limit, then the counters for error and unknown roads are reset to zero. If the speed limit is
38
different from the current value, then a new display pattern is stored. In both cases, the controller
drives the LEDs with the display pattern.
7.3.2
Alternatives
The code to decode the GPS information is standard, as the code takes in data as a character array
then breaks that string down into its various components. Finding the correct location of the
nearest speed limit sign will be a challenge. If the GPS gives accurate data for direction, the code can
fan out opposite the vehicle’s motion to find the speed limit sign. This can be a problem if roads are
winding or if there are bridges or intersections. Another option is to store the past few iterations of
the code, and if the speed limit is consistent, then it can be outputted. This makes sure that the SLI
is not confused by one bad data point. The code could also look forward as well as backwards, to
see if the speed limit is consistent in front of the user and behind the user.
7.3.3
Decisions
For the prototype, the selected Arduino microcontroller supports code in C or C++. The team has
experience with this programming language, which makes it ideally suited for the prototype.
Arduino has its own IDE, which takes care of the compiling and loading necessary for the prototype.
The team has developed initial algorithms for the GPS data reading and extraction blocks from
Figure 10. The team has not begun developing the software for the other sections at this time. The
team will do testing as described in Section 8.3 to determine that the algorithms developed fit
within the context of the overall goals for this function.
39
8
Integration and Initial Testing
8.1 Common Tests
8.1.1
Testing Method
The team continues to prepare a set of tests to prove the performance of the system as described in
the Objectives and Requirements (Chapter 4) and the specific system architectures (Chapters 5-7).
The tests are described in detail below. This list is not inclusive, as the team continues to iterate
through different tests.
8.1.1.1 Hardware Compatibility Test
The team will test the hardware systems for each function to ensure that they are compatible. The
team must be able to receive data on their specific processor from their hardware components. The
team has begun some testing, but the specific test has not been designed. It will come on a future
report.
8.1.1.2 Temperature Test
This test will consider the temperature of the system as well as individual components as time goes
on. If the owner uses their vehicle for a longer trip, these components may be on for hours at a time.
In that case, the team must confirm that not all the components overheat in that period. The team
has not created a specific test to accomplish this task. It will come on a future report.
8.1.1.3 Power Consumption Test
Similar to the temperature test, this test will consider the power dissipated. A large part of this test
is to find the current draw of the function and individual components, as the production model will
need to operate on the battery power of the vehicle. The team has not created a specific test to
accomplish this task. It will come on a future report.
8.1.1.4 Latency Test
A latency test will determine if the code is running slow enough to affect performance. This will be
done by analyzing the time it takes to run the initialization process without any code body. The
team will then compare this value to other latency tests involving specific pieces of code. The team
has not created a specific test to accomplish this task. It will come on a future report.
8.1.2
Initial Test Results
The team has not performed tests for any of the previously mentioned tests.
8.1.3
Future Testing
The team has not begun testing for any of the previously mentioned tests.
8.1.4
Current Integration
The team has not integrated anything relevant to the previously mentioned tests.
40
8.2
Rapid Deceleration Warning
8.2.1
Testing Method
The team continues to prepare a set of tests to prove the performance of the system as described in
the Objectives and Requirements (Chapter 4) and the specific system architecture (Chapter 5). The
tests are described in detail below. This list is not inclusive, as the team continues to iterate through
different tests.
8.2.1.1 Accelerometer Accuracy Test
This test will consider the accuracy of the accelerometer. The requirements state that the brake
lights should flash only when the vehicle is decelerating faster than 6m/s 2 and that the
accelerometer should be accurate to within a tenth of a m/s 2. This test will be conducted through
available computer software. The team has not created a specific test to accomplish this task. It will
come on a future report.
8.2.1.2 Frequency Test
This test will consider the frequency of the signal that is output the brake lights. The requirement
states that the frequency must not be greater than 4Hz. The output signal will be connected to an
oscilloscope and examined to be certain that it fulfills this requirement. The team has not created a
specific test to accomplish this task. It will come on a future report.
8.2.2
Initial Test Results
The team has not tested any RDW specific tests.
8.2.3
Future Testing
The team has not begun testing for any RDW specific tests.
8.2.4
Current Integration
The accelerometer and the Arduino microcontroller have been connected and proven to
communicate with each other. Other than that, no tests have been integrated.
8.3
Driver Awareness Sensor
8.3.1
Testing Method
The team continues to prepare a set of tests to prove the performance of the system as described in
the Objectives and Requirements (Chapter 4) and the specific system architecture (Chapters 6). The
tests are described in detail below. This list is not inclusive, as the team continues to iterate through
different tests.
8.3.1.1 Blink Accuracy Test
This test will determine what percentage of blinks are picked up by the system. If the system can
track an eye blinking consistently, then it will be able to detect someone’s eyes closing for longer
41
than a standard blink. The team has not created a specific test to accomplish this task. It will come
on a future report.
8.3.1.2 Lighting Test
This test will analyze eye motion in different amounts of light. This function must work in nighttime
as well as daytime, so a lighting test is necessary to ensure proper operation. The team has not
created a specific test to accomplish this task. It will come on a future report.
8.3.2
Initial Test Results
None of the test mentioned above has been completed up to this point.
8.3.3
Future Testing
All of the tests mentioned above still need to be completed.
8.3.4
Current Integration
No parts have arrived yet; therefore, there is no integration currently.
8.4
Speed Limit Indicator
8.4.1
Testing Method
The team continues to prepare a set of tests to prove the performance of the system as described in
the Objectives and Requirements (Chapter 4) and the specific system architecture (Chapters 7). The
tests are described in detail below. This list is not inclusive, as the team continues to iterate through
different tests.
8.4.1.1 LED Current Test
The LED output will be coming out of a demultiplexer. Testing needs to be done to determine what
the current leaving the demultiplexer is compared to how much enters into the demultiplexer. The
consistency of the current can also be analyzed. The team needs to implement the circuitry to drive
the LEDs before this test can occur. The team has not created a specific test to accomplish this task.
It will come on a future report.
8.4.1.2 GPS Accuracy Test
The team will need to test the GPS for its accuracy in adverse conditions. This can include poor
weather (cloudy/foggy), trees, tall buildings, and tunnels. The team has not created a specific test to
accomplish this task. It will come on a future report. The team has tested the GPS for accuracy as a
control in good conditions.
For the first test, the team went to 10 points on Calvin College’s campus, and we took the GPS to
them and recorded the data for latitude and longitude. The team visited the ten points more than
once, to see if the results become more accurate as time goes on. The team entered the longitude
and latitude data into Google Maps to find the error in meters. The approximate error for this test is
42
one meter, due to the accuracy of Google Maps and the human error involved in walking the GPS
around campus.
A second accuracy test was be run on the road, which is the application of this project. Since this
test is a combination of a speed test and position test, the position was displayed every seven reads.
This retained enough accuracy for a position test while being able to test the speed every output
without the data being cluttered.
A third test involved driving around Ann Arbor, in both country and city roads. This test considered
GPS obstructions in people’s daily commutes, such as tall buildings in downtown and trees in the
country.
8.4.1.3 GPS Velocity Test
The GPS not only reports position data, but velocity data as well. This information will be used to
output a different color LED if the driver is going more than 10 miles per hour over the speed limit.
The consistency of the GPS velocity information should be determined to find how sensitive that
code can be written. The team has not created a specific test to accomplish this task. It will come on
a future report. A quantitative analysis has been done by monitoring the vehicle’s speed and the
output from the GPS from within the car.
The first speed test will look at the speed (in miles per hour) returned by the GPS device. This will
be monitored within the vehicle, as quantitative analysis of the speed would be difficult to achieve.
For an initial test, a qualitative analysis of the speed limit accuracy is enough, especially since this
data is not necessary for the primary function of this device. Further testing is necessary to make a
quantitative assessment of the speed accuracy. Besides the speed limit, the course made good data
was analyzed, as that could be used in the GPS position algorithm. The course made good depicts
which direction you are headed in, as a measure of degrees from north. This data will be analyzed
using a similar quantitative analysis as for the speed data.
8.4.2
Initial Test Results
8.4.2.1 LED Current Test
The team has not run this test at this time.
8.4.2.2 GPS Accuracy Test
The results are problematic. The average error is approximately 20 meters. The best accuracy was
around 1 meter, but the worst accuracy was about 40 meters. Unfortunately, the 40 meters
measurement was not an outlier. See Figure 14 for all the data taken for this test. Each test has
similar average error, so the GPS does not become more accurate over time.
43
Figure 14. GPS Accuracy Data for the First Test
The average latitude and longitude’s distance from the point was approximately equal to the
average of the distances calculated for each test. This indicates that the GPS was generally incorrect
in the same direction from the expected point. This means that the GPS was more precise than it
was accurate.
The results of this test are not satisfactory for this function. Further testing is necessary to
determine if the GPS module will work properly for this function.
In the second test, the position accuracy improved from the data in the first test. The team placed
the GPS module on the dashboard of a moving vehicle. Figure 15 shows the route taken and the
data collected. The GPS did a much better job of tracking position on the move, even within the
confines of a car on a cloudy day. Looking at the map visually, it was easy to see which path was
taken, and there was no question as to what road was travelled. This is promising for the Speed
Limit Indicator project, which will rely on computations as opposed to visual analysis. If a visual
analysis is quite simple, a computational method is feasible.
44
Figure 15. Second GPS Test, Mapped to Google Maps
A third qualitative test was done in Ann Arbor. This test occurred on city streets and country roads,
to provide a wide array of data. Figure 16 shows the data from the entire test. The country roads
went as smooth as the first test, but the city offered some troubling data. Figure 17 shows a portion
of downtown Ann Arbor. An irregularity in the data is clear. The GPS was obstructed by the high
buildings in downtown Ann Arbor. Trees have not had an effect on performance as far as we can
tell, but buildings have a tangible effect. Further testing on this issue is necessary.
Figure 16. Third GPS Accuracy Test, Mapped to Google Maps
45
Figure 17. Third GPS Accuracy Test, Close-Up On Downtown Ann Arbor
8.4.2.3 GPS Velocity Test
The speed and course made good data seemed to be accurate enough for our uses. Relying on a
speedometer of the car for a comparison point, the speed outputted by the GPS was correct with a
few miles per hour. There was no compass to compare with for the course made good data, but it
correctly showed when the vehicle was generally moving north, south, east, and west. The course
made good remained constant within a few degrees when the vehicle was traveling in an
approximately straight line.
8.4.3
Future Testing
The team needs to develop qualitative testing approaches to each problem. Once that is done, the
team can test each individual problem with a given set of criteria.
8.4.4
Current Integration
Currently, only the GPS and microcontroller are in possession of the team. These two pieces have
been connected and communicate with each other successfully. Their integration has led to initial
testing for the GPS accuracy test and the GPS velocity test.
46
9 Business Plan
9.1 Business Strategy
The Smart Dashboard has developed a business strategy to market this project as a profitable
business. All three safety functions will be offered as one product, which will decrease the price per
function. To separate each function into a separate product, each function would duplicate the
microcontroller and memory, which would come to an additional $20 per part. Factoring in the
additional PCB manufacturing and packaging costs, the total costs to manufacture each product
separately would be 33% more than to implement all three within one product as we are doing.
Therefore, it will be easier to enter into the market as the lower variable price helps to offset the
high initial fixed price.
9.1.1
Customer
The Smart Dashboard plans to market this device to car manufacturers. Our product will be a
luxury package that car manufacturers can add to basic models, such as the Ford Fusion. The team
will design the product to integrate with the current dashboard of a particular model, so the
manufacturer can choose whether to include it in the vehicle. This makes our business viable longterm, as redesign will be necessary for different models of cars that we may be selling to.
9.2 Marketing Study
In order to determine the feasibility of this project in the marketplace, a study of the current
marketplace is necessary. Various car safety functions are currently available, from cars that
monitor the lane markings to detect drift to cars that monitor the car in front of you to detect
possible collisions [24].
9.2.1
Competition
There are no direct competitors that can match all three safety functions. However, competition
does exist from companies that perform one of our functions. GPS devices today do display the
speed limit on certain models, but those are aftermarket devices that would not be integrated into
the vehicle during fabrication. There is an aftermarket product designed to flash a third brake light,
and is designed to comply with all United States regulations [25]. Mercedes-Benz incorporated a
driver awareness device into some of their high-end cars beginning in late 2008 [32]. Other
companies have incorporated similar systems, such as Ford [33], Volkswagen [34], and Volvo [35].
Many of these systems are based on lane departure warnings, but the function provided is similar
enough to ours to be considered direct competition.
9.2.2
Market Survey
Our product is a unique blend of vehicle safety functions not currently offered by any other
manufacturer. The speed limit indicator has demand, even though GPS devices could tell you the
speed limit on a handheld device. “In an age when GPS devices seem to be replacing roadmaps, is it
too much to ask for a built-in speed limit indicator? Wouldn't such an option make the roads safer,
47
in addition to cutting down on driver anxiety?” [26]. The market is eager for vehicle safety functions
in general, and our product offers new safety functions not currently offered in commercial
vehicles. To begin, the team is considering the Ford Fusion. In 2011, Ford sold approximately
250,000 Ford Fusions in the United States [30]. The team believes that 10% of those vehicles could
have our package installed on them. For one model, we expect to achieve sales of 25,000 products
per year. Our possible market is much greater than one model of car. We could expand to working
with one automaker on all their vehicles or even working with many automakers.
9.3 Cost Estimate
The cost estimate for this product is different for the prototype and the production model. The
prototype is under a strict budget as defined by the Senior Design class instructors. The prototype
uses development boards in the design process, while the production model will use different parts
that can be soldered to a printed circuit board that will be more efficient in terms of size.
9.3.1
Prototype Budget
The team is developing the prototype to prove the concept of The Smart Dashboard. Table 12 gives
our initial budget estimates for the project. Our team has requested $602 in funds for the entirety of
the project.
Table 12. Prototype Budget
SLI
RDW
DAS
Item
Cost
Item
Cost
Item
Cost
GPS
$43
Accelerometer
$23
Raspberry Pi
$35
Demultiplexer
$6
Prototype Brake Lights
$75
Power Supply
$5
Arduino Uno
$30
Arduino Uno
$30
4 GB SD Card
$10
RGB LEDs
$25
Shipping
$10
Webcam
$100
SD Card Adapeter
$15
Outputs
$40
SD Card
$5
LEDs
$10
Shipping
$20
Shipping
$20
Function Total
$144
Function Total
$220
Misc Replacements
$100
Team Total
$602
9.3.2
Function Total
$138
Production Budget
The production model budget is split into two sections. The variable costs are similar to the
prototype budget in Section 9.3.1, in that the cost estimate is based per unit. The fixed costs are
incurred at a single point in time or are a yearly cost.
48
9.3.2.1 Variable Costs
Table 13 shows an estimate of the variable costs for the prototype. The expected cost is
approximately $95 per unit. The team selected an ARM processor for the production model. Further
analysis is necessary to determine if this processor is best for the project. The volume of 25,000
annually comes from Section 9.2.2, in which we hope to sell our product for 10% of Ford Fusions
sold in the United States each year.
Table 13. Expected Variable Costs for the Production Model
Item
Model
Unit Price
Quantity
Total Cost
Accelerometer
ADXL345
$3.696
25000
$92,400
GPS
A2200-A
$13.60
25000
$340,000
LEDs
OSRAM Opto Semiconductors LUW
JNSH.EC-BRBT-5E8G-1
$0.081
25000
$2,025
Memory
Spansion S34ML04G100BHI000
$6.95
25000
$173,750
Demultiplexer
TI CD74HCT154M96G4
$0.25
25000
$6,250
Microcontroller
STM32F372CCT6
$3.52
25000
$88,000
Camera
RB-Lin-48
$39.20
25000
$980,000
Resistors
RK73H2BTTDD1001F
$0.003
250000
$750
Connector
4-794628-0
$1.71
25000
$42,750
$20
25000
$500,000
5% of variable costs
$4.45
25000
$111,296
Variable Cost Per Unit
$93.46
Total Var. Cost
$2,337,221
PCB / Packaging
Replacements
9.3.2.2 Fixed Costs
Table 14 shows an estimate of the one-time fixed costs for the production model. These include the
design time behind the product and the software suites necessary to design our product.
Table 14. Expected One-Time Fixed Costs for the Production Model
Item
Cost
Notes
Design
$1,000,000
10000 hours, $100 per hour design time
$150,000
Software Suites
Capital Investment
Table 15. Amortized One-Time Costs
One-Time Costs at Year 1
$1,150,000
49
Year 1
Year 2
Year 3
$164,335
$281,635
$201,135
Table 15 shows the amortized costs for the one-time costs. This uses a 7-year recovery period using
MACRS. The initial design costs can be spread over the young life of the company to reduce the
large debt right at the start. Table 16 shows the fixed annual costs. Yearly costs include salaries of
all employees as well as the costs to rent an office building in Detroit, Michigan. Detroit was chosen
for its locality to the automotive companies located in Detroit. All three team members are
residents of the state of Michigan, and would like to keep jobs in Michigan and help stimulate the
economy there.
Table 16. Fixed Annual Costs
Item
Cost
Notes
Sales Team
$200,000
Two sales staff, $100k/yr including benefits
Management
$500,000
Management team
General Labor
$200,000
Janitor, Secretary, Shipping
Office Rental
$26,000
Ford Building [48]
Utilities
$2,600
~10% of office cost
Research and Development
$60,000
~10% Gross Margin
9.4 Estimated Profits
Table 17 shows a profit estimate for years one through three. As a unique product, the team feels
that selling the product for $150 per unit is reasonable. The 2012 Ford Fusion offered advanced
packages for a navigation system and a rear-sensing camera. These packages cost $1,995 and
$2,940, respectively [31]. Our system provides similar worth to these other packages, so
automakers should be willing to pay $150 per unit to make it worthwhile for them. Our profit
margin is relatively low, but low margins are part of the automobile industry. We expect our
volume of sales to increase every year. It just takes a large contract to have a much larger quantity
there. Further financial analysis is necessary to find the best and worst case scenarios, as well as a
break even analysis.
50
Table 17. Estimated Profits for the Production Model
Year 1
Year 2
Year 3
Total Variable Cost
$2,337,221
$2,570,200
$2,803,855
Total Fixed Cost
$1,152,935
$1,270,235
$1,189,735
Total Costs
$3,490,156
$3,840,435
$3,993,590
Selling Quantity
25,000
27,500
30,000
Selling Price
$150
$150
$150
Revenue
$3,750,000
$4,125,000
$4,500,000
Gross Margin
$259,843
$284,564
$506,409
Taxes
$90,945
$99,597
$177,243
Profit
$168,898
$184,996
$329,166
Profit Margin
4.84%
4.82%
8.24%
51
10
Conclusions
10.1 Project Feasibility
Creating a project with three vehicle safety functions will be filled with challenges. Our class load at
Calvin College has prepared us to work through problems and work with diligence. The team is
motivated to bring this project to completion with an exceptional product. Many of the challenges
are software based, and most of those challenges can be solved through time and hard work.
The team has determined that the project as proposed is feasible. The team has worked for
approximately 200 hours thus far in the semester. The team is willing to take time over Interim to
do hardware testing and initial algorithm development. The second semester will involve building
the prototype and fully testing its capabilities. The team estimates that there will over 600 hours of
total work to complete the entire project, so the project will be approximately 33% done at the end
of the first semester.
10.2 Current Status
10.2.1 Rapid Deceleration Warning
The team is currently in possession of the selected accelerometer and microcontroller, and initial
testing has begun to interface these two hardware components. After that is accomplished, the tests
as described in Section 8.1 can begin.
10.2.2 Driver Awareness Sensor
The team has just selected the components to use, and they must be ordered and shipped in order
to continue. Currently, the team is working to research various outputs that could be used to alert
the driver in the case that they are falling asleep.
10.2.3 Speed Limit Indicator
The team is currently in possession of the selected GPS module and microcontroller. They have
successfully communicated with each other. The team is determining the exact testing method for
the GPS accuracy tests described in Section 8.3, and then testing will begin to determine the
accuracy of the GPS.
52
11
Credits and Acknowledgements
The team would like to thank Calvin College engineering professor Steven VanderLeest for advising
the team, encouraging professionalism, and demanding a high standard of excellence.
The team would like to thank GE Aviation employee Tim Theriault for consulting with the team and
providing insight into possible hardware and software issues.
The team would like to thank engineering professor Yoon Kim for providing valuable insight and
ideas for the project.
The team would like to thank all of the people who have supported the project through social media
sites like Facebook, Twitter, and YouTube.
53
12
References
[1] Weiss, Merkel. "Confronting Driver Distraction." The Futurist 41.1 (2007): 16-7. ProQuest
Business Collection; ProQuest Engineering Collection. Web. 12 Nov. 2012.
[2] http://usatoday30.usatoday.com/money/autos/story/2012-01-17/cars-trucks-agepolk/52613102/1
[3] http://www.unece.org/fileadmin/DAM/trans/main/wp29/wp29regs/r48r6e.pdf
[4] Bloomfield, John and Lynam, Niall. "Deceleration based anti-collision safety light control for
vehicle." US Patent 6411204. 25 June 2002.
[5] cmucam.org
[6] Richard, G. Oderwald, and A. Boucher Britt. "GPS After Selective Availability: How Accurate is
Accurate enough?" Journal of Forestry 101.4 (2003): 24,27,2. ProQuest Engineering Collection. Web.
10 Nov. 2012.
[7] Vicente Milanés, et al. "Autonomous Vehicle Based in Cooperative GPS and Inertial Systems."
Robotica 26.5 (2008): 627-33.ProQuest Engineering Collection. Web. 10 Nov. 2012.
[8] J, E. Naranjo, et al. "GPS and Inertial Systems for High Precision Positioning on Motorways." The
Journal of Navigation 62.2 (2009): 351-63. ProQuest Engineering Collection. Web. 10 Nov. 2012.
[9] Jo, Kichun, Keounyup Chu, and Myoungho Sunwoo. "Interacting Multiple Model Filter-Based
Sensor Fusion of GPS with in-Vehicle Sensors for Real-Time Vehicle Positioning." IEEE Transactions
on Intelligent Transportation Systems 13.1 (2012): 329-43. ProQuest Engineering Collection. Web. 10
Nov. 2012.
[10] Li, Shuo, and Karen Zhu. "Addressing Issues with GPS Data Accuracy and Position Update Rate
for Field Traffic Studies."Institute of Transportation Engineers.ITE Journal 73.2 (2003): 32-7.
ProQuest Business Collection; ProQuest Engineering Collection. Web. 10 Nov. 2012.
[11] Iqbal, Umar, et al. "Experimental Results on an Integrated GPS and Multisensor System for
Land Vehicle Positioning."International Journal of Navigation and Observation (2009)ProQuest
Engineering Collection. Web. 10 Nov. 2012.
[12] Kyrtsos, Christos. ”System and method for providing accurate vehicle positioning using spatial
bias techniques.” Patent 5,555,503. 10 Sep 1996.
[13] Kyrtsos, Christos. ”Vehicle position determination system and method.” Patent 5,375,059. 20
Dec 1994.
[14] http://www.mio.com/technology-gps-mapping-work.htm
[15] http://www.cplusplus.com/doc/tutorial/variables/
54
[16] http://www.artba.org/about/faqs-transportation-general-public/faqs/#9
[17] http://www.artba.org/mediafiles/faqsushighwaysystemcompositionpdf.pdf
[18] Kumar, Manu and Taemie Kim. 2005. “Dynamic speedometer: dashboard redesign to
discourage drivers from speeding.” CHI '05 Extended Abstracts on Human Factors in Computing
Systems (CHI EA '05). Web. 10 Nov. 2012.
[19] http://www.futurlec.com/GPS.shtml
[20] http://salestores.com/polstar1.html?gclid=CNr7q-7CvbMCFe5FMgod5B0AjA
[21] https://www.sparkfun.com/products/8975
[22]
http://www.parallax.com/Store/Sensors/CompassGPS/tabid/173/ProductID/644/List/0/Default.
aspx?SortField=ProductName,ProductName
[23] http://www.digikey.com/product-detail/en/MT29F2G16ABBEAH4:E%20TR/557-1545-1ND/3305283
[24] http://www.safercar.gov/staticfiles/safetytech/st_landing_ca.htm
[25] http://www.pulseprotects.com/
[26] http://electronics.howstuffworks.com/gadgets/automotive/car-speed-limit.htm
[27] http://www.wikispeedia.org/
[28] http://www.itoworld.com/map/41
[29] http://electronics.stackexchange.com/questions/11884/how-many-gps-channels-make-sense
[30] http://media.ford.com/images/10031/Dec11sales.pdf
[31] http://www.cars.com/ford/fusion/2012/standard-equipment/
[32] http://media.daimler.com/dcmedia/0-921-658892-1-1147698-1-0-0-1147922-0-1-11702-00-1-0-0-0-0-0.html?TS=1266506682902
[33] http://media.ford.com/article_print.cfm?article_id=34562
[34] http://www.volkswagen.co.uk/#/new/passat-vii/explore/experience/driver-assistance/
[35] http://www.zercustoms.com/news/Volvo-Driver-Alert-Control-and-Lane-DepartureWarning.html
[36] http://www.carparts.com/classroom/charging.htm
[37] http://www.safeny.ny.gov/drow-ndx.htm
55
[38] http://www.madsci.org/posts/archives/nov98/911697403.Me.r.html
[39] http://home.earthlink.net/~dnitzer/4HaasEaton/Decibel.html
[40] http://www.gpo.gov/fdsys/pkg/CFR-2011-title49-vol6/pdf/CFR-2011-title49-vol6-sec571108.pdf
[41] http://fias.uni-frankfurt.de/~triesch/courses/260object/papers/SpeedOfProcessing.pdf
[42] http://dev.emcelettronica.com/files/u4/Block_Diagram_of_the_AVR_Architecture.jpg
[43] http://www.sparkfun.com/datasheets
[44] http://beagleboard.org/
[45] http://www.raspberrypi.org/
[46] https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/
[47] http://cubieboard.org/
[48] http://www.michigan-commercial-real-estate-properties.com/Detroit-Office-Buildings.htm
56