Rapid Prototyping
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).
STUDENTS
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
And
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
3.1.1.1 Functionality Position Pilot
3.1.1.2 Music Manager
3.1.1.3 User Studies Plans Music Manager
3.1.1.4 Screen dumps
3.1.1.5 Hardware / Software Architecture Position Pilot
3.1.1.6 Software Module and Status Position Pilot
3.1.2 AWARE
3.1.2.1 Background
3.1.2.2 Introduction
3.1.2.3 Main Features of AWARE
3.1.2.4 Key Design Issues
3.1.2.5 Architecture
3.1.3 Software Infrastructure
3.1.3.1 Computing Architecture
3.1.3.2 IBM Thinkpad
3.1.3.2 Mini-ITX
3.1.3.3 Database
3.1.3.2 OBD-II Interface Daemon
3.1.4 Hardware/Power/Display/Platform
3.1.4.1 Embedded PC
3.1.4.2 Laptop
3.1.4.3 Power
3.1.4.4 Display
3.1.4.4.1 LCD
3.1.4.4.2 HUD
4. Worklog Analysis
5. Timeline
6. Task Dependencies
7. Conclusion
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 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 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
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.
■ 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
[pic]
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)
[pic]
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.
[pic]
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.
Music Manager
[pic]
Figure 3.1.1.4(4) Overview of the music selection process by speech.
[pic]
Figure 3.1.1.4(5) Sphinx Client
[pic]
Figure 3.1.1.4(6) Overview of the music selection process by edge write.
[pic]
Figure 3.1.1.4(7) Edge Write
[pic]
Figure 3.1.1.4(8) iTunes Script
3.1.1.5 Hardware / Software Architecture Position Pilot
[pic]
Figure 3.1.1.5(1) Bluetooth enabled GPS receiver. It is connected to the PDA through Bluetooth technology.
[pic]
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.
[pic]
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
[pic]
Figure 3.1.1.4(4) Software architecture of music selection by speech.
[pic]
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 |Status |
|GPS Navigation |This is responsible for providing navigation of the vehicle, such |Works |
| |as providing faster route to a desired destination taking traffic | |
| |into consideration. | |
|Car locator |This will provide the driver with direction to get the current |Software for calculating the |
| |location of the car from the driver’s current location. GPS |distance and direction to the|
| |Navigation feature can be used for map displayed direction. |car need to be written. This |
| |Otherwise, the driver may also follow speech output commands. |will also provide speech |
| | |output commands |
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 the song title in the |Currently it only works if |
| |database and pass the song title(s) that best match the command to|the user says the whole song |
| |the iTunes script module. |title. |
|iTunes script (make use of |Takes in part of the song title and find the song title(s) that |Works fully. |
|iTunes COM Windows SDK) |match the input and return a list of matching titles and play the | |
| |best match in iTunes. | |
|EdgeWrite Driver |Sets up the parameters necessary to start recognizing characters. |Acquired the dll. Need to |
| |Then converts scrawled letter(s) to text. |write an application for the |
| | |touch screen |
|Song title completion Script |Takes the text input from Edgewrite and find a match in the |Reuse iTunes script with a |
| |playlist which is then sent to the iTunes script file. |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 dashboardhat standard m '.atabase was created so that we can demonstrate dard 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:[pic][pic]
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 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 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 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.
[pic]
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.
[pic]
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.
[pic]
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.
[pic]
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.
[pic]
3.1.3 Software Infrastructure
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.
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.
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 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.
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.
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 Infrastructure |Position Pilot and Music |HW/platform/display |
| | | |Manager | |
|Administrative Tasks |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 |
|Presentations | | | | |
|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
[pic]
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 |Spring Break |Communication interface with |Prototype of Maintenance |Phase II Presentation | |
| |communication interface | |DB completed |working | | |
| | | | |Simple Working Demo of User | | |
| | | | |Manual (no GUI) | | |
|Music |Contact Prof. Goto & | |Check status of melody |Demo current prototype | |Integrate voice activation|
|Selection |Birmingham – ‘humming | |selection software |EdgeWrite working on touch | |button |
| |software’ | |Sphinx working on computer |screen | |Finish Java program |
| |Learn use of Sphinx & use| |EdgeWrite working |Start integrating iTunes | |Work on music playback for|
| |to incorporate voice | |Start writing Java program for| | |multiple results |
| |recognition | |string matching | | | |
| |Order microphone | | | | | |
| |Explorer EdgeWrite | | | | | |
|Traffic / GPS |Order WorldNavigator | |Install software & connect to |Demo current setup on computer| |Have traffic detection & |
| |Bundle & License | |internet |Finish traffic detection on | |GPS working on PDA |
| | | |Start working on functionality|any platform | |Work on Car Locator |
|HW / Power / |Order Computer Parts & | |Received ordered parts |Debug hardware | |Install Bluetooth & |
|Display |Case | |Build Computer |Install OS on Mini-ITX | |Wireless LAN |
| | | | | | |Install HUDs |
|Software |Design software | |Implement database, assist in |Install OS on Mini-ITX | |Configure GUI for machines|
| |architecture | |database use |Move database onto Mini-ITX | |Begin moving software |
| |Divide processes over | | | | |clients onto vehicle |
| |machines | | | | |hardware |
[pic]
-----------------------
Speech
Sphinx
(Voice ( text)
Script
(Part of Song title ( Play Selected Song in iTunes)
Car
Speakers
Car
Speakers
Script
(Part of Song title ( Play Selected Song in iTunes)
Position Pilot & Music Manager
Sphinx
iTunes Script
iTunes
Voice
Song
Title
Music
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.