Rapid Prototyping by ee3kYaGM


									             Rapid Prototyping
          Of Computer Systems:
                GM/CMU Car

             PHASE II REPORT

                School of Design
                Robotics Institute
           School of Computer Science
     Human - Computer Interaction Institute
Department of Electrical and Computer Engineering

             Carnegie Mellon University
           Pittsburgh, Pennsylvania 15213

                   April 1st 2005

                              PROJECT PARTICIPANTS
This 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).

Nikhil 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 Staff
                                 Matthew Rogers (ECE)

                                   Faculty Advisors
Dan Siewiorek (HCI)                  Asim Smailagic (ICES)

                                    Editorial Board
Srikanth 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)

                                       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 Frankiewicz
Aya Horiguchi                        Karen Wong

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

                           Table of Contents
1. Introduction
      1.1 Purpose
      1.2 Background Of Phase II
      1.3 Aims of the project
2. Visionary Scenario
      2.1 Purpose
      2.2 Visionary Scenario
3. Key System Requirements
      3.1 Introduction
               3.1.1 Position Pilot and Music Manager
               Functionality Position Pilot
               Music Manager
               User Studies Plans Music Manager
               Screen dumps
               Hardware / Software Architecture Position Pilot
               Software Module and Status Position Pilot
               3.1.2 AWARE
               Main Features of AWARE
               Key Design Issues
               3.1.3 Software Infrastructure
               Computing Architecture
               IBM Thinkpad
               OBD-II Interface Daemon
               3.1.4 Hardware/Power/Display/Platform
               Embedded PC
4. Worklog Analysis
5. Timeline
6. Task Dependencies
7. Conclusion

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
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

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

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

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 Functionality Position Pilot

         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. 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. 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

    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. Screen dumps

Position Pilot

Figure 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

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

Figure 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.

Music Manager

                                                                  (Voice 

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

Figure Overview of the music selection process by speech.

Figure Sphinx Client

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


Figure Overview of the music selection process by edge write.

Figure Edge Write

                                                              Position Pilot & Music Manager
Figure iTunes Script Hardware / Software Architecture Position Pilot

Figure Bluetooth enabled GPS receiver. It is connected to the PDA through
Bluetooth technology.

Figure 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.

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

Music Manager

                       Sphinx             iTunes             iTunes
            Voice                         Script                         Music

Figure Software architecture of music selection by speech.

Figure Software architecture of music selection by edge write Software Module and Status Position Pilot
The two main software for Position Pilot are the GPS navigation software and car locator
Module              Description                                     Status
GPS Navigation      This is responsible for providing navigation Works
                    of the vehicle, such as providing faster route
                    to a desired destination taking traffic into
Car locator         This will provide the driver with direction     Software for
                    to get the current location of the car from     calculating the
                    the driver’s current location. GPS              distance and
                    Navigation feature can be used for map          direction to the
                    displayed direction. Otherwise, the driver      car need to be
                    may also follow speech output commands.         written. This will
                                                                    also provide
                                                                    speech output

Music Manager
For music selection by voice command, two software modules are used: Sphinx client
and iTunes script
Module               Description                                   Status
Sphinx client        Takes in voice command (song title), match Currently it only
                     the song title in the database and pass the   works if the user
                     song title(s) that best match the command to says the whole
                     the iTunes script module.                     song title.
iTunes script        Takes in part of the song title and find the  Works fully.
(make use of         song title(s) that match the input and return
iTunes COM           a list of matching titles and play the best
Windows SDK)         match in iTunes.

EdgeWrite Driver     Sets up the parameters necessary to start       Acquired the dll.
                     recognizing characters. Then converts           Need to write an
                     scrawled letter(s) to text.                     application for the
                                                                     touch screen
Song title           Takes the text input from Edgewrite and         Reuse iTunes
completion Script    find a match in the playlist which is then      script with a few
                     sent to the iTunes script file.                 modifications

                                    3.1.2 AWARE 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. 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:

                                            17 Main Features of AWARE


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

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.


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 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

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

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. 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

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.

                                     Screen Shots

Figure 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.

Figure 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 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 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. 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. 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. 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. 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.

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. 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. 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.

                                             26 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 Component
IBM ThinkPad T30            40W             HUD                   110.4W
Mini-ITX                    120W            I-Pod                 0.06W
Bluetooth Adapter           0.05W           PDA                   3.33W
Wireless Network Adapter    0.05W           2 LCD Monitors        16W

                                              GPS Receiver           0.5W
AC 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. Display 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. 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

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.

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)

                                 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              Position Pilot and   HW/platform/display
                                           Infrastructure        Music Manager
Administrative       26.5 hours                     -            5 hours              4.5 hours
Meetings             27.5 hours            4 hours               17.5 hours           12 hours
Class                26.5 hours            10 hours              40.5 hours           37.5 hours

Research             14 hours              2 hours               59 hours             13.5 hours
Writing Reports /    42 hours              2 hours               34 hours             26 hours
Field Testing                -             2 hours               11 hours             7.5 hours
Coding               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
                                                                                  Field Testing
                                                                                  Writing Reports /
          60%                                                                     Presentations


           0%                                                                     Class
                    AWARE       Software       HW           Position

                                                                                  Administrative Tasks

                 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/14~03/20                    03/21~03/27                03/23            03/28~04/03
               Start building                      Communication                 Prototype of
                communication                        interface with DB              Maintenance working
AWARE           interface                            completed                     Simple Working Demo
                                                                                    of User Manual (no
               Contact Prof. Goto                  Check status of melody        Demo current prototype                       Integrate voice
                & Birmingham –                       selection software            EdgeWrite working on                          activation button
                ‘humming                            Sphinx working on              touch screen                                 Finish Java program
                software’                            computer                      Start integrating iTunes                     Work on music
               Learn use of                        EdgeWrite working                                                            playback for
                Sphinx & use to                     Start writing Java                                                           multiple results
                incorporate voice                    program for string
                recognition                          matching
               Order microphone
               Explorer             Spring                                                                      Phase II
               Order
                                     Break          Install software &            Demo current setup on
                                                                                                               Presentation      Have traffic
                WorldNavigator                       connect to internet            computer                                      detection & GPS
Traffic /
                Bundle & License                    Start working on              Finish traffic detection                      working on PDA
                                                     functionality                  on any platform                              Work on Car
 HW /          Order Computer                      Received ordered parts        Debug hardware                               Install Bluetooth &
Power /         Parts & Case                        Build Computer                Install OS on Mini-ITX                        Wireless LAN
Display                                                                                                                          Install HUDs
               Design software                     Implement database,           Install OS on Mini-ITX                       Configure GUI for
                architecture                         assist in database use        Move database onto                            machines
               Divide processes                                                    Mini-ITX                                     Begin moving
                over machines                                                                                                     software clients
                                                                                                                                  onto vehicle


To top