Contributors: Enrique Secanechia-Santos, Gregg Miller, Kevin Mesolella Date: 12/11/13 Contents



Download 125.41 Kb.
Date conversion17.06.2017
Size125.41 Kb.
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:





I. Communicate with a mobile device

II. Compatible with variety of mobile phones

III. Display information on screen

IV.

Easy to install on any vehicle/small enough to fit on dashboard



V.

Operate on a power supply from within the vehicle



VI.

Should not take user’s eyes off road



VII.

Easy to see in variety of lighting conditions



Total

I. Communicate with a mobile device

1

4

2

2

3

2

4

18

II. Compatible with variety of mobile phones

1/4

1

1/3

1/2

1/3

1/4

1/2

3.16

III. Display information on screen

1/2

3

1

3

2

2

2

13.5

IV. Easy to install on any vehicle/small enough to fit on dashboard

1/2

2

1/3

1

3/2

1/3

2

7.66

V. Operate on a power supply from within the vehicle

1/3

3

1/2

2/3

1

1/3

2

7.83

VI. Should not take user’s eyes off road

1/2

4

1/2

3

3

1

3

15

VII. Easy to see in variety of lighting conditions

1/4

2

1/2

1/2

1/2

1/3

1

5.08


Engineering Requirements:


Need(s)

Engineering Requirement

Justification

I. II.

  1. Microcontroller should support Bluetooth 2.0 to 3.0 (IEEE 802.15.1)

Bluetooth 2.0 to 3.0 protocol is commonly supported by most mobile phones.

III.

  1. LCD screen should be able to connect to microcontroller via I/O pins, or video connectors (Composite/HDMI/VGA)

The microcontroller needs to have an LCD screen connected to display information to the user

IV.

  1. Microcontroller and attached LCD screen should be housed in an enclosure no larger than 8”(L) x 5”(W) x 3”(H)

The device should easily fit on any dashboard

IV. V.

  1. The microcontroller should be powered by a 12V DC socket

A 12V DC socket is commonly found in most vehicles. 12V DC should be sufficient to drive CPU, LCD, and any other additional hardware.

II.

  1. Device should be compatible with Android OS version 4.3 or later

The Android operating system will maintain compatibility with a wide variety of mobile devices. Version 4.3 was the first to offer explicit support for notification capture and redirection.

VI. VII.

  1. The LCD should display green image to windshield in.

A green image will be easy to distinguish among other objects seen through the windshield

VII.

  1. The resolution of the image projected should exceed a minimum of 320x240 pixels

The image shown should be easy to distinguish but should not have such low resolution that image quality suffers.


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:

  • All systems currently use segmented displays which limits the information that can be displayed. By using an LCD screen, information can be dynamic and can change based on what notifications and data the microcontroller receives from the mobile device.

  • The Bluetooth protocol is commonly supported by most mobile phones and microcontrollers (either built in or by added modules).

  • A microcontroller which runs a version of LINUX was chosen, since it allows easy use of USB attachments, various programing languages, and native video output support.


Considered Concepts:

  • Using an ELM327 OBDII dongle that connects to the car computer to transmit car information, such as speed and dashboard information, via Bluetooth. While this would have replicated many functions of the GMC Acadia built in HUD, much of this information is unnecessary, would add additional components that must be installed, and would be redundant since a mobile device can calculate the speed using GPS.


Microcontroller:




Raspberry Pi Model B

Arduino Duo

Freescale i.MX53 QSB

Cost

0.125

0.125

0.2

0.01

Availability

0.125

0.125

0.125

0.06

Display Capabilities

0.25

0.2

0 .1

0.2


Programing Environment

0.25

0.25

0.2

0.3

Bluetooth Support

0.25

0.2

0.1

0.25

Score:

0.9

0.725

0.82


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:




Projector LCD driven by Raspberry Pi via BBS external board (Reference)

Projector LCD driven by I.MX6

Third party LCD driven by I.MX6

Sainsmart SSD1289 LCD display driven by Raspberry Pi

Image Quality

5

-

-1

1

1

Backlight Options

4

-

0

-1

-1

Cost

3

-

1

1

1

Availability

2

-

1

1

1

Ease of Development

1

-

-1

-1

1

Score

-

-1

6

7

Continue?

No

No

No

Yes


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.
IV. Design
Microprocessor Overview:

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.

c:\users\enrique santos\skydrive\year 5\ce senior design\level 1 system diagram.png

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.

c:\users\enrique santos\skydrive\year 5\ce senior design\basic flow diagram.png

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.

