Rapid Prototyping Of Computer Systems:

GM/CMU Car

PHASE II REPORT

School of DesignRobotics Institute

School of Computer ScienceHuman - Computer Interaction Institute

Department of Electrical and Computer Engineering

Carnegie Mellon UniversityPittsburgh, Pennsylvania 15213

April 1st 2005

1

PROJECT PARTICIPANTSThis is a joint project between the students of the School of Computer Science (SCS), Human-Computer Interaction Institute (HCII), Department of Electrical and Computer Engineering (ECE), School of Design (Design), and the Robotics Institute (RI).

STUDENTSNikhil Gadia (ECE) Stephen Fabrey (ECE) Yong Hoon Lee (ECE)Srikanth Narayanamohan (ECE) Taewan Kim (ECE) Karen Lee (ECE)Venkatesh Shankar (ECE) Dukkyoo Kim (SCS) Sonali Nath (ECE)Michael Walch (ECE) Taesang Kim (ECE) Prasanna Velagapudi (SCS)

Teaching StaffMatthew Rogers (ECE)

Faculty AdvisorsDan Siewiorek (HCI) Asim Smailagic (ICES)

Editorial BoardSrikanth Narayanamohan (Chief Editor and AWARE)Dukkyoo Kim (Position Pilot and Music Manager Group Editor)Prasanna Velagapudi (Software Infrastructure Group Editor)Taesang Kim (HW/Platform/Display Group Editor)

2

GM Group

The class would like to thank the following people, as it would not have been possible without their assistance:

Lisa Troutman Jaci Feinstein Susan FrankiewiczAya Horiguchi Karen Wong

AndAlexander Eiser and the Voyager group for help in making this report

3

4

5

6

Table of Contents

1. Introduction1.1 Purpose1.2 Background Of Phase II1.3 Aims of the project

2. Visionary Scenario2.1 Purpose2.2 Visionary Scenario

3. Key System Requirements3.1 Introduction

3.1.1 Position Pilot and Music Manager3.1.1.1 Functionality Position Pilot3.1.1.2 Music Manager3.1.1.3 User Studies Plans Music Manager3.1.1.4 Screen dumps3.1.1.5 Hardware / Software Architecture Position Pilot3.1.1.6 Software Module and Status Position Pilot

3.1.2 AWARE3.1.2.1 Background3.1.2.2 Introduction3.1.2.3 Main Features of AWARE3.1.2.4 Key Design Issues3.1.2.5 Architecture

3.1.3 Software Infrastructure3.1.3.1 Computing Architecture3.1.3.2 IBM Thinkpad3.1.3.2 Mini-ITX3.1.3.3 Database3.1.3.2 OBD-II Interface Daemon

3.1.4 Hardware/Power/Display/Platform3.1.4.1 Embedded PC3.1.4.2 Laptop3.1.4.3 Power3.1.4.4 Display

3.1.4.4.1 LCD3.1.4.4.2 HUD

4. Worklog Analysis5. Timeline6. Task Dependencies7. Conclusion

7

1.Introduction

1.1 Purpose

GM and the Spring 2005 Rapid Prototyping class have been working together to produce the next generation vehicle that in tune with the entire driver’s needs. In phase I the class pitched numerous ideas that were eventually trimmed down to a select few that considered truly visionary. In phase II, implementation of these ideas became underway and this report is a chronicle of our efforts in this phase and serves as an analysis of our ideas and the features and will go provide detailed explanation of the architectures of the various components present in the final prototype that is to be developed in phase III.

1.2 Background Of Phase II

This is the second in three phases of the GM/Rapid Prototyping project. Phase II began in mid February and ended at the end of March, a total of 6 weeks. The various groups in the previous first phase were dissolved and new groups were formed. The new groups are

Position Pilot and Music Manager AWARE (Automated Warning And Recording Electronics) Software Infrastructure HW/platform/display

The Position Pilot subgroup is in charge of implementation of the GPS navigation system and the Music Manger subgroup is in charge of the integration of the iPod into the car system. The Software Infrastructure group takes care of the computer software integration and the implementation of the necessary databases. And finally the HW/platform/display group installs the necessary hardware ensuring that all systems are integrated and fully functional.

