CALVIN COLLEGE ENGINEERING DEPARTMENT
SENIOR DESIGN PROJECT
Final Report
Team 13 – The Smart Dashboard
Andrew DeZeeuw, Micah Dykstra, Nathan Gelderloos
May 8, 2013
© 2013, Calvin College and Andrew DeZeeuw, Micah Dykstra, Nathan Gelderloos
Executive Summary
The purpose of this senior design project is to design and prototype a set of car safety systems that
an automotive manufacturer could easily install. The team has split the project into three functions:
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 prototype
of this function was able to prove the functionality of the system by using an accelerometer to
measure deceleration and prototype brake lights to output the pulsed signal.
The goal of the speed limit indicator is to provide an easy way to determine the speed limit on the
current road and display it to the driver to promote safe driving speeds and reduce both incidental
and intentional speeding. The prototype of this function was able to prove the functionality in a
two-mile radius around Calvin College. It uses a GPS to find the location of the vehicle and checks a
database of speed limits to determine and display the proper speed limit.
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. The prototype of this function was
able to detect the driver’s face and eyes but was unable to detect blinks computationally. Video
output of light levels for the eyes showed the potential for blink detection, but the noise levels in
the system were too great to quantitatively detect blinks.
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 Analysis ................................................................................................................................................. 3
2.2.1
Milestones...................................................................................................................................................... 3
2.2.2
Work Breakdown Schedule .................................................................................................................... 4
2.2.3
Schedule Assessment ................................................................................................................................ 5
2.3
Method of Approach............................................................................................................................................ 6
2.4
Risk............................................................................................................................................................................. 6
System Overview............................................................................................................................................................ 7
3.1
Rapid Deceleration Warning ........................................................................................................................... 7
3.2
Driver Awareness Sensor ................................................................................................................................. 8
3.3
Speed Limit Indicator ......................................................................................................................................... 8
Objectives and Requirements ................................................................................................................................. 10
4.1
Common Objectives and Requirements .................................................................................................... 10
4.1.1
Requirements ............................................................................................................................................. 10
4.1.2
Objectives..................................................................................................................................................... 11
4.2
Speed Limit Indicator ....................................................................................................................................... 11
4.2.1
Requirements ............................................................................................................................................. 11
4.2.2
Objectives..................................................................................................................................................... 12
4.3
Driver Awareness Sensor ............................................................................................................................... 13
4.3.1
Requirements ............................................................................................................................................. 13
i
4.3.2
4.4
Requirements ............................................................................................................................................. 14
4.4.2
Objectives..................................................................................................................................................... 15
Design Norms....................................................................................................................................................... 15
4.5.1
Caring............................................................................................................................................................. 15
4.5.2
Trustworthy ................................................................................................................................................ 15
4.5.3
Transparency ............................................................................................................................................. 16
Rapid Deceleration Warning ................................................................................................................................... 17
5.1
System Design...................................................................................................................................................... 17
5.1.1
Determining Vehicle Deceleration..................................................................................................... 17
5.1.2
Comparing Data......................................................................................................................................... 17
5.1.3
Flashing the Brake Lights ...................................................................................................................... 18
5.2
Hardware System Design ................................................................................................................................ 18
5.2.1
Accelerometer ............................................................................................................................................ 20
5.2.2
Microcontroller.......................................................................................................................................... 23
5.3
6
Rapid Deceleration Warning ......................................................................................................................... 14
4.4.1
4.5
5
Objectives..................................................................................................................................................... 13
Software System Design .................................................................................................................................. 26
5.3.1
Calibrating the Accelerometer ............................................................................................................ 26
5.3.2
Reading and Converting the Acceleration Data ........................................................................... 27
5.3.3
Comparing to Threshold and Signal Output .................................................................................. 27
5.3.4
Noise Consideration ................................................................................................................................ 27
Driver Awareness Sensor ......................................................................................................................................... 28
6.1
System Design...................................................................................................................................................... 28
6.1.1
Determining Prolonged Eye Closure ................................................................................................ 28
6.1.2
Alerting Driver ........................................................................................................................................... 28
6.2
Hardware System Design ................................................................................................................................ 28
6.2.1
Microcontroller.......................................................................................................................................... 30
6.2.2
Camera .......................................................................................................................................................... 31
6.2.3
Speaker ......................................................................................................................................................... 33
6.2.4
Facial Illuminator ..................................................................................................................................... 33
6.2.5
Voltage Regulator ..................................................................................................................................... 34
ii
6.3
7
6.3.1
Vision Library............................................................................................................................................. 35
6.3.2
Operating System ..................................................................................................................................... 36
6.3.3
Initialize System ........................................................................................................................................ 37
6.3.4
Read Image from Camera ...................................................................................................................... 37
6.3.5
Process Faces.............................................................................................................................................. 38
6.3.6
Process Eyes ............................................................................................................................................... 38
6.3.7
Determine Eye State ................................................................................................................................ 39
6.3.8
Determine If Alarm Should Sound ..................................................................................................... 40
Speed Limit Indicator ................................................................................................................................................. 41
7.1
System Design...................................................................................................................................................... 41
7.1.1
Determining Vehicle Location ............................................................................................................. 41
7.1.2
Finding the Speed Limit ......................................................................................................................... 42
7.1.3
Storing the Speed Limits ........................................................................................................................ 42
7.1.4
Outputting the Speed Limit .................................................................................................................. 43
7.2
Hardware System Design ................................................................................................................................ 48
7.2.1
GPS .................................................................................................................................................................. 49
7.2.2
Microcontroller.......................................................................................................................................... 52
7.2.3
Memory......................................................................................................................................................... 52
7.2.4
Outputs ......................................................................................................................................................... 53
7.3
Software System Design .................................................................................................................................. 58
7.3.1
Criteria .......................................................................................................................................................... 59
7.3.2
Alternatives ................................................................................................................................................. 59
7.3.3
Decisions ...................................................................................................................................................... 59
7.4
8
Software System Design .................................................................................................................................. 35
Initial Printed Circuit Board Design ........................................................................................................... 67
Integration and Testing ............................................................................................................................................. 68
8.1
Rapid Deceleration Warning ......................................................................................................................... 68
8.1.1
Testing Method .......................................................................................................................................... 68
8.1.2
Test Results ................................................................................................................................................. 69
8.2
Driver Awareness Sensor ............................................................................................................................... 70
8.2.1
Testing Method .......................................................................................................................................... 70
iii
8.2.2
Test Results ................................................................................................................................................. 71
8.2.3
Current Integration.................................................................................................................................. 72
8.3
9
Speed Limit Indicator ....................................................................................................................................... 73
8.3.1
Testing Method .......................................................................................................................................... 73
8.3.2
Test Results ................................................................................................................................................. 75
8.3.3
Current Integration.................................................................................................................................. 81
Business Plan ................................................................................................................................................................. 83
9.1
Business Strategy ............................................................................................................................................... 83
9.1.1
9.2
Customer ...................................................................................................................................................... 83
Marketing Study.................................................................................................................................................. 83
9.2.1
Competition ................................................................................................................................................ 83
9.2.2
Market Survey ............................................................................................................................................ 83
9.3
Cost Estimate ....................................................................................................................................................... 84
9.3.1
Prototype Budget...................................................................................................................................... 84
9.3.2
Production Budget ................................................................................................................................... 85
9.4
10
Estimated Profits ................................................................................................................................................ 87
Conclusions................................................................................................................................................................ 90
10.1
Accomplishments ............................................................................................................................................... 90
10.2
Missed Goals ......................................................................................................................................................... 90
10.3
Lessons Learned ................................................................................................................................................. 90
10.4
Future Developments ....................................................................................................................................... 91
11
Credits and Acknowledgements ....................................................................................................................... 92
12
References .................................................................................................................................................................. 93
iv
Table of Figures
Figure 1. Project Management Example ........................................................................................................................ 5
Figure 2. Weekly Work Load............................................................................................................................................... 5
Figure 3. RDW System Diagram......................................................................................................................................... 7
Figure 4. DAS System Diagram........................................................................................................................................... 8
Figure 5. SLI System Diagram............................................................................................................................................. 8
Figure 6. Microcontroller Architecture [42]............................................................................................................... 18
Figure 7. RDW Hardware Diagram ................................................................................................................................. 19
Figure 8. Typical Brake Light Circuit ............................................................................................................................. 20
Figure 9. RDW Software Diagram ................................................................................................................................... 26
Figure 10. Noise vs. Output Data Rate – Full Resolution [57] ............................................................................. 27
Figure 11. DAS Hardware Diagram ................................................................................................................................ 29
Figure 12. IR LEDs before filter removal ..................................................................................................................... 33
Figure 13. IR LEDs after filter removal ......................................................................................................................... 33
Figure 14. Facial Illuminator Schematic....................................................................................................................... 34
Figure 15. Facial Illuminator from Driver's Perspective ....................................................................................... 34
Figure 16. Facial Illuminator Close-up.......................................................................................................................... 34
Figure 17. DAS Software Diagram .................................................................................................................................. 37
Figure 18. Initial Eye Detection ....................................................................................................................................... 39
Figure 19. Desired Eye Detection.................................................................................................................................... 39
Figure 20. Eye Locations based on Proportion of Face .......................................................................................... 39
Figure 21. Average Eye Brightness Showing Blinks................................................................................................ 40
Figure 22. Average Eye Brightness with Movement ............................................................................................... 40
Figure 23. Breakdown of Road Types [17] ................................................................................................................. 43
Figure 24. Design 1 with user following 45 mph speed limit.............................................................................. 44
Figure 25. Design 1 with user exceeding 45 mph speed limit ............................................................................ 44
Figure 26. Design 2 with user following 45 mph speed limit.............................................................................. 44
Figure 27. Design 2 with user exceeding 45 mph speed limit ............................................................................ 44
Figure 28. Design 3 with user following 45 mph speed limit.............................................................................. 45
Figure 29. Design 3 with user exceeding 45 mph speed limit ............................................................................ 45
v
Figure 30. Design 4 with user following 45 mph speed limit.............................................................................. 46
Figure 31. Design 4 with user exceeding 45 mph speed limit ............................................................................ 46
Figure 32. Design 5 with user following 45 mph speed limit.............................................................................. 46
Figure 33. Design 5 with user exceeding 45 mph speed limit ............................................................................ 46
Figure 34. Normal Speedometer [18] ........................................................................................................................... 47
Figure 35. Speedometer with Speed Limit of 40 Miles Per Hour [18] ............................................................. 47
Figure 36. SLI Hardware Diagram .................................................................................................................................. 49
Figure 37. Charlieplexing RGB LEDs circuit ............................................................................................................... 54
Figure 38. First Implementation of the LED Display .............................................................................................. 56
Figure 39. Second Implementation of the LED Display ......................................................................................... 56
Figure 40. Third Implementation of the LED Display ............................................................................................ 57
Figure 41. Final Implementation of the LED Display with Servo for Speedometer Arrow..................... 57
Figure 42. SLI Software Diagram .................................................................................................................................... 58
Figure 43. Boxes showing the size of a single part of the database .................................................................. 60
Figure 44. Current vehicle location with the bounding triangle ........................................................................ 63
Figure 45. Bounding triangle with all database points in the area ................................................................... 64
Figure 46. Speed limit data shown for points within the bounding triangle ................................................ 65
Figure 47. Initial PCB Layout. Parts listed in Table 16 ........................................................................................... 67
Figure 48. RDW Scale Model Interior ............................................................................................................................ 68
Figure 49. RDW Scale Model Exterior ........................................................................................................................... 68
Figure 50. Prototype Model............................................................................................................................................... 69
Figure 51. RDW Latency Test ........................................................................................................................................... 69
Figure 52. Display from Final Prototype...................................................................................................................... 73
Figure 53. GPS Accuracy Data for the First Test ....................................................................................................... 76
Figure 54. Second GPS Test, Mapped to Google Maps ............................................................................................ 77
Figure 55. Third GPS Accuracy Test, Mapped to Google Maps ........................................................................... 77
Figure 56. Third GPS Accuracy Test, Close-Up On Downtown Ann Arbor..................................................... 77
Figure 57. Histogram of Timing Data for GPS Extraction ..................................................................................... 78
Figure 58. Histogram of Timing Data for Triangulation ........................................................................................ 79
Figure 59. Histogram of Timing Data for microSD Card Read ............................................................................ 80
Figure 60. MicroSD Card Read for all files within the database based on order the files are stored . 80
vi
Figure 61. Time to read from the microSD card based on location of file ..................................................... 81
Figure 62. Final implementation of the SLI ................................................................................................................ 82
Figure 63. Break-Even Analysis for Year 1 of The Smart Dashboard ............................................................... 88
vii
Table of Tables
Table 1. Signals used in Figure 7 ..................................................................................................................................... 19
Table 2. Accelerometer Alternatives ............................................................................................................................. 22
Table 3. Accelerometer Decision Matrix ...................................................................................................................... 23
Table 4. Microcontroller Alternatives ........................................................................................................................... 24
Table 5. Microcontroller Decision Matrix .................................................................................................................... 25
Table 6. Signals Used in Figure 11 .................................................................................................................................. 29
Table 7. DAS Microcontroller Alternatives ................................................................................................................. 30
Table 8. DAS Microcontroller Decision Matrix .......................................................................................................... 31
Table 9. DAS Camera Alternatives .................................................................................................................................. 32
Table 10. Vision Library Alternatives ........................................................................................................................... 36
Table 11. Survey responses for each design............................................................................................................... 48
Table 12. Signals Used In Figure 36 ............................................................................................................................... 49
Table 13. GPS Alternatives................................................................................................................................................. 51
Table 14. Decision Matrix for GPS Selection............................................................................................................... 51
Table 15. Line Assignments for each RGB LED ......................................................................................................... 55
Table 16. Table of Components for Figure 47 ........................................................................................................... 67
Table 17. Frame Rate Test Results from Kernel Update ....................................................................................... 72
Table 18. Frame Rate Test Results for Overclocking .............................................................................................. 72
Table 19. Frame Rate Test Results from GPU Memory Allocation .................................................................... 72
Table 20. Prototype Budget............................................................................................................................................... 85
Table 21. Expected Variable Costs for the Production Model ............................................................................. 86
Table 22. Expected One-Time Fixed Costs for the Production Model ............................................................. 86
Table 23. Amortized One-Time Costs............................................................................................................................ 86
Table 24. Fixed Annual Costs ............................................................................................................................................ 87
Table 25. Estimated Profits for the Production Model .......................................................................................... 88
viii
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 is 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 is a system that finds the speed limit of the
road the vehicle is currently on and displays 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 is a system that monitors the driver for signs of falling asleep. If the system
determines that the driver is falling asleep, the system should 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 will attend the University of Michigan in Ann
Arbor, MI, to pursue a Ph. D. in Computer Science and Engineering.
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 has accepted an engineering position with Apex Controls in Hudsonville, MI.
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 Ultimate
Frisbee and playing the guitar.
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 (Chapter 2) discusses how the team assigns tasks and operates.
The system overview section (Chapter 3) provides a brief overview of the project and background
information on the project areas. The objectives and requirements section (Chapter 4) contains the
end requirements for the project as well as any objectives that the team should achieve. The system
architecture sections (Chapters 5-7) discuss each function in depth, providing design criteria,
alternatives and decisions at the system, hardware, and software levels. The integration and testing
section (Chapter 8) discusses the testing process for each function and includes test results. The
business plan section (Chapter 9) 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 section
(Chapter 10) summarizing the accomplishments of the team and the setbacks faced throughout the
year.
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.
Team meetings provide updates on each function from the member that leads that particular
function. While team meetings were not regularly scheduled, they occurred about once per week
with all team members present. While team members were together, discussing and thinking
through problems occurred frequently. Team members could offer assistance on high-level issues,
although the specific design decisions were fully analyzed by the member in charge of that
particular function.
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 Drive extensively to organize the
team, and allows multiple members to work on the same document on different computers
simultaneously. Each team member has a notebook on Google Drive that is a collection of tests,
code, and written sections that can be accessed by any member at any time. This openness allows
each member to be aware of what the other members are working on and have already
accomplished.
2.2
Schedule Analysis
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 gave weekly status reports to their project
advisor, Professor Steve VanderLeest. These updates helped the team realize what each team
member had accomplished and hoped to accomplish in upcoming weeks.
2.2.1
Milestones
The major milestones of this project were software development, prototype construction, and final
testing. These milestones provided the team with motivation to accomplish tasks on time.
2.2.1.1 Software
The first milestone was the development of the software for each of the three functions. The initial
iteration of this process was simply to achieve communication between the different components of
the system. The next step was to test that the software meets the basic requirements of the system.
At this point, the team could integrate the software into a working prototype of the system. The
team had hoped to accomplish initial software development by 1/31/2013.
However, the team fell behind in this area, especially with regard to development of the Driver
Awareness Sensor. The software for this system still does not meet all the requirements. The
3
software for the Rapid Deceleration Warning achieved initial functionality by 2/1/2013 and the
software for the Speed Limit Indicator achieved initial functionality by 2/8/2013. These delays
were difficult for the team to overcome.
2.2.1.2 Prototype
The second milestone was the construction of the prototype for each of the three functions. The
initial iteration of this process was to achieve a simple ‘mock-up’ or bench-top model that provided
a proof of concept. The next step was to build a prototype that resembles the final product in both
aesthetics and its function. The team hoped to be at this stage of the project by 3/31/2013.
The team was not able to construct a working prototype of the Driver Awareness Sensor, although
it was able to demonstrate some functionality by 2/22/2013 and it constructed the infrared LED
display by 3/29/2013. For the Rapid Deceleration Warning, the team constructed an initial scale
model by 2/15/2013, but it took until 4/12/2013 to assemble a working prototype of the system.
The team was able to build and test a basic prototype of the Speed Limit Indicator by 2/22/2013.
However, the team completed the final version of the prototype on 4/12/2013. The time between
constructing initial and final prototypes was longer than the team had expected.
2.2.1.3 Final Testing
The third milestone was the final testing of each of the three functions. At this time, the prototypes
of each of the systems should have been complete. These tests were to ascertain whether the safety
functions met the requirements and objectives. The team hoped to begin final testing by
4/31/2013.
Although the team did not achieve the intended functionality for the Driver Awareness Sensor, they
were able to test some features of the system as early as 4/5/2013. The team was not able to
perform as many tests as it would have liked for the Rapid Deceleration Warning, but they were
able to complete a few requirement driven tests by 5/3/2013. Finally, for the Speed Limit
Indicator, testing began early and often for the crucial components of the system. Final testing was
completed for this system by 4/26/2013, ahead of schedule.
2.2.2
Work Breakdown Schedule
The team initially created a work breakdown schedule to track progress of the project. It was
separated by the major headings of ‘Reports/Presentations’, ‘Design’, and ‘Testing’. Each of the
project functions then further subdivided each of these sections. The original work breakdown
schedule of the project is available at The Smart Dashboard’s website:
http://www.calvin.edu/academic/engineering/2012-13-team13/docs.html.
This system broke down rather quickly, however, as the team did not maintain the schedule over
the course of the project. Instead, the team shifted to Google Drive to manage their project. Figure
1 shows a portion of a Google spreadsheet that the team utilized. From left to right, the spreadsheet
contains weekly information about the date, the hours the team member worked for the week, the
goals they accomplished during the previous week, the goals the still need to accomplish, and the
division of labor throughout the week.
4
Figure 1. Project Management Example
Each member of the team had a section of this spreadsheet. This was very helpful to the team to be
able to keep track of what each team member was working on. The same spreadsheet also
contained a weekly work load chart as shown in Figure 2 so that the team could visually monitor
who was doing what percentage of the total work per week and overall. This encouraged all team
members to contribute to the project.
Figure 2. Weekly Work Load
2.2.3
Schedule Assessment
As of 12/6/2012, the team had logged about 216 hours of work. The team had completed initial
research estimated at 17 hours per function. The team had also completed the feasibility study,
which they estimated to take approximately 130 hours. The team had also completed other
deliverables estimated to take 30 hours. Therefore, the total estimated time for the tasks to be
completed was 201 hours. Compared to the 216 hours of actual work to accomplish these tasks, the
error percentage in these estimates was only about 7%.
As of 4/19/2013, the team had logged about 570 hours of work. The team has completed the
system design and initial prototyping estimated at 43 hours per function. The team has also
completed the initial software estimated at 44 hours per function. Finally, the team had also
5
completed some initial testing estimated at 60 total hours. Therefore, the total estimated time for
those tasks completed was 321 hours. Compared to the 354 hours of actual work to accomplish
these tasks since the last update, the error percentage in these estimates was approximately 9%.
The original work breakdown schedule predicted 627 hours, which included the tasks of printed
circuit board design and construction and enclosure design and construction. However, the team
has logged approximately 730 hours and has accomplished neither of these tasks. The team
obviously underestimated the scope of the project and the amount of work required to take the
project to completion. A breakdown of the completed tasks is available at The Smart Dashboard’s
website: http://www.calvin.edu/academic/engineering/2012-13-team13/docs.html.
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 repeated as the system became more refined with each iteration. The
team members made sure to keep in contact with other team members on decisions made
throughout the project. Each member was aware of the other functions and reviewed the various
decisions that the team made. This helped to 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.
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.
6
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 (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 3.
Figure 3. 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.
7
3.2
Driver Awareness Sensor
The Driver Awareness Sensor (DAS) will alert the driver to unsafe driving conditions due to
drowsiness of the driver. The DAS has three distinct components, as shown in the basic system
block diagram in Figure 4. A camera will send real-time images of the driver’s face to a
microcontroller. The microcontroller will analyze the images for signs of drowsiness and generate
an alert to wake the driver. For a more detailed look at the DAS function’s system architecture, refer
to Chapter 6 (Driver Awareness Sensor).
Figure 4. DAS System Diagram
3.3
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 5. The microcontroller takes in a GPS coordinate for the vehicle’s
position and uses it to find speed limit in the database. The database is stored in memory connected
to the microcontroller. Once the speed limit is determined, the microcontroller outputs the speed
limit to the display on the speedometer. For a more detailed look at the Speed Limit Indicator (SLI)
function’s system architecture, refer to Chapter 7 (Speed Limit Indicator).
Figure 5. 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
8
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.
9
4
Objectives and Requirements
The objectives and requirements for the project are separated by the three functions along with a
section for common objectives and requirements. This section also includes design norms, which
are implied considerations the team imposed upon the design. These considerations are moral
guidelines for the engineering ethics applied throughout the final design.
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
REQ 4.1.1.1a: 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.
REQ 4.1.1.1b: 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
REQ 4.1.1.2a: Each safety function shall be able to operate with a temperature in the range from (20) to 70 degrees Celsius.
Explanation: The components will likely 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
REQ 4.1.1.3a: 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.
REQ 4.1.1.3b: 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.
10
4.1.1.4 System
REQ 4.1.1.4a: 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.
4.1.1.5 Hardware
REQ 4.1.1.5a: The production model of the system shall operate on one microcontroller.
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
OBJ 4.1.2.1a: 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
OBJ 4.1.2.2a: 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.
OBJ 4.1.2.2b: 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 microcontroller.
4.2
Speed Limit Indicator
4.2.1
Requirements
4.2.1.1 System
REQ 4.2.1.1a: 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.
REQ 4.2.1.1b: 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 exceeding the speed limit, the display will show a different color than if
the driver is following the speed limit.
11
4.2.1.2 Hardware
REQ 4.2.1.2a: 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.
REQ 4.2.1.2b: 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 display will be given in.
4.2.1.3 Software
REQ 4.2.1.3a: 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.
REQ 4.2.1.3b: 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.
REQ 4.2.1.3c: 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.
REQ 4.2.1.3d: 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
OBJ 4.2.2.1a: 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.
12
4.3
Driver Awareness Sensor
4.3.1
Requirements
4.3.1.1 System
REQ 4.3.1.1a: 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].
REQ 4.3.1.1b: 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.
REQ 4.3.1.1c: The Driver Awareness Sensor shall generate an audible signal to alert the driver that
they are falling asleep.
REQ 4.3.1.1d: 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
REQ 4.3.1.2a: 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
OBJ 4.3.2.1a: 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
OBJ 4.3.2.2a: 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.
13
4.3.2.3 Software
OBJ 4.3.2.3a: 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.
4.4
Rapid Deceleration Warning
4.4.1
Requirements
4.4.1.1 System
REQ 4.4.1.1a: 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].
REQ 4.4.1.1b: 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.
REQ 4.4.1.1c: 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
REQ 4.4.1.2a: 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
REQ 4.4.1.3b: 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.
14
4.4.2
Objectives
4.4.2.1 System
OBJ 4.4.2.1a: 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.
OBJ 4.4.2.1b: 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
OBJ 4.4.2.2a: 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.
OBJ 4.4.2.2b: 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.
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
15
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.
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.
16
5
Rapid Deceleration Warning
5.1
System Design
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, I2C is generally considered slightly 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, would 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 accelerometers are also much more common and 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 created software to accomplish this task
and that software is stored and run on a microcontroller. Figure 6 provides a block diagram of a
typical microcontroller architecture. The Data SRAM memory will store the program, which the
team initially estimated to be fewer than 10 KB due to the relative simplicity of the system. The size
of the current integration of the system is approximately 4 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.
17
Figure 6. Microcontroller Architecture [42]
5.1.3
Flashing the Brake Lights
When the software mentioned above has detected a deceleration value above the maximum
threshold specified by Requirement 4.4.1.1a, it will then use an unused pin of the microcontroller to
output a signal to the brake lights at the frequency specified by Requirement 4.4.1.1b. It is
important that the team meet this requirement because increasing the frequency increases the risk
of unwanted health effects caused by flashing lights. The Epilepsy Foundation reports that “flashing
lights most likely to trigger seizures are between the frequency of 5 to 30 flashes per second
(Hertz)” [55]. Requirement 4.4.1.1c specifies that the system should comply with U.S. vehicle
regulations, one of which restricts the use of flashing lights. Therefore, the team decided to
simulate flashing by using the Pulse Width Modulation (PWM) capabilities of the microcontroller.
This allows the brake light LEDs to switch between bright and dim levels without turning off
completely.
5.2
Hardware System Design
The key pieces of hardware necessary for the RDW system are as follows: an accelerometer and a
microcontroller. Figure 7 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.
18
Figure 7. RDW Hardware Diagram
Table 1. Signals used in Figure 7
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)
19
Serial
Peripheral
Interface
(SPI)
Figure 8 shows a more detailed look at the interface between the microcontroller and the
brake lights. The Darlington transistor is necessary to provide the current from the microcontroller
that the brake lights require. A typical brake light circuit draws 15-20A of current [58], so the
transistor needs to be rated for this. The team selected the ECG2541 transistor because it can
handle a maximum collector current of 25A [59]. The microcontroller that the team used only has
an output current of 0.04A per pin, but the transistor has a current gain of 2000, which is more than
enough to provide the necessary amperage. If the RDW system does fail, normal operation will
continue because the system does not receive its power directly from the microcontroller.
Figure 8. Typical Brake Light Circuit
5.2.1
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.
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.
20
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 popular in the field of
electronics. The electronic hobbyist retailer Sparkfun Electronics mentions all four of the
accelerometers in its ‘Accelerometer, Gyro, and IMU Buying Guide’ [56]. The team gathered the unit
cost for each component from the electronic supplier Digikey. The team used 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 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.
21
Table 2. Accelerometer Alternatives
BB
Cost
($)
Unit
Cost Output
Signal
($)
Supply
Voltage
(V)
Range
(+/- g)
BW
(Hz)
Current
Draw
(µA)
Manufacturer
Model
Analog
Devices
ADXL335
27.95 2.89 Analog
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.253200
145
Bosch
BMA180
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
29.95 3.10
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.
22
Table 3. Accelerometer Decision Matrix
Priority ADXL335 ADXL345 BMA180 LIS331HH
5.2.2
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
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.
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 development board.
23
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.
Table 4. Microcontroller Alternatives
Current
Draw
(mA)
Clock
Speed
(MHz)
Number
of Pins
Flash
Memory
RAM
Manufacturer
Model
Cost
($)
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
24
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
25
5.3
Software System Design
Figure 9 shows a software flow diagram of the RDW system. The software must (1) calibrate the
accelerometer upon start-up, (2) read the raw data from the accelerometer and convert this data to
usable deceleration data, and (3) 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 current software can be found
on The Smart Dashboard’s website: http://www.calvin.edu/academic/engineering/2012-13team13/docs.html.
Figure 9. RDW Software Diagram
5.3.1
Calibrating the Accelerometer
Most accelerometers need calibration before use. This is done by examining the acceleration
output at a known acceleration and subtracting the offset from the output. On start-up, the vehicle
should not be moving and therefore the acceleration in the horizontal direction should be zero. The
ADXL345 accelerometer has offset registers that contain values that it automatically adds to the
acceleration data and stores in the output data registers. The software first measures 100 data
horizontal acceleration data values and averages them to remove most of the noise. The difference
between this value and the actual value of zero is then written to the offset register. Because the
offset registers are cleared when power is removed, calibration must be performed every time the
26
system starts up. This also ensures that the system meets the accuracy specified by Requirement
4.4.1.2a and is ultimately safe for the end-user.
5.3.2
Reading and Converting the Acceleration Data
The raw, full-resolution, acceleration data is a 13-bit value in twos complement form. The software
reads this value from the appropriate data register. To convert this value to the unit g
(gravitational force), the software first multiples the value by the total g range (in this case 32g) and
then divides it by the number of values represented by 13 bits. The software then converts this
new g value to the unit m/s2 by multiplying the value by the gravitational constant (9.80665 m/s2).
5.3.3
Comparing to Threshold and Signal Output
Now that the data is converted to the proper units, the software compares this value to the
acceleration threshold of -6.5 m/s2 as specified by Requirement 4.4.1.1a. If the value is greater than
this threshold, the software outputs the pulsed signal for a specified time limit. The pulsed signal is
creating by alternating between low and high PWM values separated by a delay of 0.125 seconds to
achieve an overall period of 0.25 seconds, which corresponds to the 4 Hertz frequency specified by
Requirement 4.4.1.1b. Once the time limit is reached, the program returns to the start of the overall
loop.
5.3.4
Noise Consideration
Because of noise, the team could not realistically meet Objective 4.4.2.2b, which states that the
system should read in the acceleration data at the maximum data rate allowed by the
microcontroller. Figure 10 shows how the output data rate affects the output noise of the
accelerometer. The noise increases at a slow rate until approximately 100 Hz at which point the
rate of noise increases significantly. Therefore, the team selected 100 Hz as the data rate for the
accelerometer. As shown in …, this data rate is fast enough to meet Requirement 4.4.1.3a while also
limiting the noise to less than 1.5 least significant bits (LSB). At full resolution, there are 256 LSB/g
so that the noise corresponds to less than 0.06 m/s2, which also fulfills the precision demanded by
Requirement 4.4.1.2a.
Figure 10. Noise vs. Output Data Rate – Full Resolution [57]
27
6
Driver Awareness Sensor
6.1
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. The team can implement this with a
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 11 shows a block diagram of the hardware with expected signal communications.
28
Figure 11. DAS Hardware Diagram
Table 6. Signals Used in Figure 11
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.
29
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 microcontroller 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
30
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
Camera
6.2.2.1 Criteria
Cost [25]
This is an important criterion because the team has a limited budget with which to build the
prototype.
Ease of Software Programming [20]
The camera should be able to be connected to the microcontroller and set up with minimal effort.
Resolution [10]
The camera should have at least 640x480 resolution in order to provide adequate picture quality.
Higher resolutions would result in better pictures, but would also increase the time required to
process the image.
IR Capable [10]
The camera must be able to sense infrared light in order to take advantage of the facial illuminator.
Some cameras have this capability out of the box and need no modifications, while the team would
need to modify others to allow infrared light.
31
6.2.2.2 Alternatives
There were many similar cameras to choose from. Table 9 provides a sample to show the
similarities. Cameras that caused issues for others [50] when connecting to the Raspberry Pi were
not included in the list.
Table 9. DAS Camera Alternatives
Camera
Cost
Resolution
IR Capable?
Works with RasPi
Logitech C120
$10
640x480
Modify [51]
Yes
Logitech C905
$33
1600x1200
Modify
Yes
HP Webcam HD-2200
$21
1280x720
Modify
Yes
Microsoft LifeCam NX-6000
$20
1280x1024
Modify
Yes
Sony PlayStation Eye
$18
640x480
Modify [52]
Yes
Sunvalleytek Y712 Webcam
$12
1024x768
Yes
Unknown
U19-A Night Vision Webcam
$10
640x480
Yes
Unknown
6.2.2.3 Decisions
The Logitech C120 was primarily chosen for its low cost and because there were tutorials on how to
remove the infrared filter from the camera. It is also verified to work with the Raspberry Pi [62].
6.2.2.4 Implementation
The camera required a small modification to remove the infrared filter. Figure 12 shows the
infrared LEDs before the filter was removed. Though the team designed the LEDs to be at maximum
brightness, the light is only slightly visible. The removal of the infrared filter was straightforward.
The filter was located just above the sensor and securely adhered to the housing. After removing
the housing to protect the sensor, the team removed the filter, though it broke in the process. This
was not a problem because the filter is not required. The infrared LEDs are much brighter without
the filter, as shown in Figure 13.
32
Figure 13. IR LEDs after filter removal
Figure 12. IR LEDs before filter removal
6.2.3
Speaker
Since the Raspberry Pi has an audio out jack, any speakers can be connected in order to produce the
alert for the driver. Due to time constraints, the team did not select a specific speaker, as desktop
speakers would have worked for the prototype.
6.2.4
Facial Illuminator
The team selected 950nm infrared LEDs for the facial illuminator. The team positioned these near
the camera so that they could adequately illuminate the field of view of the camera. The
illumination allows the camera to keep a fast frame rate, instead of slowing due to poor lighting
conditions, as well as providing overall better lighting conditions for the detection software.
The team designed the prototype facial illuminator to run on a 5-volt supply, as that is the same
voltage as the Raspberry Pi supply. With a forward voltage of ~1.5V and max current of 20mA, the
team decided 21 LEDs by placing three LEDs in series and placing seven sets in parallel, as shown in
Figure 14. To obtain the correct forward voltage and current, the team selected a 27-ohm resistor
for each set of LEDs in series. Pin 1 provides +5V, while Pin 2 is connected to ground.
33
Figure 14. Facial Illuminator Schematic
The resulting facial illumination appears as a bright bar of light from the driver’s perspective, as
shown in Figure 15. Figure 16 shows a close up view of the facial illuminator prototype with its
array of LEDs.
Figure 16. Facial Illuminator Close-up
Figure 15. Facial Illuminator from Driver's Perspective
6.2.5
Voltage Regulator
Due to time constraints, the team was unable to determine the correct voltage regulator to use for
integration into a vehicle. For the prototype, the team used a standard AC-DC power adapter
capable of supplying at least 1A at 5V to the RaspberryPi. This allowed the team to test the
prototype without connecting the system to a vehicle.
34
6.3
Software System Design
Figure 17 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. The current software can be found on The Smart Dashboard’s website:
http://www.calvin.edu/academic/engineering/2012-13-team13/docs.html.
6.3.1
Vision Library
In order to save time and avoid reinventing the wheel, the team decided to use a vision library to
assist with the image capturing and processing. Table 10 shows a number of vision libraries and
their original audience and intended uses, as determined from their respective websites. The team
selected OpenCV because it is the most well developed and provides functions for face and eye
detection. Additionally, the team has found many uses of OpenCV for similar projects.
35
Table 10. Vision Library Alternatives
Library
Website
Audience/Use
Language
OpenCV
http://opencv.org/
Provides common infrastructure
for computer vision applications
C, C++,
Python
CellProfiler
http://www.cellprofiler.org
Biologists, for quantitatively
measuring phenotypes from
thousands of images
Python
ImageJ
http://rsb.info.nih.gov/ij/
Image processing using Java
Java
FIGI (Figi Is Just
ImageJ)
http://fifi.sc
Distribution of ImageJ with
bundled plugins to assist
research in life sciences
Java
Endrov
http://www.endrov.net
Designed to address the
shortcomings of ImageJ
Java
Mango (Multiimage Analysis
GUI)
http://ric.uthscsa.edu/
mango/
Viewer for medical research
images
Java
GNU Octave
http://www.gnu.org/
software/octave/
Numerical computations
C++
GemIdent
http://www.gemident.com/
Identifies regions of interest,
specifically with few colors and
small variation
Java
3DSlicer
http://www.slicer.org/
Visualization and image analysis
C++,
Python,
Java, Qt
OsiriX
http://www.osirixviewer.com/
DICOM image processing
software
ObjectiveC
Insight
Segmentation
and Registration
Toolkit
http://www.itk.org/
Image analysis, medical
C++,
Python,
Java
Integrating
Vision Toolkit
http://ivt.sourceforge.net/
Fast and powerful C++ computer
vision library
C++
VIGRA (Vision
with Generic
Algorithms)
http://hci.iwr.uniheidelberg.de/vigra/
Customizable algorithms and
data structures
C++
6.3.2
Operating System
Due to the complexity of this function, the team decided to use an operating system to handle the
low-level system details. The Raspberry Pi website recommends the Linux based OS called
36
Raspbian, as they specifically designed it for the Raspberry Pi [61]. For the prototype, the team also
used the Windows OS for testing, as Python can run on many operating systems.
Figure 17. DAS Software Diagram
6.3.3
Initialize System
This step performs the necessary setup to read images from the camera and process them. This
includes loading the cascade files used for facial and eye detection and setting the camera capture
settings.
6.3.4
Read Image from Camera
This step is relatively simple since the team is utilizing the OpenCV library. A simple function grabs
the frame from the camera and decodes it into a usable form. It then returns an array containing the
RGB image data.
37
6.3.5
Process Faces
In order to process the faces, the program first uses a Haar cascade classifier to detect possible
faces in the frame. The team uses the Haar cascades classifier data provided with OpenCV instead
of creating a custom cascade classifier. The team decided against creating a custom cascade
classifier due to time constraints and due to the unknown improvements that the process may or
may not provide.
The program must then determine if any of the detected rectangles contain the driver’s face and not
other people in the background or a random part of the image that looks like a face. The face
classifiers are reasonably accurate, so they will generally only find the driver, though this must be
checked to ensure accuracy and reliability. To determine the correct face, the algorithm determines
if the face is within a certain distance from the previously found face. If the face is not within the
acceptable area, the distance increments for the next loop. This continues until the face is found
again and the distance is reset.
Once the correct face is determined, the program will average the face rectangle with previously
found faces to smooth the face rectangle. This prevents the face rectangle from jumping around, yet
provides enough accuracy to follow the driver as he or she moves.
6.3.6
Process Eyes
This step proved to be much more difficult than finding the face. The team originally used a similar
Haar cascade classifier for detecting the location of the eyes. However, this was very unreliable and
was very dependent on the person’s face as well as the general lighting conditions. It also often
detected multiple eyes or eyes in locations that are not eyes. Initial attempts are shown in Figure
18. Figure 19 shows the desired action, though this was sporadic.
38
Figure 18. Initial Eye Detection
Figure 19. Desired Eye Detection
After attempting to tweak the settings to obtain better recognition, the team decided to go with a
proportion based approach. After some trial and error, the team determined that the eyes are
generally between 25% and 50% of the height of the face rectangle from the top of the face and
25% to 45% of the width of the face rectangle from the sides, as shown by the orange grid lines in
Figure 20. While this approach still did not always accurately locate the eyes, it was much more
reliable than the first approach.
Figure 20. Eye Locations based on Proportion of Face
6.3.7
Determine Eye State
The team found it very difficult to determine quantitatively the state of eye, whether open or closed.
The initial thought was to determine the state by comparing the average brightness of the eye
region to the previous brightness levels. Since open eyes are generally darker than closed eyes
because the eyelid covers the iris and pupil when the eyes are closed, the average eye brightness
should increase when the eye is closed. Figure 21 shows a graph of the average brightness for each
39
eye over about 10 seconds. The background represents the average brightness as a shade of gray.
The arrows highlight small upticks that occurred from normal blinking. For this sample, the driver
was not moving and the lighting conditions were constant. However, when the driver moves or the
lighting conditions change, it is much more difficult to determine when blinks occur. Figure 22
shows an example of the variance in the brightness of the eyes with only small movements. Due to
time constraints, the team was unable to continue to improve upon this process.
Figure 21. Average Eye Brightness Showing Blinks
Figure 22. Average Eye Brightness with Movement
6.3.8
Determine If Alarm Should Sound
Due to time constraints, the team was unable to implement this step of the function. The team had
planned to connect a speaker to the Raspberry Pi. The system would emit a warning tone to notify
the driver if it determined the length of the blink was more than one second, as specified by
requirement 4.3.1.1b.
40
7
Speed Limit Indicator
7.1
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.
41
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 23 shows the breakdown of road types. Approximately 35% of roads in the
42
United 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 23. 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. To consider transparency further, we surveyed
the general population to see what ideas were the most transparent and functional. Participants
could rate each design separately on a 5 to 1 scale, from strongly like to strongly dislike.
Participants could also choose to combine multiple designs into their ideal for the final question of
the survey. The team generated five different ideas for displaying the speed limit to a standard
speedometer, which has the speeds in a circular pattern and a speed indication arrow pointing to
the specific speed. Each design is described below, and the results of the survey of 34 people is
analyzed after that.
7.1.4.1 Design 1
The first design only involves the speed indication arrow. The arrow would light green if the user
was following the speed limit and would light red if the user was exceeding the speed limit. The
speed indication arrow is always moving to some extent, so the user’s eyes would naturally be
drawn to this item on the speedometer. The primary issue with this design is that the specific speed
43
limit is not reported to the user. This design could be combined with some of the following designs,
or another way of reporting the exact speed limit could be done. The team feels that the
transparency of the design would be compromised if the user did not know the exact speed limit.
Figure 24 shows this design if the user is following the speed limit (in this case 45 miles per hour),
and Figure 25 shows this design if the user is exceeding the speed limit.
Figure 24. Design 1 with user following 45 mph speed
limit
Figure 25. Design 1 with user exceeding 45 mph speed
limit
7.1.4.2 Design 2
The second design changes the speed indicators around the speedometer as that speed is passed.
The number lights up green if the user is following the speed limit and lights up red if the user is
exceeding the speed limit. This design also does not explicitly state the speed limit, although it is
easier to determine what the speed limit is since multiple indicators are lit up at a time. The team
was hesitant to utilize this design due to the issues with transparency given in the section above.
Figure 26 shows this design if the user is following the speed limit (in this case 45 miles per hour),
and Figure 27 shows this design if the user is exceeding the speed limit.
Figure 27. Design 2 with user exceeding 45 mph speed
limit
Figure 26. Design 2 with user following 45 mph speed
limit
44
7.1.4.3 Design 3
The third design changes the speed indicator around the speedometer that corresponds to the
current speed limit. Again, the indicator lights green if the user is following the speed limit and
lights red if the user is exceeding the speed limit. In this case, an LED is used to show the speed limit
as opposed to simply backlighting the numbers. The second and third design could have been
expanded for both using an LED and backlighting the numbers. This design appears more
transparent to the team, as the explicit speed limit is displayed to the user, as well as whether or
not the user is speeding. Figure 28 shows this design if the user is following the speed limit (in this
case 45 miles per hour), and Figure 29 shows this design if the user is exceeding the speed limit.
Figure 29. Design 3 with user exceeding 45 mph speed
limit
Figure 28. Design 3 with user following 45 mph speed
limit
7.1.4.4 Design 4
The fourth design is a bar along the perimeter of the speedometer that lights up the valid speed
limits for the user. The bar is green, signifying that those speeds are allowed for use. This design
shows no red if the user exceeds the speed limit, although the speed limit is explicitly displayed to
the user. The lack of color change could be a transparency issue, as many devices use the
convention that green is good and red is bad. The colors displayed do not change as the speed
changes, and this static system may be easier to ignore for the user, nullifying the possible benefits
of this system. Figure 30 shows this design if the user is following the speed limit (in this case 45
miles per hour), and Figure 31 shows this design if the user is exceeding the speed limit.
45
Figure 30. Design 4 with user following 45 mph speed
limit
Figure 31. Design 4 with user exceeding 45 mph speed
limit
7.1.4.5 Design 5
The final design is a bar along the perimeter of the speedometer that lights up the ineligible speeds
for the user. The bar is red, signifying that those speeds are not available for user. This design only
shows red to the user, and the colors do not change as the speed changes. This design seems more
preventative in nature, as it is blocking out what is not allowed. The user will be cautious to enter
and remain in the red, and speeding should ideally be reduced. This design has similar
transparency concerns as the fourth design, as the static system may again be easier to ignore.
Figure 32 shows this design if the user is following the speed limit (in this case 45 miles per hour),
and Figure 33 shows this design if the user is exceeding the speed limit.
Figure 32. Design 5 with user following 45 mph speed
limit
Figure 33. Design 5 with user exceeding 45 mph 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, which is nearly identical to the fifth design generated by the team. A speed limit of 40 miles
per hour would show orange lights over all speeds greater than 40 miles per hour. Figure 34 and
Figure 35 show this concept. Their system would also use various visual and audio warnings as the
driver got over a certain threshold over the speed limit. For example, a beeping sound from the
46
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 34. Normal Speedometer [18]
Figure 35. Speedometer with Speed Limit of 40 Miles
Per Hour [18]
7.1.4.6 Survey Results
A survey of 34 participants showed what a group of potential users felt was the most user-friendly
and transparent. Table 11 below shows the number of participants who rated each design, with 5
being strongly like and 1 being strongly dislike. The averages are also listed on that scale. The
weighted average makes the total average equal to three, since more participants voted positively
than negatively.
47
Table 11. Survey responses for each design
Strongly
Like (5)
Like
(4)
No
Opinion
(3)
Dislike
(2)
Strongly
Dislike (1)
Average
Weighted
Average
Design 1
6
20
4
3
1
3.79
3.48
Design 2
5
8
6
15
0
3.09
2.78
Design 3
12
14
1
6
1
3.88
3.50
Design 4
7
11
6
9
1
3.41
3.07
Design 5
2
6
3
18
5
2.47
2.23
Total
32
59
20
51
8
3.33
3.00
Both designs one and three scored quite well, with design four above the total average and design
two below the total average. Interestingly, the fifth design was not well received. This design was
the subject of academic research as shown in Section 7.1.4.5. Their research indicated that their
design reduced both intentional and unintentional speeding. It is possible that the fifth design is
best suited to discourage speeding, although it is not the most user-friendly. The team decided that
transparency and caring were important factors in the decision making process, and the opinions of
these participants was weighed very heavily. The third design easily had the most strong likes,
although the number that both liked and strongly liked that design equaled the number for the first
design. In the open-ended question at the end of the survey, multiple comments suggested a
gradient of color, slowly transitioning from green to red as the user begins to speed. Other
suggestions included using a noise or flashing lights for excessive speeding. The team decided that
those suggested features would be helpful but not necessary to implement for the prototype, and
that the team would consider designing these features if time would allow.
7.1.4.7 Decision
The team selected the third design to implement for the prototype model. When choosing between
the third and the first design, the team chose the third design for its transparency, ease to
implement, and highest average score in the survey. The team could improve this design using
some of the participant suggestions such as a light gradient or noise, although that would be
considered an extra feature that is not necessary to the design of the prototype.
7.2
Hardware System Design
The hardware necessary for the SLI is as follows: a GPS, a microcontroller, memory, and the LED
output. Figure 36 shows a block diagram of the hardware components, and shows the expected
communication between those components. This section currently considers the prototype
48
components only. The team will develop criteria for the production model and include those
decisions in a future report.
Figure 36. SLI Hardware Diagram
Table 12. Signals Used In Figure 36
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
5x D OUT
Digital output going to the display, either 0V, 5V, or Hi-Z
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)
7.2.1
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.
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
49
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 13. A decision matrix is given in Table 14, with each GPS rated in each criterion on a scale
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.
50
Table 13. GPS Alternatives
Cost
# of
Channels
Cold
Start-Up
Time (s)
Voltage
(V)
Power
Use
(mW)
Accuracy
(m)
Temp
Range
(°C)
EM406A
$40
20
42
4.5–6.5
220
10
-40 to
85
Polstar
[20]
10-019
$15
12
50
3.3–5
120
5
-40 to
70
Sparkfun
[21]
Locosys20031
$60
66
35
3–4.2
135
3
-30 to
85
Parallax
[22]
PMB648
$40
20
42
3.3–5
325
5
-20 to
70
GPS
Seller
Model
Number
Futurlec
[19]
Table 14. Decision Matrix for GPS Selection
Priority
EM-406A
Polstar
10-019
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.
51
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.
Late in the design process, the team discovered that the size of the code written was too large to fit
onto the Arduino Uno selected. The team purchased an Arduino Mega, as the system designed to
that point could be easily ported to the Mega and the Mega has an order of magnitude increase in
onboard memory (256 kB vs. 32 kB). The team learned that the onboard memory criterion
considered in Section 5.2.2.1 should have been a larger weight. In that case, the Pinguino would
have been chosen over the Arduino Uno. The code written was larger than expected, as the code to
control the LED display and the SD card memory were both larger than expected.
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 REQ 4.1.1.2a.
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.
52
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.
The team chose to use a microSD card and shield for the Arduino. MicroSD cards have sufficient
capacity for our prototype implementation, as the chosen microSD card is 2 gigabytes. The 2
gigabyte microSD cards are the largest microSD cards that use the FAT16 file system, which is
recommended when using the SD library for Arduino. The explicit details for how the microSD card
was utilized for the database is given in Section 7.3.3.5.
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 or following the speed limit.. The output system must be able to display
both conditions.
In addition to the lights to indicate the speed limit, the team implemented a speedometer to
indicate the current speed of the vehicle. For the production model, this would not be necessary, as
the speedometer used in the car normally would be used. This functionality is to make the
prototype’s functionality more clear. The speed of the car would need to be output using the
conventional speed indication arrow.
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. See Section 7.1.4 for alternatives for displaying the speed limit.
To indicate the speed of the vehicle, the speed data gathered via the GPS can be used to update the
speedometer. This would make the update rate of the speedometer equal to that of the GPS, which
is one second for the GPS selected. A servo is used to control the arrow to indicate the speed. Two
choices of servos were available to the team: (1) continuous and (2) standard. Continuous servos
are controlled by moving clockwise or counterclockwise from their current position, while
standard servos are controlled by moving to a specified angle.
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. Figure 37 shows the circuit for the LED array. The LED
53
array does not need to use a demultiplexer due to the method used, called charlieplexing. This
allows each individual LED to be lit by providing 5V to one lead and ground to another while
applying the high-impedance input state to the other leads. The input state ensures that the current
flowing from that pin is near zero, so no LEDs will be lit except the one specified.
Figure 37. Charlieplexing RGB LEDs circuit
Using common cathode RGB LEDs increases the complexity of the design, as two LEDs share one
cathode pin. The schematic in Figure 37 accounts for this. Table 15 shows the LEDs and the pins to
which they are connected. Each line is connected to a pin of the microcontroller so it can be
properly controlled. The software on the microcontroller can then determine which pins are set to
5V, ground, and input to light the individual LED. The forward voltages of the green and red LEDs
are different, at 3.2V and 2.0V respectively, which means that other LEDs may light. This happens
because there are other current paths that can travel between 5V and ground that are possible if
the forward voltages are not matched. This problem was solved by adding resistors to each line,
thus decreasing the voltage drop possible in each LED. The LEDs will be slightly dimmer, but only
the LED assigned to light will light.
54
Table 15. Line Assignments for each RGB LED
Speed Limit
Red Cathode (+)
Red Anode (-)
Green Cathode (+)
Green Anode (-)
25
2
1
3
1
30
4
1
5
1
35
1
2
3
2
40
4
2
5
2
45
1
3
2
3
50
4
3
5
3
55
1
4
2
4
60
3
4
5
4
65
1
5
2
5
70
3
5
4
5
The first version of the LED display was a charlieplexed circuit using single-color component LEDs.
This was done to show the feasibility of charlieplexing as a concept. The team used a breadboard to
speed up the build of this version, as it was never designed to go on the road and be tested. Figure
38 shows the first version of the LED display.
55
Figure 38. First Implementation of the LED Display
The second version of the LED display used RGB LEDs soldered to a perforated board. This version
could be tested on the road, as it was a standalone model. This display uses the circuit shown in
Figure 37 and tests the feasibility of charlieplexing common-cathode RGB LEDs. Figure 39 shows
this integration, including the wires to connect to the microcontroller.
Figure 39. Second Implementation of the LED Display
The third and final version of the LED display was wired in the same way as the second version of
the LED display. The final version was interfaced with an actual speedometer to give an example of
how the SLI would look in an actual automobile. Diffused RGB LEDs were used for the final version
to increase the viewing angle and decrease the brightness of head-on viewing. Figure 40 shows the
final integration.
56
Figure 40. Third Implementation of the LED Display
The team selected a standard servo over a continuous servo. Standard servos will go to an exact
position, so once the speedometer arrow is calibrated, the servo will output the correct speed every
time after calibration. The servo was mounted to the speedometer for the final version of the LED
display as shown in Figure 41.
Figure 41. Final Implementation of the LED Display with Servo for Speedometer Arrow
57
7.3
Software System Design
The software running on the microcontroller will receive data from the GPS, analyze that data to
find the correct speed limit, and then output that speed limit to the outputs. Figure 42 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. The current software can be found on The Smart Dashboard’s
website: http://www.calvin.edu/academic/engineering/2012-13-team13/docs.html.
Figure 42. SLI Software Diagram
58
7.3.1
Criteria
The software needs to manage the following pieces: a database of speed limits with their GPS
coordinates, a GPS that outputs position, velocity, and direction, and an output that consists of an
LED display. 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
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 array down into its various components. There is one major tradeoff to consider
for finding the speed limit: the size of the area to look in and the robustness of the code to analyze
within that area. The software will need to look in an area around the current location, as GPS data
is never exact. As the size of the area increases, it is more likely that other roads will be found and it
will be more difficult to determine what the speed limit is. With a small area, the code does not need
to be as robust, but more data will need to be taken in the database in order to support a small area.
With a larger area, the database can be smaller, although the code to analyze the area will need to
be more complex. This is a tradeoff the team considered when designing the algorithms described
in the following section.
7.3.3
Decisions
For the prototype, the selected Arduino microcontroller supports code in C or C++. The team has
experience with these programming languages, which makes them ideally suited for the prototype.
The team chose to use C++ as the team does have more experience with C++ over C. Arduino has its
own IDE, which takes care of the compiling and loading necessary for the prototype. The database
will be stored on the microSD card in small blocks. Figure 43 shows a sample block in the area
around Calvin College. This allows the data for the block the vehicle is currently in to be stored on
the Arduino itself. This will reduce the amount of memory accesses for the microSD card, which
should improve performance. Testing of this performance is given in Section 8.3.2.3.3. Section
7.3.3.5 offers a detailed explanation of the database interface on the microSD card.
59
Figure 43. Boxes showing the size of a single part of the database
The team has developed algorithms for each block from Figure 42, and the following sections offer
explanations of all the blocks.
7.3.3.1 Initialize Controller/Initialize GPS
These two blocks include all the necessary libraries as well as initialize all the variables necessary
for the code to run. The GPS communicates via TTL serial communication, and is controlled via the
Software Serial library. Global variables are used for the current latitude, longitude, course made
good, and speed. These variables are updated in the extract data block and are used when searching
for location and determining if data needs to be read from the microSD card.
7.3.3.2 Read Data From GPS
The GPS follows standards set by the National Marine Electronics Association (NMEA), specifically
the 0183 protocol. This protocol states that data strings coming in must be comma delimited, and
all strings are made up of ASCII characters [49]. The Parallax GPS selected transmits four of those
GPS strings: (1) GPS fix data ($GPGGA), (2) GPS satellites in view ($GPGSV), (3) GPS dilution of
precision and active satellites ($GPGSA), and (4) recommended minimum specific GPS data
($GPRMC). The string that contains the information relevant to this system is the $GPRMC string. It
contains latitude, longitude, course made good, and speed over ground. This string is the only one
that will be stored by the Arduino, as the string also contains a byte that tells if the string has valid
data or an error has occurred (such as no satellites in range).
60
7.3.3.3 Extract Latitude, Longitude, Direction, Speed Data
Since the GPS strings follow the NMEA 0183 protocol, the data is comma delimited. This allows the
team to extract the relevant information from the string using software. Only the latitude, longitude,
course made good, and speed data are extracted, while the other information within the string is
ignored. The function that extracts the data returns 1 if the function completed properly and the
relevant data was updated, returns 0 if the GPS string found was not the $GPRMC string, and
returns -1 if an error occurred. An error can occur if the GPS does not have the proper satellites in
view, or if the code itself encountered an error extracting the data. These errors are used for the
error-checking block in Section 7.3.3.4.
7.3.3.4 Error-Checking
In this system, the error-checking block is very simple. If the GPS extraction block returns -1, an
error has occurred and the error counter is incremented. Every time the GPS extraction block
returns 1, valid data has been found and the error counter is reset. The error counter is not reset if
the GPS extraction block returns 0, since errors in the relevant $GPRMC string could exist even
though the GPS extraction block found no specific errors and returned 0.
7.3.3.5 Reading from the SD Card
In order to use the database stored on the microSD card, certain conventions were created to allow
data to be collected and used easily. Descriptions of three major factors going into the creation of
the database are given below.
7.3.3.5.1
Naming Conventions
The database on the microSD card is stored in small enough pieces that one piece of the database
could be stored on the Arduino at all times. The FAT16 file system uses a short filename (or 8.3
filename) that limits the size of the name of the file. The file can be named using eight characters,
which can be followed by a period and up to three letters of file extension. In order to minimize the
amount of data points in each file, a naming system needed to be created that allowed minimal area
and distinct file names. To name files, four digits from latitude and longitude are combined to create
the eight character filename. Since latitude ranges from 90 degrees to -90 degrees, the first four
digits can be taken. This yields precision to a hundredth of a degree latitude. However, longitude
ranges from 180 degrees to -180 degrees. Decimal precision to a hundredth of a degree is still
possible, if the values above 100 and below -100 are accounted for in the file extension.
The file extension makes up three letters, and each character helps identify what data is contained
and what location it corresponds to. The first letter corresponds to the latitude. If the latitude is
positive, the first letter of the file extension will be a ‘P’ (for ‘positive’). If the latitude is negative,
then the first letter of the file extension will be an ‘N’ (for ‘negative’). The second letter corresponds
to the longitude. If the longitude is positive and greater than or equal to 100 degrees, the second
letter of the file extension will be a ‘B’ (for ‘big’). If the longitude is positive but less than 100
degrees, the second letter of the file extension will be a ‘P’ (for ‘positive’). If the longitude is
negative and less than or equal to -100 degrees, the second letter of the file extension will be an ‘S’
(for ‘small’). Finally, if the longitude is negative but greater than -100 degrees, the second letter of
61
the file extension will be an ‘N’ (for ‘negative’). The last letter of the file extension corresponds to
the type of data stored in that particular file. Four different files are created at each location. First,
the latitude and longitude are stored together, and the last letter of that file extension will be a ‘G’
(for ‘GPS coordinates’). Second, the course made good data is stored in files where the last letter of
the file extension is a ‘C’ (for ‘course made good’). Third, the speed limits are stored in files where
the last letter of the file extension is an ‘S’ (for ‘speed limit’). Finally, the number of data points
stored for that particular location is stored in files where the last letter of the file extension is a ‘N’
(for ‘number of points’).
For example, at a location with latitude -32.8631234 degrees and longitude 124.8846482 degrees,
the speed limit data would be stored in the file 32862488.NBS. The file extensions are crucial, as the
speed limit data in the file 32862488.PNS would be for the location with latitude 32.86 degrees and
longitude -24.88 degrees. The first location is in western Australia, while the second location is in
the middle of the ocean west of Morocco. The file names are the same, but the file extensions hold
crucial information necessary to being in the right location.
7.3.3.5.2
Box Size
The two boxes shown in Figure 43 correspond to the actual data stored in the bigger box and the
area covered where the GPS will use that particular file. The smaller box corresponds to one
hundredth of a degree in both latitude and longitude. In that particular location, the box is 0.69
miles tall and 0.51 miles wide, yielding a total area of 0.35 square miles. The actual data stored in a
file covers a larger area than the file itself. Due to the method of triangulation for determining
location (see Section 7.3.3.7), a thousandth of a degree buffer surrounds the entire box that the file
covers. In this way, the data points ahead of the driver will still be found even if the vehicle is near a
file boundary and has not changed files yet. In the location used in Figure 43, the larger box is 0.83
miles tall and 0.61 miles wide, yielding a total area of 0.51 miles.
7.3.3.5.3
GPS Data Logging
In order to create the database, a GPS data logging program was written to automatically place the
data into the correct files. This required driving around all of the streets within the database, but
the data collected would not need to be edited in order to be used in the database. Using the Ardino
serial window, the user would enter the speed limit manually as the vehicle went along, but the
course made good, latitude, and longitude data would be automatically stored at a certain interval
(3 seconds). Since manual operation was necessary, the driver of the vehicle did not interact with
the system, and a passenger would operate the data logging code. The code would handle the buffer
zone issues discussed in Section 7.3.3.5.2, so the data would need to be written to a maximum of
four files and a minimum of one file.
7.3.3.6 Overwrite Arduino data with SD data
In order to search for the speed limits in the area, the correct data must be on the Arduino to
decrease latency due to memory reading and writing from the microSD card. Once the position has
been updated via the GPS device, the software checks to see if the files currently loaded on the
Arduino are correct for the current location. If they are not, the Arduino overwrites the current data
62
on the Arduino with the new files from the microSD card. There is a threshold for the largest a file
can be while also being stored on the Arduino. At this point, no files are larger than this threshold,
but further data could push this above the threshold. The largest current file holds 78 speed limits,
while that maximum threshold is set at 500 speed limits. If size of the file on the microSD card is too
large, the data will not copy and an error will occur until the vehicle enters a new area with a file
smaller than the threshold.
7.3.3.7 Search for location
To find the speed limit, the software searches the area around the vehicle’s current location and
decides which of the points in the database best describe the vehicle’s current location. This is done
because GPS coordinates are never exact, especially at the precision to which they are being stored.
The team decided to use a triangle around the vehicle’s current position, shown in Figure 44. The
points within a triangle can be calculated easily using simple algebra, which made it an ideal choice
for the shape to surround the point. The triangle points in the direction that the vehicle is currently
travelling, so the example in Figure 44 shows the vehicle travelling west.
Figure 44. Current vehicle location with the bounding triangle
The code then determines which points in the database are contained within that triangle. In Figure
45, the small circles represent data points stored in the database. The software determines that
63
three of the database points are within the triangle, and performs operations to determine which of
the points are valid for the road the vehicle is currently on.
Figure 45. Bounding triangle with all database points in the area
Figure 46 shows that one of the points is not correct, at 25 miles per hour. The software would first
check if there are any points within the triangle or not. If no points were found within the triangle,
the unknown road counter would be incremented. If any number of points were found within the
triangle, the software would determine if the speed limits all match. If all the speed limits found are
equal, that is determined to be the new speed limit. If differences in speed limit are found, the
software uses the course made good data to determine which points are valid. If the course made
good data from the database is within thirty degrees of the current course made good of the vehicle,
that point is determined to be valid. The value of thirty degrees safeguards against slight errors in
the sensors as well as curvature in the road. If the points within thirty degrees still have different
speed limits, the software decides to set the speed limit as the previous speed limit determined.
This means that merging could result in the previous speed limit being used until the vehicle is
sufficiently far away from the road they merged from, but this situation is more rare than staying on
the same road and another road running parallel to it nearby. In the example given in Figure 46, the
25 miles per hour point is ruled out as it is facing north (or south), while the 30 miles per hour
points are facing east (or west). The speed limit in that situation is determined to be 30 miles per
hour.
64
Figure 46. Speed limit data shown for points within the bounding triangle
7.3.3.8 Error/Unknown Road Counter
The error counter is only incremented if an error occurs with the GPS device, the GPS data
extraction code, or the microSD card code. Each time the code successfully determines the speed
limit, the error counter is set to zero. If the error counter is greater than three, a sufficient number
of errors has occurred and the speed limit that is currently output is incorrect. In this case, the LED
display outputs nothing. A non-zero error counter that is less than or equal to three will not change
what is driven to the LEDs.
The software manages the unknown road counter separately from the error counter. The unknown
road counter is incremented only when the number of points in the database found in the bounding
triangle is equal to zero. If the bounding triangle contains points from the database, the unknown
road counter is set to zero. When the unknown road counter is greater than three, too much time
has passed since finding points in the database, so the vehicle must be outside the range of the
database. In this case, the LED display outputs nothing. A non-zero unknown road counter that is
less than or equal to three will not change what is driven to the LEDs.
7.3.3.9 Output Speed Limit
The LED array is a charlieplexed set of RGB LEDs as described in Section 7.2.4. To light a single LED,
three of the pins are set to be high impedance inputs, while the other two pins are set to 5 volts
65
(high) and ground (low). The pin assignments for the LEDs is given in Section 7.2.4.3 in Table 15.
The software first sets all of the pins to input state to ensure no other LEDs temporarily light while
the switch is being made. A large case statement with all of the pin assignments will set one pin to
output high and one pin to output low based on the pin assignment. Functions exist for specialized
outputs, which consist of outputting error messages and outputting the fact that the GPS has
connected properly. Specialized error messages can be output to the LED array to help debug
specific portions of the code during final testing. Any errors can be quickly identified using this
method.
66
7.4
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 47 shows the initial printed circuit board (PCB) layout, using the components and
dimensions listed in Table 16. 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 47. Initial PCB Layout. Parts listed in Table 16
Table 16. Table of Components for Figure 47
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
The team did not place a high priority on producing a PCB for this project. The team would have
liked to produce a PCB, but the team was occupied with finishing the prototypes completely as they
are described, and no time remained to design and produce an actual PCB. The design of a PCB is
considered in the productions model financials, given in Section 9.3.2.
67
8
Integration and Testing
8.1
Rapid Deceleration Warning
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 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.1.1.1 Latency Test
This test considers the overall speed of the system. Requirement 4.4.1.3b states that the time
between reading in a deceleration value above the threshold and detecting and outputting the
pulsed signal should be less than 50ms. The time elapsed is measured by taking the time before
and after this section of code. The time elapsed is stored for twenty different runs through the
code.
8.1.1.2 Scale Model Test
This test is qualitative in nature and it considers the operation of the system on a smaller scale. The
team mounted the components of the system (microcontroller, accelerometer) to an RC car, using
component LEDs as miniature brake lights. Figure 48 and Figure 49 show the interior and exterior
of the scale model. The team mounted a small breadboard to the back of the RC car to connect the
microcontroller, accelerometer, and the component LEDs. A 9V battery mounted to the side of the
RC car provided the necessary power. The team also used this model to provide a proof of concept
and support the feasibility of the system.
Figure 48. RDW Scale Model Interior
Figure 49. RDW Scale Model Exterior
68
8.1.1.3 Prototype Test
This test is also mostly qualitative and it considers the operation of the system under real-life
conditions. The team assembled a prototype of the system with an isolated center high mounted
brake light and 9-volt power supply as shown in Figure 50. The team placed the system within an
actual vehicle and examined the response of the brake lights to various acceleration conditions.
Figure 50. Prototype Model
8.1.2
Test Results
8.1.2.1 Latency Test
Time to Detect Rapid
Deceleration (ms)
An important requirement of the system is that it detects a rapid deceleration quickly. Figure 51
shows the data that the team obtained for this test. The time between the start of the main loop and
detecting a rapid deceleration fluctuated between 16 and 20ms over twenty runs. Therefore, the
team can conclude with a reasonable amount of confidence that the system meets Requirement
4.4.1.1b.
RDW Latency Test
25
20
15
10
5
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Run #
Figure 51. RDW Latency Test
69
8.1.2.2 Scale Model Test
The team’s initial design of the system flashed the brake lights of the vehicle only when its
deceleration is above the specified threshold. After examining the operation of the scale model, the
team realized that, since the deceleration is often only above the threshold for a moment, the brake
lights do not flash long enough to be noticeable. Given the project’s design norm of transparency
and objective 4.4.2.1a, the team changed the system to allow the brake lights to flash for a specified
amount of time after the system detects a rapid deceleration (see Section 5.4.3). This gives the
following driver a chance to realize what is happening.
8.1.2.3 Prototype Test
Video of the working prototype is available on the homepage of The Smart Dashboard’s website:
http://www.calvin.edu/academic/engineering/2012-13-team13/. The team realized that they
needed to decrease the deceleration threshold for testing because the required threshold of 6 m/s2
truly only attained in an emergency braking scenario. Therefore, the testing threshold was set to
2.5 m/s2 and the team started testing by braking the car softly, which demonstrated that at a low
deceleration the brake light did not flash. The team then applied the brakes hard and observed that
the time that the light flashed coincided with the time limit specified in software. Finally, the team
applied the brakes hard for a longer period and observed that the light flashed until the
deceleration had dropped below the threshold. This was a successful test in simply demonstrating
the functionality of the system.
8.2
Driver Awareness Sensor
8.2.1
Testing Method
This section details the set of tests that the team wanted to run on the prototype to prove the
performance of the system as described in the Objectives and Requirements (Chapter 4) and the
specific system architecture (Chapter 6). The tests are described in detail below. This list is not
inclusive, as the team continues to iterate through different tests. The team performed most of the
testing during the writing of the software as functionality was added. For example, the team tested
to make sure the system could capture video and process the images from the camera as the team
wrote the code. This process was generally a test to see if it worked or not. If it failed, the team
rewrote the code and iteratively tested until the code performed as desired.
8.2.1.1 Frame Rate Test
This test will determine if the microcontroller can process the frames from the camera at an
acceptable rate. The average blink rate is between 100-400ms [53]. In order to capture a blink in
four frames, the frame rate should be between 10-40 fps. The frame rate can tend towards the
lower frame rates because the blink duration increases as the level of drowsiness increases. The
team will run initial tests to determine how fast the system can grab frames from the camera and
process them into a usable state. The grab() function grabs a raw image from the camera. The
read() function performs the grab() function as well as decodes it to make it usable. These functions
will be run 1000 times and the times averaged to get the results.
70
8.2.1.2 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
than a standard blink. The team will perform this test on multiple people and the team will analyze
how many blinks were recorded accurately.
8.2.1.3 Lighting Test
This test will analyze face and eye tracking in different lighting conditions. This function must work
in nighttime as well as daytime, so a lighting test is necessary to ensure proper operation. The team
will perform this test with different lighting conditions and record the total time the system
correctly identified the face and eyes.
8.2.2
Test Results
8.2.2.1 Frame Rate Test
This test was run multiple times using different settings on the Raspberry Pi. Initial results were
showing frame rates around 2-3 fps, which is significantly below the acceptable level. After some
research, the team found a kernel update [54] for the Raspberry Pi, which significantly increased
the frame rate. Before the update, the function time was very inconsistent, as well as being slower
than expected. After the update, the function time was much more consistent and significantly
faster.
The team also experimented with overclocking the system and changing the amount of memory
allocated to the GPU. The overclocking made a significant difference while changing the memory
allocation did not make a noticeable difference.
71
Table 17. Frame Rate Test Results from Kernel Update
Scenario
Grab() (ms) Read() (ms)
Initial
369
386
After kernel update
74
90
Removed 20ms wait in code, which was necessary before update
57
73
Table 18. Frame Rate Test Results for Overclocking
Overclock Setting Grab() (ms) Read() (ms)
None – 700MHz
57
73
Modest – 800MHz
53
68
Medium – 900MHz
49
63
High – 950MHz
48
61
Turbo – 1000MHz
34
44
Table 19. Frame Rate Test Results from GPU Memory Allocation
GPU / CPU Memory Split (MB) Grab() (ms) Read() (ms)
16/492
57
72
64/448
57
72
128/384
57
72
256/256
57
72
8.2.2.2 Blink Accuracy Test
The final prototype is unable to detect blinks on its own. Therefore, the team could not perform this
test as desired. However, the graph of the average eye brightness, discussed in section 6.3.7, does
show indication of blinks that can be visually determined by an observer.
8.2.2.3 Lighting Test
Due to time constraints, the team was unable to perform quantitative lighting tests. However, by
observing the variation of caused by differing lighting conditions, the team was able to note that
proper lighting is important for accurately locating the face. Additionally, the average eye
brightness is very dependent on the lighting. When the lighting on the face fluctuates, the graph is
very inconsistent and it is difficult to detect blinks.
8.2.3
Current Integration
The team was able to connect the camera to the RaspberryPi and perform initial testing. The team
configured the final prototype to run from a desktop computer, due to limitations with the
72
RaspberryPi. Figure ### shows display of the final prototype. This display shows the various steps
the team used to determine the blinks of the driver. The team implemented the facial illuminator on
a breadboard and directed the light towards the driver.
Figure 52. Display from Final Prototype
8.3
Speed Limit Indicator
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 (Chapter 7). 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 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
73
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
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.3.1.2 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.3.1.3 Latency Test
For the SLI function, multiple blocks of software can be tested for their performance. The GPS
device updates every second, so in a worst-case scenario all possible computations necessary
should be completed in less than one second. To time each section of code, the time is taken before
and after the block of code is executed. The time elapsed is stored for fifty different runs through
the code. Fifty was used as an arbitrary first number, and may be altered if the results seem to be
affected by this value. All of the times will be output as well as the average so that the data can be
74
analyzed. The blocks of software that are considered large enough to be a major burden on
compute time are described below.
8.3.1.3.1
Extracting values from GPS string
This block of code is run immediately after each GPS string received is deemed valid. This code is
run every time the GPS is updated, so this code runs every second. The time for this block of code is
useful to know as it is a guaranteed loss for each run. Subtracting this time from one second would
give the total time allowed by the other sections.
8.3.1.3.2
Triangulation and speed limit identification
The block of code for triangulation and speed limit identification, like the code described in Section
8.3.1.3.1, is run every time the GPS updates the values. However, this code can have widely varying
runtimes, which depend on the number of database points found in the bounding triangle. If there
are many points within the triangle which are different speed limits, the code must go through a
more complex set of commands to find the proper speed limit. Finding the average runtime and the
maximum/minimum runtimes will be helpful for understanding how the code functions.
8.3.1.3.3
MicroSD card
The code necessary to access the microSD card runs only when the vehicle enters a new area that is
described by another file than the one currently stored on the Arduino. In that case, the new files
from the microSD card replace those on the Arduino. The runtime for this code depends on the size
of the file. The team tested the runtime of the code contained within the final prototype design. This
code reads different types (long, int) as well as clearing the old data, so the runtime is more variable
than the other latency testing done on the prototype.
8.3.1.3.4
Servo Updates
As a late addition to the design, a servo was added to display the current speed of the car for the
prototype speedometer. This code has few lines of code to time, as the servo receives a pulse output
from the microcontroller that controls its movement. The bulk of this section is a delay function
that is used to allow the servo to physically move before other items in the code can run. This
makes sure the servo can behave properly and other commands are not written to the servo before
it finishes its first command.
8.3.2
Test Results
8.3.2.1 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 53 for all the data taken for this test. Each test has
similar average error, so the GPS does not become more accurate over time.
75
Figure 53. 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 54 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, 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.
76
Figure 54. Second GPS Test, Mapped to Google Maps
A third qualitative test was done in Ann Arbor, Michigan. This test occurred on city streets and
country roads, to provide a wide array of data. Figure 55 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 56
shows a portion of downtown Ann Arbor. An irregularity in the data is clear. The high buildings in
downtown Ann Arbor obstructed the GPS at times. Trees have not had an effect on performance as
far as we can tell, but buildings have a tangible effect.
Figure 56. Third GPS Accuracy Test, Close-Up On Downtown
Ann Arbor
Figure 55. Third GPS Accuracy Test, Mapped to
Google Maps
77
The team determined that the accuracy shown in the above tests is sufficient for the prototype of
the SLI. The software has safeguards to handle bad inputs from the GPS device, such as that shown
in Figure 56. The triangulation method and counters for unknown roads and errors would make the
issues above irrelevant.
8.3.2.2 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. This is sufficient for the prototype of the SLI. The course made good
data is used for general direction within thirty degrees, so minor perturbations in data should be
inconsequential. The speed data is only used to determine if the RGB LED lights green or red, and
slight errors would not have a large impact, as there is error in the built-in speedometer as well.
8.3.2.3 Latency Test
8.3.2.3.1
Extracting values from GPS string
The team took timing data as the system was operating normally. The time to run through the GPS
extraction function in milliseconds was taken each time it was called up to 50 times. The histogram
of the timing data is given in Figure 57.
25
Frequency
20
15
10
5
0
92
93
94
95
96
97
98
99
Time (ms)
Figure 57. Histogram of Timing Data for GPS Extraction
The time to take in and extract the GPS values took a consistent amount of time, approximately 96
milliseconds. This is valuable information when considering the latency of the entire system, as one
loop of the code can take at most one second to complete to ensure the update rate of 1 Hz for the
78
GPS is possible to have the greatest data resolution. Taking the values necessary from the GPS take
about one tenth of the available time, and it stays consistently in a range from 93 to 98 milliseconds.
8.3.2.3.2
Triangulation and speed limit identification
The triangulation code looks at all the points contained in a triangle around the vehicle and
determines which of those points has the correct speed limit. Timing was done while the system
was operating normally. The timing was taken each time the triangulation code was called, and 50
pieces of timing data were taken. The time is in milliseconds. Figure 58 shows the histogram of the
timing data for triangulation.
35
30
Frequency
25
20
15
10
5
0
0
1
2
Time (ms)
3
4
5
Figure 58. Histogram of Timing Data for Triangulation
The time to run the triangulation code is very small. At most, the triangulation code took 4
milliseconds to run. This block of code is a major concern for fitting a single iteration of the code
under 1 second, as it is quite fast now and could not be updated to be much faster. Both the GPS
extraction code and the triangulation code take about a tenth of a second combined.
8.3.2.3.3
MicroSD card
The microSD card code involves reading the database values from the microSD card to the Arduino
microcontroller. Timing was done while the system was operating normally. Timing data was taken
each time data needed to be copied from the microSD card, which happens much more infrequently
than the GPS extraction code and the triangulation code. The team took 25 data points for the
microSD card timing, and Figure 59 shows a histogram of that data.
79
Frequency
20
18
16
14
12
10
8
6
4
2
0
100 - 200
200 - 300
300 - 400
400 - 500
Time (ms)
500 - 600
600 - 700
700 - 800
Figure 59. Histogram of Timing Data for microSD Card Read
The time to read data from the SD card varied more wildly than the GPS extraction and
triangulation code, although this was expected. The number of data points within each file has an
impact on how long it takes to read that to the Arduino. Fortunately, the highest data points were
still less than 800 milliseconds, which allows the entire software loop to remain under 1 second.
The majority of the time the data took under 400 milliseconds to complete.
The team decided to test the microSD card timing code further. The code to read in the values was
separated from the system and tested over all the files currently in the database. Figure 60 shows
the file size and the time it took to read the data as the location on the microSD card increases. The
overall trend for reading values is increasing even as the file sizes stay nearly constant.
Number of Points or Time (ms)
400
350
300
250
Points
in File
200
150
100
Time to
Read
50
0
1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52 55 58 61 64 67
File Number
Figure 60. MicroSD Card Read for all files within the database based on order the files are stored
80
This shows that the time to read values from the microSD card depends on more than just the
number of entries in each file. The team decided to test the location on the microSD card itself. A file
with 20 entries was copied into 100 different files. The team ran the microSD card timing code
using those identical files. Figure 61 shows the results.
180
160
140
Times (ms)
120
100
80
60
40
20
0
1
5
9 13 17 21 25 29 33 37 41 45 49 53 57 61 65 69 73 77 81 85 89 93 97
File Number
Figure 61. Time to read from the microSD card based on location of file
This shows that the time to read values from the microSD card also depends on the location where
the file is stored. It appears that every 16 files, the time to read jumps to another plateau, with an
approximate 10 millisecond jump between plateaus. For the prototype of the SLI, this does not have
a large impact on functionality, although this would impact the design of the database for a
production model with many more points in the database.
8.3.2.3.4
Servo Updates
This timing data was not tested, as the approximate time to run this block of code is known. A delay
function is issued for 200 milliseconds, which accounts for the majority of the time required to fully
update the servo. Since this could mean that one loop of code would exceed one second if all four
major parts were run in one loop, the code to update the servo only runs if no read was made from
the microSD card. This means that the maximum timing for a loop that includes servo updates is
approximately 300 milliseconds, still well under the one second that is required for this system.
8.3.3
Current Integration
The team has the SLI prototype running. The microSD card has a simplified database that is
sufficient for testing in the correct format. The microSD card can be accessed via software as
described in Section 7.3.3.6. The software takes in GPS values once per second and checks the
database on the Arduino to see if any points in the database are within a bounding triangle drawn
around the current point. If so, an algorithm is run that determines which database point is correct
81
and outputs that speed limit to an LED display. A servo controls the pointer of the speedometer to
output the current speed of the vehicle. If sufficient errors are detected, no speed limit will be
output to the LEDs. Figure 62 shows the final integration of the SLI. From left to right, the items
are: (1) GPS module, (2) Arduino Mega with microSD card shield, (3) batteries, (4) prototype
speedometer with LED display.
Figure 62. Final implementation of the SLI
82
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 as a Tier 1 auto supplier.
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. Therefore,
our business is viable in the long term, as each model of car that The Smart Dashboard markets to
will require specific redesigning for that particular model.
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
83
too much to ask for a built-in speed limit indicator? Wouldn't such an option make the roads safer,
in addition to cutting down on driver anxiety?” [26]. Garmin may be trying to satisfy that demand,
as the GPS supplier is looking to become a Tier 1 car supplier. Although initially Garmin would plan
on installing car radios with GPS navigation options, it is possible that Garmin would use these
resources to try to offer a speed limit indicator. A Garmin spokesperson stated that, “We …. are well
positioned to become a tier-one supplier to the automotive industry…We already provide
integrated cockpits for pilots to the aviation industry, and we are dedicated to bringing a similar
level of technology, integration, safety, reliability, and efficiency to the automotive market as a tier
one supplier” [60]. Although Garmin would not be direct competition immediately, they seem to
have the most resources to design a speed limit indicator and be The Smart Dashboard’s main
competitors in the future.
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 20 gives
our initial budget estimates for the project. Our team has requested $602 in funds for the entirety of
the project. The components where the actual price is listed as $0 were borrowed from the Calvin
College Engineering Department for the duration of the project.
84
Table 20. Prototype Budget
SLI
RDW
DAS
Item
Est.
Cost
Act.
Cost
Item
Est.
Cost
Act.
Cost
Item
Est.
Cost
Act.
Cost
GPS
$43
$42.58
Accelerometer
$23
$22.95
Raspberry
Pi
$35
$0
Arduino
$50
$58.95
Prototype
Brake Lights
$75
$36.95
Power
Supply
$5
$0
RGB LEDs
$22
$21.12
Arduino Uno
$30
$0
4 GB SD
Card
$10
$0
SD Card
Adapter
$15
$16.45
Shipping
$10
Webcam
$100
$20
SD Card
$5
$3.98
2.1mm to 9V
Connector
$5.25
Outputs
$40
Perf Board
$9
$8
4x 9V Batteries
$10.59
LEDs
$10
$12.99
Small
Breadboard
$6.99
Shipping
$20
Function Total
$82.73
Function
Total
$220
Servo
Function
Total
$144
$164.07
Misc
Replacements
$100
$21.12
Team Total
$602
$297.87
9.3.2
$138
Remaining Budget
$7.95
$27.95
$304.13
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.
9.3.2.1 Variable Costs
Table 21 shows an estimate of the variable costs for the prototype. The expected cost is
approximately $56 per unit. The team selected an ARM processor for the production model. This
processor operates at 800 MHz, which is above the frequency of the processor on the Raspberry Pi.
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.
85
Table 21. Expected Variable Costs for the Production Model
Item
Model
Unit
Price
Quantity
Total Cost
Accelerometer
LIS331DLTR
$0.6504
25,000
$16,260
GPS
MAX2741ETI+
$5.77576
25,000
$144,394
GPS Antenna
W3011
$0.702
25,000
$17,550
LEDs
LTST-C19FD1WT
$0.12
250,000
$30,000
Memory
MT29F2G08ABAEAH4:E TR
$3.26808
25,000
$81,702
Microprocessor
AM3703CBP
$16.50
25,000
$412,500
Camera
OVM7690-R20A
$3.614
25,000
$90,350
Resistors
RK73H2BTTDD1001F
$0.003
500,000
$1500
Connector
4-794628-0
$1.71
25,000
$42,750
$20
25,000
$500,000
5% of variable costs
$2.6725
25,000
$66,850.30
Variable Cost Per Unit
$56.15
Total Var.
Cost
$1,403,856.30
PCB / Packaging
Replacements
9.3.2.2 Fixed Costs
Table 22 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 22. Expected One-Time Fixed Costs for the Production Model
Item
Cost
Notes
Design
$1,000,000
10000 hours, $100 per hour design time
Capital Investment
$150,000
Software Suites
Table 23. Amortized One-Time Costs
One-Time Costs at Year 1
$1,150,000
Year 1
Year 2
Year 3
$164,335
$281,635
$201,135
Table 23 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 24 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
86
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 24. Fixed Annual Costs
9.4
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
$30,000
10+% of Gross Margin
Estimated Profits
Table 25 shows a profit estimate for years one through three. As a unique product, the team feels
that selling the product for $105 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 $105 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.
87
Table 25. Estimated Profits for the Production Model
Year 1
Year 2
Year 3
Total Variable Cost
$1,403,856.30
$1,544,241.93
$1,684,627.56
Total Fixed Cost
$1,122,935
$1,240,235
$1,159,735
Total Costs
$2,526,791.30
$2,784,476.93
$2,844,362.56
Selling Quantity
25,000
27,500
30,000
Selling Price
$105
$105
$105
Revenue
$2,625,000
$2,887,500
$3,150,000
Gross Margin
$98,208.70
$103,023.07
$305,637.44
Taxes
$34,373.05
$36,058.07
$106,973.10
Profit
$63,835.66
$66,965.00
$198,664.34
Profit Margin
2.53%
2.40%
6.98%
Our break-even chart for year 1 is given in Figure 63. After the first year, depending on the success
of our product, it should be viable to lower the cost of The Smart Dashboard to market it to other car
manufacturers. Lowering our costs would make it easier to get new contracts across multiple
manufacturers and models, allowing our volume to increase significantly. The extra profits allowed
by selling at a high volume would allow the company to invest in surface mount technology so that
board manufacturing and population could be done in-house. These profits would also allow the
research and development budget to increase, which is necessary to stay current and ahead of our
competitors.
350,000
Units Sold Per Year
300,000
250,000
200,000
150,000
100,000
50,000
0
60
65
70
75
80
85
90
95 100 105 110 115 120 125 130 135 140 145 150
Selling Price ($/unit)
Figure 63. Break-Even Analysis for Year 1 of The Smart Dashboard
88
The financials presented in Table 25 can be considered as a best-case scenario. In that case, all of
the products that the company produces would be sold in that given year. Costs would increase if
the volume is lower than expected, as some parts have volume discounts that would no longer
apply below 25,000 units. A worst-case scenario could be the cause of any number of items. If the
company’s fixed costs are greater than expected (such as office, utilities, unexpected workforce
payments, or greater number of design hours necessary), the break-even chart would be shifted so
that more units would need to be sold to break even at a certain price. If the price to manufacture
one product increases, this would also have an impact on the financial well-being of the company.
These issues could include higher PCB manufacturing and population costs, a higher volume of
replacements, or parts going out of stock that need to be replaced by costlier parts. The company
could survive slight variations in cost estimates early on, although major issues may cause the
company to not be feasible under those specific conditions.
89
10
Conclusions
10.1 Accomplishments
The team produced three car safety features. The Rapid Deceleration Warning was demonstrated in
a scale model and in an actual car under real-life conditions. The Driver Awareness Sensor was able
to find the face and eyes and use the facial illuminator to improve lighting conditions. The Speed
Limit Indicator was able to determine the correct speed limit and display corresponding
information on the speedometer using a GPS, Arduino microcontroller, microSD card, and LED
display. The team generated software that could create and add to a database of speed limits that
works all over the world. The team also implemented the concept using a mockup speedometer.
10.2 Missed Goals
The team was unable to integrate the features into a vehicle, but instead was able to show demos of
how they would work within the vehicle. The team did not design or produce a printed circuit
board that would integrate all three functions on one board. The team never integrated all three
functions into one system, and the software is stand-alone for all three functions. While the team
stayed under budget as a whole, the SLI was over its allotted budget.
10.3 Lessons Learned
The team learned many lessons throughout the year. This section includes some of the major
setbacks.
One of the major setbacks was the increasing complexity of the projects as the year progressed. At
the beginning of the year, it seemed simple to create multiple car safety features. However, as the
year progressed, the amount of work required was greater than expected. Additionally, with each
team member working on a separate function, there was little room for overlap and each member
was increasingly on his own to complete his project. Dividing work across functions was very
difficult, if it ever worked at all.
The team regrets that they did not operate under a stricter schedule. The team should have
updated the initial schedule with new tasks as they became known and estimated their completion
times more precisely. This would have caused less headaches at the end of the year wondering how
much time should be devoted to each task.
Another setback was the realization that the Raspberry Pi might not be powerful enough to process
the imagery. This caused a delay in the formation of the Driver Awareness Sensor software.
Additionally, had the team known that code written and run on a desktop computer could be easily
converted to run on the microcontroller, the team would have started writing the code sooner on a
desktop computer.
For the Speed Limit Indicator, the team initially chose the Arduino Uno. As more complexity was
added to the system, the team realized that the Uno did not have the memory required to hold all of
the code necessary to prototype the function. The team had to purchase an Arduino Mega, as the
90
team was too far along to switch development boards. The team would have considered other
microcontrollers if it was known what the approximate size of the program would be.
10.4 Future Developments
The team considered many options that would be useful additions to this project, but were not
within the scope of what the team could accomplish. The team would have liked to design and build
a printed circuit board. This would be the first step in integrating all three functions into one
design. The software would need to be restructured to run cohesively on one processor, as per
Requirement 4.1.1.5a. For the Speed Limit Indicator, a gradient of changing light could be added to
make the transition from not speeding to speeding less sudden. The team also could add audio
feedback and flashing lights in the case of extreme speeding.
91
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 Bob DeKraker for his help when ordering parts necessary to the
project.
The team would like to thank Phil Jasperse for his help and suggestions when using the metal shop
and its equipment.
The team would like to thank all of the people who have supported the project through social media
sites like Facebook, Twitter, and YouTube.
92
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/
93
[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
94
[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
[49] http://www.marimsys.com/pages/nmea_codes.htm
[50] http://elinux.org/RPi_VerifiedPeripherals#USB_Webcams
[51] http://www.free-track.net/forum/index.php?showtopic=2219
[52] http://codelaboratories.com/research/view/ps3-eye-disassembly
[53] http://www.wolframalpha.com/input/?i=average+blink+length
[54] http://www.raspberrypi.org/phpBB3/viewtopic.php?p=316916#p316916
[55] http://www.epilepsyfoundation.org/aboutepilepsy/seizures/photosensitivity/
[56] https://www.sparkfun.com/pages/accel_gyro_guide
[57] http://www.analog.com/static/imported-files/data_sheets/ADXL345.pdf
[58] www.procarcare.com/includes/content/resourcecenter/encyclopedia/ch11/11fig16.html
[59] http://www.datasheetarchive.com/ECG2541-datasheet.html
[60] http://www.ceoutlook.com/2012/04/18/garmin-wants-to-be-tier-one-car-audio-supplier/
[61] http://www.raspberrypi.org/wp-content/uploads/2012/12/quick-start-guide-v1.1.pdf
[62] http://elinux.org/RPi_VerifiedPeripherals#USB_Webcams
95