https://lh5.googleusercontent.com/6cj_kcxp1sjqsg3fi1s8gckkkceajiqvt6e9pnntvvzdccw8ih7t-xkvlz-mnfoooccs2ag0eiorvrz6lc6ntrp2ixbv9vhtruuxp9vrfxdiensm8qmukunr88gd

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.

http://i2.wp.com/marks-space.com/wp-content/uploads/2013/10/sainsmartschematicv2.png

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:

  • Bluetooth communication protocol

  • Serial Peripheral Interface

  • Android Software Libraries


Multidisciplinary Aspects:

  • Electrical Engineering - circuit design

  • Software Engineering - microcontroller software and android application development

  • Optics - reflective display and lighting conditions

  • Industrial Design – design and manufacturing of dashboard mount and system enclosure


Background:

  • Interface and Digital Electronics - displaying information on LCD screen

  • Data and Communication Networks - different network protocols

  • Computer Science - Java


V. Constraints and Considerations
Extensibility:

  • Software extendable to helmet HUD’s.

  • System can be used in other environments or vehicles such as boats, busses, construction vehicles, etc.

  • Mobile applications can adjust notifications so that it may display more relevant information to drivers


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:

  • Must be stable in vehicle.

  • Must operate on a power supply from within the vehicle.

  • Must work in a variety of lighting conditions.


Others:

  • Must not increase distraction rather than reduced distraction.

  • Must follow traffic and driving laws of market sold in.



VI. Cost Estimates
Part List:

Component

Cost

Our Cost

Availability

Raspberry Pi

$35.00

$0.00

Already Own

USB Bluetooth Adapter

$20.00

$0.00

Already Own

TFT LCD

$15.99

$15.99

SainSmart



5-10 business days

Android Phone

$100-$500

$0.00

Already Own

Total Cost: $170.99 - $570.99



Actual Cost: $15.99


LCD Driver Circuit Part List:

Name

Description

Quantity

Cost (each)

Our Cost

Distributer

Lead Time

74HC4040N

12-Stage Binary Ripple Counter, DIP-16

1

$0.538

$0.538

www.newark.com

4 days

74HCT4094

8-Stage Shift Store Bus Register, DIP-16

3

$1.50

$4.50

www.newark.com

4 days

100nF Capacitor

100nF Ceramic Capacitor

4

$0.258

$0.00

CE Department

0 days

10k Ohm Resistor

10k Ohm Resistor

1

$0.017

$0.00

CE Department

0 days

Pi Cobbler Breakout Kit, Raspberry Pi

Raspberry Pi Ribbon Cable w/ GPIO Breakout

1

$7.95

$7.95

www.newark.com

4 days

Garmin Head-Up Display Windshield Film

Transparent glazing used to project image from display

1

$11.99

$11.99

www.amazon.com

5 days

LED, High Lumen Module, Green

LED used for projection method

1

$9.95

$9.95

www.mpja.com

7 days

Total Cost: $35.98

Actual Cost: $34.93

Total Overall Cost: $206.97-606.97

Actual Overall Cost: $50.92

VII. Testing Strategy
Bluetooth Testing:


  • After installing the Bluetooth drivers and manager, ensure that it can pair with a mobile device. This has already been tested.

  • After pairing the Raspberry Pi and the mobile device, ensure that the Pi can receive information from Bluetooth by sending a file from the mobile device to the Pi. This has already been tested

  • Being able to write a simple program to receive any Bluetooth packet from a mobile device, ensuring that a written program is capable of receiving Bluetooth packets from the operating system. This should be able to be tested within a month.

Android Testing:



  • Test would be modularized as much as possible.

  • Integrations tests for each section of development.

  • Integration testing for the whole system.

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

  • Interfacing (Hardware)

    • Difficulties:

      • Finding LCD displays which are compatible with our microcontroller.

    • Sources of Failure:

      • Displays must use standard signals (HSYNC, VSYNC, etc...).

      • Synchronous displays (such as the projector LCD) have precise timing requirements which are only attainable with some microcontrollers.

    • Solutions:

      • Use an asynchronous display so that the display can work with almost any microcontroller.

    • Analysis:

      • An asynchronous display will not rely on the microcontroller for precise timing and will have a sufficient refresh rate to display the appropriate notifications.

  • Brightness

    • Difficulties:

      • The image from LCD alone may not reflect onto HUD reflective film.

    • Sources of Failure:

      • The LCD backlight alone may not be bright enough to project the LCD image onto the reflective film.

    • Solutions:

      • Use an LED array and the appropriate lenses in place of the backlight if necessary.

    • Analysis:

      • The LCD with the supplied backlight or an LED projection system should be sufficient to display an image on the windshield.