Implementation began in this phase, as the various groups looked towards software and hardware components that they could bring into the car. Some software components had to be implemented by the group members them selves while others were taken form various other projects. Working together the groups looked to implement a working prototyped for phase III.

1.3 Aims of the project

The main aim of phase II is to gauge the feasibility of the ideas and concepts agreed upon in phase I towards making a working prototype in phase III. The end goal is to produce a revolutionary system where driving is a more useful, entertaining, enjoyable and safer experience. Driving experience is enhanced by integration of many novel features such as being able to play songs form the iPod, knowing exactly where you are with the Position

8

Pilot using GPS navigation and not worrying anymore about car maintenance and random car failures: with AWARE maintenance is a breeze and worrisome noises are a things of the past.

2.Visionary Scenario

2.1 Purpose

In this section we recap the visionary scenario that was formulated in phase I. Modifications were made when appropriate when the feasibility of some ideas were not possible and where other ideas and concepts were changed.

2.2 Visionary Scenario

The alarm is blaring loudly as Sally reaches over to shut it off. It was 8:05 am and she had a quiz to attend at 8:30 am. As she approaches the parking lot, she can’t remember where she parked her car after drinking late night. She quickly glances on her key that directs her to the car. She hurries over to the car with a pile of books in her hands. Good that the car automatically unlocks instead of her trying to juggle with her keys and books to open the door.

She sticks in her PDA, MP3 player and cell phones into their respective cradles which charge themselves up using a normal two-pin socket. She presses the voice activation button on the steering wheel and shouts “Numb/Encore” to play her favorite tune from Jay-Z and Linkin Park. It immediately puts her in a happy mood so much so that she increases the volume to full blast with the volume controls on the steering wheel. She uses the car’s sensors to help her back out of unusually tight parking spot. With her level of driving skill, Sally was sure she would have hit her car against the car behind her if not for the car’s parking and blind spot warning sensors.

As she is driving, Carrie, her personal car assistant, reminds her that she has an appointment with the dentist at 10:30 am. Sally hits herself on the head as she realizes she forgot to brush her teeth. Oh well, she hopes the dentist won’t be too disgusted with her breath reeking from alcohol. Suddenly, the GPS pulls up a navigation map comes up indicating traffic jam on Morewood Avenue her usual route to campus. It provides an alternate route via Beeler street to campus. Sally is glad she invested in the top notch GM GPS system as it just saved her from missing her quiz.

After class, it is time for her to head for her dentist’s appointment. As she is driving there, Carrie reminds Sally before any upcoming turns. Sally then have time to switch to another lane and turn when an arrow is displayed on either end of the windshield. Sally whistles and wishing she could just go back and crawl under her bed. Sally manages to make it to the dentist’s clinic without much incident. After her regular check up, she heads onto her car again. It is snowing so heavily that she decides to

9

turn on the headlights. Ops! She has no idea how to turn it on in her brand new car. She shouts “manual”, then “headlights”. Carrie brings up the instruction showing her how.

Suddenly the car starts making a funny sound and a red symbol pops up on the HUD and her touch screen. She is puzzled by this funny looking symbol colored in red and presses the symbol on the touch screen which then pulls up an explanation of the symbol. The manual explained that the radiator in the car was running out of radiator liquid and needed to be refilled with the “Green” type radiator liquid. The red color alert displayed indicated that this should be taken care of immediately. But, that didn’t explain the funny sound the car was making. Sally records the sound on her PDA and attaches it to the car’s onboard performance statistic report and says “send to dealer”. Her car pulls up Sally’s favorite dealer information from her PDA and sends it to that dealer. She waits for a couple of minutes and receives a call from the dealer. The dealer informs Sally that the sound is related to the radiator fluid and it would go away once she replenishes it. Sally thanks the dealer and disconnects. She clicks on the search button on her touch screen to pull up the search menu. Then Sally types in “Gas Station” and the GPS displays the directions to the closest Mobil gas station. Sally drives over there and approaches the store. She notices that there are two kinds of radiator liquid, one being “Green” and the other being “Orange”. She remembers the car indicating the “Green” one that she purchases and pours it into the radiator. Hmm, that’s interesting Sally wonders. She shouts “notes” and “find out about difference between ‘green’ and ‘orange’ radiator fluid”, which is recorded into her PDA to remind her to ask about the difference the next time she was at the dealer’s workshop for the car’s maintenance checkup. She pulls out of the gas station and begins her drive back home.

