Rapid Prototyping of Computer Systems GMCMU Car

Rapid Prototyping of Computer Systems: GM/CMU Car PHASE 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 February 18, 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) Chun-Yi Dukkyoo Kim (SCS) Sonali Chen (Design) Venkatesh Shankar (ECE) Nath (ECE) Gregor Kronenberger (INI) Michael Walch (ECE) Taesang Kim Karen Lee (ECE) Kietae Park (ECE) Prasanna Velagapudi (SCS) (ECE) Teaching Staf Matthew Rogers (ECE) Faculty Advisors Dan Siewiorek (HCI) Asim Smailagic (ICES) Editorial Board Nikhil Gadia (Chief Editor and HCI Group Editor) Stephen Fabrey (Infrastructure Hardware/Software Group Editor) Yong Hoon Lee (Wireless Group Editor) Prasanna Velagapudi (Audio/Visual 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 Frankiewicz Aya Horiguchi Karen Wong Susan Table of Contents Introduction – HCI Group Background Overview 2.1 Product definition 2.2 Product development methodology Design Principles………… Features……………… 4.1 Background………………… 4.2 Digital Assistant 4.3 Key’s Function 4.4 Communication Control Input/Output… 10 System Architecture……… 12 Visionary Scenario 13 Onstar vs Visionary Scenario Feature Comparison 15 Audio/Visual Visual/Audio Overview………………………………… 16 9.1 Visual Interfaces… ………… 16 9.2 Audio Interfaces 16 9.3 Camera……… 16 10 Technology Survey……………………………………… 17 11 Product Design Specifications… …………………… 18 11.1 HUD… ………… 18 11.2 In-Dash LCD 18 11.3 Center Console LCD 19 11.4 Microphone…… ………… 19 11.5 Tape Adapter 19 11.6 Web Cameras 19 12 Dependencies…… ……………………………………… 20 13 Architecture……… ……………………………………… 21 Infrastructure HW/SW 14 Development Environment………………… ………… 22 15 Laptop ……………………………………… 23 16 Desktop… ………… ……… 23 17 Services… ………… ……… 23 18 OBDII…….…… …………………………… 24 19 PCI Devices….… ……………………………………… 24 Wireless Group 20 Wireless/Communications………………… ………… 25 21 Technology Survey ……………………………………… 25 22 Dependencies… … ……… 27 Appendix A HCI Group’s Work Logs………………………………… …………………… 28 B Visual/Audio Group’s Work Logs….…………………………………… …… 29 C HW/SW Group’s Work Logs…………………………………………………… 30 Introduction Background The Spring 2005 Rapid Prototyping class is working in conjunction with General Motors group to design and develop a prototype of a car that enriches the driving experience This class is divided into three phases of which the first phase is nearing its end spanning from mid-January to mid-February The purpose of the first phase was to brainstorm and design innovative ideas that could be potentially prototyped in the remaining two phases of the class Students were split into groups depending on their interest and discipline: human-computer interaction (HCI), infrastructure hardware/software, wireless communications, and audio/visual groups The HCI group led the way in brainstorming, discussing, and formulating new ways to create a great car This resulted in the creation of a visionary scenario which enabled the remaining groups to go out and research the availability and feasibility of functionalities demonstrated in the visionary scenario The results of this phase are summarized in this report We will be using these results in guiding us in creating a feasible prototype as the project continues by the end of the semester The report begins by discussing the underlying principles that guided car’s features, functionality, and interface Phase I has allowed us to gain tremendous insight into the needs and limitations of the drivers through our discussions with the GM group and our own brainstorming sessions We have included a listing of the features and human computer interaction conventions that will be used to develop a prototype of the car Subsequently, the report will go provide detailed explanation of the software architecture and of the software components that will be created Lastly, we will explain the hardware specifications and some of the limitations that we will face in order to create a successful prototype Overview 2.1 Product Definition The GM car will be designed to make driving a more useful, entertaining, and safer experience It will link information from several sources which include: the driver’s life, his/her current environment, the Internet, entertainment media, and more In addition, the car will be designed to fit the user types and needs researched by the GM group particularly, but not limited too, the female driver By taking into account the driver’s preferences, limitations of attention whilst driving, and through the use of features such as speech recognition, the driver can take advantage of the car’s features without comprising his/her attention and hence safety The main theme that has been chosen for the car is “ a personalized car that responds to its environment” and we will try and design the car to achieve this goal to the fullest extent possible given budgetary and time constraints 2.2 Product Development Methodology The HCI group began this process by reviewing the research done by the GM group over the last couple of semesters regarding the needs and wants of a female driver Subsequently, the HCI group began brainstorming ideas, both individually and in a group discussion format In the brainstorming process, very little consideration was given to the feasibility We instead tried to come up with ideas that each of us thought would be needed in the car to create the “ideal car” From these ideas, we chose to categorize them into main areas that we hoped to address in our design process and in addition drop ideas that were too far reaching The areas that we managed to categorize them into were: GPS, iPOD/PDA/USB, Physical Design, Maintenance and Information, Voice Activated devices, and Driving Control These ideas were then used to generate a visionary scenario that was presented to the class Using the feedback from the class as well as the GM group, we fine tuned our visionary scenario to include only ideas that were necessary and fit our budged and time constraints This lead to our ideas being clustered into three main areas of: Digital Assistant, Key’s Funtion, and Communication Control We will go into more detail later on in the report regarding these areas Subsequently, the Audio/Visual, Infrastructure Hardware/Software, and Wireless groups presented ways in which the ideas in the visionary scenario can be implemented The results of their research will be presented later in the report Our designs and research accommodated for the exploratory work done by students in the past for the GM project in 2001 Design Principles When determining what features to provide drivers with, it is critical for us to keep the design principles in mind Below is a list of design principles that we follow:  Avoid having functionality that can be purchased directly from the market Instead, it would be fine to purchase a product and build more new functionalities on top of it  Demonstrate at least the initial functionality For example, voice recognition can be used for unlocking the door, selecting a song, etc Due to time constraint, supporting one voice command feature will represent the voice recognition idea  Emulate functionality if real-time information inaccessible For example, if the car bus is not accessible, the idea of remote start can be emulated by, say, lighting up a bulb in the car remotely  If complete functionality cannot be implemented, demonstrate limited functionality from which GM can then carry on what we started  Focus on infrastructure that is common to several functions  Do not modify the car itself For example, not drill holes  Try to make systems portable to other vehicles Features 4.1 Background Our features are clustered into three main categories: Digital Assistant, Communication Control and Key’s Functions, with each category building upon the design principles outlined above The main goal is to cater to the user’s needs by adapting and anticipating, form proactive suggestions to preprogrammed settings; the car becomes the ultimate experience for the driver 4.2 Digital Assistant Carrie, the digital assistant is the ‘butler’ of the car: always there for the driver With voice recognition for voice commands, Carrie helps the driver navigate through traffic with proactive suggestions by an active GPS system with up to date traffic information Pooling resources such as the PDA, iPod, cell phone, the Internet, GPS and onboard diagnostic and blind spot sensors, Carrie is immediately ready for the user, whether it is to avoid heavy traffic, taking down voice notes or listening to his or her favorite song Carrie also anticipates the user’s future tasks For example, Carrie would look into the user’s PDA for the appointment list and plot the fastest route, taking into consideration whether the user is late Carrie could also look into the user’s "to do" list and remind him or her For example if ‘get bagels’ were on the list, Carrie would give a reminder when the car passes a bagel shop Another example might be that the driver might be low on gas, and Carrie noting gas is low, charts the fastest route to the nearest gas station, reachable with the remaining gas Or if there is something else wrong with the car, such as radiator fluid problems, Carrie would plot a course to the nearest authorized dealer or gas station Having engine trouble is a thing of the past With onboard audio sensors, troubling diagnostic noises can be recorded for playback to the dealer Oops can’t go to the dealer? Have something important to do? Don’t worry, the driver can record and transmit performance and safety statistics, with the audio recordings to the dealer from his or her car With manual information pertaining to the problem automatically brought up to the main user’s touch screen display, the driver can set his mind at ease With such a clear and easy to use documentation system, waiting at the side of the road for assistance is a thing of the past 4.3 Key’s Functions Away form sight doesn’t have to mean away from mind The key can show the driver the parked location of the car, using a GPS generated map, especially when he or she can’t is in a crowded car park and can’t find the car The car immediately unlocks when the user gets near, godsend when hands are full of groceries The car also locks up when you leave it, so you don’t have to strain to remember if you forgot to lock it when you left it With Driver Id, the car immediately reverts to the driver’s preprogrammed settings, such as radio, temperature and seat lengths, when he or she enters the car 4.4 Communication Control With email and Internet merely at the touch of the button away, the user remains connected to the outside world Carrie brings up important emails and cell phone calls allowing the user to get vital information quickly Also the driver can access the Internet through his touch screen display, nifty when he or she wants to get the latest sports news or current information on his destination Also, as stated above, diagnostic information is sent through the Internet to the dealer, the user is constant contact with the dealer and gets vital for that application were far less stringent, the same products were deemed more than adequate for the new application 10 Technology Survey The V/A group identified several technologies which we found addressed our interface needs quite readily LCD technology was found to be versatile and cheap, and thus formed the backbone of our display technology In accordance with the visionary scenario, we searched for a HUD unit, but eventually settled on a projection unit left from a previous GM project For our audio needs, we considered several possibilities for playing sounds in the vehicle, including a tape converter and an external amplifier However, we quickly settled on the tape converter, and since most are similarly designed and priced, extensive research was unnecessary We also analyzed several microphones to determine which would work best in an automotive environment The specifications for our cameras suggested that USB webcam devices would work well in our scenario, so we focused our product research around them LCD Touch Screen ? VGA ? Scree n Size Dimensions Cos t $40 Remarks Xenarc 700TS TFT LCD w/VGA Touchscreen Yes Yes 7” 7.75”W x 4.75”H x 1.38”D Lilliput 7” VGA Touchscreen Yes Yes 7” 7.36”W x 4.92”H x 1.30”D $27 $40 $49 Too big for console $84 Too expensive; DVD player not needed; No VGA Xenarc 700Y 7’’ TFT LCD Monitor with VGA No Yes 7” 7.75”W x 4.75”H x 1.38”D Xenarc 800TSV 8" TFT LCD w/Touchscreen Yes Yes 8” 9”W x 6.5”H x 1.6”D Pioneer 6.5" LCD Touchscreen w/DVD Player No No 6.5” 7.25"W x 4.5"H x 1.3"D First choice for touchscre en Second choice for touchscre en First choice for nontouchscre en Xenarc 700V 7" TFT LCD Monitor No No 7” 7.75"W x 4.75"H x 1.38"D $32 No VGA Microphones Sennheiser PC130 Headset Plantronics AUDIO10 PC Microphone Web Cams Labtec WebCam Pro CP Technologies USB Mini PC Web FlexCam Frequency Response Noise Canceling Cost Remarks 30Hz-18kHz Yes $29.99 High quality, but expensive unknown Yes $8.78 First choice Video Resolution (pixels) Capture Speed (fps) Cost Remarks 640x480 30 $29.99 First Choice 352x288 30 $21.76 QuickCam Orbit Webcam 640 x 480 30 $129.99 QuickCam Pro 4000 WebCam 640 x 480 30 $99.99 Extremely small; video resolution not as good Camera view can be adjusted; very expensive High Quality but too expensive 11 Product Design Specification 11.1 HUD The selected HUD was simply the system used in 2001 by a previous GM project Since commercial HUDs were still relatively difficult to locate, being superseded by the proprietary automotive markets, the V/A group decided that the best strategy was to reuse the older model 11.2 In-Dash LCD To compensate for the lack of information that could be feasibly displayed on the HUD unit, an LCD unit was chosen for mounting over the dashboard instrument cluster Since the unit is in an inaccessible location, a touch screen interface was unnecessary Therefore, an LCD was simply selected for low power consumption, high resolution, and small size The information displayed on this unit will be driven primarily by real-time events in the vehicle filtered such that only highpriority data is relayed From our technology survey, we elected to use the Xenarc 700Y LCD display Not only was this one of the smallest VGA displays we found, making it ideal for dash mounting, but it also had the advantage of being recently certified as an automotive component This assured us that the Xenarc would be ideal in an automotive environment 11.3 Center Console LCD Since this unit would be the primary mode of interaction for the driver into the system, it was necessarily chosen to be a touch screen The final product was selected based on low power consumption, maximum cross-OS compatibility for the touch screen interface, high resolution, and price The user would use this screen to configure all other aspects of the system, including the other screens, as well as to access non-essential or non-real-time information from the database In light of this, we elected to use the touch-screen version of our in-dash LCD display, the Xenarc 700TS Since we were physically limited in mounting size by the dimensions of the radio receiver we planned to supplant, we required a similar size display for the dash and the console Thus, the Xenarc series was once again, a natural choice 11.4 Microphone For the voice recognition components of the system, it was necessary to identify a microphone that could record the driver’s voice usably Due to the noisy environment of the vehicle, a noise canceling model was chosen While the exact mounting point is dependent on the exact geometry of the vehicle, the most likely mounting location is on the vehicle’s driver’s side A-pillar 11.5 Tape Adapter The system required audio output to alert the driver of time-critical events Since this system is a prototype, however, it was deemed unnecessary to modify the existing audio receiver in the vehicle To interface with the existing audio system, an inexpensive tape adapter was selected that would take the line-level output from the computer and convert it to simulated magnetic media for the existing vehicle receiver This approach was minimally invasive to the vehicle, and was similar in quality to a replacement audio system The actual model of the tape adapter is, as of yet, undetermined, although most commercial products are nearly identical in quality and readily available 11.6 Web Cameras Although it remains to be determined where and when these cameras will be used, we have selected a model that we believe is best suited to this application Our primary concern was adequate resolution, since there was originally the possibility of a facial recognition component However, since the Labtec component we selected was also reasonably priced, we maintain this choice for the other applications in the vehicle 12 Dependencies In contrast to the other groups, the V/A interfaces were primarily dependent on the HCI visionary scenario The products selected during the technology survey were specifically selected to minimize hardware dependencies by providing the most generic interfaces possible to the other components However, the decision of which products to use was primarily based on the information that the HCI group needed to convey In the end, a three display system was chosen, which partitioned the displayed information by detail and criticality In terms of visual display devices, the group has three different types of display – a heads up display (HUD), a touch screen display and an In-Dash display As the software group has not decided on the OS they will be using, we chose displays that work with both Windows and Linux operating systems Another dependency concerning the displays is the actual size and dimension We were uncertain about what size display would fit best in the in-dash area, during the non-rectangular shape of the dash We used cardboard cutouts to determine which displays would fit Furthermore, as plan to use the HUD from a previous project, we have to determine the interfaces and capabilities of the previous unit There is still an issue of how much power will these displays use—it may be necessary to switch of the touch screen at some times, and so forth However, even with three displays, power consumption is overshadowed by the projected power costs of the onboard computing The noise canceling microphone will have relatively few dependencies Virtually all consumer microphones use one of two interfaces: USB or unbalanced microphone signals Since our computers had both available, any commercial product was viable Microphones power consumption is also negligible and should therefore not be an issue The group has decided to use the existing speakers already present in the vehicle Doing so will solve the placement and location issues associated with using an external amplifier and speakers As we are not using an amplifier, our power consumption is further minimized However, we have yet to locate the specific cassette adapter we will be using Also, there are some concerns about the quality of music playback using this technique There are still location issues with the cameras that the group is installing for blind spot detection It is undecided whether they would be mounted on the top, at the rear, or elsewhere in or on the vehicle Power consumption of these cameras has also not been calculated as yet, although it is expected to be relatively low 13 Architecture The V/A units used very common hardware interfaces for all inputs and outputs Therefore, most of the relevant architecture was simply necessitated by commercial standards for data communications The following is an architecture diagram of the hardware system, reduced to only the display components, and their approximate locations in the vehicle The laptop handles most of the interface functionality, controlling the HUD and the touch screen It also handles audio IO in the system, connecting both to the microphone and to the tape converted through its integrated sound card The embedded PC handles the remaining dash display and the camera(s) onboard the vehicle, using its video card and USB bus Both systems are only lightly loaded by the display components they support, and, in the case of unforeseen problems, the common interfaces between the units allow for interchangeability between the two computer systems Infrastructure – HW/SW 14 Development Environment Considering the many devices and services that could possibly need to be implemented, choosing the proper development environment is clutch We investigated MAC OS X as well as Linux and Windows environments The need to handle a vast array of devices led us to decide on using a small form factor desktop Since we were already given a laptop, it is possible to use two systems The desktop will run Linux for stability, and the laptop will run Windows for proprietary software and devices The computers will communicate via Ethernet, so devices may be connected to each system as necessary The current hardware diagram is: 15 Laptop The laptop that was provided will be used to run the user interface and any devices needing proprietary Windows interfaces Components that will be run by the laptop are the touch screen, GPRS interface, and sound card The laptop runs a web browser to display data from the desktop 16 Desktop Configuring and running background services for Carrie is best implemented in a Linux environment In order to power an ATX computer, a DC-DC power supply will be much more efficient than converting the car's battery power to AC, then back to DC Several options exist to regulate the battery power so it is suitable for use by an ATX board Stand alone options are listed in the table below: Watts Size Fan Ignition Input HDD 2nd HDD PIII/P4 Cost Mini-box.com PW-200-M w/ITPS Mini-box.com PW-80 MiniBox.com M1ATX Powerst ream.com PST-ITX-2 Orbitmicro.com KPDX250H 200 small pieces N Y 12-20V Y Y Y $89.00 80 106 x 57 mm N N 11-30V Y Maybe 90 161 x 45 mm N Y 6-30V Y 3A limit Y $79.95 80 126x57x26 mm N N 10.8-20V Y Maybe 250 150x86x142 mm Y N 9-18V Y Y Y $179.00 $59 $58.50 Another option is an integrated DC-DC power supply in the case This simplifies construction of the desktop and configuration in the vehicle The case from opussolutions.com is similar to the first option in the table built in to a reinforced case for vibration prone environments 17 Services The web server and database will be run from the desktop computer running Linux The desktop also provides for the use of PCI add-on cards The PCI cards will include a video card for the supplementary displays, and an 802.11b/g wireless card Using an ATX system ensures plenty of USB ports for all the mobile devices Most importantly, the desktop's serial interface will be connected to the car through the OBDII interface 18 OBDII Car's problems are expressed through OBDII Instead of flashing a warning light like the dashboard, OBDII describes the problem very specifically Using the problem code from the OBDII interface, a daemon running on the desktop looks up the problem in the database and displays the detailed description on the web server 19 PCI devices The 802.11b/g standard will be used to communicate to wireless devices such as PDAs It may also connect to the internet while on campus This may be used to demonstrate concepts that could later be implemented with a wide area wireless connection PCI slots can also be utilized for capturing data Either a video capture card with a camera or a DAQ for sensors can aid with parking A PCI card can also be used to expand the ports if there are devices that require additional inputs Due to the necessary three displays, an additional video card will also be added to the desktop A dual output card ensures the computer can drive two different screens, while the laptop runs the touchscreen Wireless technologies 20 Wireless / Communications Our group joined together to visualize possible applications of wireless devices that can be implemented on the prototype and brainstormed for ideas that can be related to wireless communications As to not limit ourselves to technology availability or capabilities we envisioned applications that may be possible to be implemented or be modified for simplification We came up with the following chart of applications after several brainstorming sessions Key applications Remote Starter Car -> Wireless device Alarm Report Between cars Status Report Wireless Dev -> Car Online Traffic & navigation Internet access Passive Keyless entry system Temperature and personalized settings Car Finder Streaming video to wireless device Entertainment, gaming Collision Prevention Onboard internet access Mass Storage Device Networking between vehicles Remote Navigation Auto Navigation After group leaders’ discussions and capabilities research we came up with a visionary scenario that incorporates some of these features while some applications were dropped or be proposed as an additional add-on for future implementations 21 Technology Survey First, we proceeded to produce a comparison matrix of several technologies we will use and require for communications Key features RFID (used in present) Internet access Cell phone (low bandwidth but broad coverage) On board computing Laptop (light, portable and enough processing power) Collision prevention Radar Based (too complicated and expensive with broad capabilities) Cell phone (need to be implemented) WLAN (802.11g provides best bandwidth but very limited coverage) Mini desktop (best in processing power and storage but power hungry) Sensor Based (implemented by parking sensors) Bluetooth (good bandwidth but too limited coverage) PDA (pocket size, limited processing power) Positioning system (vehicles communicating each other with position information) After discussions, we decided that we should implement key features by integrating passive RFID technology rather than cell phone based due to lack of benefits compared to the amount of work required to implement the applications Passive RFID technology is based on the normal RFID technology but improved for passive entry, no button required for entry Although it is fairly new technology it is already implemented in buildings and cars and there are some products available on the market as shown below For internet access we searched for wireless connections through cell phones via GPRS or CDMA 3G networks offered nationwide by commercial carriers Also for wider bandwidth we plan on implementing WLAN internet access as the prototype can have access to the wireless LAN capabilities offered by Carnegie Mellon WLAN is being offered by several commercial carriers also so that it is very important for high bandwidth and heavy traffic communications As WLAN is the best choice we also have the possibility to offer internet connectivity by Bluetooth but it isn’t the best choice due to the lack of infrastructure and commercialization On board computing is required to process data coming from the car as well as running applications such as traffic reports or navigation systems Collision Prevention issues many problems related to benefits versus cost, developing time and part cost Radar based technologies can be very accurate but have many problems regarding small scale radars (radars usually have coverage of several miles) Sensor based collision preventions may be implemented as driving guides so that we can place object sensors as blind spot detection systems or parking guides Positioning is partially already implemented by GPS systems which we will integrate with a PDA or laptop based computing center to provide online traffic reports and advanced positioning capabilities 22 Dependencies Some of our applications were included in the visionary scenario, slightly modified in some aspects that helped shape the specific applications to be implemented In order to maintain simplicity we chose to incorporate available technologies and standards to perform many of the applications Internet connectivity should be provided by network carriers either by WLAN or cell phone based Positioning should be based on GPS technology and software including maps and online traffic report APPENDIX A-HCI Group’s Worklogs Nikhil Gadia: Class Time: 13:30 Group Meeting: 15:00 Writing Reports/Presentations: 15:00 Research: 5:00 Administrative Tasks: 4:00 Architecture Design: 2:00 Liaison Meeting: 2:00 Total: 56:30 hours Karen Lee: Administrative Tasks: 4:40 hours Class: 12:30 hours Writing Reports/Presentations: 16:10 hours Staff/Leader’s Meeting: 2:30 hours Group Meeting: 15:15 hours Liaison Meeting: 2:30 hours Research: 10:35 hours Total: 64:10 hours Srikanth Narayanamohan: Class Time: 8:30 hours Group Meeting: 10:30 hours Writing Reports/Presentations: 9:30 hours Miscellaneous: 1:00 hour Total: 29:30 hours Venkatesh Shankar: Class Time: 12:00 hours Group Meetings: 17:15 hours Research: 4:00 hours Writing Reports/Presentations: 16:30 hours Total: HCI Group Total: 49:45 hours 199:55 hours B-Visual/Audio Group’s Worklogs Michael Walch: Class Time: Group Meeting: 5:30 Writing Reports/Presentations: Research: 6:00 Administrative Tasks: 5:15 Staff/Leader’s Meeting: 3:00 Total: 14:50 hours hours 2:15 hours hours hours hours 36:50 hours Prasanna Velagapudi: Architecture Design: 1:00 Class: Writing Reports/Presentations: Staff/Leader’s Meeting: 1:00 Group Meeting: 6:35 Research: 1:10 Total: hours 10:40 hours 4:40 hours hours hours hours 25:05 hours Sonali Nath: Class Time: ?:?? hours Group Meeting: ?:?? hours Writing Reports/Presentations: ?:?? hours Miscellaneous: ?:?? hours Total: ?:?? hours Additional members in the V/A group left the course before hours could be calculated for them C – HW/SW work log hours KieTae Park Administrative Tasks: 3:10 Class: 13:30 Field Testing: 1:00 Group Meeting: 4:30 Liaison Meeting: 2:00 Research: 2:00 Staff / Leaders Meeting: 1:40 Writing Reports / Presentations: 1:00 Total: 28:50 Steve Fabrey Administrative Tasks: 2:00 Architecture Design: 1:00 Class: 14:00 Group Meeting: 3:30 Liaison Meeting: 1:00 Research: 9:00 Writing Reports / Presentations: 4:30 Total: 35:00 Gregor Kronenberger Class Time: ?:?? hours Group Meeting: ?:?? hours Writing Reports/Presentations: ?:?? hours Miscellaneous: ?:?? hours Total: ?:?? hours ... 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... listing of the features and human computer interaction conventions that will be used to develop a prototype of the car Subsequently, the report will go provide detailed explanation of the software... able to be set through the use of “user profiles” in the car If a different user (other than the owner of the key) approaches the car, he/she can manually change the car? ??s preset settings to their