Microcontroller

  • LCD Interfacing (Drivers)

    • Sources of Failure:

      • Incompatible/No drivers – since the Raspberry pi does not natively support TFT LCD output through its I/O pins.

    • Solutions:

      • Implemented and installed drivers and hardware created by online open source community to provide compatibility.

    • Analysis

      • The Raspberry Pi does not natively support screen output through its I/O pins and supports output only through HDMI or composite video. An online community of programmers created a driver circuit and drivers for the Raspberry Pi kernel for a Sainsmart LCD screen. Using this community project, the LCD screen was able to be used with the Raspberry Pi.

  • Bluetooth

    • Difficulties:

      • Installing and interfacing with Bluetooth from Raspberry Pi.

    • Sources of Failure:

      • Incompatible/No drivers

      • Unable to access Bluetooth packets from mobile device

    • Solutions:

      • By using a USB Bluetooth Adapter and installing Bluetooth manager software, the operating system will handle the sending and receiving of Bluetooth packets.

    • Analysis

      • Since the Raspberry Pi does not natively support Bluetooth, and the operating systems that could be installed do not include a Bluetooth manger, it was initially a concern that Bluetooth could not work for the Raspberry Pi, but upon connecting a USB Adapter and manually installing the manager software, the risk was eliminated.

Android

  • Sources of Failure:

    • Bluetooth

    • GPS - Determining speed via GPS

    • Limited API’s for notification catching

  • Solutions

    • Bluetooth

      • Use standard libraries that are well documented.

    • GPS - Determining speed via GPS

      • Use an averaging and error reduction algorithm, with some trial and error to get better accuracy.

    • Limited API’s for notification catching

      • Choosing android version 4.3 or greater will allow for easier notification handling and greater API support.

  • Analysis

    • Bluetooth

      • Communicating over Bluetooth was a concern, but after an investigation and minor experimentation, this risk has been greatly reduced. Standardization of Bluetooth communication and the number of examples that already exist makes Bluetooth a non-issue when it comes to risks

    • GPS - Determining speed via GPS

      • There is not an API to get the speed via GPS, so this needs to be calculated. Accuracy, consistency, and update speed are all areas of risk. The accuracy of a smartphone GPS is not very good, and therefore an error reduction algorithm needs to be developed to get a consistent accurate speed. The simplest algorithm will be an average over a period of time, the concern here is that better accuracy increases time to update.

    • Limited API’s for notification catching

      • Examples exist to pull notifications from an android device before version 4.3, but by choosing Android OS version 4.3 or later built in notification APIs can be used. This allows for standardization of a notification watch system that can easily be ported to later versions of android.


IX. Milestone Chart


Task

Completion Date

Responsibility

Basic Bluetooth server and client developed.

2/7/2014

ES, KM

Basic Android Bluetooth client developed.

2/7/2014

GM

Basic Bluetooth server testing complete.

2/14/2014

ES, KM

Final Bluetooth server and developed for Raspberry Pi and Android Client

3/7/2014

ES, KM, GM

Android notification capture system complete.

3/12/2014

GM

Bluetooth integration testing complete.

3/14/2014

KM

Android GPS speed calculation complete.

3/14/2014

ES

Android GPS speed calculation testing.

3/17/2014

ES

Android notification capture system testing.

3/17/2014

GM

Final implementation of notification capture.

3/31/2014

GM

Final implementation of GPS speed calculation.

3/31/2014

ES

Raspberry Pi backend software complete

4/4/2014

KM

Android app integration for Bluetooth, GPS calculation, notification capture, and GUI

4/4/2014

ES, KM, GM

Basic display GUI implemented to display test data for android development

4/7/2014

GM

Android app integration testing

4/7/2014

GM

Raspberry Pi backend software testing complete

4/11/2014

KM

Final display GUI implemented

4/11/2014

ES

Final implementation of Android app.

4/11/2014

GM

System Integration Testing

4/14/2014

ES, KM, GM

Final Integrated System

4/18/2014

ES, KM, GM

Acceptance testing starts.

4/21/2014

ES, KM, GM

Final System Demonstration.

4/29/2014

ES, KM, GM



Windshield Heads Up Display Project Proposal




The database is protected by copyright ©ininet.org 2016
send message

    Main page