She quickly heads back home parks her car and runs to her apartment looking forward to the warmth off her bed covers. She thinks to herself “What a day” and turns around and rushes up for her sleep.

3. Key System Requirements

3.1 Introduction

This section of the report covers the features that were developed in phase II to meet the Key System Requirements outlined in phase I and covered in the Visionary Scenario shown above.

3.1.1 Position Pilot and Music Manager

3.1.1.1 Functionality Position Pilot

10

Position pilot provide the driver of the car the position of the car when the driver is in the car as well as when the driver is not in the car. The position of the car will be displayed on a map with Global Positioning System (GPS) technology.

When the driver is in the car driving, Position Pilot will offer GPS navigation feature allowing the driver to route the shortest route to a desired destination. When connection to Internet is available, Position Pilot is also able to retrieve local traffic information to find routes avoiding traffic.

When the driver is not in the car, Position Pilot will offer car locator feature locating the current positions of the car and the driver and lead the driver to the car. The driver will be able to view the map display on the PDA to see the direction to the car. Otherwise, Position pilot will be able to give speech commands directing the driver to the car.

3.1.1.2 Music Manager

Music Manager aims to provide multiple ways for the driver to select and play a song. The Song can be selected either by voice command or Edge Write.

Music Selection by Voice Command User presses button for voice activation Says the song title aloud to the microphone Automatically activates Sphinx which translates voice into text and searches for

song among the available song tracks Song title is fed into a script file that searches in iTunes for selected song. Automatically plays the first hit. Display all the choices for the user on one of the displays. User can change songs.

Music Selection by Edge Write User preference or noisy environment etc The user can input the first few letters of the wanted song using edgewrite on

the touchscreen. Again using data matching the necessary matches in iTunes is found. The first song will start playing automatically with the others displayed on the

screen.

3.1.1.3 User Studies Plans Music Manager

As the music manager consists of 2 distinct systems having very different functionality the proposed user studies are two-fold. To test the voice to text interface:

Testing with multiple users having different accents to test accuracy and transparency.

11

Use a larger selection of song titles for higher precision. Test with complete sentences as well as phrases forming the song title. Test distance and angle of microphone from the user to test accuracy and optimal

usage requirements.

To test Edgewrite interface: Test proficiency of using Edgewrite with very little training. Test accuracy of Edgewrite in moving cars. Accuracy of inputting characters while not looking at the screen to imitate

conditions faced while driving. Test placement of the touch screen/buttons. Possible options involve – steering

wheel, on top of the gear shift and on the console touch screen.

3.1.1.4 Screen dumps

Position Pilot

Figure 3.1.1.4(1) Diagram above shows a sample mapped route from a starting point to a destination. The view above can be zoomed in to street level map as shown in Figure 3.1.1.4(2)

12

Figure 3.1.1.4(2) The red arrow shows the current position and direction of the car. The pick line indicated the mapped route to the destination.

Figure 3.1.1.4(3) As shown above, log file of raw GPS data can be created from which we can obtain real time position data. From this we can calculate the distance and direction from the driver to the car’s location.

13

Music Manager

Figure 3.1.1.4(4) Overview of the music selection process by speech.

Figure 3.1.1.4(5) Sphinx Client

Speech

Sphinx (Voice

text)

Script (Part of Song title Play Selected Song in iTunes)

Car Speaker

s

14

Figure 3.1.1.4(6) Overview of the music selection process by edge write.

Figure 3.1.1.4(7) Edge Write

Car Speaker

s

Script (Part of Song title Play Selected Song in iTunes)

15

Figure 3.1.1.4(8) iTunes Script

3.1.1.5 Hardware / Software Architecture Position Pilot

