Embed Size (px)
Citation preview
Team Valeo
Kevin Le, Denis Lin, Sarah Toukan, David Zhang
Rafael Guevara, Andres Martinez, Felix Marquette, Jules Scordel
Stanford University & Paristech
ME 310
June 10, 2014
Table of Contents 1. Prelude ....................................................................................................................................... 8
1.1 Executive Summary ................................................................................................................... 8
1.2 Glossary .................................................................................................................................... 10
2. Context ..................................................................................................................................... 13
2.1 Corporate Sponsor................................................................................................................... 13
2.2 Need Statement ....................................................................................................................... 13
2.3 Corporate Liaisons ................................................................................................................... 14
2.4 Teaching Team ......................................................................................................................... 14
2.5 The Design Team .................................................................................................................... 14
3. Design Requirements .............................................................................................................. 18
3.1 Overview .................................................................................................................................. 18
3.2 Functional Requirements ........................................................................................................ 19
3.3 Physical Requirements ............................................................................................................ 26
4. Design Development ............................................................................................................... 32
4.1 Overview .................................................................................................................................. 32
4.2 Conceptual Brainstorming ...................................................................................................... 32
4.3 Interviews with everyday drivers and typical commuters ..................................................... 33
4.4 Benchmarking .......................................................................................................................... 39
4.5 Exploration of Ideas through Prototyping .............................................................................. 44
4.6 Final Prototype Development ................................................................................................. 82
5. Design Specification ................................................................................................................. 92
5.1 System Overview ..................................................................................................................... 92
5.2 Multi-screen Interaction ......................................................................................................... 92
5.3 Software ................................................................................................................................... 94
5.4 User Interface .......................................................................................................................... 96
5.5 Electronics ..............................................................................................................................107
5.6 Steering Wheel Mechanism ..................................................................................................107
5.7 Cockpit ....................................................................................................................................112
5.8 Motion Induced Discomfort Reduction ................................................................................114
2
5.9 CAD Drawings of Mechanical Systems .................................................................................117
5.10 Bill of Materials ......................................................................................................................123
6. Project Management .............................................................................................................126
6.1 Expected vs Executed Plan ....................................................................................................126
6.2 Deliverables and milestones .................................................................................................127
6.3 Summary Budget ...................................................................................................................128
6.4 Distributed Team Management ............................................................................................128
6.5 Team Reflections ...................................................................................................................130
7. References .............................................................................................................................137
7.1 Bibliography ...........................................................................................................................137
7.2 Consultations .........................................................................................................................137
8. Appendix ................................................................................................................................142
8.1 Appendices .............................................................................................................................142
3
List of Figures Figure 1: Context maps of the Driver's Experience and of an Intuitive UI ....................................... 32 Figure 2: Matrix of Activities ............................................................................................................... 36 Figure 3: Speed curve showing the number of interruptions at certain speed ............................... 37 Figure 4: Matrix describing time spent in car .................................................................................... 38 Figure 5: Tesla Dashboard .................................................................................................................. 40 Figure 6: Garmin HUD display ............................................................................................................ 41 Figure 7: Clicking Mechanism for steering wheel matching system ................................................ 45 Figure 8: Testing the CFP .................................................................................................................... 45 Figure 9: Dark Horse v1 Frame ........................................................................................................... 49 Figure 10: Playing the balloon game .................................................................................................. 49 Figure 11: Screen Display inside Kart ................................................................................................. 50 Figure 12: Test users of Dark Horse v1 .............................................................................................. 51 Figure 13: Inside view of the Kart ....................................................................................................... 51 Figure 14: Building the Dark Horse 2 Prototype ................................................................................ 53 Figure 15: Nature Projection onto dashboard ................................................................................... 54 Figure 16: LED lighting with User testing ........................................................................................... 54 Figure 17: Text from vehicle ............................................................................................................... 57 Figure 18: Tablets mounted on dashboard ....................................................................................... 57 Figure 19: Road Footage from Camera mounted in car ................................................................... 58 Figure 20: User footage from Camera Mounted in car ..................................................................... 58 Figure 21: Projector set-up ................................................................................................................. 60 Figure 22: Projected dashboard ......................................................................................................... 60 Figure 23: Picture of the main overview of the Storyboard ............................................................. 62 Figure 24: basic stock blank dashboard ............................................................................................. 64 Figure 25: Basic blank dashboard with SMS app ............................................................................... 64 Figure 26: Nature background ........................................................................................................... 65 Figure 27: Christian's choice of background atmosphere ................................................................ 65 Figure 28: Dashboard night mode configuration .............................................................................. 65 Figure 29: Christian's setting during automated mode .................................................................... 66 Figure 30: Christian's settings during transition mode ..................................................................... 67 Figure 31: Gina car concept ................................................................................................................ 68 Figure 32: Shape shifting idea ............................................................................................................ 68 Figure 33: Main dashboard panels ..................................................................................................... 69 Figure 34: Clips attachment ................................................................................................................ 69 Figure 35: curved tube ........................................................................................................................ 69 Figure 36: zoom on fabric ................................................................................................................... 70 Figure 37: User testing ........................................................................................................................ 70 Figure 38: From manual to autonomous ........................................................................................... 72
4
Figure 39: Application ideas ............................................................................................................... 73 Figure 40: GPS for Christian ................................................................................................................ 73 Figure 41: Screenshot of Dashboard Layout ..................................................................................... 74 Figure 42: Philippe Testing ................................................................................................................. 75 Figure 43: Physics Toolbox Application .............................................................................................. 77 Figure 44: Pushing Kevin in our prototype ........................................................................................ 78 Figure 45: Rigid bar ............................................................................................................................. 78 Figure 46: Shock absorber .................................................................................................................. 78 Figure 47: Failure ................................................................................................................................ 79 Figure 48: MID Incidence Chart .......................................................................................................... 80 Figure 49: Vertical Vibration Testing .................................................................................................. 81 Figure 50: Fore and aft testing ........................................................................................................... 82 Figure 51: Graph of fore-and-aft vibrations ...................................................................................... 82 Figure 52: Paris Critical Experience Prototype .................................................................................. 83 Figure 53: Touching the screen on our Funky prototype ................................................................. 83 Figure 54: Automated Car Test .......................................................................................................... 84 Figure 55: Final sketches of screen locations in cockpit ................................................................... 84 Figure 56: 3D mapped dashboard ...................................................................................................... 85 Figure 57: Screenshot of Animatic ..................................................................................................... 86 Figure 58: Our 3 screen interface ...................................................................................................... 86 Figure 59: Front screen in manual mode ........................................................................................... 87 Figure 60: Center stack screen ........................................................................................................... 88 Figure 61: Steering wheel and screen ................................................................................................ 88 Figure 62: Three screens while in media player mode ..................................................................... 89 Figure 63: Scott using our system ...................................................................................................... 93 Figure 64: Wooden frame for Linear Actuators ................................................................................ 93 Figure 65: Behind screen view ........................................................................................................... 93 Figure 66: Screen side view ................................................................................................................ 94 Figure 67: Steering wheel screen, manual to autonomous .............................................................. 96 Figure 68: Steering wheel screen, autonomous to manual .............................................................. 96 Figure 69: Front Screen in Manual Mode .......................................................................................... 97 Figure 70: Front Screen in Autonomous Mode (No apps ................................................................. 98 Figure 71: Manual Mode, Center Console Screen ............................................................................ 99 Figure 72: Phone App - Front Screen ...............................................................................................100 Figure 73: Phone App - Wheel Screen .............................................................................................100 Figure 74: Mail App, Front Screen ....................................................................................................101 Figure 75: Suggestions on Wheel Screen .........................................................................................101 Figure 76: Messaging App, Front Screen .........................................................................................102 Figure 77: Messaging App, Wheel Screen .......................................................................................102 Figure 78: Media Player (book), Front Screen .................................................................................103 Figure 79: Media Player (book), Wheel Screen ...............................................................................103
5
Figure 80: Media Player (movie), Front Screen ...............................................................................104 Figure 81: Media Player (movie), Wheel Screen .............................................................................104 Figure 82: Media Player (pictures), Wheel Screen ..........................................................................105 Figure 83: Media Player (music), Wheel Screen ..............................................................................105 Figure 84: Device Sync, Front Screen ...............................................................................................106 Figure 85: Device Sync, Wheel Screen .............................................................................................106 Figure 86: MID circuit diagram .........................................................................................................107 Figure 87: Motor circuit for linear actuators and motor ................................................................107 Figure 88: Isometric CAD view of Steering Wheel Assembly ..........................................................109 Figure 89: CAD of Steering Wheel Assembly ...................................................................................109 Figure 90: CAD of Steering Wheel ....................................................................................................110 Figure 91: Exploded CAD of steering wheel ....................................................................................111 Figure 92: Wood Frame Only ...........................................................................................................112 Figure 93: Partial Acrylic Covered Frame .........................................................................................112 Figure 94: Heating acrylic .................................................................................................................112 Figure 95: Bending acrylic .................................................................................................................112 Figure 96: Pink Foam Armrest ..........................................................................................................113 Figure 97: Bent Acrylic ......................................................................................................................113 Figure 98: Completed Cockpit ..........................................................................................................113 Figure 99: Wiring the LEDs ...............................................................................................................114 Figure 100: Testing the LEDs ............................................................................................................115 Figure 101: M.I.D System in prototype (view from side of prototype) ..........................................115 Figure 102: Acrylic covering for M.I.D (from driver point of view) ................................................116 Figure 103: Driver point of view of the dashboard and M.I.D system ...........................................116 Figure 104: Linear Actuator Mount ..................................................................................................117 Figure 105: Dashboard Frame Side View .........................................................................................118 Figure 106: Dashboard Frame Top View ..........................................................................................118 Figure 107: Dashboard Frame Behind Screen View ........................................................................119 Figure 108: Dashboard Frame Front of Screen VIew ......................................................................119 Figure 109: Dashboard Frame ..........................................................................................................120 Figure 110: Dashboard with Acrylic Covering Front View ..............................................................121 Figure 111: Dashboard with Acrylic Side View ................................................................................121 Figure 112: Dashboard with Acrylic Top View .................................................................................122 Figure 113: Dashboard with Acrylic, view from Driver side ............................................................122 Figure 114: Dashboard with Acrylic, View from Passenger side ....................................................123
6
List of Tables Table 1: Functional Requirements ..................................................................................................... 19 Table 2: Physical Requirements .......................................................................................................... 26 Table 3: Descriptors used to classify interviewees ............................................................................ 33 Table 4: Angela's Needs ...................................................................................................................... 34
7
1. Prelude 1.1 Executive Summary Today, the world’s leading carmakers are racing to design the car of the future. Entertaining and visually stunning concepts are showcased in every passing international auto show, from Toyota’s Fun Vii to Rinspeed’s XchangE and Mercedes’ Biome car. Even non-automotive companies such as Apple are eyeing the significant market opportunity to define the technology of the future car. In the midst of all this development is the new and inevitable eventual trend towards autonomous vehicles. Valeo is well positioned to be the industry leader in this new market - both through the supply of autonomous car technology, as well as through the definition of the perfect user experience to its client automotive companies. Though there has been much exploration of creative concepts, the “human part” of autonomous vehicles has yet to truly be developed by any single company. A truly intuitive experience - where the user’s needs and behaviors are fully addressed - is needed. It is this that will distinguish successful and lasting products from cool concepts that quickly fade. In our design development process, our team asked ourselves: what will make the perfect user experience in an autonomous vehicle? To answer this question, we ran through many cycles of user testing - paying close attention to
the user and their behavior - until we arrived to a final product vision we believe truly addresses users’ needs. Our team envisions an experience that is completely customized to the user, and has named the product Carmeleon - the chameleon car that adapts to suit its user. Early needfinding by both ENPC and Stanford showed that although the novelty of a concept will impress a user, unless the system is configured to the user’s unique preferences, the user will not have an ideal experience and at worst, may disregard the system entirely in favor of their smartphone. The heart of the Carmeleon system is a dashboard that dynamically changes between two modes, autonomous and manual driving. In manual mode, the system’s behavior resembles a traditional cockpit. Two 13.3 inch screens, one in the dashboard and one in the center console screen, display important information to the user about his or her drive, including speed, proximity of the car to surrounding objects, etc. Once the car has entered a traffic zone and is travelling under 35 km/h, it is permissible for the user to activate autonomous driving mode, done by pressing a switch located behind the steering wheel. Once autonomous mode is activated, a number of changes take place as the car morphs for the user. The two 13.3 inch screens move towards the user, and the dashboard screen is now available to open the user’s apps. It can be controlled
8
either directly or by a 7 inch tablet in the center of the steering wheel. Significantly, a series of tests our team conducted, simulating user experience in an “autonomous car”, also showed that the vast majority of users experience marked physical discomfort when interacting with an interface. The most sensitive of these users become severely nauseous, and the least sensitive describe experiencing headaches and trouble concentrating. Due to these problems, most users described wanting to turn off the provided interface after 5-10 minutes of use. This will pose serious problems to the feasibility any system that incorporates use of a screen or interface. To prevent the user from experiencing motion induced discomfort (MID) while interacting with the screens, a series of LEDs located in the user’s visual periphery flash at a speed equal to that of the car’s. The software offering on the steering wheel tablet and dashboard screen now changes, allowing the user to access to apps such as music, media, and texting, as well as an online app store. Lastly, the car now takes over control of the steering, and the steering wheel and column rotate left and right, giving the user indication of the car’s motion, and the option to grab and take back control whenever needed
9
1.2 Glossary 80/20 An aluminum bar set designed for easy
frame construction App Mobile application Acrylic bending A manufacturing process that involves
using a heating element to heat acrylic enough so that it can be formed.
Active Damping A system in which dampers are turned on and off depending on various stimuli sensed by the system
Arduino An open-source electronic prototyping system complete with microcontroller and programming language
Cockpit The driver’s space and the amenities in that space
Center Stack or Console The place in a car where the radio, air conditioning and sometimes the gear shifter knob can be found.
Damping An influence upon an oscillatory system to reduce the oscillation
Dark Horse Prototype A prototype which is unlikely to succeed but provides the opportunity to explore an unknown part of the design space
ETA Estimated Time of Arrival EXPE Project exposition held on the 5th June
2014 at Stanford and June 2014 at the Paris d.school
Fore-and-Aft Forwards and backwards motion
Functional Prototype Also known as Funk-tional, a prototype that approximates the final product and includes commitments to design choices such as configuration, technology or geometry.
Funky Prototype A prototype in which existing parts have been hacked and combined to approximate a system without making a
10
costly commitment to any one configuration, technology, or geometry
GPS
Global Positioning System; a system using satellites to pinpoint the location of something
Haptic Feedback Tactile, or touch-based, feedback Intracar
Between unique cars
Kinect Camera based motion and gesture detection system by Microsoft
Laser cutting A manufacturing process that uses a laser to precisely cut designs through various materials
Lateral Side to side motion Leap Motion Motion and gesture detection system LED Light Emitting Diode; a type of light Makey-Makey An electronic prototyping platform for
inventors MID Motion Induced Discomfort Motion Induced Discomfort A broader term that encompasses all
forms of discomfort resulting from motion, including motion sickness, which is a more severe form
Motion Sickness A feeling of nauseousness that some people experience as a result of motion in boats, cars, rollercoasters, etc.
Passive Damping A system in which the dampers are always on, regardless of the stimuli sensed by the system
Pitch The rotation of something about its transverse (side-to-side) axis
PVC Polyvinyl chloride; a type of polymer used to make piping
Shapeshifting Dashboard A dashboard that is able to physically change
Sensory Conflict Theory The prevailing theory that attributes motion sickness to a conflict between the body’s vestibular system and the visual system
11
Transition Time The time it takes for a driver to take back control of an automated vehicle
UI User interface Vestibular System Located in the inner ear, this is the body’s
system for detecting motion
Visual System The body’s system that is responsible for taking in light through the eyes and translating that data into images for the brain.
Wizard The person controlling the functions in a Wizard of Oz experiment
Wizard of Oz Experiment An experiment where variables and features are simulated and not actually working
12
2. Context 2.1 Corporate Sponsor Valeo is an independent industrial group fully focused on the design, production and sale of components, integrated systems and modules for the automotive industry, mainly geared towards CO2 emissions reduction. Valeo ranks among the world’s top automotive suppliers Group Profile:
• 72,600 employees • 29 countries • 125 plants • 21 research centers • 40 development centers • 12 distribution platforms
Valeo’s strategy is based on a philosophy of sustainable, responsible development.
2.2 Need Statement Valeo has created a brand that is well-known and respected in the automotive industry by providing customers with reliable, safe, and effective solutions. Valeo has already developed numerous driver assistance systems and technologies that bring the company closer to achieving its goal of an intuitive and safe driving experience. These systems have prepared Valeo to take the next big step in the automation of consumer vehicles - automated driving in traffic. Autonomous driving will soon become a reality. Most of the technological challenges are about to be solved, and Valeo expects its system to be on the market by 2018. But there are still some issues to be fixed from the user’s point of view. Today, car interiors are mainly
designed for drivers to enjoy the experience of steering, putting aside any activity that could prevent them from fully focusing on the road. But automation will enable new kinds of in-car action and entertainment, such as reading, watching movies, passing phone-calls or even paper writing, for which the current paradigm of cockpit layout is not intended. As the line between driver and passenger becomes blurred, the cockpit must evolve into a flexible and customizable space in order to satisfy the needs and wants of different users, while maintaining the familiar layout of essential driving components such as the steering wheel and pedals. In order to provide a comfortable and relaxing ride to the driver, the solution must address both the in-car experience while in autonomous mode, allowing him to use this new free time to do whatever he wants to do, as well as the experience of transitioning to manual mode in a seamless and reassuring way. Knowing that there is a significantly higher risk of crashing during this switching phase, we must work on making it safe and intuitive, incorporating both an alert system that gently and effectively grabs the driver’s attention and a feedback system that provides him with all necessary information to take over the vehicle.
BRIEF Team Valeo’s goal is to reinvent the driver’s experience in automated cars during traffic jams.
13
2.3 Corporate Liaisons Patrice Reilhac: Is the Innovation and Collaborative Research Director at Valeo. [email protected] Julien Moizard: Is the Project Manager in Driving Assistance Research at Valeo. [email protected] Patrick Sega: Is the Collaborative Projects Director in the area of Research and Innovation at Valeo. [email protected] Philippe Gougeon: Is the Collaborative Projects Director in the area of Research and Innovation at Valeo. Loan My Descourvieres: Is the Collaborative Projects Director in the area of Research and Innovation for America and Asia at Valeo. [email protected] Patrick Bonhoure: Works in the area of Research and Innovation at Valeo. He has a PhD in Ergonomics. [email protected] All of them are part of the Comfort and Driving Assistance Business group (CDA). This is a group that aims to develop interface systems between the driver, the vehicle and the environment, which help to improve comfort and safety. The group focuses on intuitive driving, with four complementary priorities: easy, ergonomic interaction with the vehicle for the driver, driving agility with better visibility of the surrounding environment, connectivity, and safe, personalized access.
2.4 Teaching Team
STANFORD TEACHING TEAM Mark Cutkosky, Professor [email protected] Larry Leifer, Professor
[email protected] George Toye, Professor [email protected] Gabriel Aldaz, Coach [email protected] Daniel Levick, Teaching Assistant [email protected] Aditya Rao, Teaching Assistant [email protected] Stephanie Tomasetta, Teaching Assistant [email protected] ENPC TEACHING TEAM Véronique Hillen, Professor [email protected] Claire Fiszer, Instructor [email protected] Pierre Levy, Coach [email protected] John Gedge, Professor [email protected] Mathieu Chabasse, Teaching Assistant [email protected] Mathieu Spiry, Teaching Assistant [email protected] Aurelien Sibiril, Teaching Assistant [email protected]
2.5 The Design Team 1.5 The Design Team Stanford Team
14
Sarah Toukan
Status: 2nd year M.E. graduate student at Stanford Contact: [email protected] I grew up in the turmoil and excitement that is the Middle East, between the desert plains of Saudi Arabia and the grassy hills of Amman, Jordan. I received my B.S. in mechanical engineering from Stanford just over a year ago, and I am now working to specialize in product development. I love manufacturing techniques, design, and generally, the act of creation, and have been lucky enough to have seen the insides of all types of workshops all over the world - places where pen gets put to paper and idea realizes form, my favorite places of all. My other hobbies and interests include philosophy, psychology, coffee, beautiful buildings, music, traveling, and hearing people’s stories. Jiarui David Zhang
Status: Mechanical Engineering Graduate Student at Stanford University Contact: [email protected] Born in Zhenjiang, China, I came to the US when I was 12 years old. I graduated from the University of Vermont with a B.S in Mechanical
Engineering minoring in Mathematics in 2012. One of my favorite experiences during that time was my summer internship at Sandia National Laboratories in Albuquerque, New Mexico working on projects relating to the integration of electric vehicles with the smart grid. Now, I am at Stanford studying mechanical engineering design, manufacturing techniques, and exploring my interests in various areas including green energy, entrepreneurship, and product design. I really enjoy travelling, to experience life in ways unfamiliar to what I am used to, and to learn and appreciate different cultures with greater understanding. Kevin Le
Status: M.E. Coterminal Student Contact: [email protected] Born and raised in Chatsworth, CA, I graduated from Stanford University in 2013 with a BS in Biomechanical Engineering. I am extremely interested in medical device design and have worked for Boston Scientific Corporation and Cibiem, Inc. Aside from engineering, I have other passions include the Los Angeles Lakers, the San Diego Chargers, and all Stanford University sports teams.
15
Denis Lin
Status: M.E. Coterminal Student Contact: [email protected] I'm from Southern California (Thousand Oaks) and earned my BS in ME from Stanford this past spring. I played on the Stanford tennis team for the last four years and am generally a big sports fan and movie buff. When it’s not NFL Sunday, I enjoy playing tennis, flag football, volleyball, basketball, swimming, reading, and hiking. I also love making things and enjoy fiddling around in Solidworks and machining in the PRL. THE ÉCOLE DES PONTS TEAM Andrés Felipe Bedoya Martínez
Status: Electronic Engineering Student at Pontificia Universidad Javeriana Cali Colombia Contact: [email protected] I am an electronic engineer who has worked for 5 years in multidisciplinary teams on making innovative, political, rebellious and crazy ideas happen.
Rafael Eduardo Guevara Gomez
Status: Electronic Engineering student at Pontificia Universidad Javeriana Cali Colombia Contact: [email protected] I was born and raised in the mysterious paradise known as Colombia, and after living in Germany for a while, I came back to study Electronic engineering specialized in telecommunications at the Universidad Javeriana Cali. I’m currently done with my courses duties and hence I am focusing on the design thinking culture, that’s when I decided to join the ME310 program and to top it off, I was selected to attend to the program at the École des Ponts in Paris. This year combines some of the things I like the most: traveling around the world and working in a multicultural team, so I could say things are just getting better and better. Felix Marquette
Status: Industrial designer, specialized in transportation design Contact: [email protected] I am a Parisian drawing-addict music-loving optimistically-backpacking & feverishly-partying industrial designer. I also love to take photos and to discover new means of expression. Freshly graduated from the Strate College design school of Paris, after five years studying transportation and mobility design, I was still thirsty for knowledge. That’s why I decided to
16
join the ME310 team. I hope it will be the occasion to meet other students from every part of the globe and to discover the world from totally different points of view.
Jules Scordel
Status: Mechanical Engineering graduate student at École Normale Supérieure de Cachan Contact: [email protected] I grew up in Paris, where I have been studying mechanical engineering for the past years. I entered the École Normale Supérieure of Cachan, a research oriented university in Paris, to deepen the scientific aspect of my studies in materials and structures mechanics. Understanding that innovation does not only come from technological progress, and being very interested in the innovation process, I want to understand better the development of a product that focuses on the end user, from its ideation to making it real. In my free time I enjoy sports like hiking, swimming and rugby. I’m also very curious to get my hands on anything that allows me to be creative, from photography to code. I really enjoy traveling and meeting people from different cultures, so having a team from very
different places, makes this program even more interesting!
17
3. Design Requirements 3.1 Overview The design requirements define what our final prototype is ultimately supposed to do. These requirements have shaped the design of our final prototype - each requirement is critical to the success of the overall system, and in order to determine if we’ve met each requirement, we came up with specific metrics to compare our prototype against. These requirements and metrics have been constantly revised and revisited throughout the year as we have continued to gain new insights from prototyping and user testing.
The requirements are divided into two categories: Functional and Physical. Functional requirements are related to what the solution must be able to do and what level of functionality the solution must be able to provide. Physical requirements are related to the design itself and the physical constraints and physical attributes that the final solution must have. The two tables of Functional and Physical requirements can be found below.
18
3.2 Functional Requirements Table 1: Functional Requirements
Requirement Category Metrics Rationale Comparison Quick transition between modes
External The driver should be able to take back control in 7 seconds or less
Once the driver has expressed the desire to take back control, he/she should be able to do so in as short of a time as possible because the car should always cater to the desires of the driver as long as it is safe to do so. Some drivers will not be thinking very far in advance and will initiate the transition right before they need to exit the highway. Most drivers also don't like waiting, especially if they've already expressed the desire to be in control of the vehicle.
The transition from autonomous to manual takes 7 seconds to complete. However, the driver can begin to take back control while the transition is still occurring because the windshield is almost fully visible. Therefore, our system allows the driver to take back control in 4 seconds and meets this requirement
A simple, easy to learn interface
External Driver can launch an application from either the home screen or from another application with less than two touches of the screen. Driver should be able to complete a
Simplicity is key, especially since our system is competing with the simplicity and ease of use of a smartphone. We need to make sure that the barrier to usage is low and that the interface is
Our user interface allows the user to open any application with a single press of a button. This is always the case, whether the user has just switched into autonomous mode or already
19
simple command such as "Send a text message to Claire" without further directions.
welcoming, or else the user is likely to just take out his/her phone. It is critical that the driver can easily perform common tasks and can learn how to navigate the interface in a short amount of time and with a small amount of effort
has another application open. In addition, our user interface follows standard symbols and interactions that are used in the smartphone and tablet industry so that the transition to our system is smooth for users. Simple tasks such as sending a text or making a phone call are very intuitive and our users were able to perform these tasks with very little outside input. Our prototype meets this requirement.
Transition between modes is clear and obvious
External With no outside direction, a user should be able to correctly identify when the transition is occuring, when the car is driving itself and when the driver is manually in control of the vehicle
To ensure safe operation of the vehicle at all times, the driver must always be aware of the status of the vehicle, particularly when the vehicle is transitioning between modes. It is critical to the safety of the driver and passengers that the driver knows when he/she needs to manually drive the vehicle and when it is okay for him/her to release the steering wheel.
Users are able to tell if they are in autonomous or manual by the different screen configurations as well as by what is displayed on the screens. The steering wheel screen is completely locked in manual mode and only turns on in autonomous mode. There are also on-screen notifications that inform the driver of the current transition status. Our system
20
successfully meets this requirement.
System must inform user about traffic conditions
External When a user interacts with our system, he/she should at all times be able to identify when he/she will be in traffic ("I will hit traffic in 3 minutes"), for how long that traffic will last ("I will be in traffic for 10 minutes), and the ETA ("I will arrive in 15 minutes")
Needfinding showed that users desire real-time information about estimated time of arrival and estimated amount of time in traffic because knowing this information decreases their stress and anxiety
The center screen displays a progress bar that visually shows where the car is along it's entire route, as well as which sections of the route have traffic and will allow for autonomous driving. The progress bar also shows time to arrival and time left in traffic. These features help our system to meet this requirement.
System must reduce M.I.D by helping to narrow the discrepancy between the driver's visual system and vestibular system
Internal The incidence of M.I.D should be less when using our regularly operating system (with M.I.D reduction) than when using our system with the M.I.D reduction mechanism turned off for any specific user
M.I.D prevents passengers from comfortably reading and watching media content in cars because they receive conflicting signals from their vestibular system and their visual system. Drivers of autonomous vehicles will experience similar symptoms, and so our system must reduce these symptoms to allow the user to enjoy interacting with our system and utilizing its features.
Two strips of LEDs are mounted on either side of our prototype - these strips of LEDs have been wired and coded to simulate the pattern of light that you would see if you were driving through a tunnel at the speeds displayed on the dashboard screen. Because our prototype doesn't move, we were unable to determine the effectiveness of these visual cues on reducing M.I.D. With
21
further testing, we would be able to determine whether or not our system meets this requirement, but at the moment, we have not confirmed that our system reduces M.I.D.
Interface must allow a considerable amount of customizability to match the user's preferences
Internal Applications can be moved around within the extended display area and can be sized and positioned according to the user's specific preferences
Our user testing revealed that people's preferences vary widely when it comes to what features they care about and where they would want them. Customizability is important to allow our system to adapt to the wants and needs of all of our users instead of just perfecting the experience for one very specific user.
We felt that allowing users to move and re-size apps across the various screens would allow sufficient customizability to make users feel that the system was built for them. Due to time limitations and technical challenges, however, we were unable to realize the ability to move and re-size applications. The customization of our system is still evident though in the adjustable chair position and wide spectrum of applications right at the user's fingertips. Because of these features, this requirement was somewhat met - in the future, we would hope to be able to swipe applications from screen to screen, to full-
22
screen or half-screen applications, view and run multiple applications at once, etc.
M.I.D. system must not hinder driver's ability during manual driving
Internal A driver must be able to drive at least as well with our system as he/she does in a regular car
In manual mode, the driver is solely responsible for safely operating the vehicle, so our system must not in any way negatively affect his ability to drive and make decisions.
The LED strips do not light up during manual driving and are instead completely hidden. They turn off one second before the completion of transition from autonomous to manual. Because the M.I.D reduction system is completely turned off during manual driving, we can definitely conclude that the M.I.D reduction system does not hurt driving ability and that our system meets this requirement.
M.I.D. system must be intuitive and happen in the background
Internal The driver should not explicitly notice the M.I.D reduction system and it should turn on automatically whenever the user is performing an activity that puts him/her at risk of M.I.D
Because the M.I.D system is meant to enhance the experience for all users, it should be automatic and should not distract the user from enjoying the interface. The user should not have to think about the M.I.D system at all - it should just work
The LED strips are located outside of the user's central cone of vision, in their peripheral vision - in the space between 50 degrees and 60 degrees from center. The LED strips turn on automatically one second after start of transition from
23
manual to autonomous and are on at all times during autonomous driving. The placement of our LEDs ensures that the M.I.D reduction system is in the background and is hardly noticed by users. The fact that it is turned on at all times during autonomous driving is a bit of overkill (because if the driver just sits there and looks outside, then he/she will not experience M.I.D) but does not hurt anything (worst case scenario is the driver looks outside and the LEDs just reinforce what is happening outside). Based on the above two points, our system meets this requirement.
System must provide adequate elbow support
The driver should be able to type on the steering wheel screen for ten consecutive minutes without getting fatigued or uncomfortable
One of the functions of the steering wheel screen is to be used as an extended keyboard to type long emails or write documents. This experience needs to be better than typing on the small smartphone keyboard, but the new hand
We built an armrest and set the height to be right at the elbow height of a 5' 8 male while he is typing on the steering wheel screen. Obviously, this position isn't adjustable and will not be ideal for many of our users,
24
placement requires external elbow support.
but for a user around that size, the armrest provides just the right amount of support. Our system meets this requirement (not for all users, but the feasibility and functionality of the concept is sufficiently demonstrated)
System must not allow driver to interact with steering wheel screen or dashboard screen in manual mode
Driver does not interact with either of these screens beyond the first couple of exploratory touches
During manual mode, the driver needs to be focused on the road and on the surroundings. In order to ensure that the driver does not get distracted, we need to only give him access to the center console screen, just like in any other car.
In manual mode, the dashboard screen is locked and does not allow interactions. It displays the common dashboard information (speed, rpms, navigation, etc) but does not allow the user to interact with it. The steering wheel screen is completely locked and does not display anything until autonomous mode is activated. Our system meets this requirement.
25
3.3 Physical Requirements Table 2: Physical Requirements
Requirement Metrics Rationale Comparison Smooth and comfortable transition between modes that is easy to activate but cannot be activated on accident
Activation of transition should require no more than the press of one button - this button must be located no further than 45 cm away from driver.
The button to switch modes must be easily accessible to the user in order to save time and for the driver's convenience - the easier it is to activate, the more likely the driver will be to use it. On the other hand, the button cannot be so accessible as to be easily pressed on accident - this is extremely unsafe and can put the occupants of the vehicle in serious danger.
Switching from one mode to the other requires a simple shift of a paddle that is located behind the steering wheel screen (45 cm away from chest). The paddle is difficult to press unintentionally based on its location. This requirement is met.
Prototype should remind users of the interior of a modern luxury vehicle
Cockpit should have consistent and refined color palette consisting of blue, neon green and different shades of grey. There should be no more than 4 types of material visible to the user, to keep the design clean.
This system is designed for implementation into high-end vehicles 3-5 years from now, so it must fit with the interior design of vehicles in the current high-end vehicle market
The graphical interface has a consistent color palette composed of shades of blue, neon green and different shades of grey. The dashboard is all black and the driver can only see three different materials when seated - leather, acrylic, and fabric. The shape of the dashboard is simple and clean. The smooth curved shape and the materials used both convey a futuristic luxury,
26
thereby satisfying this requirement.
Must preserve the general structure of a modern car cockpit. This means a steering wheel in roughly the same position, a dashboard and central console in roughly the same positions, adequate leg space (if we had pedals, they would be in the same place as in a car), similar positioning of driver in relation to the dashboard and center console, etc
The dimensions of our prototype cockpit must be roughly the same as those of the standard cockpit (within 20 cm of each dimension). The steering wheel should be positioned within 10 cm of its position in a standard car relative to the seat and to the dashboard.
Our system is expected to be implemented within the next 5 years, so we can reasonably assume that cars will generally maintain the same structure that they have today in terms of shape, size, distance between seat and dashboard, etc.
Our prototype cockpit has the same dimensions as a 2009 Volkswagen Jetta, but with a customized curvature. The steering wheel is positioned approximately 7 cm from its position in a standard car. Our prototype follows the general car cockpit paradigm and meets this requirement.
Steering wheel must always be accessible to the driver at all times
Driver should be able to see and grab the steering wheel with both hands at all times, even when the car is in autonomous mode.
The steering wheel must remain accessible to the driver in order to allow the driver to take control of the vehicle at any time in case of emergency. Based on user testing, drivers will also experience anxiety if they cannot see or access the steering wheel, even if the vehicle is in autonomous mode. In addition, as mentioned in the above requirement, our system is expected to be implemented within the next five years, and it is highly likely that steering wheels will continue to be a
The steering wheel doesn't change position at all. The only change during autonomous and manual mode is that in autonomous mode the steering wheel rotates on its own to simulate the car turning. Our prototype satisfies this requirement.
27
critical part of the car cockpit during that time.
Interactive screens must be within reach of driver during autonomous mode
All screens must be within 50 cm distance from the center of the chest of the driver during autonomous mode. The bottom of the dashboard screen must be more than 10 cm above the (fully horizontal) steering wheel.
The driver should be comfortable while interacting with all screens. They should not have to actively avoid objects to access the screen. Since the steering wheel stays in place, the dashboard screen must clear the top of it in autonomous mode.
We implemented an adjustable seat distance to account for varying driver heights and leg lengths. This means that drivers with shorter arms also sit closer to dashboard, making it easy for them to interact with the touch interface. All of our users had no problem interacting with the interface, and the dashboard screen sufficiently clears the steering wheel so that it doesn't get in the way of the screen. Our adjustable seat distance really ensures that the screens are comfortable to reach by drivers of almost all sizes, so our prototype satisfies this requirement
Center console screen must be within reach of driver during manual mode
Center console screen must be within 70 cm from the center of the chest of the driver during manual mode.
The driver should be able to reach the center console screen while manually driving for the same purpose that the center console is within the driver's reach in normal cars. This is the only screen that needs to be reached in manual mode. Slight stretching to interact with this screen is okay
The center console screen is reachable by all users without them severely straining to reach it. Distance varied based on how close the driver chose to sit from the dashboard, but everyone could reach the screen and actually tried to interact with it even though it was a
28
because interaction will be very short.
screenshot. This requirement was met.
Steering wheel must remind users of a standard steering wheel
When users sit down at our prototype and grab the steering wheel, they should immediately know that it is a steering wheel and should be reminded of a standard steering wheel.
The steering wheel is part of our experience only because we are designing an experience for an existing environment that includes a steering wheel. Therefore, we must have a steering wheel that conveys the concept of a standard steering wheel in order to adequately present our concept, even if it doesn't look or feel exactly like a real one.
Our steering wheel is approximately the same diameter as a standard steering wheel, with a cross-sectional diameter slightly smaller than standard. We used a similar shape with three spokes, but instead of a full circle, we had the steering wheel open at the top in order to help with screen clearance. In all of our user testing, not a single person commented on the fact that the steering wheel was not a full circle and everyone seemed to instinctively know that it was a steering wheel. This requirement was met.
Nothing can interfere with steering wheel rotation during either manual or autonomous mode
Steering wheel must be able to rotate 30 degrees in both directions while in autonomous mode and must be able to freely rotate 360 degrees during manual mode
Especially in manual mode, the steering wheel is the only means of directing the vehicle and so nothing can get in the way of the user as he/she rotates the steering wheel. In autonomous mode, the steering wheel will rotate on its own to signify to the driver that the car is operating correctly - the steering wheel will never rotate more than 30 degrees in
We carefully positioned the before and after positions of both dashboard screen and center console screen so that they would never interfere with the motion of the steering wheel. This was one of the key factors when determining the placement and angles of movement of the screens. This requirement was met.
29
either direction because the vehicle can only be in autonomous mode in traffic on the freeway, so it's presumably on a relatively straight road (and obviously staying in its own lane). Nothing should block the rotation of the steering wheel because that will affect the steering of the vehicle and potentially cause it to crash
30
31
4. Design Development 4.1 Overview To design a product that addresses the need statement outlined in section 1.2, our team underwent a rigorous nine month design development process, engaging in continuous ideation, needfinding, benchmarking, and prototyping. The following sections provide a summary of the most important insights derived from these steps of the design process, which all directly informed the design of the Carmeleon system. More detailed information can be found in the appendix.
4.2 Conceptual Brainstorming The first phase of exploration was driven by multiple brainstorming sessions on the understanding of the problem. From the problem statement given by Valeo, the
team felt that it would be helpful to better define the concept of “intuitive driving”. It was also important to brainstorm the advantages and disadvantages of the driver’s experience, particularly with regards to traffic jam scenarios. Lastly, the team brainstormed existing technologies, services, possible solutions, and drew parallels from similar situations and the current ways of resolving them. Then, our team clustered the information and ideas generated from the brainstorms in order to plan out future paths of explorations (e.g. interviews, experiments, user observation, among others). From the brainstorming on user experience, we created a context map that allowed us to clearly define the driver’s experience and the definition of intuitive user experience as it is shown in the figure below.
Figure 1: Context maps of the Driver's Experience and of an Intuitive UI
32
4.3 Interviews with everyday drivers and typical commuters We wanted to use user interviews as a means to 1) understand users’ current pain points concerning the experience of being caught in traffic; 2) question implicit assumptions we held about what people want; and 3) develop an understanding of what creates a great driving experience. We interviewed users from as many different demographics as possible: male and female, young (<30 years old) and older (>30 years old), different cultural backgrounds, and different professions and industries. This diversity in our interviews allowed us to garner a wider variety of viewpoints with which to build our understanding of the problem. For our user interviews, we asked questions centering around 3 broad themes: 1) the user’s feelings about being stuck in traffic 2) what the word “intuitive” signifies to the user and 3) the user’s thoughts on and propensity to use automation. A sample of some of the interviews we conducted with everyday drivers can be
found in appendix 7.x. The needs expressed in these interviews are summarized in a coggle map in appendix 7.x.
APPENDIX REFERENCE Key Lessons Learned:
• Wide spectrum of personalities to design for some people control-freaks, some people happy to have everything automated; some drivers frustrated with traffic, some drivers who love to drive, etc.
• In expressing wants, users spoke less about specific feature and more about how they want to be made to feel
User Categories For all the interviews we conducted (>50), we described each of the interviewees using the following descriptors from the 3 dimensions below:
Table 3: Descriptors used to classify interviewees
Situation Desire Approach
Commuter Mobility Defensive
Pleasure-seeker Power/Thrill Aggressive
Drives for occupation Comfort Passive
Full-time driver Efficiency Friendly
33
For instance, a few of our interviewees can be defined as “pleasure-seeking” car enthusiasts, who desire both “power” from their ride, and have an “aggressive” driving approach. The user we decided who would be of highest impact to design for is the “commuter” who desires “comfort” and “efficiency” from their ride, and is a “defensive” driver. Most commuters we spoke fell into either the “passive” or “defensive” category; we decided to focus on a “defensive” driver because they require a more stringent design solution. The “defensive” driver is somewhat of a control-freak who requires sensory cues to reassure them that the car’s automation system is reliable and safe, and to persuade them to relinquish control to this automated system. “Extreme Users” Although we defined our prototypical user as a commuter, we didn't limit ourselves to talking to people from this category. Interviewing users who drive in different contexts (i.e. : long day trips, or professionals for whom the car is their
instrument of work) is a way to yield insights from users having an extreme use of their car, and thus needs that can appear more critical than others. Our persona Stemming from the results of our user interviews, we created a user persona that embodies many of characteristics we identified in a large set of our interviewees. Our prototypical user is Angela Smith, a 40 year old professional who commutes to and from work every day. Angela is an ambitious professional, and therefore highly prizes efficiency and productivity. She would like to arrive to work - and at the end of the day, to her home - in the most energized state possible, so she also desires comfort from her vehicle. Angela is married with two kids - a 13 year-old boy and 9 year-old girl, and as many other moms is a defensive driver who needs to feel in control. She tries to be a “cool mom” who stays on top of technology, and so is relatively tech-literate. Angela’s needs are described in the table below:
Table 4: Angela's Needs
Need Description
Perception of control
If Angela doesn’t feel that she is in control of the system and knows what is going on, she will never feel comfortable handing over control to the automated system, making the automation feature irrelevant. For her to feel in control, Angela needs the ability to turn the automation system on and off. She also needs real-time information from the car, letting her know what’s going on if she desires that information.
Work productivity
As a working professional, Angela would like to use time that was previously wasted to be productive and do work in her car.
34
Home productivity
Angela also would like to get things ready before she arrives home. She’d like to order groceries; pre-heat the oven; check her son is out of soccer practice before she picks him up; etc.
Connectivity To achieve the above work productivity and home productivity, Angela needs to connect to others through email, skype, phone, sms, etc.
Safety As any other user, Angela needs the car to safely get her to her destination, both while in automated mode and manual mode.
Co-passengers’ pleasure
Angela would like her family members and friends to enjoy themselves whilst in the car with her; for instance, her daughter might enjoy playing an educational game involving the passing scenery.
Relaxation So that she arrives at her destination, Angela would like the option to sometimes relax in the car, napping, listening to music, feeling immersed in a “spa” environment, etc.
Intuitiveness In order for the driving experience to be pleasurable and not energy-draining or frustrating, Angela needs the user interface to be intuitive, so that for example, she understands how to retake control of the car, and what’s going on when she’s not in control.
PoV driver observation Motivation and description :
• Our main motivation was to understand the driver’s experience and needs in traffic by actually driving in traffic and explicitly capturing that experience on film for analysis
• Mounted a GoPro camera to a hat and wore it while driving to film driver’s POV
• Deliberately drove into traffic on the 101 and 880 highway
Observations: Driving Observations
• Not too bored in stop-and-go traffic because radio was on. Music and interesting talks kept me entertained.
• Tempted to look at phone any time an audible notification was heard.
• A good number of other drivers in traffic had headphones in while driving.
Video Observations • Driver looked at phone when car was
stopped, but dropped phone as soon as needed to go forward in the car.
• When looking at phone, driver only checked e-mail and text messages.
• Driver changed lanes often in traffic, to find fastest moving lane.
Conclusions: When driver felt it was safe, he would check his phone. If he felt that he had time, he would respond. Otherwise, he only read the text and focused on the road.
35
Needs Analysis After collecting user data, we wanted to sort the different tasks the driver could carry out in an automated car, against both the level
of focus required and the “type” of activity, from functional to fun (see figure below). We did so in order to understand better the spectrum of possible activities in a car.
Figure 2: Matrix of Activities
• At the bottom of the matrix are tasks simple enough to be performed while driving with few consequences on safety. There are no opportunities here, as people usually carry out these tasks.
• In the middle of the matrix are the tasks that are not dangerous enough to prevent some people from performing them, and that if carried out may cause accidents.
36
• At the top of the matrix are the tasks that require full attention and are not currently performed by drivers, except those who are completely irresponsible. These are the tasks that we chose to focus on in the autonomous context, because we believed they could make the big difference for the user
• We will have to pay particular attention to the extreme top right area: when people get involved too deeply in a game or a fun activity they have really hard time accepting to stop what they are doing.
• The only activity that we completely rejected until now is sleeping, mainly because it would be physically impossible for the user to wake up and take back control in the imparted time (5s).
During an observation trip with a potential user, we recorded the speed variation of the car, to observe the speed patterns (see
figure below). On a 40 minute trip, with around 20 minutes of traffic, the car decelerated and then accelerated from under to over 20km/h more than 10 times. It means that potentially (assuming autonomous mode is activated when the car reaches that speed), the user will have to switch 20 times from one mode to another. The curves also showed that the maximum time autonomous mode is activated is about 8 consecutive minutes, for a total of about 14 minutes. The average time autonomous mode is activated for is about 1.5 minutes.
Figure 3: Speed curve showing the number of interruptions at certain speed
37
If this trip was representative of a normal commute, it means that our future users will be interrupted in their tasks every 1 minute and a half. What can be accomplished in such little time? We plotted this out in a second 2x2 matrix, shown in the figure below.
We divided the task between “active” (pushing) and “passive” (pulling) activities, the second being much easier to interrupt than the first.
Figure 4: Matrix describing time spent in car
38
4.4 Benchmarking Business Benchmarking Valeo is a premiere car parts supplier who provides components to car OEMS. They do not produce vehicles themselves but rather supply OEMs with technologies to augment the functionality of their customers’ vehicles. With this in mind, we hope to produce a product that will be able to be manufactured by Valeo and distributed to their customers as a stock feature, built-in and integrated into the vehicle, aligned with Valeo’s product portfolio and business model. Technology Benchmarking Past Project Reviews Many ME310 projects have been dealing with innovative car cockpits in the past years. After going through many of them, we found one project from 2013 particularly relevant to our exploration and understanding of the driver experience. One further, less relevant but still interesting, project we benchmarked can be found in section 7.x.1, under “Appendix: Benchmarking”. Audi 2013 - Transforming the Journey into the Destination This project’s goal was to enable drivers to perform activities in an autonomous vehicle, but in much further horizon (2035). Although the context of their product was in a more distant future than ours, the preliminary questions regarding the needfinding of the user experience in such vehicles are similar in both projects.
Benchmarking experiments they conducted, focused on the driver’s feeling (motion sickness), the transition from manual to automatic, and cue indicators. When doing another task than driving in a fast moving vehicle, motion sickness can really be a problem. Their experiments led to the expected result that with no visuals, motion sickness comes very quickly, but also that canceling one sense like hearing leads to an enhancement of the driver’s attention to visuals. The conclusion was that a visual and anticipatory feedback would be necessary to avoid motion sickness while working. We decided that we should address the issue of lighting, to evaluate the right amount of visual information to let the driver have a sense of the car’s motion, while at the same time not interrupt his current activity. At this point we understand the importance of continuing to provide the necessary information, how much and how, to the user while he is enjoying another activity while in autonomous mode. Testing light and voice indicators, the Audi team observed that real time indication is not useful as anticipatory warnings are. Working with lights indicators, the absence of light led the user feel that the system might not be working correctly, and when active, the user needed to interrupt his current activity to switch his attention to the screen. Working with voice indicators the experiments proved to be more effective,
39
but at the same time much more intrusive in the user current activity. Our understanding is that in order to address both effectiveness of the notifications, as well as enjoyment of another activity, the solution will synesthetic, possibly combining sounds and visuals. Looking at their CFP, we understood that in order for the notifications to be integrated to the experience of the user, it would need to overlap between the environment and the interface being used by the user. This would ensure taking the user : • out of his current activity without being disruptive • into the current driving situation Tesla Model S We visited a Tesla dealership to get a better idea of how drivers interface with Tesla vehicles. Some of the most poignant takeaways were that the Tesla user interface was very similar to that of a smartphone or a tablet. Rather than physical buttons and knobs, Teslas have a 17” touch screen in the center console that allows users to change car settings like air conditioning temperature or car lighting. In addition, Teslas have knobs on the steering wheel that allow the driver to modulate the interface directly in front of the driver. Also, apps will soon be available in Tesla vehicles, adding to the user’s experience. From this trip, we learned that Tesla’s approach to designing a user interface was to mimic how people already interact with tablets or smartphones. By using a similar interface interaction that people will be comfortable with, their
interface design will inherently be intuitive, thus improving a driver’s user experience.
Figure 5: Tesla Dashboard
Los Angeles Auto Show Motivation and description We went to the LA Auto Show to see what the big automotive companies are currently offering in terms of car user interfaces in their newest vehicles. The carmakers all had their newest models (fully loaded!) at the show, so we really got to see a wide range of approaches and were able to get a good sense of the general trends in the automotive industries. We also wanted to see if we could get more information on the “advanced” driver assistance systems offered in the higher end vehicles. Leap Motion Exploration Motivation and description Our motivation for this test was to explore alternative ways of interacting with devices. We wanted to experience what it’s like to interact with a device without physically touching it, so we turned to Leap Motion. We connected a Leap Motion board to a
40
computer and tested its usability by playing games and using computer control applications. We plan on potentially using the Leap Motion later on, for prototyping as well. Observations
• Can recognize gestures and movement in 3D space.
• Gestures include tilting hand up and down, moving in a circle, making a fist, and moving finger towards screen as if one was touching the screen
• Can recognize distinct fingers • Fairly responsive, but has a short
range. Garmin HUD Brief Description The experience of utilizing a heads up display in the car is one that is very interesting to us. Having the display projecting onto the windshield directly in driver’s line of vision could provide a safer and more convenient. Key Lesson Learned We felt that it was a very cool concept. Though we tried it on a rainy night. The HUD is able to project the navigation interface onto the interiors of the windshield quite well. Pros One immediate benefit we found was that we can place this HUD directly in front of the driver, which makes it a lot easier for the driver to follow directions while driving. The driver no longer needs to tilt his head and shift his line of sight to the right or down, which makes it safer and more convenient. Cons
Despite the fact that it was a rainy night and that distorted the projection, it was also immediately apparent that this concept would work at its current state only in total (or near total) darkness. When cars come from and past from the opposite lane, their beaming front lights make it almost impossible to see the projection. We believe that during daytime, it would also be hard to see. Due to the fact that we bought this Garmin “temporarily”, we didn’t use the peel and stick sticker onto the windshield. Maybe this sticker would deflect the distractive light. Maybe this would present a much more effective product. However, we can see how it becomes an issue even with the peel paper.
How to solve traffic Jam: Brief Description Jonas Eliasson Explain in a TED talk that reducing the amount of cars in a traffic jam the flux of cars could increase really fast and highly minimize the traffic jam. Key lesson Having a good user interface while in a traffic jam is quite helpful but it would be better if the traffic jam doesn’t exist with the help of current technology.
Figure 6: Garmin HUD display
41
Nine days Traffic Jam: Brief Description A 62-miles traffic jam that have last for 9 days is a strong signal of the importance of designing for massive population. Key lesson Traffic jam is going to be more and more common and designing for it may requires taking into account either solutions to the traffic jam or solutions for the user experience while being in traffic jam. Mitsubishi EMIRAI “car of the future” Brief Description The changes on the size and shape of the front panel are not significant to the current cars but they are using tactile panels and biometric sensors for pilot health information. Key lesson User interface presented for mitsubishi where intuitive, tactile and biometric information were trending features of the interface. Voice control can be surprisingly distracting for drivers Brief Description A study made for Toyota report that voice control can be useful for short sms or e-mail writing but can be very distracting and complex for simple manual tasks as changing features of the car like interior temperature or current radio station. Key lesson We aim to perform short task with high efficiency so voice command might not be
useful for changing features in the car but for short writing tasks. VW app conducts electro symphonies to the tune of your driving Brief Description Volkswagen has developed a way to turn its cars into giant metal DJs. When plugged into a Volkswagen GTI, the German vehicle manufacturer's Play the road IOs App. uses a swath of data from the car — including its velocity, engine revs, and location — to create a soundtrack that changes as it's driven. Key lessons Improving user experience might involve giving some musical feedback. Burkhard Bilger: Has the self-driving car at last arrived? Brief description Introduction about google driverless car in which is exposed the need statement mentioning the big amount of accidents caused by human errors. It also speak about Anthony Levandowski, former director of Google X, the company’s semi-secret lab for experimental technology. Key lessons Google aims to sell their car showing the poor ability of drivers to avoid car crush and law violations. TapTap Wristband Connects Couples With Wireless Vibrations: Brief description
42
A kickstarter have created a wristband which is used to tap or recibe taps from one person. Key lesson A vibrating alert in the wrist can give certain information to the user to improve UI. Audi A3 with MMI Touch gesture-based entertainment system hands-on Brief description New audi A3 include a gesture feature which allows you to input information by writing with your finger. It also includes voice commands, social network (facebook, twitter) connection and gps navigations system as well as web information. Key lesson They use a pad besides the gear shift exploring the writing task and the gesture commands. KIA GT Sports Transparent OLED Car Dashboard Display Brief description A transparent OLED display in the front of the steering wheel as well as in the right side of the driver. Key lesson A UI using OLED could give a cleaner vision of the dashboard The driverless road ahead: Brief Description Perspective of some of the impacts that a driverless car could have in the future. Key lesson
Design for an automated car is design for a different world because we need to take into account that with driverless come new business and new ways of transportation. In Search of the Ideal User Interface in Cars: Brief Description Examples of implementation of consumer electronics in dashboards to approach the human machine interface between drivers and cars. Key lesson There are some challenges not only in regulations but in the way the new features must be released into the market. It seems that people does not want to have al the latest technology but the technology they are capable to assimilate in their context Multiple Dashboard Pictures: Brief description Pictures of different concept and real cars in the market. Key lessons Information in driving steering wheel, touchpad panels and nature based design is being developed for different brands. Concept cars express the aims of the carmaker or dashboard designer for the future developments. How Apple plans to turn car dashboards into giant touch screens fitted with LASERS that track eye movements Brief description Apple has registered a patent about a system which uses laser to identify eye movement and create a UI in car dashboards.
43
Key lesson
Competitors benchmarking and current ideas for cross pollination.
4.5 Exploration of Ideas through Prototyping
Critical Function Prototype (CFP) The idea of a critical function prototype is to create an object, system or app that will let the user explore and test a specific concept related to critical aspects of a particular design. The design must be "critical" regarding the overall features and must answer fundamental questions about form, functionality and of course, user interaction. Critical Function Prototype at Stanford CFP MOTIVATION The autonomous vehicle has the potential to completely revamp the driving experience. Since the car will be in automatic mode during traffic jams, the driver will be able to do a myriad of tasks inside the car in that time. These tasks or activities would require different levels of attention, and in some specific cases such as napping, complete immersion. While these new possibilities could positively influence the driving experience dramatically, it is important to think about what would happen once the traffic begins to clear and the driver has to take back over control. This span of time is vital in helping the user transition safely and smoothly from his or her current activities to being the driver again. Also, as discovered from the user interviews, a safe transition between automated driving and manual driving is critical to the driver’s willingness to use the system, as people still need to
develop trust with automation. It would also be important to look at how to gently and smoothly direct the user away from his or her current task at hand, and seamlessly transition into the driving position. Therefore, the Stanford team focused their efforts on understanding and improving the transition experience from autonomous to manual mode. The car component deemed critical in the midst of this transition is the steering wheel. During autonomous mode, the steering wheel turns by itself, or could be available to perform different input tasks, without the driver interfering with the car’s steering. In other words, the driver is essentially hands free and will likely be busy with something else. When the time comes to take back control, the driver needs to be alerted, reorient with the surroundings, and take control of the steering wheel. So, the Stanford team decided to build a critical function prototype to address safety during transition, and simulate the autonomous driving experience to better understand the transition. This brings us to the matching mechanism. CFP CONSTRUCTION Before developing the prototype, it was necessary to make some assumptions related to the autonomous driving, which are as follows: • In automatic mode, the car can merge lanes. • The automation system will only be used in traffic jam. • The car cannot switch freeways. • The driver won't need to take control of the car while braking. • The driver will be forced to stop doing his current task in order to take control of the car.
44
In order to simulate autonomous driving, the steering wheel was coupled to a Nintendo Wii Steering Wheel controller. A cockpit was created using a chair and dashboard to simulate the driver’s space inside a vehicle. The Wii is connected to a projector that shows images on a screen in front of the dashboard to simulate the driver’s environment and is also connected to a TV screen on the floor that will allow the “automatic” driver to see the driver’s environment. In order to test the ability of the user to match the steering wheel to the car’s wheel orientation, we built a mechanical matching system into our experiment. One shaft was rigidly attached to the driver’s steering wheel and had keys that fit into the holes of another shaft which was joined to the Wii steering controller. When the driver’s wheel is properly oriented with the Wii steering controller, the keys will slide into the hold and click in. Then, the driver will be able to control the steering wheel, which in turn will control the Wii controller.
Figure 7: Clicking Mechanism for steering wheel matching system
CFP TESTING An experiment was conducted using the " Wizard of Oz " technique to simulate car
automation and the transition from automated to manual. Users first watched an instructional video prior to the experiment to understand the situation they are in, the meanings of alerts, and the general procedure. After, they were given an article to read, and also were allowed to play on their cellphones while the car “drove” itself during a Mario Kart time trial race. Then, they were alarmed at a random time by an voice alert to signal the car wanting driver to take control. At this point, the driver follows the audio directions to take complete control of the vehicle and drive the vehicle. The directions specifically tell the driver to take the steering wheel and move the wheel in and wiggle around until the driver has matched the wheel to the car’s orientation, at which point the steering wheel clicks into place. The time between the alert beginning and the driver taking the wheel was recorded, as well as the time for driver to successfully click in the steering wheel.
Figure 8: Testing the CFP
CFP FINDINGS Initial feedback and Adjustments After the first testing there was some feedback from the users, which the team immediately adapted to the prototype as listed below:
45
Placed a marker on the locking mechanism so users would know when steering wheel is actually “clicked in” Created a calmer environment in the car by turning off the sound from the game Changed alerts from vibration coupled with music ringtone to a pleasant and calm voice that communicates: *beep bop* "Traffic ahead is clearing up. Your car will be ready for you to take control. Please put your hand on the steering wheel to commence the matching process." *Beep bop* " The steering wheel is now clicked in. Please orient yourself with your surroundings. You will have control of steering in three seconds.* Key Insights Once the suggestions were applied and the users tested the prototype, some interesting insights were found: • People are initially somewhat confused in their first trial about the matching mechanism as well as the exact situation they are in. • People mentioned that It would be nice to have a button that the driver could push when they are ready to take control, rather than the car telling you to take control within a 3 seconds span • Very few people were looking at the environment to check their surroundings (simulated driving environment) during the matching process. Most people were only looking directly ahead on the road after focusing on looking at the “invisible” matching mechanism connected to the steering wheel
Lessons Learned Some suggestions for improvements that came out of testing will become valuable information for future experiments: It would be nice to have a indicator of takeover progress. It could be a progressive sound pattern or a light indicator Make the message alert shorter after driver is accustomed, maybe after an initial training period. This could be shortened to a single distinguishable noise The car should be able to realize when a straight road (better environment for takeover) is coming up. This would allow for a safer and easier location for the driver to takeover One thing that could really help improve the driver’s comfort during automatic mode is to have a time estimator showing how much time is left in traffic, so the driver can focus on doing a task that is appropriate and desirable according the time. CRITICAL FUNCTION PROTOTYPE AT ÉCOLE DES PONTS General prototype description We bought a Fiat Punto dashboard in a junkyard and put it on a wooden structure to recreate roughly the interior space of a car with the right dimensions. The model has eight shopping cart wheels so that we can move it around in the loft. The prototype was tested by 3 teachers, 5 students and about 10 professional commuters : Prototype 1: Thumbs up ! Questions: - Will the user accept a new way of typing ? - Should the keyboard be physical or digital? - Should we add a trackpad? - How much time do we save ?
46
Description: We split a regular computer in two and placed the keys on the wheel where the driver usually put his thumbs when driving: on left and right sides of the wheel. The entire wheel is wrapped in aluminum paper and linked to a computer screen via the MaKeyMaKey invention kit. When you touch it, the screen, placed just behind the wheel displays successives screenshots to imitate the menu navigation in the dashboard. Feedback: Claire > the ergonomic issues can change a lot from one user to another English teacher > Not really comfortable with the thumb writing, though she agreed that she could get used to it. A big screen is necessary for people who don’t have a perfect vision. Veronique > Don’t use her thumbs to write, only his index. Rafael > the higher is the screen, the better for his neck. Students > All agreed that writing with thumbs is fine because it’s really fast and efficient, even if a real keyboard would always be better. Commuters > Skeptics about this way of writing. Conclusion: - Switching time: no move is necessary to get back to driving. - Big generational differences: adults above 30 write mostly with index, students and youngs with thumbs. - Changing the shape of a keyboard never get big success. Prototype 2: Keyboard on the wheel
Questions: - Will the user like the keyboard over the driving wheel, under it or at the sides? - Will the position be comfortable enough to write texts? Even really often? - Should the trackpad be in the steering wheel? - How much time do we save? Description: The split keyboard is replaced by a regular airport keyboard, which can be adjusted in height to fit the user’s preference. We let the testers choose where and how they want to type, without influencing their choice. Feedback: Student > The right height is on top of the wheel, just under the screen English teacher > beware of wrist twisting that can be dangerous and harmful. The right height is about the middle of the wheel Milos > The right height is at the bottom of the wheel. The trackpad can either be in front of the keyboard or next to the gearstick. Commuter 1 > Often write with only one hand so they wouldn’t mind having the keyboard on the side instead of in the middle. Commuter 2 > Automation would be less scary if you had no wheel at all, like in a train. Conclusion: - We should take into consideration people's habits, comfort preferences and tiredness of driver that will have dramatic influence on the experience. If our design is not flexible enough, it won’t be able to adapt to users; how can we make it more modular ?
47
What’s next ? - Define more precisely for whom and for which activities we are designing, so that we don’t get lost in the broad world. Focus on one specific user, ie: professional commuter - Find how people write their SMS and mails - Get some data and real numbers of the situation to improve the context - Try to make the wheel release less scary, instead of avoiding it. - For the people that want to keep the wheel, how can they write with no hands? We have to test the voice commands or voice writing like Siri. Eye movements can also be interesting. - Use projector to adapt the shape of the interface to the wheel and dashboard Dark Horse Prototype v1 Motivation People sitting in a car in autonomous mode in a traffic jam situation are bored, frustrated, and surrounded by people who may feel the same way. Thus, they may want to have a way to both entertain themselves and to interact with other drivers around them. Dark Concept Physical icons and physical (non-digital) games can enhance social interaction and allow autonomous car drivers in traffic to interact at a more personal level. General Key points Physical icons that float above cars could help drivers indicate their willingness to
interact with others in different ways and help draw unexpected or desired connections. Intra-car interaction can take shape in many possible forms - messages, emoticons, multiplayer games, requests for services (food / coffee delivery / companions), automatic traffic status updates, social network status updates (Facebook/Twitter/Instagram), exchange of ideas or suggestions (route, scenery), etc. In this prototype, we specifically investigated intra-car gaming. Prototype Description Scenario In order to simulate the concept of intra-car gaming, the team decided to create a scenario with two cars stuck in the middle of a traffic jam. The cars are given the opportunity to game with each other as long as they are within visible distance of one another. Two “cars” constructed by the team were pushed straight forward in slow stop and go motion, and the “drivers” (volunteers) were able to perform activities prescribed by the specially constructed prototype. Insert InCarGaming picture Kart construction To construct the two model “vehicles” for testing, the team initially sought to borrow shopping karts from nearby grocery stores. The team also looked into renting or borrowing golf karts. After learning that neither of these were viable options, the team decided to construct its own karts from scratch, which actually made it simpler to implement the desired modularities.
48
After some deliberation, the rolling chairs from the loft were chosen to serve as the base of the karts due to their availability and ease of movement. To simulate the enclosed environment of a car, a rectangular frame was constructed from PVC pipes and attached onto the chairs. The frame extended one chair’s length in front of the driver, and two additional wheels were attached to the front supports. Veils made from hemp and cloth were draped over the PVC frame to enclose the “car”, but windows were cut out to allow the driver to see forwards and to both sides like in a real vehicle. To simulate the dashboard, the team cut out a pocket on the front veil, which allowed a smartphone to slide in and project to the driver directly.
The Games A lot of thought went into figuring out which games the prototype should include. In order to differentiate this gaming experience from that of a smartphone game, the games needed to prompt the driver to make physical movements. Another goal of this prototype was to encourage the driver to look outside of his window at the other cars he is gaming (interacting) with, which would in turn force him to be aware of his surrounding environment. Games that demand only
short time durations were chosen so that they could be completed while the players’ cars are still within eyesight of each other in the ever-changing traffic jam situation. Inspired by MarioKart and the mini games from MarioParty, the team decided on two games. Balloon Poppin’ The goal of this game was for each driver to compete and pump an air balloon situated atop their own cars, with the winner being the first one to successfully pop his or her own balloon. The top of the kart was replaced with a transparent plastic cover with a slot cut out for a tube to run through. On top, a non-inflated balloon is tied securely onto one end of the tube. The tube runs through the kart “ceiling” all the way down and is connected to a small hand pump on the other end. The driver is able to pump the balloon while sitting in the driver seat and can see exactly how big the balloon is at any moment. At the same time, he or she can look outside the window and see the other players’ balloons atop their respective cars to check on their progress.
Figure 9: Dark Horse v1 Frame
Figure 10: Playing the balloon game
49
Ball Tossin’ The goal of this game was for the driver to toss as many balls as he can into a bucket mounted on the top of his own car. A bag containing several small beach balls was provided to each participant, and they needed to reach out of their car windows to throw the balls into their baskets. In a given time limit (1 minute), the driver with the most balls in his basket is the winner. A big transparent plastic bucket was mounted atop the clear plastic ceiling to allow the driver to see their game progress. The Interface Though the gaming experience itself was designed to be physical, a smart, digital interface was still extremely important in the initiation, set up, and facilitation of this experience. The team brainstormed several ideas on how this interface could be constructed and what it would look like. Though the most ideal thing to do would have been to build a real app and install it on separate tablets to simulate this experience, we deemed it to be too challenging and time consuming given our time constraints and focus on rapid prototyping. An alternative that could produce a similar experience was found through a clever combination of powerpoint and Skype screen mirroring. Two smartphones were each mirrored to show the desktop of a computer that was running a slideshow of a pre-made powerpoint. This powerpoint was run by a remote team member and contained the flow and content that the team envisioned to create an intuitive and pleasant experience. The interface specifically allowed the drivers to change their icon status, indicate willingness
to game, select games, see what others have selected, depict game progress, watch facial reactions of other players through the phone webcam during games, and record the drivers’ gaming scores and preferences.
Figure 11: Screen Display inside Kart
Prototype Summary Karts built out of PVC pipes, rolling chairs, foam core, and fabric In-car displays are phones that wirelessly mirror a computer display Roof has two clear panels: one allows driver to see his balloon, the other allows driver to see into his bucket A tube runs from a balloon taped to the top of the roof to a pump that sits inside the car A bag of small balls is taped to the inside of the car Storyboard David, Sarah and other lucky drivers are riding in autonomous mode in a traffic jam. They are in separate vehicles that have intra-car gaming capabilities. Traffic is horrible, and the car is going nowhere. David is getting increasingly bored, and wonders whether other drivers would like to interact through a game. So, he chooses a game to play (options listed in a display on the front dashboard) - an icon
50
with his suggestion pops up on top of his car. There are 2 game options available: Balloon-popping game Ball-tossing game David selects the balloon-popping game. Now, he waits for 1 more player to join his game. His front display shows 1 out of 2 players ready. Sarah (another autonomous car driver in traffic close to David) can see the icon atop David’s car. She decides that she wants to play the same game with David, so she selects that game as well. —> The icon pops up on top of her car as well. Her display turns on, showing her the number of players currently ready to play. She joins, and now the game is ready to start (2/2 players. Shown on the display) Once the necessary number of players (in this case 2, but could be more) is met, the game begins. Game is in progress. The drivers can see the progress of their own balloon as they pump it up, as well as the progress of their opponent’s balloon atop their car. They also have the option to see a live front cam of the other driver playing the game to add more excitement and personal connection. (All done through screen mirroring). Once the game ends, the players are notified of the results (winner or loser) and they can choose to select another game if they want to continue playing. A point system could also be implemented to provide some form of incentive or motivation.
Both David and Sarah are very entertained :) Testing - Observations
Figure 12: Test users of Dark Horse v1
In the balloon game, we noticed that the drivers sometimes hesitate towards the end due to the fact that it’s quite loud when the balloon pops. This problem was resolved after we gave our users noise cancellation earmuffs at the beginning of the game. We also observed that all of the participants were constantly looking outside the window throughout the game to check on the progress of the other driver. This shows that the games effectively prompted drivers to be aware of the surrounding environment.
Figure 13: Inside view of the Kart
51
Our observations and the in-car video recordings showed that participants were very competitive with each other during the games. Though there was no reward for winning, it was entertaining and interesting to see participants put in a great deal of effort, especially into pumping the balloon. This could be due to either the nature of this specific game or the competitive nature of the students who volunteered. Participant Comments: “I got competitive” - Alec, Ben “If it was only on the screen, it would've been less fun” - Alec “I like being able to see it physically” - Ben “If you're on a typical road, you share the same route (traffic lights and all that). Might be interesting to interact with them. ” - Michael “Didn't make a huge difference to me that we didn't know it each other.” - Michael “I didn’t know what was going on in the beginning, but once you are in the process it is very intuitive.” - Alec “In a car, there's no follow up” - you won’t sustain that relationship” - Ben “I like the silence in my car, it’s my space and I don’t want to be social” - Ben “Wierd.” - Michael “Would be more entertaining if I knew the person.” - Martin Testing - Insights and Reflection The Valeo team’s winter quarter journey started with a plethora of radical ideas and approaches to explore opportunities made possible by autonomous driving. Many users had expressed feelings of boredom and a desire to be entertained during traffic jams. This prototype explores the dark concept of intra-car gaming to address these issues by
entertaining drivers and enabling social interaction in the middle of the traffic jam. The team took the opportunity to test a prototype that allowed drivers in neighboring cars to interact with one another by playing physical games with one another. One key insight that the team found very interesting was that the users’ willingness to participate and their ability to enjoy the gaming experience was highly dependent on their mood and mindset at the time. When participants were given these two options and prompted to play, they participated with a lot of excitement and competitiveness. However, when asked whether they would desire such features inside a real car, our volunteers were unsure of their answer. People mentioned that while this idea was very original and fun, they were unlikely to deploy them in real life. People tend to value their time commuting to and from work as their personal time, a time to relax and think. Their mindset and emotional state are unlikely to prompt them to use their personal time to initiate further social interaction with strangers on the road, no matter if it’s very early in the morning on their way to work or on the way home after a stressful and busy day at work. This key insight forced the team to take a step back and re-frame the problem and the scenario of the problem statement. Before the team could continue to tackle the explicit desires for productivity and entertainment, the team needed to first ensure that the users would be in the right emotional state to take advantage of the available features of the designed system. This new frame of mind allowed the team to see that anxiety and stress are significant
52
barriers to enjoying the commuting experience and so we set our sights on the next destination along the journey - stress relief and stress prevention. Dark Horse Prototype V2.0 Motivation After another round of interviewing users and conducting further need finding, the team discovered a more fundamental need that had to be addressed first before we addressed any solutions that incorporated entertainment & productivity: the need to provide stress relief for commuters. Based on user interviews (see User Interviews section below), traffic is a highly stressful activity for our target users primarily because 1.) they are actively trying to calculate arrival time and make route decisions, and 2.) they are worrying about those they are responsible for. Needfinding - Common findings between interviews
• Hate waiting • Have somebody they are responsible
for that’s waiting for them • In a rush to arrive to destination • Most of commute spent alone in car • Anxious from traffic • Some have anger problems
Stress is the major problem and the major issue preventing users from enjoying the commute! Dark Concept Your car soothes you and relieves your traffic induced stress by invoking a mix of
therapeutic treatments including mood lighting, calming visuals and music, large screen video projection, and stress-relieving smells. Prototype Description This entire prototype was constructed and tested in a real car’s passenger seat. Remote-controlled multi-function LED light strips were attached to the roof of the car, passenger side door, and under the passenger side dashboard. Through some strategic wiring, someone sitting in the back could change the lights to any pattern or color, including all fade, blinking, spectrum, single color, and multi-color.
Figure 14: Building the Dark Horse 2 Prototype
Air fresheners in the vents were used to create a scent that mimics that of nature. Sounds and music were played from a phone or a computer via the car stereo system. An external small portable bluetooth speaker was also used to more accurately simulate sounds of nature and add to sound quality. Images or clips of nature were enlarged and projected onto the passenger dashboard
53
through a pico projector mounted to the ceiling of the car. The clips included calming nature videos, and were controlled by the “wizard” sitting in the back.
Figure 15: Nature Projection onto dashboard
Testing All of the testing was done in Denis’ car, with one experimenter sitting in the back controlling the timing and altering the sound and visuals for the participant sitting in the passenger seat. The goal of the test was to determine how effective each method was in reducing stress for the participant. The methods under investigation included: Mood Lighting Nature Video Projection Soothing Music Files Air Freshener Scents To initially induce stress upon the participants, extremely annoying and stressful sound clips were combined into a 30-second long track. The sound clips included a mixture of baby cries, trucks honking, construction, and death metal. After each round of playing these extremely annoying sounds, the participants were
given different types and combinations of relief agents. There were a total of 5 different combinations that were tested: 1. Nothing 2. LED only 3. Nature video + Nature sound 4. Soothing music only 5. LED + Music (All with the air freshener in the background)
Figure 16: LED lighting with User testing
Each calming cycle was run for 60 seconds. After each cycle, the participants were told to record their calmness level on a scale of 1-10 (with 10 being the most calm) before and after the calming cycle. At the end of user testing, they were asked whether they would realistically use any of the features they had experienced.
54
Please rate, on a scale of 1 to 10, how calm you felt after the stress sounds: STRESSED 1 2 3 4 5 6 7 8 9 10 CALM Please rate, on a scale of 1 to 10, how calm you felt after test #: STRESSED 1 2 3 4 5 6 7 8 9 10 CALM Would you realistically use these features in an autonomous car? Please circle Y or N: Nature projection & sounds: Y/N LED lighting: Y/N Relaxing music: Y/N Testing - Results and Observations After the testing, many users said that the LED light was too bright and should be softened for a more calming effect. The most popular stress relief method was the combination of LED lighting and music. However, users generally had different preferences. Testing - Insights and Reflection The results of the stress relief tests suggested that personal preference is a huge determining factor in the effectiveness of a given stress relief method. It is quite hard to determine a single solution that works to relieve everybody’s stress because everybody has different preferences for soothing methods. Although some were better than others on average, at the
individual level the effectiveness really depends on the users’ specific preferences. Thus, the team decided to further explore and understand the reality of stress. Since finding a single solution to the question of how to relieve stress was too difficult, the team decided to instead dig deeper and ask a different set of questions. Besides exploring ways to relieve people’s already existing stress, a potentially more effective method would be to tackle the root of the problem by addressing the causes of stress for our users. This led the team to the construction of Dark Horse Prototype version 3.0, Stress Prevention. Dark Horse v 3.0 Prototype Motivation After exploring stress relief, our team decided to tackle our users’ anxiety through stress prevention. Our v3.0 prototype aimed to prevent the user from even becoming stressed to begin with, by addressing the source of their problems. We believed this solution, if feasible, to be more ideal than one in which a user’s stress is relieved after it occurs.
Ideation Our team knew, from our needfinding, that commuters find traffic jams stressful for the following reasons:
1. They having someone who they are responsible for waiting for them at their destination (this can be children, the elderly, or pets)
55
2. They expend a lot of energy trying to “optimize” the route of their commute by picking the one that will allow them to arrive as quickly as possible. Despite this, they feel as though they “never win” and always second-guess their route decision after they’ve made it
3. They hate the sensation of waiting with nothing to do
To totally eliminate the user’s anxiety, our team ideated on solutions to tackle these problems individually. To tackle first source of stress, we thought the car could become the user’s personal assistant and manage their schedule. Before the user’s commute home, the car would send them reminder texts, at certain intervals beforehand, reminding the user to head towards their car in order to make it to their destination on time. Once the user has started their commute, the car would provide them with information about their dependents and associated courses of action. For example, a father might receive confirmation that his daughter is waiting for him outside her high school; the car might then give the father the options of either calling his daughter, or sending an automated text saying “Will be there by” followed by the car’s Estimated Time of Arrival (ETA). The daughter might be sent a link to track her father’s route and progress. To address the second source of stress, the car could take on the task of optimizing the route, and itself select the fastest route to the user’s destination. It would put this route on display for the user, as well as an ETA that updates in real-time. The car could address the third source of stress through entertainment and
productivity tools on a touch interface and other means of distraction, including perhaps even physical goods the personal assistant car has picked (magazines, books, a user’s favorite soft drink or food). Each of the three solutions would be highly personalized to the user’s preferences, habits and circumstances. We believed only a customized solution would truly eliminate a user’s stress.
Design and Building To prototype the above concepts, our team conducted a wizard-of-oz experiment, in which we simulated car automation by using another driver, while the user sat in the passenger seat and experienced “autonomous driving”. The user was instructed to avoid interaction with the driver. To be able to properly evaluate the efficacy of our stress prevention solutions, we conducted two runs with each user - one baseline run in which we drove the user in the “autonomous car” without any extra features, and one run in which we incorporated the features of our solution. In this way, we could see how just autonomous driving itself impacted the user’s level of stress, and from that determine how effective our stress-prevention concepts really were. We created two different set-ups for our two different test users, customized to address their specific needs and sources of stress. For our first user, Frances, we planned to text her from an unknown number addressed as “Your Autonomous Car”, letting her know she should leave, as shown in Figure 17 below
56
Figure 17: Text from vehicle
Once Frances entered the car, she would hear a voice message played from a smartphone telling her the car’s ETA. We attached two tablets, one in which she could see an updating map of her car’s route, and another streaming a live video of her dogs at home. We determined that Frances becomes stressed worrying about her dogs at home (see “Interview with Frances Notes” in section XXX), and for this reason included the latter tablet. To create the doggy cam set-up, we arranged with Frances to visit her home and set up cameras near her dogs, which she believed would be streaming live footage of them. This was technologically infeasible however, so instead - and unknown to Frances - our team filmed her dogs for a few minutes from the angles the cameras were positioned in, and instead created a pre-recorded video to play in the car. We left the cameras in her house to have her believe that the dogs were being filmed in real-time. The two tablets were mounted in the car as shown in Figure 18 below.
Figure 18: Tablets mounted on dashboard
For our second user, Heather, we discovered through our baseline test that the “autonomous mode” lowered her stress to a sufficiently low enough level that i) she was in the right mindset to enjoy entertainment offerings and ii) other stress prevention methods, such as route information, would be unnecessary. For this reason, for this iteration of the prototype we provided Heather with entertainment and productivity tools, to distract her from the sensation of “waiting” and “wasting time”. These included the following, all stowed in the passenger seat side compartment and in front of the chair: a book, magazines, a notepad and pen, fruits, a set of dumbbells, and an wifi-connected HP tablet stocked with apps and content for Heather to use. For tests with both users, we mounted one camera pointing towards the user, to record their facial expressions and behaviour during the test, and one camera pointing towards the road, so that if the users reacted to an in-traffic event, we would know what that event was. Screenshots from the camera footage, showing the camera angles, are shown in Figures 19 and 20 below
57
Figure 19: Road Footage from Camera mounted in car
Figure 20: User footage from Camera Mounted in car
Test Feedback Three major findings emerged from our testing. The first was one we did not anticipate but was extremely important: during the tests, both users experienced motion sickness, particularly Frances. For most of the test, Frances was very unhappy due to nauseousness she experienced while being driven. The problem was so severe that she later described being close to throwing up. She explained this as being a result of both the stop-and-go driving, and as a psychological reaction of not being in control of the vehicle. Heather too described that she experienced motion sickness (in a milder form) while looking at her smartphone. This discouraged her from continuing to use it and she ended up storing it away after five minutes of use.
The main take-aways from this finding are that:
1. Motion sickness has the potential to ruin a user’s entire experience, so any design solution must address this, and
2. Users need to be able to have control of the vehicle at their command, if they’re going to feel comfortable
The second major finding that our testing revealed was that users have strong preferences for the layout and features of systems, and need to i) already be very comfortable with the operating system and ii) have the device preconfigured to their desired settings, if they are even going to use it at all. In a follow-up interview with Frances, we discovered that although she found the doggy-cam exciting in the beginning, it “annoyed me after a while; it just gave peeks of my dogs”. She wished she had the functionality to change the camera angle, and in the end paid no attention to the tablet. With Heather, we noticed that she prefered to use her iPhone instead of using the tablet. She later described to us that she was discouraged from using the latter because she didn't have her login info and preferred apps already stored in it. That led us to this significant insight: in-car interfaces must be designed such that the activation energy to use them is lower than pulling out a smartphone, otherwise users will use the latter and the interface will be rendered useless. The last major finding we discovered was that automation itself can bring stress down
58
to a sufficiently low enough level. We asked Heather during the baseline test to rate her stress level, and she responded that the automation brought her stress down “by 95%”. This tells us that in an automated vehicle, a solution may incorporate entertainment and productivity, and not require supplemental stress prevention tools, as the automation itself reduces stress significantly. Other findings from the test are detailed below, and full post-test interviews with Frances and Heather can be found in appendix xxx.
France - Baseline automation
• Frances enjoyed the experience because i) she arrived faster than expected, ii) because she could sit, relax, and begin to wake up, and iii) because the autonomous car’s aggressive driving style matched her driving style
o Take-away: Autonomous car should match or supersede user’s expectations of ETA. The car should also either match the user’s driving style, or if not possible, distract them from noticing
Frances - Automation with prototype
• Reaction to in-car map with ETA was positive; however Frances pointed out that she couldn’t use the information to make a route decision herself, so in her eyes it was useless
o Take-away: Route information should take in active input/choice of the
user, to make them feel as though the route optimization is beneficial and that they’re in control of the optimization
• Reaction to in-car features was very positive; she was very excited to see her dogs. However, she later explained that if she observed them “going crazy”, that would greatly increase her stress during her commute because there would be nothing she could do
o Take-away: Observation is not helpful unless it can be linked to one or more courses of action - e.g. give the dogs food, call for help, etc.
Heather - Automation with prototype
• Heather was neutral about the car reminder. She thinks it would maybe be useful in abnormal circumstances - for example, if her ETA is 10 or 15 minutes higher than it usually is
Pinboard Dashboard and 3D Mapping Motivation From previous research on user interfaces, we had found that in addition to being intuitive, a high level of customizability is also an important design principle to enhance the user experience. This feature allows the user to change the environment of the cockpit so he or she can adapt different setups depending on mood, mindset or personal preference. In addition, a high level of customization helps the user
59
feel a closer personal connection with his or her car. Ideation To create a high level of customization, several features had to be made as flexible and intuitive as a smartphone. First, the car must allow the user to easily change the position of every app within the display surface. Second, there must be easy to set up profiles with saved preference settings for various users. Third, the interaction with the system must be accomplished via gesture recognition or voice recognition to stay in line with the current smartphone’s interaction paradigm and ensure seamless interaction. Finally, the user must receive feedback in order to feel in control of his system at all times. Design & Building With all of our ideation requirements in mind the design team managed to develop a prototype that recreated the experience of having a customizable dashboard. We used a cardboard dashboard with a blank surface and asked the user to fill the blank space with the apps they wanted. In addition, we created a second blank dashboard and used the wizard-of-oz prototyping technique to simulate user control and interaction with the system. We used a 3D mapping tool and Adobe After Effects - with a computer mouse, we were able to move apps to different positions and change colors or background images based on user hand movements or voice commands.
Figure 21: Projector set-up
To give feedback to the user, a visual interface was set up to show the user what setting he or she had chosen.
Figure 22: Projected dashboard
User Testing With two physical prototypes built, we performed user experience tests for each one of them. The first prototype, the blank cardboard dashboard with post-its, was installed beside the cafeteria of the university and several students were asked to fill the blank space with drawings or pictures of the applications they would use
60
in two different modes: autonomous and manual. The second prototype, the blank dashboard with projection and dynamic interaction was set up in our loft space and was tested with members of our teaching team as well as other students in our course. Testing revealed a new set of interesting requirements. With the blank dashboard, we found that users prefer very different setups for manual and autonomous modes. This reinforced the need for different profiles in our next prototypes. The blank dashboard with projection revealed that people want a clear and uncluttered dashboard. This motivated us to develop a minimalistic user interface for further prototyping. Users also expressed a desire to take the steering wheel out when in autonomous mode - this desire was dismissed in previous testing because people had expressed a sense of panic about the removal of the steering wheel. However, we learned during this testing that the reason users wanted to remove the steering wheel was because it prevented them from easily reaching the dashboard. With this in mind, we wanted to test out the concept of bringing the dashboard closer to the user in autonomous mode to eliminate this problem without actually removing or hiding the steering wheel. Christian scenario testing Motivation Motivated by the previous dark horse prototype, in which the high customization capabilities and an intuitive interface allowed the user to change the environment of the
cockpit and adapt it to his or her mood, mindset, and favorite activities, the team decided to further explore human-machine interaction ideas. We wanted to incorporate into the prototype possible daily commuting activities that would be performed by the drivers, as well as develop a clearer way to help them understand the transition between manual and auto mode while interacting with certain apps and in certain situations. To do so, a global understanding of the interactivity between driver, in-car system, and other drivers was developed. With this global understanding of our complete system, users are more likely to propose useful feedback and constructive ideas than if they are just shown a single moment or activity which they will understand, perform or do because they will not be able to relate this to the overall concept of their dashboard. Ideation
It was critical for us to explain the whole scenario in a way that made the following clear to users: how the system can be used in daily commuter situations, what actions can be performed, and how they can interact with the dashboard and the interface. Based on previous user interviews and the needs and insights that came out of these, we established that the best way to accomplish this was through a storyboard which would show users the various features of the dashboard in different scenarios. Design and Building The storyboard was designed only digitally and not physically since it was an extension of the previous prototype, which was
61
already built and helped to show and clarify to the users some parts of the storyboard that may have not been clear enough. Using Adobe Illustrator the storyboard was designed in a simple but powerful way to communicate to the users the main features and characteristics relevant to every situation of the story. The scenario is described in ten frames - in each of them, different features and solutions are presented. Below are the detailed descriptions of each of these frames.
Figure 23: Picture of the main overview of the Storyboard
Frame 1: The storyboard begins with the first user: Christian, who gets in the car and is welcomed by a warm atmosphere full of bright colors and a calming voice that greets him. Frame 2 :
Christian is now driving and his dashboard is now dark blue instead of the bright colors he had chosen to welcome him to his vehicle. Displayed on the dashboard are only his GPS with the route home, the news articles that Christian likes to check at the start of each day, and the real time traffic information which comes in very handy for all drivers, but especially for him because he spends 30% of his driving time stuck in traffic jams. In the frontal dashboard, Christian has access to the standard driving gauges and important information, such as speed and fuel level. Frame 3: As expected, Christian finds himself in a traffic jam during his ride to work, but luckily for him, his automated car tells him that he can now go into automated mode, freeing him from having to perform any manual driving behaviors such as accelerating, braking, and steering. Christian receives these alerts both visually and auditorily - the dashboard changes while a voice-over similar to that in an airplane alerts him explicitly that automated mode is now available. Frame 4: Christian lets go of the steering wheel and now his dashboard changes entirely: his previously blue dashboard with the driving apps fades out and is replaced by his working space which has a more formal environment with a background of the wooden desk he has in his actual office. He has access to his most used apps for work, such as the Notes, Email, SMS texting, and Reading apps, as well as the other apps and widgets on the other side of the dashboard.
62
Frame 5: Christian is now in what we call “closed” mode, ideal for working and focusing on tasks. He is working on his notes with the keyboard that just popped out of the dashboard - the keyboard is just the way he likes it because he can adjust the size and angle so that it faces the main document and is comfortable for him to use. On his left, he now has access to the other widgets such as the weather as well as to his other files. On his right, he is able to follow all of his social networks thanks to the notification center. Frame 6: While he is working, he receives a call from a fellow worker, Claire, who is calling Christian for their appointed meeting that they had scheduled beforehand. Christian is able to answer Claire’s call without having to stop his current work by simply making a gesture as if he was picking up a real phone. The car is able to understand this gesture and connects the call. Frame 7: Christian is now attending his meeting with Claire and so his keyboard vanishes because it will no longer be needed, unless Christian wants to take some notes from the meeting. Now we switch to the other side of the conversation, where Claire is also stuck in traffic and driving the same kind of car as Christian. She, however, is a different person and has different preferences, so her car has a different atmosphere and her dashboard looks much more fun and cool, matching her easy-going, happy personality. Frame 8:
The video call is now over, so Claire hangs up using a gesture with her hand and a confirmation sound tells her that she is now disconnected from the call. Frame 9: Claire continues what she had been previously doing, playing her favorite Rock Band karaoke video game, and she continues to rock the song by playing the drums even on her knees, which she has enabled as contact surfaces and are working now as drums. On her left, she has the game center which connects her with her friends, allowing her to communicate, challenge and share with them all of her gaming achievements. Frame 10: Just as she finishes with her karaoke game, the traffic jam clears up and she is informed by the same voice signal and the information in her dashboard that it is time for her to take back control of the car. Upon receiving this information, Claire positions her hands on the wheel and as the progression bar starts to fill, her fun, playful dashboard vanishes and is gradually replaced by the other dashboard with the traffic info, GPS and driving information as mentioned before. Test Feedback Once the storyboard explaining the main interactions with the system and with other users was presented, we contacted our extreme user, Christian (the same one who stars in our storyboard), to present our storyboard to him and walk him through the scenario, frame by frame. In each frame, we mentioned and explained which activity was
63
being performed and how it transitioned to the next one. Testing with Christian The testing with our extreme user was extensive, and we made sure to discuss everything in detail such that the user was clear on how to use the automated car functions. For the first part of the testing, the user gets inside the car and is greeted with a dashboard that serves as a blank slate for the user to populate as he or she wishes based on his or her preferences. Christian chose a simple dashboard with basic apps and not too much content - when he was told to drag and drop his favorite apps from his smartphone to the car, he chose the following:
• Podcast • Arte (tv series, concerts) • Notes • Skype • Viber
INSIGHTS: The user prefers to have as little buttons/apps as possible in the dashboard. Once again, we noticed that drivers don’t want a dashboard full of content because it creates clutter and makes it difficult for them to focus or concentrate on any one thing. Instead, they all tend to want a simple dashboard with just the main applications they need and as little buttons as possible. This is a key insight that will guide the future direction of the project, because we now recognize that we need to design the cockpit in such way that users will get what they want from it but at the same time not feel overwhelmed by the amount of information displayed to them, which can
lead users to become annoyed or frustrated with the interface and eventually stop using it completely. The next part of user testing involved having the user change the car atmosphere. the first one is the totally blank dashboard or the stock one, as it can be seen in the picture xxx1. to make him understand better how it would look like, he was showed a dashboard set up with the texting app, as it can be seen in Figure 25. after that he was shown the library like atmosphere and the nature one, as shown in Figures 26 and 27. and finally he was shown the night mode setting, which has a color adjustment to be able to use it by night, as shown in Figure 28. - Christian picked an environment that reminded him of a library, out of several options
Figure 24: basic stock blank dashboard
Figure 25: Basic blank dashboard with SMS app
64
Figure 26: Nature background
Figure 27: Christian's choice of background atmosphere
Figure 28: Dashboard night mode configuration
This began the “automated mode” phase of the test, and the user was allowed to access all of his or her favorite applications. Christian enjoyed the following features of the system (some are features he wished the system had): • Traffic jam notifications • Activity suggestions - “in the time you
have, you can do : a,b,c,d, etc.” • Smart content selection - “I would like to
ask for a podcast that fits the time frame of the traffic jam”
• Suggestions based on the awareness of the user (emotion + energy of the driver)
• “I would like to interact with a debate” (podcast)
• The car can download his habits from his phone and suggest things based on this historical data (a la Google Now)
• Plan trip (proposing certain activities along the chosen route)
• Human interface: o “You have selected a
synchronizable house as your destination, would you like to sync it with the car?”
o “You have run out of the groceries you usually consume in your country house - would you like to place an order at the nearest supermarket?”
o “Awesome! you have lost 1kg” o “You look tired, why don’t you
sleep 15 mins and I’ll wake you up?”
• Show domotic issues • Social notifications • Physical keyboard • Change of environment (temperature,
color, massage, etc) with change of driver’s physical conditions (heat, position, etc.) or based on driver’s mindset (work, travel, etc.)
• Body sensing (heart rate, temperature, etc.), driver health monitoring
INSIGHTS: More than a graphical interface, the system must work as a human-machine interface that is able to suggest different activities and options to the driver at every moment of the ride. The car must know the ‘taste’ of the user. The user prefers to have everything digital except for the keyboard, which users prefer to remain physical.
65
Last but not least, integration with existing electronic devices is definitely desirable, but an even more interesting proposition would be to integrate our system with all smart objects available in the market by the time our system is implemented.
For the next change of atmosphere, Christian chose a travelling one, and his setup had the following:
• System takes initiative - helps plan the trip, making suggestions along the way to visit interesting places nearby
• Menu of notifications - itinerary, trip plan, estimated time of arrival, etc
INSIGHTS: The car should be fully capturing not only the outside but also the inside of the car (i.e information about the driver’s health, temperature) and provide an application that succinctly displays this information.
Figure 29: Christian's setting during automated mode
For the last part of the test, the driver is requested to take back control. Christian made the following suggestions:
• Store everything that is currently running
• Give the possibility to continue interacting with the system via vocal commands - system says “now you can dictate to me”
• The possibility to record voice notes that are stored in the cloud and can be accessed later
• Change environment and position of the seat gradually in order to smoothly transition the driver and the car from auto to manual.
• Allow the autonomous copilot to take back control if the driver is not ready (like an emergency option)
• A screen that comes from the roof • Rear and side cameras utilized when
taking back control in order to know what’s happening around the vehicle
INSIGHTS: When taking back control, the user needs more information than usual (e.g rear, side, and corner cameras) because this is the moment when the user feels the least in control. It is unclear to the user if he or she is already in charge of the vehicle or if the car is still managing the situation. This information will complement the auditory and visual notifications, as well as the progress bar.
Once we walked him through the whole storyboard and heard his feedback on the various dashboard configurations, we came up with a final configuration of his dashboard, which is shown in the image below:
66
The extensive feedback from our extreme user gave us valuable insights, and with these in mind, we were able to think of new solutions and ideas for our next prototypes. Fabric Dashboard Motivation At this stage, users had access to the content they desire, adapted to the driving situation (automated mode on or off), as well as having it at their preferred location on the dashboard. We received very encouraging feedback and continued to explore this direction with our funky prototype We found out that this modularity implies that people are physically interacting in different ways with the dashboard. Thus, in order for our users to access their personalized setup, we needed to make sure they could properly interact physically with it. This meant having the dashboard reachable in all situations, forcing us to ask ourselves how we could apply the driving mode duality and activity customization to the physical space.
Ideation We found users were blocked by the driving wheel, which prevented them from touching the dashboard in front of them. Some users even asked us to remove the wheel when the car was in automated mode. However, the consequence of not having the wheel at reach or in sight, led to nervousness in some users. They felt that they could not be as much as in control of the vehicle if they couldn’t see or grab the wheel. Instead of finding a way to move the driver to the dashboard or removing the driving wheel, we took a different perspective, and asked what if we brought the dashboard to the user. With the motivation of having the dashboard to be physically as flexible as its interface, we looked back at our earlier benchmarking and to the BMW Gina concept. How flexible could a car be if it was made out of a stretchable fabric? This concept car has a tubular structure on which a fabric skin is laid down to make the car body.
Figure 30: Christian's settings during transition mode
67
Figure 31: Gina car concept
This technique would not only allow for a dynamic shaping of the car geometry, but also makes the car look organic and almost alive. Such characteristics add fluidity to the user interface and brings an almost human responsiveness to the usual cold digital interaction. The Gina concept car gave us the proof that using fabric to create a dashboard could be done. Our funky prototype was going to be a new kind of dashboard, using the physical flexibility of the fabric and the digital interactivity potential of the projection. It will be both physically and digitally modular.
Design & Building
To obtain the physical modularity we aimed for, we worked on different shape shifting solutions to answer different needs.
Figure 32: Shape shifting idea
From the numerous designs we did and given the time constraints, we chose to build only one prototype to show the concept. A simple shape-shifting platform was installed to the right of the driving wheel, making a part of the dashboard pop out when in autonomous driving mode. This unique solution focused on the core need of users needing to be able to reach the interface more easily. We first build the structure upon which we would stretch the fabric. Using PVC tubes, we made simple L-shape tubular structure with an angle of about 140° between the two planes. The tubular structure not only provides rigidity in a lightweight form, but it also provides us an convenient way to mount this panel to the same prototype dashboard base we used before. Using a sewing machine, we then sewed the fabric onto a tubular structure.
68
Figure 33: Main dashboard panels
Figure 34: Clips attachment
We also made a second structure to complete the dashboard with a center stack panel. Here is the resulting fabric based dashboard, once the panels were fixed on the previous dashboard base. To produce the shape shifting action we designed a curved shape out of a bendable tube. This curve was then joined to another, more rigid, tube that would serve as its pivot axis.
Figure 35: curved tube
The curved tube continues past the intersection with the axis tube, in order to be easily activated by hand. With such results in mind, the fabric choice was of course based on its stretchability. It was also chosen for its neutral color to optimize the contrast for the projected interface.
69
Figure 36: zoom on fabric
To test the personalized interface with our main users/personas, we prototyped an interface using the presentation tool Keynote. We then used the same technique as our projected interface prototype, and displayed the presentation onto the fabric dashboard. This allowed us to go through a testing scenario with our user, by clicking through the different interface setups. It also gives us the opportunity to work on transitions like the one for the activation of automated mode or taking back control of the steering wheel. The overall personalization was built using the feedback we had from our past pin-board prototype and some design intentions we had and wanted to test. (please find presentation slides in appendix) Test & Feedback
Figure 37: User testing
We tested this prototype with our usual personas. Seated in the driver’s position, they were invited to go through a driving scenario, including transitions from the the two driving modes, as well as apps simulations like a smart GPS. Some general feedbacks that we collected from these tests were that users : • appreciated to have an easier access to the dashboard • would like to have more contrast between autonomous and manual mode • would enjoy a human-like digital assistant capable of giving suggestions and hold a fluent conversation These were small changes that we successfully implemented in the interface simulator of our next prototype. Customization was also an important part of our prototype test. Some detailed feedback we received regarding customization was: One of our users told us that she didn’t want the same seat position while driving and while in automated mode. In the end, suggestions like adjusting automatically the seat position and temperature were very recurrent from our users. When we proposed to other users who hadn’t thought of it, they seemed very inclined to have it as well. A reclining seat has been tested in another prototype (ref XX section - @Stanford Funky Prototype) to try to answer this need. In later tests, we also included automatic seat temperature sensors that would measure the driver’s body temperature and adapt the air cooling accordingly. Adjusting the screen inclination with ergonomic issues in mind was well received. Some users went further, suggesting that the design should take into account the user’s line of sight. Some of the users of a certain
70
age group are more affected than others with decreasing sight issues. A major insight we got from this was that over-personalization makes the product more complicated. We also had the feedback from one of our users that she resisted touchscreens at first, but as it became more part of her everyday life, that resistance vanished. Our decision was to allow customizability wherever the “best” solution space was, with the understanding that the user will get used to it and like it. Regarding the interface, some users insisted on having it on the windshield even though they didn’t need to worry about traffic anymore. The fact that we proposed a mostly touch interface made some users react on the need to duplicate some commands with a hands free voice command system. For the transition from automated to manual mode, the 5 seconds transition time was too fast for some users when we suddenly prompted them to take back control. Not only was it declared as too dangerous, but also not pleasant at all for the user to interrupt their activity, especially if it was a very interesting one. Our insight was to find the right balance between having two extremely different environments, and making the transition smooth and almost unnoticeable. This could be done by proposing degraded versions of an app in order to offer a continuity in the activity, while maintaining an appropriate level of safety for driving.
OS simulator on Fabric Motivation The funky prototype gave us the certainty that fabric was an extremely interesting element, opening the doors of a world of infinite new possibilities of shapes, choice of materials and degrees of movement. The logical continuation of that was now to make it real and actually make it work. The idea behind that was to show our users tangible version of the ideas they previously expressed, during the “scenario” prototype testing sessions, to see if it would match the ideal vision they had of it and if it fulfilled their requests. We also had in mind to understand how difficult it was to synchronize the physical movement of the dashboard with digital animations. For us, a perfectly timed transformation sequence was the key to an optimal transition experience, in terms of fluidity and intuitivity. Designing this sequence had been a critical challenge for us since the beginning of the project, due to the extreme constraints attached to it such as: The required time limit of 5 to 10 seconds, the necessary contrast between the two modes for the user to know at first sight what was happening, in parallel to the desired continuity of the task achieving process. Ideation
71
Figure 38: From manual to autonomous
The first step was to search for the best way to trigger that transformation in a natural way. A simple “on/off” button could have probably worked, but we were searching for something more clever: searching in panic for a deactivation button somewhere on the dashboard just seemed like a risky option. We also wondered what would be the first reflex of a driver if he was suddenly told to take over control after a long time of distraction. The answer was quite obvious: he would just rush for the wheel. That’s how it was decided that the autonomous mode would be launched instantly when the driver’s hand would both drop the wheel, and interrupted as soon as he put them both back. To make the experience more immersive we decided to emphasize the contrast between the two modes by making changes in a lot of different elements:
The background image This is a key element in our search for more contrast. The driving environment must remain neutral not to attract the driver’s attention. It must have a dark and matte color to avoid blinding or distracting him. It should also enhance the driver’s consciousness of his surroundings by using side view signals and augmented reality. Conversely, the automated environment should draw the driver’s attention away from the outside to help him forget the discomforts of traffic jams such as noise and visual pollution. A colorful and evocative environment can be a good way to provide a nice relaxing workplace. It’s also a way to remind the driver that he doesn't have to worry about driving. The home screen of the interface The frame of the active area of the dashboard will be directly influenced by the dashboard’s physical shape. This will have a direct impact on how the menus are displayed and how the driver will reach them. The apps setups The GPS is pretty useful during automation for the user to know where he is, how much time he has and how the traffic is changing. A overview of the travel plan gives him a sense of what’s happening and helps him prepare physically and mentally to take over control a long time before he actually has to. But, he doesn’t need the step-by-step guidance with details on the crossroads he’s about to reach. Just like the GPS, a lot of apps will have different functionalities and appearances based on what the user will need for each modes.
72
Figure 39: Application ideas
The relative importance of apps Some apps can be used in both modes, although their relative importance will grow or decrease depending upon other parameters of the frequency at which they will be used. For example, the speedometer and the gas meter are two of the driving widgets that people asked to keep while being in auto mode. But since they are not crucial at that moment, we reduced their size and pushed them to the extreme left of the screen. We wanted our interface to be tailored to the user, as if the car knew him personally. So the interface was personalized to each user we tested. We customized the home screen using their names and profile pics and displaying the apps that they asked for.
Figure 40: GPS for Christian
Design & Building We built this mock-up on the basis of our previous prototypes. The physical part of the dashboard was previously described in the Funky Prototype section and will be developed further in the design specification chapter. The transformation automated using a mechanical system composed of a small servo motor and a Makey-Makey card. The motor was activated by the contact of the tester’s hand on the steering wheel, wrapped in aluminium foil to conduct signals to the Makey-Makey card. We added a projector on a tripod, to project the screen of a computer on which we had the interface-simulator. We decided not to 3D map the projection, because this surface was curved and dynamic. It would have been a long and useless effort to do so and it was not really the purpose of this prototype. The interface elements were all designed with Adobe Illustrator to emulate the graphic design of the Apple’s iOS 7. They were then imported in the Keynote
73
presentation, to add shifting or clicking animations.
Figure 41: Screenshot of Dashboard Layout
We first planned to use a Microsoft Kinect to make the user interact with hand gestures. Given the short amount of time we had, we then decided to simulate the interactivity. Someone from our team imitated the user’s gestures, following his right hand with the cursor, and clicking exactly at the same time. In this way, testers had the impression that they were directly using a mouse with their bare fingers. Collecting Feedback For this session, all the users were chosen amongst the testers of the “scenario” prototype, so that we already had notes of their preferences. After being briefly introduced to the new prototype, they were installed in the cockpit, hands on the wheel and had to act as if they were driving. At some point, we would randomly launch the transition signal, to see if they would naturally let the wheel go, and after a while make them take it back with another signal. In the meantime, they were told to navigate freely through the menus of both modes and try to click on everything they wanted.
They also had to described the reason of their action and what they expected. Being context aware Quotes: “I want the car to change of route if
necessary without asking me all the time” - Christian
“I don’t want to confirm every choice I make“ - Claire
“I wants to choose my mood myself. I would feel so uncomfortable if the car could take decisions without my approval.” - Catherine INSIGHT: The car must adapt its level of initiative to the user: if the user cancels the car’s suggestions too often, the car stops taking decisions. Extending the experience to passenger Quotes: “I use Waze, I share my informations, in fact I’m ok to do anything that can help solving traffic jams. I could even share my car if I knew it could help” - Catherine “I am not comfortable receiving messages from strangers. And what if the software can be hacked?” - Catherine INSIGHT: An automated car is a great opportunity for interaction between driver and passenger, but that must be managed carefully. Only certain kind of interaction are welcomed (A huge majority of women want to avoid flirting for instance). Also, the passenger’s actions must not disturb the driver when he’s in control (by watching movies, playing games, speaking out loud, or any other disturbing activity) A good solution might be to design a special setup for car sharing, that will keep personal informations private and display only some apps and notifications, preselected by the driver.
74
Figure 42: Philippe Testing
The driving wheel Quotes: “I’d not feel safe at all if the wheel could
move around” - Catherine “It’s difficult for me to turn to the sidescreen in today’s car because of the driving wheel” - Philippe “The wheel is in my way, I can’t easily reach the panel to interact. Can’t you remove it?” - Christian INSIGHT: Christian made the wheel fall while trying to show something, that’s why he asked to remove it. But the reason behind that is that he want to have an easy access to all the dashboard. So instead of removing anything, we will make the control panel move up to the user: same result, only safer. An even simpler option would be to find a way to make the wheel part of the interaction system, just like in one of our very first prototype, turning it’s annoying presence into a great opportunity. Transition As an overall result, the grab & drop system did not work very well, for a very simple reason: people touch the wheel all the time without meaning it, simply because it’s in front of them. And they drop it very often while driving: to emphasis their comments, to make a sign to another driver, to scratch,
or simply to rest their wrists. Every time, this triggered the unwanted transition process. It brought us back to the beginning, where we must find a way to make the triggering more subtle, either as a button or a specific command, or by adding an algorithm to the system that would differentiate between a conscious drop or a trivial gesture. Functional Prototype
Motivation Our previous prototype explored one way in which we could make the experience of riding in an autonomous vehicle more comfortable for the user. Pushing this idea further led us to a key insight in our design process - if we wanted to ensure a comfortable experience for users, then we would have to address the often overlooked but extremely relevant issue of motion sickness. For the next three weeks, we set out to understand the science behind motion sickness and how we could design a system to tackle the problem. The result was a prototype that attempted to reduce vertical vibrations felt while in a moving vehicle. Ideation
75
Motion sickness had been mentioned by users in some of our previous user testing, but we hadn’t paid much attention to it at the time because we were more focused on providing entertainment or alleviating stress rather than reducing discomfort. However, after one particular user felt extremely sick during our Dark Horse 3.0 testing, we realized that maybe motion sickness was a major problem that needed to be addressed. At that time we were already building our reclining chair with adjustable screen position, but we began to delve into the sea of existing research and knowledge surrounding motion sickness. Besides just combing the internet for research papers, we were able to get in touch with experts in various fields, ranging from vehicle dynamics to driver comfort. Our fact-finding mission uncovered the following important insights: (please see Appendix XXX for more detailed consultation notes): • Motion sickness is caused by conflicts
and delays between sensory inputs o Sensory Conflict Theory: The
sickness may be caused by cognitive conflict between visual information perceived with the local coordinate system fixed to the vehicle and the information of the body motion perceived by the vestibular system with the global coordinate system.
• There are 4 motions we need to consider: lateral, fore-and-aft, pitch, and vertical vibration
o Our conversation with Professor Paul Mitiguy revealed many intricacies with the motion of the human body in a car seat, including coupling of fore-and-aft with pitch and pivoting of the upper body at the waist
• The main goal is to reduce the relative motion between the image on the display and the head
o Lateral motion is one of the main causes of motion sickness, and most methods explored in past research have been tackling this specific motion:
Image stabilization - moves the image within the display such that it is synced with the movement felt by the head (i.e if you head goes to the right, the image will shift to the left)
Image collimation - a strategy that transforms the image such that it appears to be farther than it actually is . this makes the relative motion between the display and head to be much smaller than it actually is
Visual cues - striped
borders around the edge of the display serve as a proxy for the environment. these striped borders rotate around the screen in sync with the movements of the car in order to match the user’s visual system with the vestibular system
Monitor placement - it is exceptionally important
76
to provide good peripheral vision to the user in order to reduce motion sickness
With a better idea about the causes of motion sickness and proven methods and strategies of dealing with it, our next step was to really determine which of the four movements was the problem we wanted to tackle. Lateral motion had been the focus of most of the existing motion sickness research, but it wasn’t relevant to our problem because of our assumption that the car is moving relatively straight in stop & go freeway traffic. We conducted a preliminary test - we drove around while one of us sat in the passenger seat reading a book. The book was held in our hands. During our testing, we realized that perhaps motion sickness wasn’t the right term to describe what we wanted to eliminate - motion sickness connotes the actual feeling of nauseousness, the feeling in the stomach that makes you feel like you want to vomit. This is actually a more severe case of something we call motion induced discomfort, or M.I.D., which is an umbrella term that includes motion sickness but also headaches, migraines, and in general any feeling which makes the user less comfortable than he or she would be regularly. Our goal really was to reduce M.I.D, and our testing led us to believe that the vertical vibrations played a large role in the headaches we all developed after reading for just a few minutes each so we decided to choose vertical vibration as the motion to tackle for this prototype Mockup
With the goal of reducing vertical vibration in mind, we designed and built a cart consisting of aluminum 80/20 bars, bicycle shock absorbers, a tablet and tablet mount, and a car seat. Our plan of action was the following:
• Measure the vertical vibrations in a real car in traffic
Figure 43: Physics Toolbox Application
We taped a smartphone (with the Physics Toolbox Accelerometer application) to the passenger seat of
77
a car to measure the frequency and amplitude of vertical vibrations felt by the user during stop-and-go traffic. This data was necessary to ensure that our prototype would roughly simulate real-world conditions.
• Build a prototype that simulates the
measured vertical vibrations
Figure 44: Pushing Kevin in our prototype
The initial cart was built with only 80/20 bars, so as to be completely rigid. With this cart setup, we attached a smartphone to the seat of our cart and rolled it across various surfaces to find an initial condition with roughly the same frequency and amplitude of vertical vibration as we had measured in an actual car. Once we had found a stretch of paved road that gave us a similar amplitude of vertical vibration, we adjusted the speed at which we pushed the cart in order to try to match the frequency of the in-car data. We had users sit in the cart and pushed them along a specified part of the paved road at roughly constant velocity while they read a news article on the tablet in front of them.
• Altered the prototype to test the functionality and feasibility of our vibration-damping concept
Figure 45: Rigid bar
Figure 46: Shock absorber
78
After determining the conditions needed to roughly simulate the in-car vertical vibration data, we replaced the 6 rigid aluminum bars between the wheel base and upper frame with 6 shock absorbers to see if this system would achieve the desired effect of damping out the vertical vibrations. We wanted to again push the users at the same constant velocity along the same patch of road while they read a news article on the tablet, but unfortunately our prototype was not durable or robust enough to be tested because of design changes that had to be made as a result of shipping delays and sourcing issues.
Test Feedback Because of the poor construction of our prototype, we did not feel comfortable testing the shock absorber system. In fact, we are really glad that we didn’t have anyone test the prototype because it proceeded to fall apart as we pushed it back to the loft. However, the overall design and building process did yield some important insights, including one that forced us to reconsider whether we had decided to tackle the correct motion to begin with.
Figure 47: Failure
• Sourcing parts is not always a smooth process - for eXpe leave a large margin for parts to arrive
Estimated shipping times are sometimes unreliable, and the retailer’s information is not always accurate. We originally ordered thick 80/20 that matched the existing 80/20 on the chair frame thinking it would be available for pick-up the next day. We called the retailer the next day before leaving for the store - the customer service representative said that somehow the order hadn’t made it through the previous day but that the shipment would definitely be there the next day. So the next day, we repeated
79
the same procedure, now somewhat wary that the shipment would actually be there - with good reason, because again, the shipment wasn’t at the store. This time, the representative on the other end said that she would get the 80/20 shipped to Stanford with a guaranteed arrival by 10AM the next day. Of course, the shipment didn’t arrive the next day, and when we called yet again, the representative said that the shipment was actually on a truck after having left the facility in Chicago. It would arrive in five to six days. We ended up building the entire frame with smaller 80/20 bars that were lying around the shop - the result was a much less structural stable cart. The fact that we didn’t have the thick 80/20 in time directly contributed to the “failure” of our prototype. The moral of the story is that we need to account for things like this to happen next quarter - we cannot afford to waste time waiting for parts to arrive. We need to plan ahead of time and have contingency plans when things don’t go according to our original plan.
• The users that did test the rigid
system did not experience discomfort. This observation forced us to question the validity of our initial hypothesis that vertical vibration was a significant factor in M.I.D. We had isolated vertical vibration by essentially eliminating fore-and-aft, lateral, and pitch motion. With only vertical vibration in play, we thought
we had roughly simulated the situation where a user reads content from a display mounted to the dashboard of a car. If vertical vibration really was an important cause of M.I.D., then our users should have experienced some discomfort from riding in our cart while reading on the tablet. However, the fact that they didn’t experience discomfort was a telling sign that we needed to back up and re-evaluate the situation. Either we hadn’t simulated the situation well enough, or vertical vibration just wasn’t an issue - either way, we needed to determine which motion was responsible for M.I.D, and we set out to do just that following our failed prototype.
Post-Functional Testing
Figure 48: MID Incidence Chart
From our conversations with Paul, the four motions that were relevant to us were fore-and-aft, pitch, lateral motion, and vertical vibrations. The first thing to point out is that our previous stress-prevention tests with Heather and Frances served as valid data points for the case with all four motions because we had driven them along a route that included turns and curves in the road. We also tested this scenario with each of the four Stanford team members. All but
80
one of us experienced some form of M.I.D, so we knew that M.I.D. was a real problem and that one or multiple of these motions was contributing to it. Right off the bat, we eliminated lateral motion from our consideration because the system we are designing for is only for use in stop-and-go freeway traffic, which is relatively straight and at low enough speeds that lateral movement is a non-issue. We then wanted to isolate the remaining variables. The first variable we decided to isolate separately was vertical vibration, since that had been the motion we had previously thought was the issue. Even as we had been building our functional prototype, we had continued to conduct user testing, both with ourselves and our colleagues. We realized that the preliminary test we had used to select vertical vibration as the focus of our prototype actually wasn’t a very realistic simulation of the situation that we would have in an autonomous car - our initial test had users holding the reading materials in their hands, whereas in an autonomous car the user would presumably be interacting and/or watching a display attached to the dashboard or frame of the car.
Figure 49: Vertical Vibration Testing
This test was designed to roughly simulate vertical vibration while watching a screen. We had users sit on a vibrating massage chair while they watched a computer screen that was also sitting on another vibrating massage chair. Both the user and the computer screen were therefore experiencing only vertical vibration (none of the other three motions). What we found was that vertical vibration alone does not cause a high incidence of discomfort. In fact, out of the five people we had test this setup, only one of them reported any discomfort (the one user reported minor a minor headache). In our next test, we added fore-and-aft and pitch back in to the motion to see how this would affect the incidence of M.I.D. We ideally wanted to isolate fore-and-aft and pitch, but we realized that the amount of pitch we are dealing with is actually very little, especially if we reasonably assume that the autonomous car is a smooth driver (this is a reasonable assumption given the already existing smart algorithms that allow autonomous cars to predict into the future and adjust accordingly).
81
Figure 50: Fore and aft testing
We had users read and watch content from a tablet that was attached to the car dashboard while we drove them down a single straight lane of traffic (University Avenue through downtown Palo Alto, CA). We made sure to exclude lateral motion by asking the users to not begin reading or watching from the tablet until we were on the straight road. The results of these tests were promising - we tested 11 users, and only 1 of them did not experience any discomfort. From these results, it was clear to us that fore-and-aft motion should be our focus going forwards - we had found that vertical vibration alone did not result in a high incidence of M.I.D, but vertical vibration plus fore-and-aft (and very small amount of pitch) resulted in a high chance of M.I.D. Therefore, we concluded that adding fore-and-aft into the equation had caused this spike in M.I.D and decided that we would attempt to reduce fore-and-aft motion in order to reduce M.I.D in users.
After speaking with various experts in dynamics and controls, we realized that trying to dampen out a wide spectrum of frequencies is a difficult challenge, so we used the data we had collected in the car and measured the dominant frequency of the “vibrations”. We found this to be 0.04 Hz with an amplitude of ~0.3 G’s.
Figure 51: Graph of fore-and-aft vibrations
The conclusion from this post-functional prototype testing is that we will move forward with the goal of reducing fore-and-aft motion, with a particular focus on motion with frequency of 0.04 Hz.
4.6 Final Prototype Development
Dashboard The Carmeleon system is designed to be integrated into the car’s cockpit and create a more personalized space for the driver. Various prototypes had influence upon how we developed our concept for the car’s dashboard. In our first critical experience prototype in France, where we were tasked to build a prototype of what we thought would be a critical experience for our user, we tested where the most ideal keyboard position was for people. We sat people in front of a dashboard and had them place pieces of paper where they would use a
82
keyboard, finding that it heavily varied from person to person, but there was a decent contingency that wanted the keyboard right in front of the steering wheel.
Figure 52: Paris Critical Experience Prototype
In another prototype where the dashboard was built so that people could physically move it towards themselves, people liked that they didn’t have to reach for various controls and that everything was within reach. This was further confirmed by the funky prototype at Stanford, where we were tasked to build a completely functioning prototype, but it did not need to be incredibly high resolution. A user sat down in a chair that had a screen in front of them, and they could control how far away the screen was away from them and at what angle it was held. People really liked that they could touch the screens and interact with them comfortably.
Figure 53: Touching the screen on our Funky prototype
We also ran another test in which we drove people around to simulate car automation, to find out what they wanted to do. Not surprisingly, many people ended up looking at their phones. However, they did not use it for long, usually because whatever they really wanted to do was a little difficult on a small screen. So, we ran another test where we taped a tablet to a car dashboard and drove people around again, just to see if that would change how they interacted with digital technology. Surprisingly, more people were willing to use the tablet for longer. All of these insights helped us create the hardware half of the Carmeleon system.
83
Figure 54: Automated Car Test
The “automated car” tests helped us solidify that in automated cars, people will likely be interacting with digital technologies to access the outside connected world. The second test in the “automated car” allowed us to solidify the fact that we wanted to use large touch screens in the cockpit space. We settled on a three touch screen interface because of how a standard car is set up. The two main places where a driver looks in the vehicle is the instrument panel console and the center stack. These two areas were where we decided to place the two 13” tablets. The third tablet was placed in front of the steering wheel, based on our feedback from our critical experience prototype described above. From the physically movable prototype and the functional system prototype, we knew that people liked things coming within their touch, so we designed a system of linear actuators and mounts to make it such that the 13” screens would move towards the user in automated mode for their use. The overall dimensions of the cockpit space were determined by measuring various cars and the space available in those vehicles.
Figure 55: Final sketches of screen locations in cockpit
Software Motivation Following the concept vision for our system to be your journey’s sidekick, we knew that our Human Machine Interface would have to be able to perform various tasks and to have an accessible as well as simple and clean interface. This was important to ensure that the driver can understand and differentiate the behavior of the car in manual and autonomous mode. Ideation
84
One of the most important parts of our final product is the user interface that goes hand by hand with the rest of the cockpit. As described before, Carmeleon is a hardware and software solution that will significant improve a driver’s traffic jam experience. Although it was always known that the Human Machine Interface was a big part of our solution, no major development was made until the beginning of the winter quarter. Some broad and simple interactions were brought up and thought about in the fall quarter, but it wasn’t until a couple of months ago that we really started to think more in-depth about the interface between driver and machine. The idea of a smart assistant was developed for winter quarter and presented at the open doors presentation at Paris - a storyboard combined with a physical prototype was used to demonstrate how an intuitive and smart interface could help the driver perform a huge amount of tasks in less time, and how it could improve the driver’s experience by having something or someone to rely on. Continuing with this concept, we constructed a common scenario of a commuter using our system, in which we were able to identify main interactions and responses from the system, and we tested our storyboard with different users to make sure the system was clear and to test if there was any feature or action that was important but that we may have left out. Once we had our first results about the interface, we started implementing it in our prototypes, starting with the very first one: the 3D mapped dashboard, which can be seen in the next picture:
Figure 56: 3D mapped dashboard
Thanks to this prototype we were able to get a better idea of how the car dashboard would look like and what kind of applications we were going to have, and most importantly, how the apps could be distributed in the dashboard depending on the driver’s configuration. This prototyping and user testing allowed us to really address user customization and full dashboard interactivity. In the next few weeks, we continued to improve and implement new interactions with the interface. When we prototyped the shape shifting prototype at paris, we included a new version of the interface, which was better designed and allowed new functionalities, such as the biometric interface and the transition between manual and autonomous mode. The majority of the Human Machine interaction was shown in the animatic that the team at the paris est d.school developed for their open doors at Valeo, in which it is possible to see how Carmeleon interacts with the driver in various situations ( see appendix for more).
85
Figure 57: Screenshot of Animatic
After discussing with Valeo and taking into account all of responses we received from users regarding our interface, we were confident that our concept would address their needs and were ready to start developing the final iteration for our prototype, especially because the spring quarter was coming. Design and Build The first step was to design an interface that would match our insights, ideals, and vision - an interface that would be clear and easy to understand for the user, that would allow him to differentiate and be aware of which mode the driver was on, that would let him do any entertainment or work related activity, that would prevent him from unauthorized usage of his phone inside the car, and that would not distract the driver while in manual mode. We also wanted the interface to be customizable to allow the user to change and download new apps according to the driver’s interest.
After this, we defined the most important applications to be displayed by default in our system and we started sketching on paper the main interactions that the apps would have with the user It was not easy to make the interactions clear and suited for an in-car interface, but we managed to sketch every app for every screen in our cockpit that we were going to use in our final prototype to demonstrate to our users. Once we had our most important apps designed, we proceeded to make the real design in Adobe Illustrator to give a nice, clean-looking appearance and to begin the most challenging and important part of the interface: the behind the scenes programming.
Figure 58: Our 3 screen interface
As can be seen in the image above, the interface is split into 3 screens - to help you understand the interface and what is displayed to the driver, we will first provide an overview of the main functionalities of the system as a whole, followed by more in-depth descriptions of the interactions with each individual screen. Main Interface Overview
86
The driver will first be in manual mode, aware of the situation and in full control of the car - the human machine interface will be shut down and disabled so the driver will be focusing on the road. Only important driving information such as speed and gas level will be displayed to the driver. As soon as the driver hits traffic, the GPS located on the left side will inform the driver that there’s going to be a gap of time in which the car can go automated and the screen on the steering wheel will become active and inform the driver that he can now go in autonomous mode. Once the driver has pushed the button and the car has transitioned into autonomous mode, the whole interface will change and now the driver will have the important information at one side, the gps and route tracking at the other side, the main interface control at his fingertips, the real time feedback at his right side and the main interaction with the apps in front of him. Thanks to the interaction with the steering wheel, the driver will be able to access all of the functionalities without changing his seat position or posture and without having to check his phone. Once the traffic jam has cleared up and its time to go back to manual mode, the user will be once more informed by the car and as soon as he transitions back into manual mode the interface will be disabled again to avoid distractions and to ensure a safe manual drive.
The Frontal Screen
Figure 59: Front screen in manual mode
The frontal screen is a very important one - it displays the most important driving information while in manual mode, but in autonomous mode its interface changes entirely: (picture of frontal screen in autonomous mode)
• Left side - gps and route tracker that displays the position of the vehicle along the route and green bars that represent where and for how long the driver will be stuck in traffic jam and have the option to go autonomous.
• Right side - driver will still be aware of
what’s going on with his car because valuable information such as car’s speed, GPS and steering wheel status are displayed here
• Center - all apps will be displayed
here when opened, the user will also be able to see and open other apps from a menu of icons
The Center Stack Screen
87
Figure 60: Center stack screen
This screen is located at the right side of the driver in the center stack, it will contain useful car customization option such as the air conditioning and also important car features like the defrost feature and many others. When in automated mode, the user will have full access to real time feedback that will allow him to be aware of his surroundings and to understand how the autonomous car is driving. This will make him feel in control of what's going on around him, which is very important because the majority of the drivers are afraid of not having control over an autonomous car. Thanks to this information it will be very easy for them to take back control quickly and safe. Lastly, this screen also enables user interaction - the driver can drag and drop or just swipe apps between screens so he can
personalize his space the way he always wanted to. The Steering wheel screen
Figure 61: Steering wheel and screen
This is the main point of interaction for the driver, since he will be able to control everything at his fingertips. Once the system is active, the interface will be enabled and the driver will be able to access to the apps. Depending on which app the driver is using, the steering wheel screen will display the most important controls for this app. For example, as can be seen below, the driver is using the Media Player to play his favorite songs, so he is able to see the album cover in the frontal screen while using the steering wheel screen to control the media player settings - he can pause, fast forward or browse his music list without having to lean forward or to the side, and without having to use awkward and confusing buttons or voice commands.
88
Figure 62: Three screens while in media player mode
It is very simple for the driver to interact with this tablet, since the tablet remains fixed at all times and will not turn with every turn of the steering wheel - this ensures a much better experience than having to turn your hands and body in order to continue interacting with a screen that rotates with the wheel. Once the driver can go back to manual mode, this part of the human machine interface will be disabled and the user will not be able to perform any other task until the next autonomous phase, in which he will be able to return to his previous tasks and continue doing what he likes the most. Once we had all of this clear in our heads and the aesthetic design of the interface was fully completed, it was time to program the interface. Programming the interface In order to program the interface we used android studio, thanks to it we were able to code our graphical interface and to enable the main interactions for the users to test our final prototype. Due to our previous duty of designing the interface, it went very quick to code it, however, the majority of the problems resided in the tablets used to simulate the
dashboard, because of the lack of Ram memory and the processing capabilities, the app would ran out of memory and freeze, which led us to the conclusion that in order to provide a robust and effective functional prototype, we must have good quality materials and components. Due to the complexity and the fact that the main interaction to show to the users was the interaction between the steering wheel tablet and the frontal one, we focused on programming 2 out of 3 tablets, and since the interactions to be displayed in the 3rd tablet were simple it was a win-win. The main built in apps that we focused on are: 1. Messaging 2. Phone 3. Media Player 4. App Store 5. Cloud 6. Settings M.I.D Reduction System Motivation While conducting in car experiments, the team found a high percentage of users mentioning the fact that they felt motion sickness while using electronic devices or when reading in their cars. It’s apparent that motion sickness, technically called Motion Induced Discomfort (M.I.D) has the potential to ruin the whole in-car experience in autonomous cars since nobody can enjoy something while feeling nauseous and dizzy. Ideation
89
To tackle the problem of motion induced discomfort (M.I.D.), the team entered spring quarter with two possible solution paths in mind. The first is through a physical system in the form of a damping chair. The idea is to construct a spring damper system to drastically reduce the impact felt by the passenger sitting on the chair in response to sudden movements of the real car and in turn, decrease the likelihood of M.I.D. occurrences. The second solution paths aims to tackle M.I.D. through the utilization of visual cues. Through Implanting a method via software or hardware where the passenger can gain an additional sense of the live motion of the car while they are interacting with the screens, sensor conflict experienced by the passenger could be reduced, which would correspond to M.I.D. reduction. After thoroughly examining these two options, the team decided that while a physical system solution would be very interesting and potentially effective, building such a system under great time constraint and also perfecting it in time for EXPE is unlikely. Visual cues on the other time, would involve much less hardware and would be faster to build, test, iterate, and implement with more electronics and software involved. The sensory conflict theory states that the discrepancies of signals send by the vestibular system and the visual system can cause motion sickness. Therefore, any visual cue solution should incorporate a way to reduce this discrepancy. From group brainstorming and benchmarking of existing ideas, several potential solutions arose, including image manipulation on the tablets themselves, body sensors to give posture
feedback, and sensory conflict correction hardware in peripheral vision. M.I.D. remedy is a territory that very few existing technology have sought to address in car systems. While each idea's effectiveness is not so predictable, it is exciting to delve into a solution space that could potentially address a critical identified need. Amongst the three ideas, the peripheral vision hardware could potentially integrate beautifully with the rest of the dashboard system, and is relatively easier to construct and iterate. Therefore, the team chose this to be the first M.I.D. idea to prototype. M.I.D. LED "Tunnel Vision" To correct the discrepancy between visualized motion (fixed by distance between eyes and screen) and vehicular motion (actual speed of the vehicle sensed by the vestibular system), the team sought for ways to potentially amend the false sense of motion visualized by the passenger by giving visual cues that the vehicle is moving, while interacting with the tablets. Thinking about how speed can be sensed visually, a very applicable situation would be when a car drives through a tunnel or at night, and the driver is greeted by a streamline of road lights passing by. In three point perspective, as the car speeds forward, the lights on both sides of the road slowly changes shape and speed. A similar idea can be implemented inside the car, where the user will experience the similar situation, with the help of LED strips. While a simple pattern where the LEDs flows towards the user would suffice, there are several characteristics that would improve the effects:
90
1. Layout of lights in perspective, closer together toward the horizon, and more spaced out as they come towards you
2. Lights dispersion is more concentrated further away, and more diffused as they come past 3. The effects themselves, should be able to simulate flow where discrete light sources can be discerned, therefore imitating light sources coming past. Design and Building The most used nowadays rapid prototyping electronic ready to program board is the Arduino UNO so we programmed an Arduino to create an apparatus with LEDs that allows the car to create visual feedback to the user in order to reduce the conflicting signals sent by the sight and the vestibular system to the brain. These LEDs should be bright enough to being seen in the daylight and no too bright to be comfortable and non-distracting for the user. So, the team researched about light diffracting materials and we came up with the idea of sanding a piece of acrylic on the sides to diffract and diminish the LEDs light. With the desired effects in mind, each LED strip is constructed by soldering 16 individual LEDs together. While this turned out to be a tedious process, it is desirable that each LED can be individually controlled and programmed. Most LED strips found in store are nonprogrammable, or too costly
for this purpose, while soldered strips also gives the team greater control over the stripe housing. Because these 2 strips (one on the left, one on the right) need to be situated on the dashboard, it is desirable that their housing is stable, nonintrusive to other parts of the system, and is aesthetically pleasing. One great way to create the frosted look onto the LED strip is through the utilization of an acrylic housing. Test and Feedback The blurry effect that the side-sanded acrylic gave to the MID system was regarded as smooth and nice to the view of the testers and it creates some motion sickness while being tested which was very good since we were creating motion sickness by creating just one conflicting signal that when the car was moving would perfectly go against along with the movement signal and would delete the feeling of motion sickness.
91
5. Design Specification 5.1 System Overview Our team designed and built the first version Carmeleon cockpit for presentation at the Stanford EXPE and Paris d.school EXPE in June 2014. The cockpit was named Carmeleon to reflect our team’s vision of the car as a space that morphs to meet its user’s preferences and desires. The heart of the Carmeleon system is a dashboard that dynamically changes between two modes, autonomous and manual driving. In manual mode, the system’s behavior resembles a traditional cockpit. Two 33.7 cm screens, one in the dashboard and one in the center console screen, display important information to the user about his or her drive, including speed, proximity of the car to surrounding objects, etc. Once the car has entered a traffic zone and is travelling under 35 km/h, it is permissible for the user to activate autonomous driving mode, done by pressing a switch located behind the steering wheel. Once autonomous mode is activated, a number of changes take place as the car morphs for the user. The two 33.7 cm screens move towards the user, and the dashboard screen is now available to open the user’s apps. It can be controlled either directly or by a 17.8 cm tablet in the center of the steering wheel. To prevent the user from experiencing MID while interacting with the screens, a series of LEDs located in the user’s visual periphery flash at a speed equal to that of the car’s. The software offering on the steering wheel tablet and dashboard screen now changes, allowing the user to access to apps such as music,
media, and texting, as well as an online app store. Lastly, the car now takes over control of the steering, and the steering wheel and column rotate left and right, giving the user indication of the car’s motion, and the option to grab and take back control whenever needed. Features of the first version of the Carmeleon cockpit:
• Two 33.7 cm tablets that move towards the user in autonomous mode
• 17.8 cm tablet to control the dashboard tablet
• LED backlit transparent switch to activate autonomous driving
• Two LED strips that flash at a speed equal to the car, to counter MID
• Steering wheel controlled by car in autonomous mode
• Software offering that includes standard apps as well as access to an online app store
The hardware and software features chosen for the first version of Carmeleon were the features we believed most central to our vision, as well as most feasible to incorporate given our time frame. Many features which we initially explored, and which we believe are important for the perfect user experience, had to be left out in the first version.
5.2 Multi-screen Interaction The hardware half of the Carmeleon system involves the use of three touch screens: two 13” screens and one 7” screen. For the final
92
prototype, we used a 13-inch Hannspree tablet and a 7-inch Nexus tablet. The mounting system for the 7” Nexus tablet will be described in the Steering Wheel Mechanism section of this documentation.
Figure 63: Scott using our system
When the car is put into autonomous mode, the two 13” screens move towards the driver. This is accomplished through the use of two Firgelli mini-style linear actuators. Each actuator had a 12” stroke length and moved at a speed of 1 inch per second, while providing a push/pull force of 15 lbs-force. To integrate the actuators in the wooden cockpit frame, mounts were laser-cut out of duron and glued together around the actuators. These mounts were then screwed into the 45-degree angled wood sheet inside the wooden cockpit frame.
Figure 64: Wooden frame for Linear Actuators
The tablets had the ability to be tilted to a person’s personal preference. This was achieved by attaching the head of a camera tripod onto the linear actuator. For the dashboard tablet, a one degree of freedom tripod head was used, while a three degrees of freedom tripod head was installed for the center stack tablet. For each linear actuator, the top of the shaft was tapped so that we could put in a threaded stud. Then, the camera tripod head was screwed onto the stud, connecting the actuator and the tripod head.
Figure 65: Behind screen view
93
Figure 66: Screen side view
Two identical fixtures were made to connect the tablets with the camera tripod heads. The fixtures were made from plates of aluminum and milled down to minimize weight. A hole was drilled and tapped at the center of the back of each fixture, so that the plate could be screwed onto the top of the camera tripod head.platform, which already has a screw to mount on cameras. Last, industrial grade double-sided 3M tape was used to hold the tablet in place on the aluminum plates.
5.3 Software Even though Carmeleon opens the door to a connected world, the team mainly focused on 6 of the most important apps that every driver should have in order to have a unique experience while in traffic jam and of course the transitions from manual to autonomous and the other way around however, as the reader will be able to realize in the numeral 5. We give the opportunity to the drivers to expand their features and options as well as to have their system updated at all times. The 6 built in apps in which the team focused for the final prototype are: 1.Messaging
Thanks to this interface, the drivers are able to communicate either trhough sms or email with their phone contacts by simply activating the app, typing on the steering wheel surface and having ALL their messages as well as SMS being displayed in front of them Thanks to this, we will provide the drivers with a solution to one of their most common needs: social interacting through messaging. As it can be seen in the picture above, the small screen is the main remote and has valuable information such as the keyboard, type new SMS or email and your most contacted friends, and the frontal screen will display the conversations and the recent chats. 2. Phone The drivers also enjoy having phone calls during their commute, and thanks to our built in App which will sync all of their contacts with the car, they can make and receive phone calls, video calls and video conferences from their driver seat, without wasting precious time performing dangerous maneuvers to pair their phone with the car’s bluetooth and trying to find a way to sync their contacts while the car is driving. As it can be seen, the table in the steering wheel controls the call and the frontal one displays the contacts and also the ongoing call. 3. Media Player This app is very useful and very popular in every car, nowadays people just sync or plug in their phone/iPod and have their favorite music played.
94
However, in the Carmeleon system, the media player merges nothing more and nothing less than all of their media: Music, Pictures, Video, books and so on. As it can be seen in the next pictures, the steering wheel has the main control and interactions related to each media player component, and the frontal one is dedicated to display the content to the driver. 4. App Store this one is the brain of the interface, and will allow the driver to download any app that he might want or need, either to work or to entertain himself, the app store has a wide range of apps suited for every driver’s profile and will keep your system updated. As you can see in the picture above, the user has the main navigation options once more in the small screen and the main information displayed in front of him 5. Cloud Thanks to this app, the driver is able to sync all of his devices with the car and to access them in order to access valuable information such as emails, documents, notes and even more, as it can be seen in the picture below, the driver is able to access to his fridge and consult his groceries, and thanks to this valuable information, he is now aware of the situation and can perform a reroute in order to get to the closest super market and buy whatever he needs 6. Settings In the settings app, the driver will be able to know more, understand and change the way their system works, in this part, the user will be able to customize his car in terms of
software and apps as well as in terms of its driving. The image below shows an example in which the driver can choose the settings for his car, and can also access other important settings for autonomous driving, such as pedestrian detection or dynamic driving. But also is capable of managing his accounts or just choosing his favorite background The Transitions Both manual to auto and auto to manual transitions have been designed to be clear, informative and quick, thanks to this the driver is able to understand and differentiate in which phase his car is in. at the transition point the interface will become available and the steering wheel screen will display a message to the driver, inviting him to go automated. Once he has pulled the trigger to go automated, he is able to see a confirmation message in the small screen and a change of interface in the front and side screen. In this moment the whole interface will change and now the driver will have the important information at one side, the GPS and route tracking at the other side, the main interface control at his fingertips, the real time feedback at his right side and the main interaction with the apps in front of him. Once the traffic jam has cleared up and it’s time to go back to manual mode, the user will be once more informed by the car in the screen located at the steering wheel and as soon as he transitions back into manual mode the interface will be disabled again to
95
avoid distractions and to ensure a safe manual drive. The front screen will switch back to its original information which will display the normal and common driving widgets communicating to the driver that he is now in manual mode especially because he is able to tell the difference between modes. The Suggestion Lists Another awesome feature in the interface is the suggestion list, which based on the estimated time of the autonomous phase, and based on the time it takes for certain activities and tasks to be performed by the driver, will advise the driver to accomplish the already mentioned activities. The information will be displayed in the small screen located at the steering wheel and once the driver touches any of the suggestions it will launch the application that is linked to the task. Once the driver fulfills one of the tasks, it will be checked in the smart list, archived and a new task will be presented to the user as a suggestion
5.4 User Interface
Figure 67: Steering wheel screen, manual to autonomous
Figure 68: Steering wheel screen, autonomous to manual
96
Figure 69: Front Screen in Manual Mode
97
Figure 70: Front Screen in Autonomous Mode (No apps
98
Figure 71: Manual Mode, Center Console Screen
99
Figure 72: Phone App - Front Screen
Figure 73: Phone App - Wheel Screen
100
Figure 74: Mail App, Front Screen
Figure 75: Suggestions on Wheel Screen
101
Figure 76: Messaging App, Front Screen
Figure 77: Messaging App, Wheel Screen
102
Figure 78: Media Player (book), Front Screen
Figure 79: Media Player (book), Wheel Screen
103
Figure 80: Media Player (movie), Front Screen
Figure 81: Media Player (movie), Wheel Screen
104
Figure 82: Media Player (pictures), Wheel Screen
Figure 83: Media Player (music), Wheel Screen
105
Figure 84: Device Sync, Front Screen
Figure 85: Device Sync, Wheel Screen
106
5.5 Electronics
Figure 86: MID circuit diagram
Figure 87: Motor circuit for linear actuators and motor
5.6 Steering Wheel Mechanism
Motivation When the vehicle enters autonomous mode, the steering wheel is expected to be
navigating and turning on its own without needing any further input from the driver. Furthermore in the Carmeleon system, there is a center tablet situated on the center of the steering wheel. This tablet will not rotate no matter what the steering wheel does, and thus, there needs to be a system built in place to isolate the tablet from the steering wheel. Design In the vehicles of today, the steering column generally follows the rack and pinion mechanism to turn on a single shaft. However, with emerging technology such as drive by wire, it is reasonable to assume the steering column design will be redesigned in the near future. This, in combination with project time restraints, allowed the team to reasonably decide not to build an actual car's steering column. Instead, the team needs to create a system that is able to demonstrate the new experience imagined by the Carmeleon system. To decouple the motion between the tablet and the steering wheel, two separate shafts are used for mounting each device. A custom laser-cutted acrylic steering wheel with a bushing is mounted onto the outer shaft. Utilizing 2 press fitted roller bearings on both ends of the shaft, the inner shaft is mounted inside and one on end is connected to the tablet housing via a press fitted shaft hub. The other end of the inner shaft is permanently fixed onto the platform, so that it will never be able to rotate. The two shafts can move independently, and are mounted on an angled platform utilizing pillow block bearings to recreate the steering wheel geometry.
107
To simulate the autonomous vehicle driving on its own, it is desirable to have the steering wheel rotate on its own once the mode switch change button is pushed. For this purpose, the Animatics Legacy Smartmotor is used. This motor is very easy to program utilizing BASIC, has an internal micro controller thus only needing the Arduino to provide high or low digital outputs to turn it on and off. This motor is mounted onto the platform, and through spider couplers, rotates a belt connected to the outer shaft via a QD Bushing. The motor is programmed to turn the steering wheel at random left and right, with the angle never exceeding 30 degrees from the horizontal. This angle was found through empirical testing driving in highway traffic, as the turning almost never exceed this degree. The tablet housing mounted to the upwards end of the inner shaft is constructed to not only mount the tablet facing the user, but also to house the wireless charger for the Nexus, as well as the wires connecting to the button. The shaft hub screws into the duron, and velcro is used to mount the tablet onto the duron. Because the Nexus can only be changed in the center, a deliberate rectangular slot is cut out the fit the wireless charger. On the back of the housing, the mode switch button made out of acrylic is mounted, with either a green or a blue LED gently lighting up the button based on current mode.
108
Figure 89: CAD of Steering Wheel Assembly
Figure 88: Isometric CAD view of Steering Wheel Assembly
109
Figure 90: CAD of Steering Wheel
110
Figure 91: Exploded CAD of steering wheel
111
5.7 Cockpit The basic frame of the car cockpit space was created using wood 2x4 pieces and plywood sheets. Inside the wood frame were two sheets of plywood, with one sheet being held at 45 degrees and another at 30 degrees. The overall dimensions of the frame is 36” x 52” x 36”.
Figure 92: Wood Frame Only
Figure 93: Partial Acrylic Covered Frame
Sheets of acrylic were used to make the frame look like a car dashboard. Different holes and cut-outs were made in the acrylic sheets using a laser cutter. Then, using a heating element, the acrylic sheets were bent into various curves. This was accomplished by heating the sheets and then pushing them against various wood jigs built by the team to facilitate uniform bending and control the angle of each bend.
The bent acrylic was then placed over the wood frame and attached to the wood using the 3M double-sided tape.
Figure 94: Heating acrylic
Figure 95: Bending acrylic
The armrest was built using layers of pink foam glued together. The foam was cut using a pink foam cutter. The side of the armrest was covered with black fabric, while another foam piece was covered with leather and glued on top of the pink foam armrest. The armrest also had a bent acrylic piece attached to the pink foam that was then connected to the acrylic on the wood frame. These two separate acrylic pieces were glued together using acrylic glue.
112
Figure 96: Pink Foam Armrest
Figure 97: Bent Acrylic
The sides of the wood frame were covered with sheets of plywood, cut to mimic the shape of a car dashboard. They were then covered with black fabric and attached onto the wooden frame using brackets.
Figure 98: Completed Cockpit
113
5.8 Motion Induced Discomfort Reduction
The system to prevent Motion Induced Discomfort (M.I.D) is based on the fact that unsynchronized signals from the vestibular system and your sight produces the sensation of being dizzy and may cause puking and headaches. To tackle such a problem there is a lighting apparatus that signals to the driver that the car is moving so the conflicting systems are now not conflicting therefore, reducing the incidence of M.I.D.
The apparatus was built using a series of LEDs connected in parallel with a common ground to two shift registers commanded by an Arduino UNO microcontroller. By doing so, we sent synced signals to the brain of the user. The apparatus was covered on the top with Laser-cutted black acrylic and on the side with blurred acrylic in order to diffract the lights of the LEDs and show a bigger signal to the user. Also the shape of the acrylic was cut in a way that goes towards the user so he/she can see it with his/her peripheral or front view as it is shown below.
Figure 99: Wiring the LEDs
114
Figure 100: Testing the LEDs
Figure 101: M.I.D System in prototype (view from side of prototype)
115
Figure 102: Acrylic covering for M.I.D (from driver point of view)
Figure 103: Driver point of view of the dashboard and M.I.D system
116
To make the lights actually flash, the following pseudocode was implemented: The MID code only has one state but checks various things in its loop. First, it checks to see if the entire circuit is enabled. If the circuit is enabled, then the software iterates over every LED. As it iterates per LED, it turns on the current LED and turns off the
previous LED before it in the sequence. If it is the first LED, the software will turn off the last LED in the sequence. If the circuit is not enabled, then the software will just turn all LEDs off and leave them off. The circuit being enabled corresponds to the cockpit being in autonomous mode, while being disabled is in manual mode. The actual Arduino code can be found in the appendix.
5.9 CAD Drawings of Mechanical Systems
Figure 104: Linear Actuator Mount
117
Figure 105: Dashboard Frame Side View
Figure 106: Dashboard Frame Top View
118
Figure 107: Dashboard Frame Behind Screen View
Figure 108: Dashboard Frame Front of Screen VIew
119
Figure 109: Dashboard Frame
120
Figure 110: Dashboard with Acrylic Covering Front View
Figure 111: Dashboard with Acrylic Side View
121
Figure 112: Dashboard with Acrylic Top View
Figure 113: Dashboard with Acrylic, view from Driver side
122
Figure 114: Dashboard with Acrylic, View from Passenger side
5.10 Bill of Materials This is a comprehensive list of materials that are currently in our prototype and how much they cost.
Item Quantity Cost Per Item Total Cost Notes
2x4x96 Lumber 6 $2.82 $16.92
7/16 in x 4 ft x 8 ft plywood sheet 3 $10.25 $30.75
#8 3 in wood screws box 1 $10.98 $10.98
A21Z Right Angle Brackets 50 $0.35 $17.50
TP15 Tie Plate Bracket 50 $0.58 $29.00
1/8" Acrylic Sheet 2 $57.20 $114.40
123
1/16" Acrylic sheet 1 $25.75 $25.75
1/4" Duron Sheet 1 $8.00 $8.00
80/20 1010 Series Aluminum Bar 2 $8.51 $17.02
Caster Wheels 4 $28.05 $112.20
Pink Foam Boards 4 $10.17 $40.68
Hanspree 13.3" Tablet 2 $269.99 $539.98
Google Nexus 7" Tablet 1 $197.58 $197.58
Single Action Camera Tripod Head 1 $59.98 $59.98
Dual Action Camera Tripod Head 1 $60.00 $60.00
12" stroke, 1" stroke speed linear actuators 2 $119.99 $239.98
LED strips 2 $29.95 $59.90
Black Utility Fabric Speaker Cloth 4 $9.99 $39.96
Arduino Uno 1 $29.99 $29.99
Arduino Motor Driver 1 $12.99 $12.99
15V Power Supply 1 $0.00 $0.00 used from loft
Protoboard 1 $0.00 $0.00 already had one
Animatics Smart Motor 1 $0.00 $0.00 donate from professor
Pillow block bearings 4 $64.13 $256.52
Gear belt 1 $16.32 $16.32
Ball Bearings 2 $8.67 $17.34
Aluminum tube 1 $0.00 $0.00 found in loft
Aluminum rod 6 ft .25 in diameter 1 $6.08 $6.08
Button switch 1 $0.50 $0.50
Aluminum plates 1 $15.11 $15.11
Total
$1,975.43
124
125
6. Project Management 6.1 Expected vs Executed
Plan At the start of spring quarter, we laid down a plan for the entire spring quarter in order to have a clear vision and to ensure that we would be able to accomplish all of the objectives in time for EXPE in June. To do so, we allotted a certain portion of spring quarter to each milestone, making sure to account for the time needed to brainstorm, design, and build our prototype, in addition to preparing for various exhibitions and demos. Despite the fact that we were working from across the Pacific Ocean, our entire team worked hand-in-hand, with the team at ENPC working primarily on software development and user interface design and the team at Stanford working primarily on the hardware and physical systems required for our prototype. The ENPC team also was responsible for implementing the M.I.D reduction system. Because the prototype was to be built at Stanford at the end of the quarter, we figured this was the best way to distribute the work for the first seven weeks before ENPC arrived in the United States, and the integration of the two sides of our project really went smoothly upon arrival.
Once ENPC arrived at Stanford, we again evaluated what tasks needed to be completed and what the revised deadlines were for the three weeks before EXPE. The figure below is a Gantt chart of the many required tasks and shows who was responsible for which elements of the prototype. Our two electrical engineers from ENPC focused primarily on the electrical circuits and the code to control the hardware. Our industrial designer from ENPC worked on designing the user interface and user experience, which he then handed off to a computer science student we acquired at the beginning of the quarter to finish coding and implementing the software on to the three tablets. The rest of the team was focused on the physical elements of the prototype - building the steering wheel, building the dashboard frame, manufacturing the acrylic dashboard shape, constructing the booth, etc. Taking a look back at the timeline proposed at the beginning of spring quarter, it’s fairly clear that we were unable to meet most of our deadlines. However, despite the fact that we were behind for most of the quarter, we really pulled it all together in the last three weeks and were able to push ourselves to successfully complete our project.
Task Due date Status Valeo Work Sessions Weekly work sessions accomplished on time Build scale model damping system 4/7/2014 N/A - final design changed Development of Digital + interaction proto 4/7/2014 accomplished on 5/27/2014 User Testing Digital+Interact Proto 4/8/2014 accomplished on 5/27/2014 Part X Prepare Protos for valeo open door 4/9/2014 accomplished on time
126
Order materials 4/6/2014 accomplished on time Open door day with Valeo Experts 4/9/2014 accomplished on time Build 4/17/2014 accomplished on time CAD longitudinal motion tracks and seat 4/5/2014 4/5/2014 Order materials 4/6/2014 4/6/2014 Build 4/17/2014 4/17/2014 Penultimate Integration 5/8/2014 5/18/2014 EXPE Final Manufacturing and Assembly planning 5/10/2014 5/21/2014 Paris teammates Co-work at stanford 5/12/2014 accomplished on 5/12/2014 EXPE Brochure Draft 5/27/2014 accomplished on 5/29/2014 EXPE Brochure Final 5/31/2014 accomplished on time EXPE Poster 5/30/2014 accomplished on time EXPE Rehearsal 6/3/2014 accomplished on time Physical elements of prototype completed 5/31/2014 accomplished on time Software elements of prototype completed 5/31/2014 6/2/2014 Prototype fully integrated and functional 6/1/2014 6/4/2014 EXPE 6/5/2014 accomplished on time Final Documentation 6/10/2014 accomplished on time
The first seven weeks of the quarter really were tough for us - we had an especially difficult time meeting the deadline for Penultimate because we were still trying to figure out what we wanted our final prototype concept to be. We ended up achieving Penultimate-level integration about a week and a half later than expected, although at that point we already had a lot of momentum moving forwards since the arrival of the ENPC team at Stanford had made communication a lot easier, resulting in increased productivity and efficiency. The software and electronics systems were the most time-consuming and difficult elements of the project to complete, and we were unable to meet many of the deadlines we had set for these systems. We did not achieve full integration until the night before EXPE, which was the cause of a considerable amount of stress and anxiety. We were unable to test our final prototype with users before EXPE, although we did have enough time the night before EXPE to ensure that our prototype would be functional for the entire duration of EXPE. Nevertheless, at the
end of the day, our team managed to finish the prototype and booth construction on time and were able to successfully present it on June 5th, and the slow first seven weeks of the quarter did not prevent us from pulling it all together at the end. Other things did.
6.2 Deliverables and milestones
Deliverables Date Corporate team formation 10/22/2013 Benchmarking Review 11/7/2013 Critical Function and Critical Experience Prototype 11/12/2013 Fall Presentation 12/11/2013 Fall Documentation 12/13/2013 First team meeting in Paris 12/16/2013 Meeting with Veronique in Paris 12/17/2013 Meeting with Valeo representatives in Bobigny 12/18/2013 Brainstorming session in Paris 12/19/2013
127
Dark Horse v1 Prototype 1/16/2014 Dark Horse v2 Prototype 1/23/2014 Dark Horse Final Prototype 1/30/2014 Funktional Prototype 2/13/2014 Functional System Prototype 3/6/2014 Winter Presentation 3/13/2014 Winter Documentation 3/18/2014 Paris team presents at Valeo open-door 3/28/2014
Part X is finished 4/17/2014 Paris team arrives at Stanford 5/12/2014 Penultimate Review 5/15/2014 EXPE brochure due 5/30/2014 EXPE poster due 5/31/2014 EXPE presentations 6/5/2014 Final Documentation 6/10/2014
6.3 Summary Budget Stanford ENPC
Fall Expenditures $810.20 173.89€
Winter Expenditures $2,123.67
1567.27€
Spring Expenditures $4,927.97 4101.20€
Total Expenditures $7862.84 5842.46€
Total Allotted Budget: $8000 6000€
Amount Unspent $138.16 157.54€
6.4 Distributed Team Management
Effective team management played a critical role in our product development and realization process, especially in the last three weeks when the ENPC team joined the Stanford team in the US. After meeting each other and spending a couple short days together during the project kickoff in October, the ENPC team and the Stanford team went their separate ways. While the ENPC team was at Stanford, we had exchanged emails and other contact
information so that we could stay in touch remotely. Throughout the fall and winter quarters, the ENPC team and the Stanford team communicated primarily via email and video chat. Google Hangouts with all members of the team were held on a weekly basis, typically for an hour or two on Monday morning in the US and Monday evening in France. These weekly chats were used to update everyone on the progress made over the past week and to discuss plans for the upcoming week. During the fall and winter quarter, the two teams were generally exploring different concepts and spaces and could work separately during the week, so this structure worked quite
128
effectively. When necessary, other video calls could also be scheduled in between the mandatory weekly meetings - these calls typically were scheduled via the team email list and were used to discuss important pivots or decisions that were relatively urgent and had to be made before the next scheduled call. Our weekly Google Hangouts always followed our weekly conference calls with Valeo, which were generally an hour and a half starting at 8:30AM (US) and 5:30PM (FRA). Patrice Reilhac was typically the moderator of the conference call, with Loan My Descourvieres and Julien Moizard joining in when they could. These conference calls were really for Valeo to hear about our progress and the ideas and concepts we
were exploring, and to provide us with their feedback and thoughts. Patrice, Loan My, and Julien were all extremely helpful in answering our questions and helping us understand Valeo’s hopes and expectations for the project. The first few weeks of the project were particularly challenging in terms of managing the expectations of the two different teaching staffs as well as of our corporate liaisons - we felt that we were being tugged in many different directions and weren’t sure how to make everyone happy. However, as we got to know Patrice, Loan My, and Julien better and began to better understand the philosophies of our teaching staff, we soon realized that their hopes and expectations for our team were actually very much in line.
In December 2014, between fall and winter quarters, the Stanford and ENPC teams met face-to-face again, for the first time since the project kick-off in October. We soon realized that we needed to be in touch on a more regular basis so that we knew what our counterparts across the Pacific were doing and so that we could operate more as a single team instead of two separate identities. That week in December was critical in making sure that we entered winter quarter with the right mindset and as a cohesive group going forwards. Veronique Hillen, dean of the ENPC d.school, was particularly helpful in clearing up the doubts we had from the fall quarter and setting us on the right path. After the Stanford visit to France, our team felt much tighter-knit and the communication between teams picked up drastically. We began to talk to each other 3-4 times per week as opposed to the 1-2
times per week during fall quarter. As we continued to delve deeper into the design process, Valeo expressed a desire to be more involved with the development process - our team was happy to hear that our liaison was interested in our project and wanted to be more involved. Around the middle of winter quarter, we began having an additional weekly conference call with Julien and Patrick Bonhoure, a user experience designer at Valeo who Julien brought on to assist with our project. As opposed to the Monday conference calls, these conference calls with Julien and Patrick were more like working sessions - we would bounce ideas off of each other and discuss various concepts and prototypes. Julien and Patrick actually held two such sessions each week - one with just the Stanford team, the other with just the ENPC team. This structure made sense because we were pursuing quite divergent paths at the time with our prototypes and overall project direction.
129
Spring quarter was noticeably more fast-paced and hectic, and as a result, the amount of tension and potential for conflict and miscommunication increased significantly. Our team was poised to handle the added stress and tension because we had already addressed minor team dynamics issues earlier in fall and winter quarter. As a result of those team dynamics meetings, we had already established ground rules for mandatory weekly meeting times and holding each other accountable. Good communication between Stanford and ENPC was critical during the first few weeks of spring quarter as we tried to converge on the prototype concept we wanted to show at the end-of-year exhibition in June. Even after we had finalized the overall concept, it was difficult to get both ENPC and Stanford on the same page in terms of actual features and the specifics of what we wanted to show in June. Once the ENPC team finally arrived at Stanford three weeks before the exhibition, it was much easier to communicate our thoughts to each other and we were finally on the same page once more and ready to start making it happen. Right off the bat, we decided to create a more structured plan and schedule for the three weeks leading up to EXPE. We created a Gantt chart that listed all the tasks that needed to be completed, when they needed to be completed by, and who was assigned to work on them. We selected one member of our team (Denis) to hold everyone accountable and make sure that we stayed on schedule. This system worked really well because it ensured that everyone on our team knew exactly what they needed to do and could manage their time accordingly. Denis checked in with each member of the team at the beginning of each day to get updates on the progress of their tasks.
This system for managing our team was really effective, and without it, our prototype would most likely still be unfinished to this day. Working on this project has taught each of us about the intricacies of working on a global team and how to manage the special communication challenges that come with it.
6.5 Team Reflections Sarah Toukan As I reflect on the past year, I am hugely grateful for the opportunity the ME310 course opened to me. It has been a year working with an incredible team, an incredible corporate partner, on an incredible project and I don’t think I could’ve partnered with a better set of individuals. With regards to my team, it has been learning a wonderful 7 months learning from them, and from our interaction with one another. We had our fair share of team dynamics issues, however there was never an issue left unresolved and never lasting negative energy. I believe this is because each of my teammates was open-minded, fair and empathetic, and open dialogue was in many cases an opportunity for personal growth. Dealing with overseas communications with our teammates in Paris was at times very difficult, and I believe more frequent meetings on google hangout - had we had the time - would have been valuable. Once our teammates were in with us in Stanford, our communication vastly improved, but still experienced minor hiccups while the eight us were scrambling f to finish in time for EXPE. In terms of the project, I found working on it at every stage tremendously interesting, and
130
loved rotating from different activities to advance the project - needfinding, user testing, prototyping and back. I have come to the belief, however, that ME310 is better experienced as a full-time class - as with our teammates in Paris - than just one of several classes. At all points, our team could’ve benefited from more time spent on the project - more time spent meeting to regroup, to have more high level reflection and discussion, to prototype, to talk to users, and much more - and I believe an immersive ME310 experience would’ve exponentially increased our understanding of the design process. I’m so proud of what we ultimately accomplished, and will forever keep the learnings and memories from this project with me in future design projects. Kevin Le The last year working on the Valeo project has been an incredible, fun and challenging experience. I learned quite a bit, not only about the design process, but also about how to work with a team in a different country and how to manage a project of this length of time. Fall quarter was exciting because we had just launched our project and met our team, both from Stanford and from Paristech. We were all relatively new to the automated car space and knew virtually nothing about what that future might look like. From the beginning, we set various ground rules in regards to meetings and getting work done in a timely manner. In retrospect, this was a great decision, because it set expectations from the start and everyone knew that they could and would hold each other
accountable. Fall quarter was also a time for exploring the automated car space and understanding what that landscape would entail for drivers of the future. By the end of the quarter, we were knowledgeable about the space and also had some various ideas about what some of our user’s future pain points might be. After our trip to Paris between fall and winter quarter, we had an even better idea of what direction our teaching team and Valeo wanted us to pursue. Most of winter quarter was spent building and testing various prototypes with real users. We learned a great deal about how varied people’s preferences were in regards to things such as preferred screen position, seat position and stress relief techniques. This helped us realize that whatever we ended up creating needed to be extremely customizable. In addition, we also found from our prototype testing that motion induced discomfort could be a huge problem depending on what we tried to implement in our project. These two major learnings from winter quarter really defined our project and led us to creating the Carmeleon system. Spring quarter was all about building and design. We initially thought that we would be able to create a dashboard and a seat damping system, but the consensus amongst our teaching teams and Valeo was to focus on one. This was great advice because actually creating the entire cockpit space turned out to be an 8-person job. After we quickly figured out how we wanted everything to look, we made the designs and manufacturing plans with a sense of urgency. I cannot emphasize enough how much time is actually required to create the entire prototype. In winter quarter, we
131
underestimated how much work was left to be done for spring, but we were able to realize our mistake and commit to completing the project. The design phase took a little bit longer than usual, but we were very cautious with the process, so that we would only have to build everything once. In that respect, I would not change how we proceeded with the design, because it worked well for us and we were able to complete the project. It was an amazing feeling to have so many people genuinely excited about our product during the final presentations and at the EXPE fair. Even better was validation from our sponsor that this was something that he could see Valeo pursuing as a legitimate part of their business. From this entire experience, I would offer a couple pieces of advice. One, I would value the in-person experience above everything else in this class. We used the time at the global kick-off event to get to know our French counterparts and build a great rapport with them, making the rest of the year extremely easy to work with them. Most of our trip to Paris was spent with our team for further team building, but also productive brainstorming and research. This in-person interaction really made it feel as if we were working on an 8-person team and not two separate teams of four people. Second, I would be cautious with user testing and meetings with professors as well as the teaching team. Although they can be incredibly useful and really helpful in guiding teams towards completing the project, if the team does not take everything said with a grain of salt, it will get lost. I felt that at times, our team, collectively, would focus on something that one person said and that caused us to sometimes completely send our project in a completely different
direction. Too many of these pivots led to a great decline in our team’s productivity and also caused a bit of confusion amongst team members. Last, I would not be afraid to speak up and also not to take things personally. Various times, my group held team dynamics meetings to hold each other accountable and figure out ways to improve our productivity as a unit. In this, I was able to speak up about what I wish others would do differently, as well as hear what I can do to contribute more to make the team work better. These are lessons that aren’t applicable just in design and are things that I will remember moving forward past this project. Swag. Andrés Bedoya. From the very beginning I could feel that I was working with a great team. First quarter was a time to explore our user needs and also my teammates desires for the project. Once I understood that it was easier for me to get involved in the project since I realized that they were as committed and interested as me in putting the best of us in our work. During this quarter everything was really blurry I couldn’t understand what was the main need and since the information to cluster was hyper huge I felt completely overwhelmed and didn’t give too much of myself to the team. After self reflection at the end of the first quarter my friends encouraged me to go beyond my fears and reservations because I was really scared to give my ideas being in a foreign country in which I couldn’t even talk the language. I still don’t know why that affect me so much but it did.
132
Once my teammates told me that I could give more I took that as a challenge and I went on a way more active mode. The whole team change it’s dynamics after the first self-reflection I guess due to the level of maturity and tolerance of all the members. We got more clear, more proactive and way more analytical so, during second quarter we prototype as never before and came up with a very intensive synthesis in which we create what it would be the baseline of our future concept. After second quarter we consolidate our concept and landed it in a final prototype that would be what we called the first step to our vision. Carmeleon and Janus, the two names of our product were pretty close to what we envisioned and opened the doors to the acceptance of people and general public. They could finally dream with what we dreamed during the whole project. This path to the final prototype helped me to understand that a good team produces good ideas but just an awesome team make dream with a real experience based on hard work, good communication, persistence and hope until the very end. RAFAEL GUEVARA This last year working with valeo and with an international team has been an awesome experience. Throughout the past 9 month I have learned, laughed, enjoyed and worked with the most awesome people I could have met in the ME310 community. Since the very beginning, at the kick off we built a very strong relationship with our teammates at Stanford, and thanks to a teamwork based on trust, friendship and
respect, it was possible to have such amazing results and such a great experience working across seas. After doing an incredible ethnographic research the fall quarter, we deep dived into the prototyping world, in which all of our skills were put at probe, in order to make the best out of each prototype despite the lack of time and sometimes materials we had. it wasn't until the end of the winter quarter, that we were able to have a clear vision and a solution to dream for in our project, and this vision was built in less than three weeks at stanford and at Radicand labs, which I would like to thank for their warm hospitality and great workshop areas. thanks to hard work and less sleep we were able to encompass our vision as good as possible in a prototype and a 12 minutes keynote that went as good as expected and that opened the paths of acceptance from the public and other design teams and professors. It was an unforgettable experience to see how connected the audience was with us and how amazed people were with our solution, but the best and most gratifying feeling was to see all of that people lining up in front of our prototype just to tr it for themselves and to have their traffic jam experience reinvented, which was the WHOLE point of our project. Last, but not least, I would like to thank VALEO and all of our corporate partners, specially Patrice Reilhac for this incomparable experience and for their great support along this year. without them any of this would have been possible. I have love for all of you my good friends, thanks for this awesome year and I hope to see you all real soon and share a meal either
133
at Stanford, Paris or even at my home town in Colombia ! DENIS LIN What a year. I can’t express how proud I am of our team and what we’ve done this year. Three weeks ago, I never would have thought that we would have the success we had at EXPE - in fact, three weeks ago, I didn’t even know what our prototype would look like. We’ve come such a long ways since when we met for the first time as strangers back in fall quarter. We were so clueless back then - clueless as to how windy the path really is before finally finding the pot of gold at the end, clueless as to how many sleepless nights it would take to achieve success, clueless even as to what we were even doing. Looking back at this year, there are both positive and negative moments that stand out in my mind. The moment that shines brightest in my memory is at EXPE, seeing the reaction people had when they saw our prototype, seeing how eager they were to try it, seeing their enthusiasm as they interacted with it. The darker moments that are equally memorable are the many times that our team faltered, when team dynamics issues that were simmering just under the surface finally boiled over. Let me leave off with some advice. Team selection is critical to how much you enjoy your project and how well your project will turn out. A team that works well together can come up with a great solution to a seemingly boring problem, but a team that doesn’t get along will inevitably fail to solve even the most interesting problem. This course is an exercise in dealing with team dynamics issues and figuring out problems
for yourself - do not expect to receive much external guidance. It is a test of perseverance and determination. How long are you willing to swim in the sea of ambiguity to reach the island of nuggets? Hopefully your answer is something like 2 ½ quarters… FELIX MARQUETTE In the previous documentation, I had choosen 8 words that best described my feelings concerning the winter quarter and what we had achieved then. I said I was fulfilled by all I had learned, achieved, built during winter quarter. I was torn between the original concept and the down to earth product that comes to reality. I was lucky to be part of such an amazing team. I was frustrated by the time that project management takes in a project. I was gratified to see I found my place in the group as the only designer among seven engineers. I was surprised of how often I was surprised. I was concerned about some ethical issues, for example how automated cars could turn out to be one more step on the path leading to total technological alienation. And finally, I was determined to try and go even further. Now that one more quarter has past, I can look back at what we did. And I can proudly say that … I have learned even more, on an infinity of different topics. We used so many techniques that were new to me, from laser cutting to acrylic bending. And we met so
134
many new people. Exchanged so many ideas. With the help of the teaching team, I managed to find the right balance between the crazy and the pragmatic. We now have a product that is not only completely awesome, but also very feasible. The links within our team got even stronger. And I hope - in fact I am sure - that we will keep in touch long after ME310. Project management is no longer a problem to me. I have just started to see how my design skills and the experience I have could help me handle my time, and how a better organisation can help me design better solutions I am now a bit of an engineer, and all of my teammates have something of a designer I am surprised of how much I want to keep being surprised. I am more than ever determined to do my best and push innovation in the right direction. For a better future, where technology brings humanity to a new level of freedom. And finally, I am impatient to see what’s gonna happen next. Stanford EXPE has passed, and it was probably the most amazing moment of this year - until now. Because our new goal is to do even better for Paris’s EXPE. And because after Paris EXPE, a new challenge will be waiting for us... Jules Scordel
Presenting our prototype and concept last week at EXPE was an incredible time for all of us. I felt that all the hard work we put in this whole year, and especially these last weeks proved us right. People testing our prototype were curious about it, and positively surprised by what we had to make them test. I couldn’t even have had expected such gratifying feeling of accomplishment and usefulness for our user, and our corporate sponsor Valeo. We were able to do so because of the team we are, what all of us were able to bring to this project, and the ability of all of us to work discerningly and in a great spirit. This started from fall quarter, when we started to work together. It might have took some meetings and adjustments to establish a fitting working mode, but it wasn't too long after which we could have very interesting and constructive meetings. When the team was physically united as a whole, in Paris, and later for a more crucial time, in Stanford, it really made a difference, as we managed to go through some difficult and always unexpected situations without frustration or breaking this team dynamic. I feel lucky to have worked on this project my teammates. The commitment of some to the project might not have been the same for all, due to some different schedules, but I felt that everyone tried to give the most of himself in this adventure, even after too many sleepless nights. I feel also lucky to have the opportunity to work with such corporate liaisons. All our liaisons at Valeo were instrumental in making this project happening, by providing some but very useful indications, when our team seemed to be lost in too many possibilities.
135
Our teaching team also helped us a lot, pushing harder every time, and opening our eyes on some essential issues that we put aside sometimes, being too much focused on detailed assignments. Jiarui David Zhang Looking back, there's simply too much to say about all the experiences and learnings I came out of this class with. Working so intensively and immersed in this project has been an experience filled with all possible scenarios you can imagine, including countless ups and downs. Starting from the very initial brainstorming session, to early prototypes and deeper dives into certain topics, to failing or having to switch directions completely, to finding the "aha" moment, to struggling with the project vision, to making personal sacrifices and dealing with team dynamics, to all the all nighters leading to the very last day, and eventually to standing next to the final EXPE
booth looking at everything you have done. All of that, makes up what ME 310 is to me. A journey to discover through doing, iterating, and learning what it takes to bring an idea into fruition. I am grateful for that journey. I want to thank my wonderful teammates for going through this journey with me for this entire year. Working in different time zones and time commitments, learning how to work with each other's style and personality, and finding a path through all the ambiguity was not easy. In fact, it was way harder than I had ever imagined. But we made it through, and our hard work paid off. Standing proud next to our prototype in the very end, explaining to the line of curious and intrigued people queuing by, seeing the smiles on their faces and their thumbs up made it all worthwhile. Team Valeo, we did it!
136
7. References 7.1 Bibliography Barry, Keith. "The Future of In-Car Technology." Car and Driver. N.p., 10 Apr. 2010. Web. 18 Jan. 2014. Dagmar Kern, Angela Mahr, Sandro Castronovo, Albrecht Schmidt, and Christian Müller. 2010. Making use of drivers' glances onto the screen for explicit gaze-based interaction. In Proceedings of the 2nd International Conference on Automotive User Interfaces and Interactive Vehicular Applications (AutomotiveUI '10). ACM, New York, NY, USA, 110-116. "DOMI by Do Hyung Kim & Team, South Korea." Michelin Challenge Design. N.p., 2014. Web. 14 Feb. 2014. Fingas, Jon. "Google Applies for Patent on Gesture-based Car Controls." Engadget. N.p., 3 Oct. 2013. Web. 18 Jan. 2014. Hirao, A., Kitazaki, S., and Yamazaki, N., "Development of a New Driving Posture Focused on Biomechanical Loads," SAE Technical Paper 2006-01-1302, 2006, doi:10.4271/2006-01-1302. Hirao, A., Kato, K., Kitazaki, S., and Yamazaki, N., "Evaluations of Physical Fatigue during Long-term Driving with a New Driving Posture," SAE Technical Paper 2007-01-0348, 2007, doi:10.4271/2007-01-0348. "How You’ll Interact With Google’s Self-Driving Car: Gesture-Based Controls." Carscoops. N.p., 4 Oct. 2013. Web. 18 Feb. 2014.
Kato K, Kitazaki S, Sonoda T. Effects of driver's head motion and visual information on perception of ride comfort. SAE. 2009. Kato K, Kitazaki S. A study of carsickness of rear-seat passengers due to acceleration and deceleration when watching an in-vehicle display. Review of Automotive Engineering . 2006. 27(3):465-469. Kondoh T, Yamamura T, Kitazaki S, Kuge N, Boer E. Identification of visual cues and quantification of drivers' perception of proximity risk to the lead vehicle in car-following situations. Journal of Mechanical Systems for Transportation and Logistics . 2008. 1(2):170-180. Krome, S., Holopainen, J., Walz, S. P. (2013): Enjoyable Stress Reduction: Approaching A Design Space For The Piloted Driving Context. In: Adjunct Proceedings of the 5th International Conference on Automotive User Interfaces and Interactive Vehicular Applications. Eindhoven, NL. Parker, Laura. "Drive Time: RMIT's New In-car Entertainment System."Theguardian.com. Guardian News and Media, 30 Sept. 2011. Web. 18 Feb. 2014. "Toyota Fun-Vii Concept Vehicle." Motor Trend Magazine. Motor Trend, 29 Nov. 2011. Web. 10 Jan. 2014.
7.2 Consultations Professor Paul Mitiguy
137
Paul Mitiguy is a Consulting Professor in the Mechanical Engineering department. His specialization is in dynamics, modelling, control and vibration. How feasible do you think a damping seat+display might be? What are your thoughts on the system and modeling it? The system you’re tackling is a coupled problem. The rotation of the person’s vestibular system is connected to the longitudinal acceleration, not just the car’s pitching motion. The person can essentially be modeled like an upside down pendulum in the seat during deceleration and braking. The rotation of their vestibular system can be reduced with a seatbelt, or much better, a 5 point harness I suggest de-coupling: model a damper system that deals with one variable first (either fore-and-aft motion or picth motion), and see if you can do without tackling the second Your primary goal before doing anything should be to determine what causes the motion sickness - whether it’s pitch of the car, forward accelerations and decelerations, turning, vertical vibration, pivoting of the upper body at the waist Professor Satoshi Kitazaki Satoshi Kitazaki is a neurology professor at the University of Iowa with a strong background in mechanical engineering and driver comfort and ergonomics. He has conducted a large amount of research on effective means of reducing motion sickness in cars. Could you please briefly introduce your background?
I used to work for Nissan Research Centerin Japan. Now, my research is on driving safety with older people. Could you tell us more about your research? I worked to solve motion sickness in the back seat. Sensory conflict theory doesn’t really give you the solutions. You have to ask, what is really causing conflicts in the brain? Sensory conflict is a discrepency between your local coordinate (visual) vs. global coordinate (Vestibular system). I worked on providing image control in reaction to any braking/acceleration motion to match these coordinate systems Our experiments involved measuring participants' sickness level (Asking participants every 5 min how they are feeling) There is a trick: Image stabilization. Logos are also a trick. You needed it to divert their focus of vision. Could you tell us more about how you quantitatively measured motion sickness? There are some standards for motion sickness, including: ISO2631 International standard BS British standard MSDV (only for vertical vibrations standardized) Frequency component is definitely below 1 Hz What other methods have potential to reduce motion sickness? Good seat support can help reduce motion sickness How the vehicle is driven is also very influential on motion sickness Maybe you can tune engine and transmission for a smoother drive in automated cars Eco mode has shown to reduce instances of sickness as well
138
Monitor placement plays a difference. Access to peripheral vision (direction of gaze vector) can help reduce the sensory discrepency. Could you tell us more about your experiment doing image collimation? The relative motion between ground and display and the relative motion between display and head contribute towards conflict. Image control cancels the relative motion between ground and the display now, we need to control relative motion between the display and the head. Our study using image collimation (through lens) is that when your head moves to left, the image follows you. When your head moves upward, the image moves upwards as well. This achieved 30% reduction of sickness. To make this work however, the size of the apparatus was too big for the car cabin. That was several years back, but now you can maybe use head tracking to synchronize image. Any more suggestions for our project going forwards? Front passengers may be a little different than passengers in the back seat. Front passengers acquire less sickness, and have access to more peripheral vision. Good support of seat and body is good for not only sickness but also comfort. If driver is not holding steering wheel, seat support becomes very important for comfort. If you study a good seat design for the passengers, it could have potential to reduce sickness as well as increasing comfort Avinash Balachandran and Jonathan Goh
Avinash and Jon are PhD students working in the Professor Chris Gerdes’ Driver Dynamics Lab at Stanford University. This interview with Jon and Avinash was quite casual. They provided some good feedback on what the team plans on doing and provided some interesting inputs on what the team should look into. It seems to us that they are very knowledgeable about controls and spring-damper systems - we may want to check in with them next quarter to see if we are on track and to see if they have any suggestions or recommendations on the design and/or implementation. Skyhood damping is a damper system from a theoretical mount point in the sky and aims to damps out body frequency completely. From calculations, 4 -8 Hz vertical vibration seem to resonate with the body cavity and makes humans feel uncomfortable. There are two resonance frequency peaks when you are riding in a car. What makes driving simulators uncomfortable is that you experience a huge sensory conflict, especially when the images depict complicated driving situations. Watching displays when you are running on a jogging machine might be a similar situation for what you are trying to tackle. Maybe you could use head tracking to manipulate images? You should look into Bose and their work with semi-trucks and buses damp out chairs. Truck drivers experience huge vibrations and people have worked on technology to address this. Active damping would be ideal, where the car anticipates vibrations and damps them out before the passenger can feel anything. But, car companies have worked on this for many
139
years and it is really a tough challenge. Passive damping on the other hand, is something you should definitely try. Use a DC motor to produce vibrations of interest in a car seat and test out your damping system to see how effective it is. David Sirkin David Sirkin works at the Center for Design Research at Stanford University. He has a background in mechanical engineering and is currently focused on user-centered design and human-machine interaction. Needfinding Motion sickness People get motion sickness in simulator as well Is there a similarity between sitting in the automatic car and sitting in a taxi? Similarity between the associated motion sickness? Human Machine Interaction / User interface in autonomous vehicles User Interface Design - ergonomics? Comfort? “intuitive” Data collection - How do you measure things such as “comfortable” see if something changes driving behavior capture driving data, positioning of wheel, gas pedal physiological data eye tracking data, EEG, noisy data and not particularly reliable, kind of a drag to use capture video (go pro, fliP) scale of 1-10 (how comfortable are you?) How to make the system easy to use and intuitive? How to separate novelty factor from the other variables that might impact the results? Try with many people and many times, get people bored with it. Then, it would reflect a result that is more accurate.
Maybe there are fundamental reasons outside novelty that is more important to see. But, it is hard to get rid of novelty in your testing See if your test user responds the same way in 3 weeks CDR Resources Is there any way we can get access to the simulator? Still a work in progress. The CARS program is still undergoing some major change. Resources / Research going on at the CDR On the road studies with cars Simulator studies Ask Becky from CDR Communicating with the car, interfacing variables Centerstack design, what it shows, and how you interact with it, changing settings, put car into one mode or another, visual or spoken (what would it say), information displayed Might make people really worry when we block people’s view of the outside with the screen When do we know if we’ve hit the right design solution? People may or may not even realize it changed their lives We will know it when it solves the needs Sven Beiker Sven Beiker is the Executive Director of CARS, the Center for Automotive Research at Stanford. How feasible do you think a damping seat+display might be? What are your thoughts on the concept and prototyping it? I can definitely see the need, but I think what you’ll need to prototype will be very difficult It's very dependent on the frequency the system is trying to cancel out. Around 1 to 4
140
Hz is not too bad, but between 8-12 Hz will require a high power linear actuator To build a proof-of-concept, you’re dealing with real mechanics. You’ll potentially have to use a very large linear actuator and look into real and heavy equipment, to make sure that 1) it's a sturdy proof-of-concept and 2) it's safe to try out on users and in EXPE It'll be really great if your team finds out that it's longitudinal motion causing discomfort, not vertical, because in that case you have a much smaller frequency to compensate for Semantically, it's more accurate to say you’re "compensating for motion" than "damping" it, because you’re not slowing down speed, you’re eliminating it.
141
8. Appendix 8.1 Appendices Benchmarking
EMN 2013 - Improving the EV Driving Experience
For team EMN’s CFP, their motivation was to test the ways the vehicle could communicate with the driver without being annoying or even a dangerous distraction.
Their experiment looked at ways to notify the driver without distracting him from his driving, while we are looking for methods of alerting the driver who is not driving at that moment. However both of these scenarios seek the most effective way of pulling the driver away from an activity,
without being annoying or frustrating if too abrupt, as well as avoiding dangerous situations.
This part of the transition, that is notifying the user beforehand, is key in making the experience comfortable and safe.
They tested the reaction of the driver to different types of signals : blinking lights, air puffs, clicking noise, seat vibration. Both positive and negative results interested us. The only one that did alert the driver, and proving not to be annoying, was the use of blinking lights on the steering wheel.
Learning from their results, we gained a better understanding of the advantages as well as the disadvantages of each of these signals. Having in mind the effectiveness of light signals, we thought of generalizing this type of signal to the whole experience, and not to restrict it to the transition part, in order to communicate effectively with the driver. We also plan on pursuing on their experiment, by testing not blinking lights, but variable ambient lighting.
Tesla Model S
Motivation and description
We wanted to get a sense of what is already in the market in terms of user interface systems in cars. In particular, we wanted
142
to personally experience the user interface in the Tesla Model S because of its departure from conventional automotive dashboards. To do this, we spent about half an hour exploring and playing around with the user interface, the massive 17″ touchscreen, and the dashboard screen.
Observations:
■ Navigation in the dashboard screen in front of the driver – safer, easier, more comfortable for driver to use while keeping the road in view
■ Customizable screens (split screen on dashboard, split or full screen options on 17”) allow for personalization -> more optimizable for the individual user’s needs and wants
■ App store is coming to the Tesla infotainment system to allow drivers to customize their system.
■ Passenger can still use the touch screen when driver is driving
● Panel of essential options always kept at bottom of screen and are readily accessible to driver – (climate control buttons, emergency lights, etc)
● Central touch-screen replaces all buttons on normal cars
■ Central infotainment system very easy to use/learn/customize – “intuitive”
● Ex: to open the sunroof, all you have to do is slide the sunroof on the image of the car on screen to whatever position you want it to open to
● Touch screen incorporates all the typical gestures that are common in other touch
devices – pinch to zoom, rotate fingers to rotate the map, etc
● Browser is easy to access (a tab on the top of the touch screen) - you can do everything right from the screen, except for streaming video
■ Tesla purposely blocks it for safety reasons aka liability.
Issues We Found
● When sitting in optimal driving position, Rafael could not comfortably reach the central touch screen, especially the bottom of it where the “essentials” panel is located
● Infotainment system location (central touch screen in front between the driver and passenger) is an issue - using it for extended periods of time would be very uncomfortable and require turning neck for the entire time of usage
● We instinctively thought the dashboard screen was a touch screen – it seemed a little non-intuitive to use buttons on the steering wheel to control it
● By playing around with positioning of “screens” (paper) in relation to the driver, we found that if infotainment system were to be in front of the driver, it would have to be relatively close to the driver (i.e on steering wheel distance or closer) for driver to comfortably interact with it
■ we found this out just by having people sit in the driver’s seat and having them try to use the dashboard screen as if it were the main infotainment system and was a touchscreen)
143
Observations
Interface
● Touch-screen is standard ● Still have many buttons, knobs, sliders,
etc around the touch-screen for the most part - these have various shapes and forms
○ “touch” buttons that give haptic feedback when you “press” them
○ physical buttons that you press down ○ buttons that don’t appear until the car
turns on ○ “touch” sliders that adjust volume or
temperature when you slide your finger over them
○ physical knobs that you turn to adjust volume/temperature/change stations, etc
● Dual screen setup available in some vehicles
○ two screens in center console ○ one screen in center console, other one
in dashboard ○ one screen in center console that is
“split” ● Always more than one way to interface
with the screen ○ Touch (almost always available) ○ Button presses (almost always available
in addition to touch) ■ On center console near touch screen ■ On steering wheel (thumbs) ○ A touchpad-like mouse device in the
center cupholder area
■ The hand slides or tilts the device in the desired direction - very similar to a mouse, actually quite intuitive to use
■ Also allows for user to click - all movements including click are comfortable and pleasing to do
● Screens in the dashboard ○ Screens instead of actual dials ○ Customizable to a certain extent ■ Click wheels on steering wheel used to
select through the various screens available
● Click wheel knobs to select gears instead of the regular “stick” shifter
○ When car starts, the knob comes up so the user can turn it to the desired gear
○ This was actually something we noticed in many different cars
● Driver profiles ○ Many vehicles can remember up to 2 or 3
driver profiles - seating preferences, steering wheel preferences, mirror preferences
○ Seat adjustment is very intuitive b/c the buttons are shaped like the actual seat
■ sometimes located on door ■ sometimes located on center console ● BMW heads up display ○ BMW (certain models) offers a heads up
display that displays information on the windshield
○ When the heads up display system is on, it does NOT turn off the display on the regular screen, so actually there are two mirrored displays the driver can see
● Various text input “solutions” ○ Keyboard input screen at cupholder area
144
○ Physical keyboard (numbers only) at cupholder area
○ Physical keyboard (both text & numbers or numbers only) on center console
○ On screen text input ○ Nothing in front of driver
Driver Assistance Systems
● Blind spot & lane detection ○ Various types of warnings, all include a
visual signal on the door mirror (various locations)
○ Only gives warning if turn signal is on ■ At least one system also gives audio signal
- instead of regular turning signal sound, gives a slightly different sound
● Parking assistance cameras ○ Cameras on the side of the vehicle
(attached to the side mirror) opposite the driver
○ Rear view cameras ○ Alignment lines on screen and proximity
sensors showing which parts of car are close to something
● Adaptive cruise control ○ One system pre-pumps the brake lines
when it senses a car up ahead ○ This system doesn’t actually brake
though - alerts the driver with a sound and steering wheel vibration that gets progressively louder/stronger and more rapid as the car in front gets closer
○ Driver still has to brake - the pre-pumped brake lines help car to stop faster
○ There are other cruise control systems that will brake to keep a certain distance from vehicle ahead
● Most of these driver assistance systems are activated by buttons on the steering wheel, center cup holder area, or rear-view mirror
○ These buttons just have single icons on them, so sometimes unclear what they do
● Pedestrian detection ○ System actually can detect people or
animals in the road at night and shows a feed on screen
145
Steering Wheel Motor Code In the SMI (Smart Motor Interface) software, KP=300 KD=1000 F A=10 V=5000 C10 P=-300 G TWAIT P=250 G TWAIT P=-130 G TWAIT P=130 G TWAIT P=-20 G TWAIT P=30 G TWAIT P=-140 G TWAIT P=30 G TWAIT P=-90 G X TWAIT P=100 G TWAIT GOTO10 END
146
MID Code /* . This sketch turns on each of the LEDs attached to two 74HC595 shift registers, in sequence from output 0 to output 24. in every strip. Hardware: * 3 74HC595 shift register attached to pins 2, 3, and 4 of the Arduino and between, them as detailed below. * LEDs attached to each of the outputs of the shift register Created 22 May 2009 Modified 23 Mar 2010 by Tom Igoe Modified 28 Apr 2014 by Andr?s Bedoya */ //Pin connected to latch pin (ST_CP) of 74HC595 const int latchPin = 5; //Pin connected to clock pin (SH_CP) of 74HC595 const int clockPin =6; ////Pin connected to Data in (DS) of 74HC595 const int dataPin = 4;
147
// Pin to enable the whole circuit const int enablePin = 7; ////Pin connected to voltage divider const int SpeedControl= 0; //Delay time in ms long dt=10; //deacrising factor of potentiometer. long factor=1; int ONtime = 10; int dt2=1; int num_leds=16; void setup() { //set pins to output because they are addressed in the main loop pinMode(latchPin, OUTPUT); pinMode(dataPin, OUTPUT); pinMode(clockPin, OUTPUT); pinMode(enablePin, INPUT); Serial.begin(9600); Serial.println("reset"); } void loop() { if (digitalRead(enablePin)){
148
dt2=analogRead(1); for (int thisLed = 0; thisLed < num_leds; thisLed++) { // write data to the shift registers: registerWrite(thisLed, HIGH); // if this is not the first LED, turn off the previous LED: if (thisLed > 0) { registerWrite(thisLed - 1, LOW); } // if this is the first LED, turn off the highest LED: else { registerWrite(num_leds - 1, LOW); } // pause between LEDs: delay(dt); } delay(dt2); } else{ for (int thisLed = 0; thisLed < num_leds; thisLed++) { registerWrite(thisLed, LOW ); }
149
} } // This method sends bits to the shift registers: void registerWrite(int whichPin, int whichState) { // the bits you want to send. Use an long, // so you can use all 24 bits: long bitsToSend = 0; // turn off the output so the pins don't light up // while you're shifting bits: digitalWrite(latchPin, LOW); // turn on the next highest bit in bitsToSend: bitWrite(bitsToSend, whichPin, whichState); // break the bits into two bytes, one for // the first register and one for the second: byte registerOne = lowByte(bitsToSend); //the register one will contain the third Less significant Byte byte registerTwo = highByte(bitsToSend); // shift the bytes out: shiftOut(dataPin, clockPin, MSBFIRST, registerTwo); shiftOut(dataPin, clockPin, MSBFIRST, registerOne);
150
// turn on the output so the LEDs can light up: digitalWrite(latchPin, HIGH); delay(ONtime); //this may led to timing problems with the accelerometer. } Interviews with Daily Drivers Interview to a 20 year old female student & driver. 1. Driving
• Experience stuck in traffic jam: irritating, frustrating, annoying, waste of time cuz usually I have to be somewhere
• Driver or passenger?: I prefer to be driven – if there’s another person in the car, I don’t like being responsible for them. When I’m by myself, I’m wreckless. It’s more relaxing to be the passenger, also I can sleep in traffic.
• What runs through your mind during the drive to home/work? : Usually things I have to do whenver I get where I’m going.
• Check phone at red light?: Yes, but it depends on if I’m expecting a text or email or not.
2. Intuitive • What comes to mind when you hear the word “Intuitive”? : something that is easy,
natural, don’t really have to think about it that much • Experiences/Service/Product that are intuitive: eating, sleeping
3. Automation • Parking: 5 – cuz i don’t like parking, i always feel like i’m going to hit one of the other
cars if there are cars next to me • Traffic Jam: 5 – so I can nap, I usually don’t mind driving, but in traffic I get more
sleepy • Freeway: 2 – cuz I feel like if the car was auto driving, it wouldn’t be as aggressive
as I would be. The automated car would probably obey the speed limit and wouldn’t try to go into a faster lane, which I would do if I was driving
• What would you imagine doing in the car?: reading, texting, emails, sleeping • Watch features would you want?: shopping, hanging out with family or friends, TV. I
feel like a car already has everything it really needs. • Amount of automation? 75%
Interview to a 20 year old female student self-proclaimed road rager
151
1. Driving • Experience stuck in traffic jam: nauseating, infuriating; it depends on if I have a
good song going on and if phone is charged enough such that I know my music playlist will outlast whatever is going on, if I can just listen to my music, I’m totally fine, but if my phone is at like 3%, then I’m pissed, same with I have to listen to the radio. Normally I just dance in the car, gives me something to do other than just sit there.
• What parts of driving do you enjoy? : I like the false sense of freedom. • Driver or passenger?: 100% driver. I hate riding in a car because I just have to sit
there, can’t control where the car goes. I also notice driving patterns of the person who is driving and the driving habits of other people and critique it.
• What runs through your mind during the drive to home/work? : I’m usually just thinking about the music – singing aloud or dancing or some combination.
• Check phone at red light?: Hell yeah, every time I hit a red light, or to change the song. Sometimes I’ll check my phone even when I’m not stopped at a red light to check GPS or to decline a phone call – it’s the most annoying thing cuz when I get a call it stops the music and I have to physically decline it to go back to the music.
2. Intuitive • What comes to mind when you hear the word “Intuitive”? : “me driving”, my driving
skills are intuitive. maybe talking? I think of natural ability, senses, so maybe gauging people, understanding people? Those for me are really intuitive. Everything else you have to be mindful and think about what you’re doing.
3. Automation • Parking: 0 – if I can choose which parking spot, then maybe higher, but maybe not
because I don’t trust it, I trust my own abilities more. You have a lot of risk of it hitting other cars, malfunctioning, and then you can’t say it’s the machine’s fault cuz you’re the one who activated it in the first place.
• Traffic Jam: 0 – hell no, same reasons. b/c then why wouldn’t I just get a taxi or have someone else drive? I do use cruise control on freeways or long road trips or if I’m low on gas b/c I’m tired or don’t want to waste gas by accelerating all the time or I want to follow the speed limit b/c it forces me to do so
• Freeway: 0 – even less likely, why not just take the cal train? • What would you imagine doing in the car?: dancing, singing, not even looking at
the road, phone, all the things I do anyways in the car • What would you want to do in the car if no limits?: do work, sleeping • % automation?: 0 percent • Cool features?: if driver’s seat had a back massage, that’d be awesome.
Extra notes: • Hates the idea of automated cars – takes away from driving, why even have a car?
just take a taxi or public transportation. Thinks of it as a selfish way of transportation – spending money on something you don’t need when you could just take public transportation
• “I’m a driver, so I like driving – I’m a driving snob” • Really annoys her that some people are “stupid drivers, I honestly don’t know how
they got their license. The system will be good for these people and old people” • Too much reliance on machinery – makes her uneasy because if you are fully engaged
in an activity of your choice, how are you gonna be aware or surroundings? You put so much faith (your life) in the car’s hands.
152
• She would be more comfortable if it was automated but there was a control system – people watching out for you like the satellite control systems for airplanes. This would make it easier for her if she knew there was a 3rd party crew watching as a 2nd eye, she would trust it more.
• While you’re doing something, if there is a small popup window on screen with a panorama view of everything around you (180/360) of what’s going on, then you don’t have to look up completely, just glance at the window on screen
• Monitoring during automation, speedy assistance if something malfunctions – “they better get on it right away and fix it”, when you have automated on, someone is tracking and if something goes on, they’re on it right away
• gets pissed at other drivers – don’t signal, don’t follow rules of the road, don’t know how to maneuver smoothly, she understands if they are from a diff. state (little lenience here), but if from CA then no forgiveness. 4-way stops especially bother her b/c no one knows correct etiquette.
• For her, control over the steering wheel and car is more important, whereas for others, work is more important.
Interview to 20 year old male pilot
• Typically flies a Cessna o turns wheel -> controls tab on elevator in back of plane which controls elevation o set throttle -> maintain altitude, pitch, and heading o rudder -> controls yaw o when flying, he can basically just set all the systems so they maintain the
correct positions o has to look up from time to time, but on cross country flights, don’t really have
to pay attention much other than some checklists to do once in air i.e document fuel levels, what’s going on -> these are just official procedures you must do to get your license, no one really does it
o Presence of the yolk (steering wheel equivalent) impedes his movement, gets in the way when he tries to write on clipboard, for example
o switching back to full manual 1st thing to do before switching = check instruments, make sure throttle
and pitch settings are correct -> adjust if needed (in car, first thing he would do is check the speed) find landmarks – fly according to these landmarks. before flying, you
have course set based on landmarks (this is regulation to get your flying license) people usually just use GPS and fly GPS routes
with cars you have to be more alert in terms of outside surroundings – in a plane there’s nothing you can really crash in to
visual flight rules = spend 9/10 of your time looking outside, 1/10 of time looking inside
once in autopilot with autothrottle and auto pitch correction “manager” of systems instead of “pilot” monitoring systems, inputting a lot of stuff: waypoints, weather,
etc. • Car aficionado
o wants electronics, people would really want to use that time
153
one potential problem is steering wheel moving while driving if people are holding stuff against the wheel
moving towards electric motor controlled steering rack, so technically could decouple steering wheel from steering rack
o feels like it’d be really weird to have an automated vehicle – likes to have control, likes having the car doing what he wants to, “it’s a skill”, rewarding when you hit a shift right or make a good pass
o drives stick shift, so driving in traffic is frustrating, tiring for left leg, boring o Traffic = wasting their time when they could be doing something else, similar
to being on hold on the phone Interview to 20 year old female student living in Florida 1. Driving
• Experience stuck in traffic jam: depends on my mood. sometimes I don’t mind, if I have music and nowhere to be, then it’s like “oh well, I’ll just go with it”, but if I’m in a rush, it just sucks cuz you’re not in control. it sucks when you’re late, it’s literally the worst
• What parts of driving do you enjoy? : Freedom, you can go anywhere you want. Also I like listening to music in the car – i don’t have speakers in my room, so I can play music louder in the car, I can hear it better.
• Driver or passenger?: I prefer driving when there are not many people on the road, but it depends on who I’m driving with. I like driving by myself, or else if someone else is in the car, I’d rather be the passenger because I feel like I have more freedom when driving alone. When I’m driving with other people, I feel like they will judge me if I want to turn down some random road or they will nag me, especially my sister and mom. I hate back seat drivers.
• What runs through your mind during the drive to home/work? : If I know where I’m going, then I’m thinking about what i’m gonna do when I get there or if something happened at work or school then I’m thinking about that. If I don’t know where I’m going, then I’m thinking about going to that new place.
• Check phone at red light?: Lately, yes, because it’s legal in Fla. to look at your phone at a red light, but it’s not legal while driving. It depends – for longer lights I will check phone, but for shorter lights not so much because I’m used to CA laws
2. Intuitive • What comes to mind when you hear the word “Intuitive”? : user friendly, ease of use,
things that make sense • Experiences/Service/Product that are intuitive: hard to come up with an example
because everything I can think of I’m so used to using already…some parts of my phone maybe? like some symbols like the call button or hang up button.
3. Automation • Parking: 3 – if I was the only one in the parking lot, then maybe a 5. if parking in tight
spots, then i would be worried because you have to adjust sometimes because some people park poorly or in weird spots
• Traffic Jam: 3 – if it’s super sensitive to sensing other cars, then maybe. there is still human error of other people driving – just one stupid person could screw everything up. It just depends on how good the machine is.
154
• Freeway: 4 – if I’m going far such as SF from Stanford, then probably would because I sometimes get tired, or get sick of driving, or get tense. If I’m going somewhere nearby, then 3 – it wouldn’t bother me to drive there myself, would depend on mood.
• What would you imagine doing in the car?: Still be alert just out of habit, would still be watching the road and not checking my phone; if I’m running late, then maybe I can get ready in the car, stuff like that. I would love to exercise in my car, people always complain about not having time to exercise, so it’d be awesome. Maybe watching a movie.
• Watch features would you want?: Voice activated stuff, good quality obviously, in order to play music, play songs, connection to other apps and stuff (ex: sometimes get really good idea while driving and I want to write it down but can’t :/)
Extra notes: • Friend has a stick shift – really likes it because it feels like a game and keeps him
engaged • One main problem with trust is the limitations of the car – if you could guarantee that
it could avoid crashes it’d be a lot better. also to make me more reassured, the more I have it and the more I use it, the more comfortable I’ll be come with using it and it’ll just become natural for me
• In reality, if I had something to do, I would use automatic more Interview to Young male professional, civil engineer, living in London (used to live in Doha, Qatar, and car driver. 1. Driving
• Hrs/week: 11 • In traffic time: around 4 • Experience stuck in traffic jam: Hate it. I’m an efficiency king. It’s a pure waste of time.
Radio stations are shit. It’s also stressful because most of my driving is driving for work, and I don’t want to be late.
• Would automating decrease or increase lateness stress? Yes. Now I take the tube to work (kind of like an “automated” car) and I have no stress.
• What parts of driving do you enjoy? : Moving through different scenery; driving through a city (even if it’s going to work); being in my own space where I can control temperature and music. For a sports car, it’s like sitting inside a painting, or a work of art. It feels amazing to drive a responsive car. I also like car responsiveness: sound of the engine, responsiveness to steering wheel and gas.
• Driver or passenger?: Depends on the type of car. If there’s traffic, definitely passenger. You need to have energy to drive. Sometimes just not bothered.
• What runs through your mind during the drive to home/work? : Probably thinking about the schedule of my day. On the way back home, I can’t wait to relax. I’m sometimes reflecting on the day.
• Check phone at red light?: Yes • Factors on which car to by? : Cost, safety, aesthetics
2. Intuitive • What comes to mind when you hear the word “Intuitive”? : Logic
155
• Experiences/Service/Product that are intuitive: iPhone has intuitive written all over it, the iOS. Navigating tube system is intuitive.
• Experiences/Service/Product that are not intuitive:Android is unintuitive; driving around London unintuitive. There are few landmark; it all looks the same; and it’s not on a grid system.
3. Automation • Parking: 4 • Traffic Jam: 5. • Freeway: 4. Driving on a highway not that exciting
Interview to Asian male, ~50, works at Amgen as a research scientist, 3 children
• weekly travel – 45 mins/day during the week, 5 hrs over the weekend • an hour and a half spent in traffic jams per week • On experience of being stuck in traffic jam:
o “in LA, we’re used to traffic now, but it really depends on the situation” o if trying to get somewhere on time, which results in a little bit of frustration, a
little bit of nervousness, anxiety o if not, then just go with it o feels like it wastes a lot of gasoline because moving so slowly
• Enjoys driving, but not the act of driving itself, doesn’t care about brand or feel of specific car
o enjoys outdoors in general, the car is the means to see the outdoors, weather, surroundings, which is enjoyable
• 100% would rather be the driver o when other people drive, there are lots of tiny things that cause anxiety or are
slightly annoying ex: how they slow down could be different than how he handles it when he rides as a passenger, his hands start sweating, foot will
subconsciously push down on brake sometimes • Nothing in particular runs through his mind when he is driving
o thinks about what he is supposed to do when he goes back home, what he’s going to cook, those types of things
• Never uses phone during driving o sometimes will use bluetooth to start a conversation before driving, then start
driving, but never during red lights • Things he pays attention to when buying cars: right now, mostly economics and
reliability, which is the reason for buying Toyotas because less maintenance concerns, more reliable
• Intuitive – didn’t know what the word meant so Google translated it in to his native language, then took that and translated it back in to an english word he knew = instinctive
• parking autonomously: 3 (no strong feelings either way) o no preference between car parking itself or him parking on his own o depends on the particular situation: if it’s a very tight spot, very hard to park, he
feels it’s more likely for him to crash and so would trust the machine to do it o good feature to have available, but not necessity
• traffic autonomously: 5 (definitely yes)
156
o b/c car is going to be stop and go, also when you have traffic jam, more safe b/c you’re not going fast so less likely you are hit by someone, so he trusts the machine more
o lots of time spend traveling a short distance -> you can do other things if you can have hands-off property, you can make more effective usage of time
• traffic on freeway: depends o LAX freeway is much different than freeway between Tucson to Phoenix
(desert, very light traffic, would like to have the feature here) o In LA, 5 lanes in one direction, high level of traffic congestion, makes him very
nervous, more congested traffic conditions -> doesn’t like to have machine drive it
o Interstates that get you from one place to another, rural areas, 4-5 hours of driving at a time, would like to have it b/c it allows more flexibility
• Things would like to do while automated driving: phone calls, eating snacks, brief 5-10 min naps, sightseeing -> take pics/vids
• would want ~50% of driving automated • No limits, would want to: read, listen to music, travel, exercise • Main concern is safety and that all the features will not cost way more energy or
anything o to make him feel more safe about it, would need real data o ideally everyone is driving this type of car (network of same cars), otherwise
high tech sensors are not really as effective because a drunk driver, for example, could come from nowhere and hit the vehicle
still at risk no matter the tech of your own car and how your own car is built, but if every car knows every other car’s speed and position and such, then would feel much safer
o Warning message – when the car senses that the driver needs to pay attention in order to switch back to manual or otherwise be alert (i.e a merge coming up, freeway exit or entrance, cars breaking heavily ahead, construction going on, accidents, drunk driver?, etc)
Other thoughts on driving, user interfaces, etc that he wants to share: • Adaptive cruise control exaggerates things, sometimes can be annoying
o when a car cuts you off, your car suddenly brakes to maintain the distance between your car and the next car, without taking in to account the speed of the car that just switched in to the lane – only takes in to account the one number, distance, doesn’t care about anything else
o when you actually drive the car, it is much more smooth because you gradually get to speed and gradually adjust based on the speed of the car and things like that
o Also, when you climb up a hill, it’s not smooth – the system tries to maintain the speed of the car so the rpms go way high
o if you’re a human, you would gradually go up, even if you slow down a little bit o machine doing it and human doing it is just different – lots of these tiny things o automation -> lots of details have to be worked out to make the driver feel
comfortable • Voice activated control would be helpful (don’t have to push anything) -> change radio
stations, pick up phones
157
• Older people are less responsive, slower to react -> this type of system will be most useful for them, consider their needs and wants
• Alert system that is not annoying, not always on, just alerts when the driver needs to be alerted
Interview to Sven Beiker Stanford Engineer and daily driver
Car interface hasn’t changed much for 10 decades o steering wheel, pedals, turning signals, etc all the same o most basic controls are very intuitive
you learn 1 vehicle -> you can easily drive another vehicle o driver assistance has made it easier to drive, but this also plays a role in drivers
being distracted by other things such as smartphones – this may be combination of driving becoming so easy as you don’t have to focus as much on it (boredom) and also the availability of connected devices
user interface is one of biggest problems systems are designed by engineers -> not clear to the driver what is
going on no one has really found a good solution to this issue
• One important aspect of our problem is how long will the driver be out of the loop? o 5 seconds -> context has generally not really changed between when driver
gave up control and when driver takes back control o longer distance (several mins) -> scenario has changed, more info needed by
the driver to re-take control example: was in a congested situation, now in un-congested; was in
light conditions, now in dark conditions; etc o safety critical systems – the controller cannot brake the car as much as needed,
the driver HAS to take over control to avoid crash o IMPORTANT SCENARIO – Merging lanes
what if you are in a lane and car is driving autonomously, the lane merges in to another lane? will the system be able to do this or will the driver HAVE to take back control and do this maneuver manually? likely that the system will have difficult doing such a complex maneuver, in which case the driver will have to be very suddenly pulled back in to the loop from whatever he/she was previously doing
• Features/what people want o Driver needs to see benefit, gain something from that level of automation ->
freedom, convenience o example: allowed to text while driving = gain, or perhaps just relief/relaxation =
gain o if driver needs to monitor the situation, even when hands are off steering wheel,
then makes the system relatively pointless b/c driver still cannot do a lot of other things
o apps, programs, services that are driving specific, still haven’t found it yet o want to do and have access to what you have everywhere else as well – laptop,
ipad, tablet, etc people these days don’t really want to just sit back and relax, they want
to be productive
158
analogous to eating with a partner at a restaurant when you see two people sit down at a restaurant and one
leaves to go to the restroom, the other person immediately reaches for the phone and begins to text, check email, surf the web, etc, but when the other person comes back to the table, the phone immediately goes away.
this is very similar to our situation – we are focused on driving, but when the car goes to autonomous, we want the ability to immediately start doing other things, and when the car needs to come back to manual, we immediately put down everything else and focus again on driving
o Current systems need some type of clarification – something built in such that the system stays in touch with the driver, makes sure that the driver is at least paying some attention to what is going on
• Intuitive – haptic feedback from car, you can sense the acceleration, some indication of status of the road condition, speed information – audio feedback, perceived speed
• If the car wants the driver to take back control, needs to guide the driver Driver needs to know if he/she is supposed to brake now? accelerate?
merge/steer? Needs to catch the driver’s attention
Steering wheel lights up? Floor panels light up? Visual confirmation to do something?
Different feedback channels to driver Look at what’s been tried already – research online! (maybe the
French team can help out with this?) some channels are already overloaded – at times audio, at times
visual how to create an effective and intuitive way to
communicate with driver Driver assistance systems such as lane keeping system, adaptive
cruise control, blind spot monitoring, parking assist systems all have interface systems that warn the driver and sometimes even request the driver to take over
We should look at these systems and see what ways they use to communicate with driver
• Other suggestions on who to interview – limo & taxi drivers, pilots
159
Interviews with Extreme Users Stanford Police Officer - Donovan Edwards
Motivation and description :
A great suggestion from the teaching team as well as other students in the class was to interview police officers. First of all, it would be very interesting to get their first hand experience in observing drivers in traffic up close. Secondly, police cars are very interesting for our project because there are numerous monitors, controls, alerts mounted in the car, and the driver has a lot of incoming/outcoming information to manage while they are driving.
Police Officer as extreme user
Observations :
On drivers' behavior in TJs :
● Confirmation of our past observations (radio, GPS, talking with passenger, texting, makeup, reading)
On his use of the police car equipment :
● They are equipped with monitors and computers, added to the usual lights and sirens. These equipments are easy to use while driving.
● The computer used is the same as what he is used to (Windows). It is very user friendly and touchscreen based.
● An initial training was necessary. This is similar to what people at the car dealership said about implementing new technologies in cars.
● Everything is within arms reach. Some of the gadgets are positionally adjustable to meet the personal preference of the driver.
● Muscle memory is very useful, because it enables the driver to activate buttons and utilize features without looking while driving.
160
Police officer dashboard and equipment configuration
Conclusions :
In an automated vehicle, the driver will potentially would want to or could have access to many different gadgets and activities. It’s important to access lol
Plane Pilots
Motivation and description :
Although not in a car driving experience, plane pilots offer an interesting opportunity to investigate their impressions on auto pilot systems. We interviewed both a young pilot starting his career and having spent some time in plane simulators, as well as a retired air force pilot who is nowadays flying 777 planes.
Pierre-Olivier Bard - freshly diplomed pilot
161
Inside of a plane cockpit
Observations :
● Activation of autopilot (AP) with a single button. The copilot has to confirm for activation to be completed.
● Autopilot impacts on multiple parameters (vertical plan, horizontal plan, speed, …). An indicator provides information on what parameter is being modified.
● De-activation of autopilot with a single button on the steering wheel. Touching the wheel or pedals has no effect as long as the AP is on.
● Special function : possible to adjust some parameters manually while the AP is on. A button on the wheel, right under the thumb, has to be pressed during the maneuver.
● When AP is on, pilots check the weather, and write reports. ● Not afraid of using AP. Used often to let go the wheel. Just make sure the plane is stable. ● AP is perceived as an enjoyable experience, although frustrating at the same time. Pilots
are more and more doing “flight managing” and less actual piloting. ● Transition from AP to manual control needs training. It is the main cause of accident. When
used to it, it can take less than 10 sec. The difficulty is the sudden mechanical forces that transit in the steering wheel, not being any more resolved by the automated system.
● The pilot is notified of the situations with lights (blinking) and/or noise (beeps, pre-loaded voices). Every situation, important or not, urgent or not, and dangerous or not, is signaled to the pilot.
● Pilots aren’t legally allowed to do anything else than piloting, or related tasks, during the flight. In practice, during long trips, they often read books and newspapers.
162
Conclusions :
● The AP goes through different levels of automation. ● Turning the AP off by touching the driving wheel is too dangerous. Find a safer a way. ● Find inspiration for the car interface ergonomics from airplane cockpits for effiency. ● Feeling safe with automated mode is mostly a matter of being used to it. ● It's important for the user to get as much information as possible, especially if they need
to take control quick or in dangerous situations (turning, under bad weather, changing direction...)
● Beware of the difference of context between planes and cars : the amount of time to react or make choice is about 1 to 3 seconds in a car, about 10 to 60 seconds on a plane.
Michel Dessapt - Boeing 777 pilot, and past French Air Force pilot
Figure 6. Plane pilot interviewee and plane cockpit
Observations :
● Uses glass cockpit (LCD screens for everything). ● Signals are mostly visual. Just like in a car dashboard, the Flight Management Annunciator
(FMA) is a group of lights in front of the pilot, close from its vision horizon. It centralizes all the information of the plane status. The FMA can vary colors on each light.
● There are many buttons, spread across the cockpit, and are not all directly accessible from one position. For efficiency they are classified by topic (hydraulics, …).
● Use of sound alarms is exceptional and reserved to critical issues. Sound alerts are very distracting and annoying. The multiplicity of sound signals can be ineffective, as the overlapping of sounds makes things indistinguishable.
163
● AutoPilot (AP) is either on or off. No partial automatic mode. ● When AP is activated, the pilots are still focused on the flight (checking itenerary, ..). ● The FMA lights informs of what actions the plane is doing.
Conclusions :
The plane AP is close from the one of the automated car, as it manages speed and direction.
Like for a plane pilot, the use of advanced interfaces can be part of the experience of driving. The fact that the plane notification system uses a banner of lights in front of the driver pilot horizon line, and at the same time avoiding the use of sound, are interesting for our design of a useful and effective way to bring the necessary information to the driver.
# Interview: Car dealership Duffort Motors sales managers
Motivation and description : We wanted to interview these persons for two reasons.
They are both daily commuters enduring traffic jams on the entirety of their commute. One of them goes through at least 1 hour of traffic jam for his commute back home, the other one being on the opposite side of the scale, with a commute time of 20 minutes. Due to their job, they change cars every 3 months, and implies that they have tested many cars.
The second reason is that they have been working in the automotive retail business for a long period of time, being in direct contact with clients. Their experience with new car technologies being introduced to clients can prove itself useful in our project. We could also point out that the range of cars they are used to sell is the segment that interests us for the business development of the project (Land Rover, Jaguar, Volvo).
Figure 7. Car dealership duffort motors
164
François Delvallée
Observations :
As a commuter :
● Phone calls (professional) is his main activity. Calls that he couldn’t get done before during the day.
● Interested in automated driving in traffic jam situations, for optimizing his time. ● Uncomfortable letting go the wheel. ● Had an apprehension at first when using adaptive cruise control, trusting the
vehicle to brake by itself. There is a progression in the acceptance. ● Uses solely the car system, not his phone (in his jacket). Satisfied with the present
integration of his electronic appliances with the car system : ○ No text / mails. Phone is not visible. ○ Music. Connects iPod with a cable.
As a car dealership sales manager :
● Importance of showing and explaining the technological features to user. Understanding implies acceptance. People have different approaches to technology. Technology is complex, and the interface not that intuitive. Needs to be explained.
● Do not present in the dashboard too many features at the same time. Except for safety, where acceptance is easier.
● Important to make the driver feel as the master of his car. Should get final decisions in some cases of automation.
Conclusions :
Takes advantage of the traffic jams. On his way home to pass phone calls, because he doesn’t have time to do it at work.
People have different levels of use of a system. For example here, François is already productive with phone calls that last the whole time of his commute. A keyboard can be useful to him for example, but is clearly not his main issue.
Technologies have a real wow effect on the clients, but still need to be showcased. It should not need the case. Intuitivity should aim to answer the need of explaining to the sellers, and even more to the drivers.
Intuitivity does not mean putting everything on the dashboard like in a plane cockpit. To not discourage the user, we should not present all the features.
165
Understanding the user, means understanding the driver psychology. In case of the automated driving pilot, make sure the driver still feels as the master of his vehicle and not deprived (ie: keeping the hands on the wheel).
Cyril Foucard
Observations :
As a commuter :
● Phone calls, emails, sms. Short tasks. Things he couldn’t get done before. ● Smartphone is not hidden. One hand on the wheel, the other to use his
smartphone. ● Uses partial automated systems like adaptive cruise control when tired. ● Not interested in automated car driving system, as he already manages to do
things. Recognizes the value of making it safer. As a car dealership salesman :
● Every regulator and helps are activated by default and can be deactivated. ● Clients get afraid even of adaptive cruise control. Untrusty of technology, fear of
the case of breakdown / bug. ● Fear of letting go the driving wheel.
Conclusions :
Taking advantage of the traffic jam to do things he didn’t had time to do before.
People are afraid to test the technology, even in a demonstration ride.
Dark Horse Brainstorming: Dark Horse Prototype Brainstorming The start of winter quarter was a perfect time to pursue ideas that seemed a bit crazy and push beyond the conventional design frame. Through several sessions of brainstorming and ideation, the team came up with 24 ideas for the dark horse prototype. Each idea was unique in some way, and offers features or services that challenge the traditional assumptions of what a car can do. The process of coming up with and developing these ideas was very fun for everybody and the team felt very excited to envision the future of autonomous vehicles. Ideas 1. Food Delivery Car: People like to eat in their cars (at least in US). Wouldn't it be interesting if one could order food (or coffee like Starbucks) from their car and get it delivered to them (with drones, or people on motorcycle, for example) while they are in traffic? Another interesting twist with this idea would be a scheme where a motorcyclist with 100 Starbucks coffees drives through traffic and people in their cars can see how many are available (through a display on their car), and can request/purchase one.
166
2. Vending Machine Car: You stock the "vending machine" with drinks and snacks (it is capable of keeping things cold or warm, depending on what you need). You put coins in (assuming it's satisfying to put coins into vending machines. You’re not really paying for it, but this is just for satisfaction) and type in the code for what you want, or press a button on a touch screen. The item then falls down similar to a vending machine and you can enjoy it. 3. Comodes Car: What happens when you have to use the bathroom but are stuck in traffic? You really would rather not exit the freeway or pull off to the side of the road, but you still want to comfortably relieve yourself. How could we tackle this challenge? 4. Morning Car: Getting ready, taking a shower, having breakfast, shaving, or even putting on make-up takes a long time. What about getting ready while being in traffic jam so you can sleep a bit more in the mornings? The car will provide the necessary bathroom and kitchen equipment, and you will also have the privacy to change! Your car basically is a continuity of your home, and when you get out at your destination, it would be just as if you got out of your home’s front door fresh and clean. 5. Bed Car: You’re in your bed at night, fast asleep. What if you can continue sleeping until the morning and wake up in your car? Your car could be your bed and become physically coupled with your bedroom. Knowing how long the traffic jam is estimated to last, your bed moves automatically out of your bedroom into the car. You wake up in the traffic jam, and now just have to get ready. Your car turns into the morning car (see idea 4 above). 6. Movie Theater Car: Create an in-car movie-watching experience where the lights dim, and a screen comes out just like in a movie theater. Seat position will change to a comfortable position and a popcorn maker and a soda machine will be in the center console! 7. Locker Room Car: The car will provide you with a space to fix yourself up, change, wash your face, brush your teeth, and even take a shower. 8. Gym Car: A lot of people wished they had more time to work out, and for them the gym car is the answer! Weight-training, cardio workouts (treadmill, elliptical machine), yoga and pilates, and personal training are all on offer. The car is able to save your statistics so that you can monitor your performance and your improvement over time. Some of the workouts can also incorporate visuals to make it more fun to work out - for example, a bicycle simulation with a heads-up-display that can turn the environment into the Grand Canyon or Loire Valley. While lifting weights, the heads-up-display can project a slowly filling energy canister. 9. Educational Car: This car offers educational games that interact with the environment for our users who travel with children. Heads-up displays on all windows can point to things that are in the environment - things such as buildings, animals, landmarks, etc. It can give you information and allows you to interact with your surroundings. There can also be a gaming feature for younger kids, like “point to something that is green”, or “I spy”, and so on. 10. Spa Car: This car creates an on-demand spa-like atmosphere for passengers.
167
11. Traffic Indicator through color display: Depending on the car’s location in a traffic jam, your car would be be able to estimate how much traffic is ahead of you by looking at the color indicators (gradient like fashion, or a timer like fashion) floating above the cars directly in front of you. It could help reduce the driver’s anxiety and allow the driver to do other in-car activities and to visually check the traffic jam status with a quick glance. 12. Icon Car: A display on top of the car that can display driver emotions, update status, indicate willingness for interaction (games/chatting), make requests for services (food, gas, or companions), and fetch ideas and suggestions on routes, scenery, or attractions. It can also incorporate the following features: posting icons (emoticons), or selfies/photos photobooth (share with roadies or friends only) customizable icons (their own face, or generic smileys/LINE style icons) automatic updates of information 13. Physical Gaming Car: This car is for users who are bored, de-energized, or stressed and could use some fun. It offers physical gaming - different from purely digital gaming because it involves greater ranges of motion and actual objects, so it is more stimulating (more of the senses can be invoked). It can include games such as beer pong, balloon popping, tag, hide-and-seek, lasertag, skiing, ring toss, kids games, and so on.
14. Car-aoke: You are bored of listening to the music on your ipod and the radio, but you want to listen to a certain genre of music (hip hop, rock, etc…). So, you select the "station" which puts you into a pool of people around you who are also listening to that station. The person who selects the next song rotates such that everyone gets to choose a song. People can up-vote or down-vote other people's selections. People with lots of up-votes end up selecting more songs and vice versa. In the Karaoke version, you join a group of other singers, (singer rotates), vote for them, and even choose the next song. 15. Meeting Spot: What if you can pair your car with another one not only in speed and direction but even physically, in order to create some kind of big power-rangers-like car that allows you to have meetings, exchange objects and documents, or just have fun while in traffic jams! The cars combine to create a larger lounge where personal face-to-face interaction can take place. 16. The “Gimme a Ride!” Car: Carpooling, as with the iPhone service app, Uber. This idea uses the automated mode to ease carpooling. Imagine you’re in your car, with this service on. You get a notification from someone asking for a ride that almost matches yours. Just answer yes or no. If accepted, the car gets automatically re-routed. The user gets in, and your smartphones recognize each other and exchange data without you even noticing it. After reaching the guest’s destination, the car will continue on its way to the initial destination. The users that accept other people’s ride requests are rewarded with points and alternative money they can spend.
168
17. Love Car: Traffic jam time can be seen as a waste of time but it also can be the best time to interact with the one you love in a very intimate way. With dynamic polarization, noise suppression and other features, you can create an incredible environment to have sexual interaction in a very synesthetic way. 18. Bipolar Car: You can switch between two opposite environments when you are in automated mode. - OPEN mode: You are fully conscious of what is happening around you. You feel in control at all times and that is reassuring. You can interact with other users in the cars that surround yours, share your ride, and enjoy the scenery thanks to augmented reality guides. This mode is warm, social, fun, and curious. - CLOSED mode: You are totally cut off from the external world, like in a cocoon. You forget that you are in a car and you can focus on complex tasks such as working, or just chill and take a nap. This mode is quiet, zen, and smooth, like in an office or a room. 19. Teleporter: This concept aims to answer the need of people feeling powerless and unproductive when stuck in traffic jams because they are cut off from their working space. The idea here is to recreate another space inside the car cockpit to make you feel as if you were somewhere else. All the surfaces around you will act as tactile screens to recreate different atmospheres, from your office’s desktop to a peaceful countryside landscape. Sound effects and fragrance-releasing devices will help create a complete and synesthetic experience. It can even immerse you in whatever content you want - movies, books, etc - and provide whatever input interface you need. 20. Hologram Meeting: The idea here is to have your interlocutor represented in front of you, not only on a screen, but in realistic 3D, to emulate a discussion as close to reality as possible.
21. Haptic Handles: You can actually touch and feel physical stuff remotely. This idea is very specific and technologically centered. It can be used as a way to develop one of the previous ideas and to push it further. For example, in the teleportation idea, one can not only recreate a sense of being somewhere else, like in your office, but also allow you to interact with objects that aren’t in your car right now. By being able to physically interact with people, you will even be able to feel their presence around you and no longer feel alone in your car. 22. Machine Gun: A game to relieve people from their stress, or just to have fun while playing. Your steering wheel becomes a toy machine gun to shoot other cars around you, using augmented reality (AR). Driver’s behaviors are analyzed and the more aggressive they are on the road, the more points you earn by shooting them. 23. Jolly Jumper: Just like Lucky Luke’s horse, your car will be there for you as soon as you need it. Forget about a key, an app, a code - instead, your car simply uses the data it collects from your habits and your smartphone to predict when you are going to need it. It then gets ready just before you leave from home/work. Just like a real pet, it will learn from you and assist you in every task you have.
169
24. Instajam: A service that allows people to have an understanding of the cause of the traffic jam. For example, a traffic jam usually happens when people slow down to stare at an accident. Instead, thanks to Instajam, cars passing by the accident can take a picture at full speed, and diffuse it to the community of drivers. The outcome is that users will have an understanding of the reason why they are stuck without further delaying the cars behind them. Selection The Stanford team chose to combine ideas 12 and 13 as their first Dark Horse idea to prototype. Ideas 18, 19 and 20 had a common theme of creating an illusion or atmosphere. The Paris team took these ideas and developed them for their Dark Horse prototype. Interview with Sven Beiker: Sven Beiker is the Executive Director of CARS, the Center for Automotive Research at Stanford. How feasible do you think a damping seat+display might be? What are your thoughts on the concept and prototyping it?
• I can definitely see the need, but I think what you’ll need to prototype will be very difficult • It's very dependent on the frequency the system is trying to cancel out. Around 1 to 4 Hz is not
too bad, but between 8-12 Hz will require a high power linear actuator • To build a proof-of-concept, you’re dealing with real mechanics. You’ll potentially have to use a
very large linear actuator and look into real and heavy equipment, to make sure that 1) it's a sturdy proof-of-concept and 2) it's safe to try out on users and in EXPE
• It'll be really great if your team finds out that it's longitudinal motion causing discomfort, not vertical, because in that case you have a much smaller frequency to compensate for
• Semantically, it's more accurate to say you’re "compensating for motion" than "damping" it, because you’re not slowing down speed, you’re eliminating it
Interview with Professor Satoshi: Professor Satoshi Katazaki is a mechanical engineering professor at the University of Iowa. He has done a lot of research on effective means of reducing motion sickness in cars. Professor Satoshi Interview Notes Motion Sickness Could you please briefly introduce your background? I used to work for Nissan Research Centerin Japan. Now, my research is on driving safety with older people.
170
Could you tell us more about your research?
• I worked to solve motion sickness in the back seat. • Sensory conflict theory doesn’t really give you the solutions. You have to ask, what
is really causing conflicts in the brain? • Sensory conflict is a discrepency between your local coordinate (visual) vs. global
coordinate (Vestibular system). • I worked on providing image control in reaction to any braking/acceleration motion to
match these coordinate systems • Our experiments involved measuring participants' sickness level (Asking participants
every 5 min how they are feeling) • There is a trick: Image stabilization. • Logos are also a trick. You needed it to divert their focus of vision.
Could you tell us more about how you quantitatively measured motion sickness?
• There are some standards for motion sickness, including: o ISO2631 International standard o BS British standard o MSDV (only for vertical vibrations standardized)
• Frequency component is definitely below 1 Hz What other methods have potential to reduce motion sickness?
• Good seat support can help reduce motion sickness • How the vehicle is driven is also very influential on motion sickness • Maybe you can tune engine and transmission for a smoother drive in automated cars • Eco mode has shown to reduce instances of sickness as well • Monitor placement plays a difference. • Access to peripheral vision (direction of gaze vector) can help reduce the sensory
discrepency.
Could you tell us more about your experiment doing image collimation? The relative motion between ground and display and the relative motion between display and head contribute towards conflict. Image control cancels the relative motion between ground and the display now, we need to control relative motion between the display and the head. Our study using image collimation (through lens) is that when your head moves to left, the image follows you. When your head moves upward, the image moves upwards as well. This achieved 30% reduction of sickness. To make this work however, the size of the apparatus was too big for the car cabin. That was several years back, but now you can maybe use head tracking to synchronize image.
171
Any more suggestions for our project going forwards? Front passengers may be a little different than passengers in the back seat. Front passengers acquire less sickness, and have access to more peripheral vision. Good support of seat and body is good for not only sickness but also comfort. If driver is not holding steering wheel, seat support becomes very important for comfort. If you study a good seat design for the passengers, it could have potential to reduce sickness as well as increasing comfort Interview with David Sirkin David Sirkin works at the Center for Design Research at Stanford University. Interview Notes Needfinding
• Motion sickness o People get motionsickess at simulator as well o Is there a similarity between sitting in the automatic car and sitting in a taxi?
and the associated motion sickness
• Human Machine Interaction / User interface in autonomous vehicles o User Interface Design - ergonomics? Comfort? “intuitive” o Data collection - How do you measure things such as “comfortable”
see if something changes driving behavior • capture driving data, positioning of wheel, gas pedal
physiological data • eye tracking data, EEG, noisy data and not particularly reliable,
drag to use capture video (go pro, fliP) scale of 1-10 (how comfortable are you?)
o How to make the system easy to use and intuitive? o How to separate novelty factor from the other variables that might impact the
results? Try with many people and many times, get people bored with it. Then,
it would reflect a result that is more accurate. Maybe there are fundamental reasons outside novelty that is more
important to see. But, it is hard to get rid of novelty in your testing See if your test user responds the same way in 3 weeks
CDR Resources
• Is there any way we can get access to the simulator? o Still a work in progress. The CARS program is still undergoing some major
change. • Resources / Research going on at the CDR
o On the road studies with cars o Simulator studies
172
Ask Becky from CDR Communicating with the car, interfacing variables
• Centerstack design, what it shows, and how you interact with it, changing settings, put car into one mode or another, visual or spoken (what would it say), information displayed
Might make people really worry when we block people’s view of the outside with the screen
• When do we know if we’ve hit the right design solution? o People may or may not even realize it changed their lives o We will know it when it solves the needs
Interview with Avinash and Jon Avinash and Jon are PhD students working in the Chris Gerdes lab at Stanford University. This interview with Jon and Avin was quite casual. They provided some good feedback on what the team plans on doing, provided some interesting inputs on what the team should look into. Skyhood damping is a damper system going into somewhere in the sky and aims to damps out body frequency From calculations, 4 -8 Hz vertical vibration seem to resonate with body cavity and makes human feel uncomfortable. There are two resonance frequency peaks when you are riding in a car. What makes driving simulators uncomfortable is that you experience a huge sensory conflict, especially when the images depict complicated driving situations. Watching displays when you are running on a jogging machine might be a similar situation for what you are trying to tackle. Maybe you could use head tracking to manipulate images? You should look into Bose and their work with semi-trucks and buses damp out chairs. Truck drivers experience huge vibrations and people have worked on technology to address this. Active damping would be ideal, where the car anticipates vibrations and damps them out before the passenger can feel anything. But, car companies have worked on this for many years and it is really a tough challenge. Passive damping on the other hand, is something you should definitely try. Use a DC motor to produce vibrations of interest in a car seat and test out your damping system to see how effective it is. Interview with Heather Kirton What were you doing on your phone on the drive over?
173
Well, I don’t use facebook much, so I thought, why not open it up and check. I check it every 2 to 3 days. Are there any other apps you use, blogs you look at - pinterest, instagram, etc.? I do use an app called Houzz - it’s kind of like pinterest for houses. One of my friends told me about it and I’ve been using it for around a year and a half. [Renovating home so use it to get ideas] Why did you choose to look outside of the window on the way to Stanford, but to check your phone on the way back? Well, in the morning it didn’t occur to me to pull out my phone. Sometimes it’s also more tiring, to look at something, have to think about that thing. On the way back I thought, “oh, why don’t I check my phone?” But it was only for five minutes, just until we reached the Stanford dish. It’s funny though. After looking at my phone, I felt a little bit dizzy. But I have checked it in the car at other times… for example, from the passenger seat I sometimes look up directions if we need that. Why didn’t you use anything available in the car? It was down time for me… I don’t have an excessive amount of down time. I always have to be fixing something for someone, or preparing food for someone… so I appreciated the time to be down Did you feel self-conscious about using anything in the car? Like you would be observed? No. Actually, I felt, you know the awkwardness you feel when you’re sitting with someone trying to think of something to say? This was the opposite feeling, since I had a lot of topics of conversation I was thinking about, but we had to sit in silence. Why did you choose to use your phone instead of your tablet? Used phone because facebook, it’s already there, I know where to find it, I’m logged in. It seemed like it was more work to use the tablet to open facebook. It’s like, when I go shopping with my friends. When we go out, I like to accompany them, but I don’t like to do any shopping, unless I’m by myself. I can do what I want, feel comfortable that way Why did you choose not to read one of the books? Well, if I had started, how useful would it have been? I wouldn’t have gotten very far and then I’d have to put it down. It didn’t seem productive to me. But I should’ve taken a look at
174
the books you had, just to get an idea about what they were. Maybe I could’ve read just the first page, to see what they’re about Do you have a reading list? No, but that’s a good idea. My mother lives with us. She’s 90 years old, and she’s losing her sight, so she listens to a lot of audio books. I’m always on the look-out for books for her - she finishes them much faster than me. I’m sure… she has much more leisure time Yes, I know. And I’d love that. When she complains I remind her that’s it’s not a bad way to spend time What did you think about the reminder message from your car? [Heather received a message telling her traffic was bad, and reminding her to start walking in next ten mins] It was fine. I was curious about it (I thought - traffic isn’t good right now?). Do you have any reminders on your phone? No. But that’s a good idea Did you find the display of ETA useful? Yesterday it was 3:30, so for example if you receive a text tomorrow saying 3:32, the day after it might be 3:27…? If it’s a difference of a few minutes, probably not. 10-15 minutes, could be Interview with Frances Yang What was your emotional state during the commute? At the end I felt nauseous and sick; I wish I had the power to take control. So that I would drive myself and fix nauseousness Can you walk us through your emotions during the test? I felt bad knowing you were waiting and I was late getting into the car. Once I stepped into the car, I thought “Oh it smells really great in here!” because of the car scent. When I saw the tablet streaming a video of my dogs, I thought “This is really cool I can see my dogs” Then I started talking to my boyfriend. Usually I talk to my boyfriend the whole drive back. We listen to the radio the whole time.
175
Does the time fly faster? Yes, it does. A lot faster. Then it got hot; it got really hot. I hate air blowing in my face too. The smell became just way too much. Did you find the ETA display useful? The ETA wasn’t working. Also, It depends on what I can do with ETA. If I don’t have control over the car and it’s route, I don’t know what I can do with that information anyways. Any other thoughts? Having you drive also made me notice other things. “Oh, I should get a car wash” when we passed a car wash. So maybe a to-do app in the car would be useful. The doggie cam annoyed me after a while; it just gave peeks of my dogs. I was happy when I saw the dogs. It was good. I was really surprised how many times Franky went to that bin. If my dogs were going crazy and I can’t get home in time though, that would be even more stressful. If you called them and the sound of your voice played through a speaker in your apartment, or we played a video of you, do you think that would help? I don’t know if my voice would help. I don’t think they would care about seeing me on a screen. When were you watching the doggie-cam? Because I get nauseous, I would only watch on a red light. What where you doing on your smartphone while the “autonomous car” was driving you? I was reading the news; I was also chatting; I was also texting Do you prefer driving yourself or having the car in autonomous mode? Because I got nauseous, I like driving better How would you compare this test to the baseline test? During the baseline test I didn’t get as nauseous. I think, when there’s stop-and-go traffic, I would drive. When the lights are green, I would turn on automation. Let’s say if someone texts me; if I were driving, I could just press on automated, answer the text, and go back to driving.
176
During the test though, I felt like I could have thrown up. Do you prefer voice calling or video calling? Calling is fine. Functional Prototype at Paris: Physical Specifications The functional prototype consisted of : - a car dashboard as the base of the setup - fabric skin panels clipped on top of it - a shape-shifting actuator (a bent tube that pushed on the interior side of the fabric skin) - a gaming wheel to activate the transition and shape-shifting from driving mode to automated mode This driving wheel was covered on both front and back sides with an adhesive aluminum foil sheet. When the user held the wheel, his hands would close the circuit between the two aluminium foil sheets - this trigger was registered by a Makey-Makey control card. The gaming wheel was set-up on a tubular structure that was set up on its side to avoid making a hole in the fabric dashboard. All of the tubular structures (for the fabric skin panels, shape-shifting axis, wheel support) were made from PVC tubes for plumbing (diameter 32 mm). An Arduino microcontroller was used to control the servo motors responsible for the shape-shifting. Two sensors were placed on the pivoting axis of the shape-shifting tube to relay its position to the Arduino. The interface was beamed onto the dashboard using a projector that sat on top of a tall tripod placed behind the user. The projector was hooked up to a computer that was running the prototyped interface (using Keynote presentation tool). Functional Specifications The following is an explanation of the different sequences in the driving modes transition. The Makey Makey registered a signal based on whether or not the user’s hands were on the steering wheel. This signal was interpreted as a desire to switch driving modes (automated on/off) and then relayed to an Arduino that controlled the motors responsible for the shape-shifting. Two sensors on the pivoting axis of the shape-shifting tube were used to signal its position to the Arduino and hence instruct the Arduino to make the correct movement. [arduino + makeymakey] In terms of physical functionality, the whole prototype was very mobile, even though it was meant to be used statically. It allowed us to easily conduct tests in different rooms of the d.school on different occasions.
177
The user was never alone when using the prototype. He was always guided through a driving scenario, including transitions from normal driving to automated mode, and then back to normal driving. Throughout the testing scenario, we also introduced our users to apps and functionalities that we had designed and implemented in response to past feedback (body heat measure, intelligent rerouting proposition, etc). Regarding its digital functionality, the interface was manipulated using a wizard-of-oz technique, as we did not had time to implement a hand tracking system using something like a Kinect or Leap Motion sensor. This meant that when the user put his finger on the dashboard to click a button or select an item, one of our team members at the computer (with its display mirrored to the projector) would click on the screen to simulate interactivity.
178
