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