Figure 3.1.1.5(1) Bluetooth enabled GPS receiver. It is connected to the PDA through Bluetooth technology.

Position Pilot & Music Manager

16

Figure 3.1.1.4(2) HP iPAQ 1900 series. It also comes with Bluetooth technology so that the GPS receiver can be connected to it. The PDA will also connect to the laptop for access to the internet.

17

Figure 3.1.1.4(3) Overview of the whole hardware architecture. The above figure shows how the Position Pilot and Music Manager fit into the whole system.

Music Manager

Figure 3.1.1.4(4) Software architecture of music selection by speech.

Sphinx iTunes Script

iTunesVoice

Song Title

Music

18

Figure 3.1.1.4(5) Software architecture of music selection by edge write

3.1.1.6 Software Module and Status Position Pilot

The two main software for Position Pilot are the GPS navigation software and car locator program.Module Description StatusGPS Navigation This is responsible for providing navigation

of the vehicle, such as providing faster route to a desired destination taking traffic into consideration.

Works

Car locator This will provide the driver with direction to get the current location of the car from the driver’s current location. GPS Navigation feature can be used for map displayed direction. Otherwise, the driver may also follow speech output commands.

Software for calculating the distance and direction to the car need to be written. This will also provide speech output commands

Music ManagerFor music selection by voice command, two software modules are used: Sphinx client and iTunes scriptModule Description StatusSphinx client Takes in voice command (song title), match

the song title in the database and pass the song title(s) that best match the command to the iTunes script module.

Currently it only works if the user says the whole song title.

iTunes script (make use of iTunes COM Windows SDK)

Takes in part of the song title and find the song title(s) that match the input and return a list of matching titles and play the best match in iTunes.

Works fully.

19

EdgeWrite Driver Sets up the parameters necessary to start recognizing characters. Then converts scrawled letter(s) to text.

Acquired the dll. Need to write an application for the touch screen

Song title completion Script

Takes the text input from Edgewrite and find a match in the playlist which is then sent to the iTunes script file.

Reuse iTunes script with a few modifications

3.1.2 AWARE

3.1.2.1 Background

This group initially started off as a User Manual group for GM. However, by trying to offer systems that offer more than simple user manual functions, GM’s User Manual group has evolved into the GM AWARE (stands for ‘Automated Warning and Recording Electronics) group. GM AWARE provides electronic user manual functionality, but also provides a warning system to replace existing systems that provide arcane light ups on the dashboard based on detection of certain problems. The system also includes maintenance checks and update recommendations, far more superior from most existing car systems nowadays. GM AWARE is a complete package.

3.1.2.2 Introduction

AWARE helps drivers better understand the problems and maintenance associated with their cars. The AWARE interface was programmed using GUIs in java. This was done via the way of using Swing Components and Applications. It is very user-friendly and easy to understand. Furthermore, since actual road conditions would be difficult to test (such as driving 3000 miles for a brake fluid change reminder), a simulation program that randomly changes certain component settings in our database was created so that we can demonstrate the working system with complete functionality. The three basic functions of the system are the Maintenance system, the Problem Detection system, and the Electronic User Manual. The Maintenance System reminds the driver of maintenance updates when the suggested number of miles has been reached. There are levels of severity regarding these maintenance recommendations, from ‘suggested’ to ‘strongly suggested’ to ‘critical’. AWARE’s Problem Detection system gets rid of the problem of idiot lights on the dashboard. This system explicates car problems textually through a message interface that describes the problem at hand. This system is extremely sensitive and can display even minor problems detected that any standard dashboard would definitely not be able to. Finally, the electronic User Manual simply provides fast, efficient searching of what is otherwise a cumbersomely large document. With our keyword searching system, AWARE can direct users to the required section of the user manual much faster than if they manually had to thumb through pages.Let us delve into the specifics of the system now:

20

3.1.2.3 Main Features of AWARE

Maintenance

The main focus of the maintenance section of AWARE is to keep maintenance records and warn users of the periodic scheduled maintenance that is either based on the user’s changeable preferences or default settings. There are two innovative ways the user can change his maintenance settings.

