Contributors: Enrique Secanechia-Santos, Gregg Miller, Kevin Mesolella Date: 12/11/13 Contents
Download 125.41 Kb.
|
- Navigate this page:
- II. Requirements Specification. 4 Needs. 4 Engineering Requirements. 5 III. Concept Selection. 6 Microcontroller. 6
- User Interface. 18 Engineering Standards. 18 Multidisciplinary Aspects. 18 Background. 18
- VII. Testing Strategy. 21 VIII. Risks. 21 LCD Display. 21 Microcontroller. 22 Android. 23
- Marketing Diagram: II. Requirements Specification Needs
- Engineering Requirements
- III. Concept Selection Existing Systems
- Microcontroller: Concepts Chosen
- Raspberry Pi Model B Arduino Duo Freescale i.MX53 QSB
- Score: 0.9 0.725 0.82 LCD Screen
- Pugh Concept Selection Matrix
- Android Device/Development
- IV. Design Microprocessor Overview
- Multidisciplinary Aspects
- V. Constraints and Considerations Extensibility
- VI. Cost Estimates Part List
- LCD Driver Circuit Part List
| Windshield Heads Up Display
Description: Displays important notifications from mobile devices in an opaque image superimposed on the windshield of the user’s vehicle. Contributors: Enrique Secanechia-Santos, Gregg Miller, Kevin Mesolella Date: 12/11/13 Contents I. Overview. 3 II. Requirements Specification. 4 Needs. 4 Engineering Requirements. 5 III. Concept Selection. 6 Microcontroller. 6 LCD Screen. 7 Android Development. 9 IV. Design. 10 Microprocessor. 10 LCD. 12 Android App. 15 User Interface. 18 Engineering Standards. 18 Multidisciplinary Aspects. 18 Background. 18 V. Constraints and Considerations. 18 VI. Cost Estimates. 19 Parts List. 19 LCD Driver Circuit Part List. 20 VII. Testing Strategy. 21 VIII. Risks. 21 LCD Display. 21 Microcontroller. 22 Android. 23 IX. Milestone Chart. 24 I. Overview Needs Statement: Modern mobile devices have been known to cause distractions to drivers of automobiles. Several hands-free options already exist for talking on mobile phones, and several vehicle manufacturers now include an interface to mobile devices in the vehicle's existing electronics. However, more drivers need to be able to be aware of important notifications from a mobile phone without taking their eyes off of the road. There is a need for a system that provides important notification information without looking away from the road while driving. Objective: The objective of this project is to design and build a device to show notifications from mobile devices onto an opaque image on the windshield of the user’s vehicle. The device should be easy to add to any vehicle and should be able to display notifications from any mobile phone without taking the user's eyes of the road. Description: The device will display information using an LCD screen, and will receive notifications through Bluetooth from an Android device. The Android app will be configurable so that the user can select important notifications to display. 
Marketing Diagram: II. Requirements Specification Needs:
Engineering Requirements:
III. Concept Selection Existing Systems: Currently in the market there are two types of HUD’s, built-in HUD’s in the dashboard of the car, such as the one found in the 2013 GMC Acadia, as well as dashboard mounted HUD’s such as the Garmin HUD. Images of each are shown below. The built in HUD’s use the car’s computer to get information such as the speed, dashboard information (high beams, signal lights, drive gear), and updates from the car’s entertainment system (such as song/station changes, incoming calls, etc.). The car’s computer is significantly more powerful than current project needs, and the application of the HUD is limited only to car functions. Dashboard mounted HUD’s, such as the Garmin HUD, connect to a mobile device using the Bluetooth protocol, and from the phone receives navigation data and car speed using the Garmin StreetPilot app for the iPhone or NAVIGON for iPhone, Android, or Windows Phone systems. The Garmin HUD performs similarly to how the microprocessor for our design should perform, but is only limited to Garmin applications for information.  
Garmin HUD Built in HUD (2013 GMC Acadia) Microcontroller: Concepts Chosen:
Considered Concepts:
Microcontroller:
LCD Screen: A common way of displaying an opaque image on a surface such as a windshield is projection. LCD projectors typically project light through a transparent LCD screen, while DLP projectors use a rotating wheel and lens to beam light onto the display surface at each pixel location over given timing interval. An existing LCD projector was reverse-engineered to gain an understanding of LCD projector operation. The Sony LCX017 LCD was confirmed to be used in the projector examined. This particular projector used a prism to split white light into red, green and blue components, each of which had its own LCX017 display. These individual beams are then recombined and projected through various lenses before reaching the screen. Another method of displaying an image on a transparent surface is reflection. To facilitate reflection, an opaque but reflective sticker is positioned on the glass above a simple LCD panel with a standard backlight. Both projection and reflection will be investigated. For either case LCD technology was selected for this project. Thin Film Transistor displays or TFTs are one of the many types of LCD displays. Among these are asynchronous panels or “smart displays” and synchronous panels or “dumb displays”. Synchronous panels are considered “dumb displays” because they constantly need to be updated at a set refresh rate. Synchronous displays are typically driven by a driver chip, FPGA or a microcontroller with dedicated TFT interface hardware such as the Freescale i.MX6. These devices typically output a horizontal and vertical synchronization signal as well as a parallel data bus for color or monochrome pixel data. Asynchronous displays are considered “smart displays” because they need only to be updated when the image changes. This makes them ideal for use with microcontrollers that do not have access to high resolution timers, such as the Raspberry Pi. The Sony LCX017 used in the existing projector is a textbook example of a synchronous display. Among the microcontrollers and display controller options available for synchronous displays, the Freescale i.MX series microcontrollers and an external driver board made by “BBS-BildSysteme” specifically for the LCX017 LCD were both considered. Third party asynchronous displays with standard backlights were also considered for the i.MX6 in place of the LCX017 salvaged from the projector. The BBS external driver board, because of its very specific targeted group of users proved to be cost prohibitive at a price of roughly $2000 USD. With the aid of a Sony CXD3500R timing generator, the LCX017 projector LCD could also potentially be driven with the Freescale i.MX6’s TFT interface. However, as seen in the above table, the Sony LCX017 projector LCD exhibited poor image quality when used in the required lighting environment. To determine if the existing LCD would meet the needs of the project, a test fixture was implemented to operate the LCD outside of the original projector with its original driver circuitry. When driven by its existing circuitry, the display showed a very weak image visible only on the display itself. Using an LED for illumination, no projection of the image was visible to the human eye. Without the sophisticated system of lenses and filters found in the existing projector, the LCX017 LCD proved to be inadequate for this application. Although several other standard TFT LCDs using this technology are available for the i.MX series microcontrollers, the unnecessary complexity of synchronous LCD technology proved to be a prohibiting factor. The Sainsmart SSD1289 LCD was investigated as an asynchronous alternative to the above LCDs. Although this LCD is available with a standard backlight, the backlight could be replaced with a high-power LED to make it behave like the LCX017 for possible projection instead of reflection. At 320x240 pixels, this display measures 3.2” diagonally and offers a lower pixel density than the LCX017 which operates at 1024x768 and has a 1.8” diagonal length. This makes it ideal for projection of small images without powerful lenses. Because it is an asynchronous display, it can easily be driven by a Raspberry Pi. For these reasons, the Sainsmart SSD1289 LCD was chosen for this project. Pugh Concept Selection Matrix:
Android Device/Development Mobile OS’s other than Android, like Windows Phone and iOS, are available. There are many reasons for choosing Android over the rest. Android is the only one that does not require a developer’s license. It has the largest market share worldwide, and most importantly it offers the largest selection of APIs. Version 4.3(Jelly Bean), the proposed version, has 2.3% of the android market. This is not a concern because all later versions will also be supported and the percentage of the android market that is compatible with version 4.3 will only grow in number. The main reason for choosing this particular release is the newly added support for notification capture and redirection. While possible in older versions, it is not an intended feature and therefore more difficult. Version 2.0 for Bluetooth and later will be supported, due to the available module (a USB Bluetooth 2.0 dongle). The choice to use Bluetooth over other communication methods, was a clear choice as each smart phone has Bluetooth capability coupled with the device. Another concern is calculation of the vehicle speed via GPS. There is no built in method, and being that smart phone GPS tends to be very inaccurate, a method for determining the speed must be created. This will have to involve an error reduction algorithm, which could range from being a simple average to a more complicated solution.
The microcontroller acts as the central point of the HUD system. It acts as the Bluetooth server to receive messages, notifications and other information from a mobile device, and then displays the information on an LCD screen. The largest risk with the microcontroller is Bluetooth support and LCD display support, and whether any of these two components will require additional hardware or software drivers. The microcontroller chosen was the Raspberry Pi Model B. By connecting a USB Bluetooth Adapter to one of the two USB ports on the Raspberry Pi, and installing the Bluetooth drivers and Bluetooth manager software, the Raspberry Pi will support Bluetooth 2.0, meeting Engineering Requirement A. The Raspberry Pi can then be programed to act as a Bluetooth server, and can use the operating system to handle the connection between the Pi and a mobile device. The Raspberry Pi natively supports HDMI and Composite output, but can support TFT LCD screens via the I/O pins, though this requires additional hardware and compatible software drivers, since the Raspberry Pi does not natively support this type of display. A TFT LCD screen is currently being used, since it is the most affordable option, and the other connection types are either too costly, or too large. This meets engineering requirements A and C. The Raspberry Pi receives power through a standard micro USB port, and is compatible with most car cell phone chargers that connect to the 12V DC supply in most cars, meeting Engineering Requirement D. The Raspberry Pi is also very compact, with dimensions of 85.60mm x 56mm x 21mm, or 3.37” x 2.2” x 0.83”, meeting Engineering Requirement C, and allows for enough space for a TFT LCD screen to be connected and placed above. This design minimizes the risks mentioned above by using already written drivers for the Raspberry Pi to enable support for a USB Bluetooth Adapter, and to output to a TFT LCD display through the Pi’s I/O pins, though this requires additional hardware. Using a USB Bluetooth adapter relieves the need have to use a separate Bluetooth module which would require connecting it to the I/O pins, and manually writing drivers. This also frees the I/O pins to be used for the TFT LCD. The driver circuit for the LCD requires additional hardware, and additional drivers, for which the schematics and drivers were provided by an online community project. Level 0 System Diagram: Below is the Level 0 System Diagram, showing the most basic concept for the Windshield Heads Up Display System, where the main device will be powered by a 12 volt power source, receive Bluetooth packets, and output an image to an LCD screen to be projected to the windshield. 
Level 1 System Diagram: Below is the Level 1 System Diagram of the Windshield Heads up Display System, specifically the microcontroller. As shown below the Raspberry Pi is powered by 5V DC from a micro USB connected to the car’s 12V power supply. A Bluetooth packet is received and handled by the USB Bluetooth adapter which via the USB bus, sends the information to the microprocessor. The microprocessor will interpret this data, then send the data to the I/O pins of the Raspberry Pi to be sent to the LCD screen. 
Basic Software Flow Diagram: Below shows the basic functionality of the software written for the Raspberry Pi. After making a connection to the mobile device through Bluetooth, the software will enter a loop, where it waits for a Bluetooth packet to be received. If one is received it will read in the data, interpret the notification or updated information, and then will update the display to show the new information or update existing information. 
LCD Overview: The Sainsmart SSD1289 LCD was selected for this project. Being able to use a Raspberry Pi simplified the microcontroller selection greatly. Because the Raspberry Pi has a built-in SPI interface, the display can be set up to receive pixel data serially. A circuit containing a set of shift registers can be used to transmit SPI serial data to the LCD’s parallel data bus. An open-source Linux driver can be used to display the Raspberry Pi’s standard desktop environment. This display meets all of the necessary engineering requirements. It meets the minimum resolution requirement of 320x240 pixels. It requires 5VDC for operation and 3.3VDC for the supplied backlight (if used), both of which can easily be derived from a 12V DC socket. This can be accomplished by the Raspberry Pi or an external converter circuit. The requirement of a green backlight can be met by supplying an external high-power green LED and/or an appropriate color scheme for the GUI. This display minimizes risk because it has a well-designed circuit diagram and Linux driver accompanying it. It can be used for either projection or reflection, which increases its chances of being useful for its intended purpose. At a minimum, this device could also be used as a normal display without the use of projection or reflection. LCD System Diagram: An overall system diagram for the LCD display is shown below. The main components for this system are the microcontroller (Raspberry Pi), the LCD display controller and the Sainsmart SSD1289 LCD display. DC Converter Circuit Raspberry Pi LCD Controller Circuit SSD1289 LCD Display 12VDC
5VDC 16-bit Data Bus 3.3V, 5V DC SPI Bus
Control Signals Image
3.3VDC Bluetooth Dongle USB Android Phone Bluetooth Packets LCD Physical Component Placement: The physical component placements for the device are shown below. The reflection design uses the display and its supplied backlight to reflect an image onto the transparent glazing. The projection design uses a high-power LED, a set of lenses and an LCD without a traditional backlight to project an image onto the transparent glazing. 
LCD Driver Circuit Schematic: The LCD driver circuit schematic is shown below. The circuit consists of a binary counter and three shift registers. The circuit converts synchronous serial data from the Raspberry Pi into the 16-bit parallel data used by the display. 
Android Overview: For both the Bluetooth and Android OS most of the mitigation (in this scenario) is done by choosing a standard and following it. The rise of issues during development in these two areas also needs to be considered. It is difficult to determine mitigation for software design; most comes from good programming practices and good unit tests. For all of the Android development there are a large number of previously made applications that the design can follow or modify. The design for the GPS speed calculation however has less documentation, or rather there is no one way to go about it. For simplicity a simple average calculation, that possibly throws out outliers, will suffice for our proof of concept design. This is a valid solution that will reduce the risk of errors and time spent on app development. Overall Android system design flowchart: Below shows a simple system flowchart that shows the overall system design. The flowchart including the three main sub-functions in the system, GPS speed calculation, notification updates handling, and Bluetooth communication between the Android device and the microcontroller. Start
Request GPS speed Listen for new notifications Send update package via Bluetooth to micro-controller
GPS Speed Calculation Flowchart: The flowchart below shows the design flow of the GPS calculation. This design involves taking in multiple GPS location data, determining speeds, and averaging the speeds together to reduce error. Some experimentation may need to be done to refine the algorithm to increase accuracy. This will be done periodically to ensure current speed is shown. Store speed Request
GPS data Process Average Speed Store GPS data Start
Accumulated required number of samples? Yes
No User Interface: Below is the information to be displayed on the windshield. 
Engineering Standards:
Multidisciplinary Aspects:
Background:
V. Constraints and Considerations Extensibility:
Manufacturability: If the Windshield Heads Up Display system were to be manufactured, the Raspberry Pi would not be able to be used, instead a separate microcontroller must be used. This custom microcontroller would have Bluetooth built in, run an embedded version of Linux, and natively support a TFT LCD display. The software for the microcontroller can be easily ported from the Raspberry Pi since both run in the Linux environment, and the Android App would be unaffected. Reliability:
Others:
VI. Cost Estimates Part List:
Total Cost: $170.99 - $570.99 Actual Cost: $15.99 LCD Driver Circuit Part List:
Total Cost: $35.98 Actual Cost: $34.93 Total Overall Cost: $206.97-606.97 Actual Overall Cost: $50.92
Android Testing:
LCD Testing: The display will need to be tested to ensure that it works in this very specific environment. Two tests can be performed to determine this display’s fitness for our particular application. The tests should investigate both the reflection and projection configurations discussed previously. The first test which can be performed is the reflection test. This test can be performed as soon as the LCD is confirmed to be working and the windshield film is available. If the image of the display can be reflected onto the windshield film, the included backlight should be sufficient for our purposes. If the included backlight is not sufficient, the projection configuration can also be tested. If the original backlight is replaced by a high-power LED module that is sufficient to project the image onto the windshield film, then this method will be preferred. VIII. Risks LCD Display
Microcontroller
Android
IX. Milestone Chart
Windshield Heads Up Display Project Proposal Directory: edge edge -> Edge of Your Seat Fiction (Suspense, Action & Survival Stories) edge -> The work number company code edge -> Marilyn Hair, Outreach Manager 4225 Roosevelt Way ne, Suite 100, Seattle, wa 98105 edge -> Telecon Attendees edge -> For immediate release merage School “edge” Students Grab Hold of the Long Tail edge -> Mitchell Ludwig edge -> Strength and Weaknesses of Team Members edge -> Usb webcam Integration Notes edge -> Abstract The "Smart Walker" Download 125.41 Kb. Share with your friends:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||