Through the user’s touch screen located on the dashboard Or on his home personal computer, with the information being transferred

to the carputer through a USB storage device

However only minor changes are allowed on the user touch screen such as changing the mileage at which a certain maintenance task is to be performed. For example changing oil changes to be performed at every 10 000 miles instead of every 15 000 miles. It is not advisable for the user to be able make involved changes to the system, as this would take his attention away from the road, which is an unwanted situation. As such the major changes can only be implemented on the user’s PC. This also allows the user to own the information and not the car, thus users can update their maintenance information in the comfort of their homes, at work or even at school. This means that users need not tediously use the touch screen keyboard to enter large amounts of information, and can use the keyboard of their PC instead. The touchscreen LCD means that the user can view the information at a touch of a button, at any time. Whenever a car component is at its scheduled maintenance mileage, a warning goes off and alerts the user. As such the user effortlessly records his maintenance information whenever he or she successfully completes the suggested maintenance. The user can also send the maintenance records directly to GM through the bluetooth wireless located in the carputer, allowing for easy transfer of information between GM (or GM authorized mechanic) and the user.

USB storage device

The USB storage device is key in transferring information form the users PC to the carputer. The user is given it, when he or she buys the car to keep on their keychain. The maintenance records stored in the carputer are transferred to the USB device whenever it syncs with the carputer. The user can then easily hand over the maintenance records to the authorized mechanic either in person or through the Internet form their workplace or home. Alternatively the user can change and record their preferences on his PC and update them when the user synchs the device with the vehicle. The vehicle then updates its records and warns user of next scheduled maintenance.

Problem Detection

The pooling of information form the stored maintenance information the ODB-II diagnostics and the user electronic manual allow for rapid detection of problems. With such breadth of information, the user is given more sophisticated warnings then the traditional ‘check engine’ light. The problem detection system checks and interprets

21

diagnostic signals form the OBD-II interface. Since the OBD-II interface is extensive and connected to almost every component of the vehicle, more then a hundred possible problems can be rapidly detected. Not stopping at that, the problem detection system references both the maintenance records and the user electronic manual to give the user pertinent and useful information along with the severity of the problem, using clearly defined color codes. Thus the user is absolved of the responsibility of trying to figure out what went wrong.

User Manual

The electronic user manual while not designed to replace the standard user manual will display important selective text, taken from the user manual. The user can also search the user text for specific function with the built in search function. With such information at their fingertips, the user can make quick and informed decisions when they are carrying out maintenance tasks or when the problem detection system displays any problems.

Display

The display is color coded to inform the driver the severity of problems detected by the problem detection system and the maintenance intervals. They are displayed on the touch screen in color, with red indicating the most severe, yellow less so and green the least severe rating. Here is a breakdown of each color:

Red: Major car problems or severely overdue maintenance Yellow: Minor car problems or overdue maintenance Green: Reminders for scheduled maintenance

3.1.2.4 Key Design Issues

The AWARE group's project has many functional dependencies on the other GM group's work particularly the GM Position/Location group and the Platform group. In addition, since our software will be used by the end user, who in this case is the driver, we have to work closely with the GM Design group headed by Professor Shelley to ensure it is user friendly and appropriate. The main issues facing us are broken down below in subcategories.

Aesthetic Look and Functionality - this is probably one of the key design issues that we are facing currently in the development of our project. We want to minimize the user inputs in our software so that the user can focus more on driving than on the AWARE program. Instead, we have tried to design it so that the program displays any messages/warnings and the user can use the touch screen to click buttons to bring up menus or reach other features. One of the key design focuses is to minimize the typing by the user and in places where the user may want to enter text. Instead, we are working to use the voice recognition software currently being research by the GM position/location group or the EdgeWrite so that we can develop one standard way of inputting information instead having multiple different forms of input, which would

22

confuse the driver. We will be working closely with the GM position/location group who are currently testing the various input methods using CMU's Sphinx software for voice recognition and the EdgeWrite software. Secondly, the aesthetic look is important to make the program easy to use. The program has to be easy to use and good to look at so that driver can operate the program without dedicating too much attention and focus more on driving instead. We will be working closely with Professor Shelley's GM Design group to create a user-friendly application.

• OBDC II data output-We have currently designed our application to run on simulated data, as the ODBC II is still not installed on the car. However, this should be a relatively straightforward switch over from our test data and to the actual table containing the OBDC II output. This is under the GM Platform group's responsibilities so for the current moment we will have to test our program with our own created test data and only after the ODBC II is installed can we test with real data flow from the car.

• E-manual-We are currently in the process of converting the manual into an electronic form where it is easier for the user to access and in addition we are tagging the user manual pages with keyword so that searching for the relevant manual page is a relatively trivial task for the user.

• Smart Solution Finder-this is going to be one of the key features of our software where our program is able to highlight the most appropriate solution to a problem from a list of possible solutions after taking context into account. This will be done by working in conjunction with GM Position/Location group who will be installing the GPS into the car. We will have figure out a way to download the GPS coordinates into a database and in addition be able to assess whether that coordinate represents a landmark such as a gas station, etc. Using this contextual data, our program will try and come up with an appropriate suggestion to problems by using the contextual information.

• Maintenance Preferences-We have managed to build an maintenance preferences database which will allow the driver to input his initial preferences for maintenance of various components in the car and using these settings, the AWARE program is able to remind the driver when certain maintenances are needed.

These are the main key design issues that we faced during Phase II. Going into Phase III, our efforts are going to be concentrated on working on the Smart Solution Finder, improving the aesthetic looks of the AWARE program, and integration of the program into the car with the other GM groups work.

3.1.2.5 Architecture

Current System Architecture in Vehicles

The figure below shows the current warning system in vehicles. When problems are detected, the check engine light turns on. When the user sees the light on, they have to go through the long process of figuring out what the actual problem is. This is because

23

the check engine can be turned on by a number of problems that vary in severity. The user will have to check their user manual and maintenance records. If they still can’t figure out the problem, they’ll have to bring it into their mechanic.

AWARE System Architecture in GM Vehicles

The figure below shows how the AWARE system will work. When a problem is detected by the ODB-II diagnostics, the system will consult the user manual and maintenance records. It uses this information to display the severity of the problem along with information on problem and how it can be fixed. It will no longer be the responsibility of the user to figure out what went wrong or what the problem is. AWARE will take of it for them.

24

25

Screen Shots

Figure 3.1.2.5(1) Main Page: The main page will show the component and maintenance warnings. User will be able to get information on both warnings. For maintenance warnings, the user will be able to input that the maintenance was completed to make the warning go away.

26

Figure 3.1.2.5(2) Maintenance Preferences: The user will be able to set their preferences for maintenance intervals. The values will initially be set for the manufacturer recommended intervals.

Figure 3.1.2.5(3) E-Manual: The user will be able to search the user manual by keyword and view that information on the touch screen.

3.1.3 Software Infrastructure

27

3.1.3.1 Computing Architecture

The onboard computing is composed of two machines, an IBM Thinkpad T30 laptop, and a custom mini-ITX PC. There are several reasons why the processing on the vehicle is divided over two machines. First, by running two machines, it is possible to maximize OS compatibility for the third party drivers and software used in the project.

3.1.3.2 IBM Thinkpad

This laptop is a standard IBM notebook PC. It has been configured to run Windows XP, and as such, will be running all of the Windows-dependent software. This includes the OBD-II interface and the Bluetooth and 802.11b wireless software. It is connected to the console LCD, so it also acts as the display client for the GM Position Pilot and Music Manager.

3.1.3.2 Mini-ITX

This custom PC has a number of features specifically designed to work in an automotive environment, most of which are discussed in the hardware architecture section of this report. In the future, it might be possible to move all onboard computing to this machine, thereby completely and permanently integrating the system into the vehicle. This machine runs the Debian Linux operating system. As such, it is optimal for remote administration and development. It therefore hosts the MySQL database backbone. Since its display adapter connects to the driver’s side LCD display, it necessarily hosts the GM AWARE client.

3.1.3.3 Database

Linking all of the independent software clients together is a global MySQL 4.1 database. There are several benefits to MySQL that make it particularly suited to this system. First, MySQL is free for non-commercial use. Second, MySQL has support for a wide range of programming languages. Finally, MySQL transactions are performed over TCP sockets meaning that any particular client can be moved between machines with little or no code revision. It also allows direct manipulation of variables, making testing and debugging individual components trivial.

3.1.3.2 OBD-II Interface Daemon

With the introduction of electronic control units on many core components of modern vehicles, and the integration of these units on unified vehicle networks, it is possible for vehicle diagnostics to be encoded and transmitted digitally over a single network. The OBD-II is the standardized interface used to interface to this network, and has been the standard on vehicles since the mid-90s.

28

One of the integral components of the GM AWARE system is the ability to detect specific failures in the vehicle and report them in a functional way to the driver. Utilizing a proprietary OBD-II scan tool that connects to a PC via an RS-232 port, it is possible to directly request error codes from components of the vehicle. This information is then recorded in the database, and interpreted by the GM AWARE client.

3.1.4 Hardware/Power/Display/Platform

This section of the report will describe the over hardware system architecture. In the diagram below, there are six different systems; Embedded PC, Laptop, PDA, GPS, HUD, and two LCDs.

3.1.4.1 Embedded PC

Embedded PC is a Mini-ITX System which is currently running Debian Linux. This system will serve as a database server with MySQL as described in software infrastructure section. This system is responsible for an In Dash LCD. The items installed in this PC are Biostar motherboard where Mobile AMD processor is mounted. There is also a Hitachi 60GB 7200RPM hard-disk which is a laptop hard-disk in a Mini-ITX system. There is more than enough shock resistance built in the Mini-ITX case’s hard-disk mounting slot with rubber and also the laptop hard-disk are more shock resistive than other regular desktop hard-disks. Thus, this will ensure the protection needed for the hard-disk due to the uncertainty of road conditions. Also, RS-232 port in the motherboard is communicating with vehicle’s ECU in the car to analyze the OBD-II codes.

3.1.4.2 Laptop

The laptop is installed with Microsoft Windows XP. This system will communicate with the driver thru the Console touch screen LCD and the HUD (Heads-Up Display). This laptop has many networking capabilities. It has regular wired LAN, Wireless LAN, Bluetooth, and USB, The Wired LAN is used to communicate with the Embedded PC to pull database’s data off and show the result to the driver. On the other hand, the Bluetooth device is used to communicate with the PDA and GPS system. The laptop’s sound system is hooked up with car audio system using a tape converter. The USB port links iPod which is being used in the Music Manager function.

29

3.1.4.3 Power

The major objective of the power group is to implement a subsystem that will provide enough power to run all of the hardware in the vehicle.

We estimated the power consumption of each of the hardware in order to find out how much power is needed to be provided. The table below shows the power consumption of the AC and DC components in our platform.

AC Component DC ComponentIBM ThinkPad T30 40W HUD 110.4WMini-ITX 120W I-Pod 0.06WBluetooth Adapter 0.05W PDA 3.33WWireless Network Adapter 0.05W 2 LCD Monitors 16W

30

GPS Receiver 0.5WAC Consumption 160.1W DC Consumption 130.29

Total Consumption 290.3W

Starting batteries are not intended to be used for deep-cycle operations, and the use of the hardware through the starting battery could wear out the battery fast. However, our entire hardware platform consumes less than 300W, which tells us that we do not necessarily need an additional battery source. Thus, use of another battery would be better, but it would be an option for our hardware platform

The starting battery is a DC power source, thus, in order to power up the AC components in the system, we are going to use a DC/AC inverter. The DC/AC inverter that we are using provides 2000W of power at AC outlet levels. This will provide sufficient power to our platform.

When the vehicle is off in the garage, the battery of the car will be drained off quickly. Therefore, in order to prevent this from happening, the AC components will be plugged into the wall outlet in the garage. The DC components do not use much power, except for the HUD, so they can be remained plugged, but the HUD will be turned off.

3.1.4.4 Display

3.1.4.4.1 LCD

There are two types of display components in our platform. One is LCD touch screen monitor from Xenarc, and another is a HUD unit that was left to us from the previous GM project. We will have two LCD monitors in the platform. One will display the diagnostics of the information such as warnings or the user manual, and the other monitor will display any non-critical information, such as the position/location, or system settings.

The Xenarc LCD monitor is built for the use in automobiles, therefore the unit consumes little power (8W/unit). The 7 inch wide screen with resolution of 800 x 480 provides us a clear display. The LCD will be connected to the computer via standard VGA, therefore anything displayed by the computer will be able to be displayed on the monitor. In addition, the touch screen will enable to the drivers to control the systems of the vehicle more easily.

3.1.4.4.2 HUD

The head up display will display any critical information of the vehicle with color codes. It will be able to provide important information without drawing too much attention to the drivers.

The HUD system consists of two main components: the projector unit and the combiner. The projector will be mounted on the ceiling of the vehicle and will display the output towards the windshield. The combiner will be attached to the windshield, and the image that is produced by the HUD will be reflected off of the combiner so that the driver could see the information.

31

The HUD system that we have from the previous GM project is the Datavision 110, manufactured by Delco. It has a resolution of 234 x 382, and it is capable of displaying full-motion video and is legible in the daytime sun. However, the technology of the product is quite old, and it consumes too much power for a display system (110.4W)

32

33

4. Worklog Analysis

Here is a tabulation of the total time spent on the different activities by the different groups during phase II.

Activity/Group AWARE Software Infrastructure

Position Pilot and Music Manager

HW/platform/display

Administrative Tasks

26.5 hours - 5 hours 4.5 hours

Meetings 27.5 hours 4 hours 17.5 hours 12 hoursClass 26.5 hours 10 hours 40.5 hours 37.5 hours

Research 14 hours 2 hours 59 hours 13.5 hoursWriting Reports / Presentations

42 hours 2 hours 34 hours 26 hours

Field Testing - 2 hours 11 hours 7.5 hoursCoding 101 hours 4 hours 15 hours -

The graph below shows that the groups consistently spent the most amount of time in class and in meetings. Most of our time was spent delegating work and planning the implementation of the different components. Also the AWARE group did a large amount of coding, as the group could not use any preexisting code and had to implement the maintenance logging and problem detection systems form starch. But in doing so the group members learnt more about the design through the actual implementation A large amount of time was also spent by the Position Pilot and Music Manager group as they had to look into using preexisting code and altering it for our use. Due to the nature of the large project, a significant time was also spent on presentations and writhing reports. This is expected, as documentation is important and essential in a large distributed project with many members undertaking different tasks

34

5.Timeline

At the start of this phase II, each group came up with a timeline to better coordinate each member’s efforts and outline clear objectives that were to be met at the end of the phase. Here below is an integrated timeline from all the groups.

02/28~03/06 03/07~03/13 03/14~03/20 03/21~03/27 03/23 03/28~04/03

AWARE

Start building communication interface

Spring Break

Communication interface with DB completed

Prototype of Maintenance working

Simple Working Demo of User Manual (no GUI)

Phase II Presentation

Music Selection

Contact Prof. Goto & Birmingham – ‘humming software’

Learn use of Sphinx & use to incorporate voice recognition

Order microphone Explorer

EdgeWrite

Check status of melody selection software

Sphinx working on computer

EdgeWrite working Start writing Java

program for string matching

Demo current prototype EdgeWrite working on

touch screen Start integrating iTunes

Integrate voice activation button

Finish Java program Work on music

playback for multiple results

Traffic / GPS

Order WorldNavigator Bundle & License

Install software & connect to internet

Start working on functionality

Demo current setup on computer

Finish traffic detection on any platform

Have traffic detection & GPS working on PDA

Work on Car Locator

HW / Power / Display

Order Computer Parts & Case

Received ordered parts Build Computer

Debug hardware Install OS on Mini-ITX

Install Bluetooth & Wireless LAN

Install HUDs

Software

Design software architecture

Divide processes over machines

Implement database, assist in database use

Install OS on Mini-ITX Move database onto

Mini-ITX

Configure GUI for machines

Begin moving software clients onto vehicle hardware

35