Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Mobile and wearable devices are prevalent in our everyday lives, including our cars. As a result, there has been an increase in people accessing social media and apps while driving as reported in Germany (Vollrath et al. 2016) and the US (NHTSA 2016). Not only are drivers calling and texting; they do not stop short of browsing Facebook, taking selfies, and video calling (AT&T 2015). Indeed, the “car is merging with consumer electronics” (Normark 2015) as gadgets such as smartphones, fitness trackers and dashboard cameras enter the driving space. These devices have essentially become automotive user interfaces, even though they were never designed as such.

Statistics show the average age of all vehicles in Australia (Australian Bureau of Statistics 2016) and the United States (United States Bureau of Transportation Statistics 2014) is approximately ten years. Since this time span vastly exceeds the product lifetime of consumer electronics, smartphones and other gadgets are likely to be used in the car for another decade without dedicated vehicle integration (Android Auto, Apple CarPlay, etc.). This presents an opportunity for new driving experiences to take advantage of.

Mobile phones are often portrayed as unwanted distractions, which is reflected in a vast array of research on this topic. Distractions such as unsafe phone use can be caused by a lack of engagement in the driving task (Steinberger et al. 2016). Our previous studies indicate that driver boredom is most likely to occur in low-stimulation conditions such as routine drives, speed maintenance, cruise control, or low traffic. Semi-automated driving further amplifies the significance of this issue. A cutback in manual control causes a lack of engagement in the driving task more often, yet requires drivers to remain vigilant and take over control at any time (Casner et al. 2016). Vehicles are gradually evolving through several levels of partial (L2), conditional (L3), and high (L4) automation (SAE International 2014). One can expect some form of manual control for at least another two decades to come (Litman 2015), which emphasises the ongoing need for task engagement.

Drivers perform best and safest if their arousal levels are neither too high nor too low. The relationship between arousal and performance is referred to as the Yerkes–Dodson Law (Yerkes and Dodson 1908). It suggests that during periods of low arousal, added workload may improve performance, while during heightened arousal, higher workload may reduce performance. Added workload and distraction have received extensive attention in the driving context, whereas lack of engagement and low arousal have not.

The ability to add engaging, yet safe stimuli when needed, e.g., through gamified driving apps, can therefore, have direct impact on road safety and user experience (Schroeter et al. 2016; Heslop 2014). Capitalising on real-time driving data for gamified safe driving provides novel driving experiences. These have not been explored to date. In the near future, capabilities of connected cars and semi-automated vehicles, which can be even less engaging than manual driving in terms of the primary driving task (Casner et al. 2016), further broaden the design space. Biometrics, e.g., related to arousal, can contribute as an indicator for engagement in the driving task. This information may be one way to help determine appropriate points in time to present gamified interventions. For example, vigilance or stress experienced while driving in a big city for the first time would be reflected in high arousal levels and would therefore suggest that adding stimuli is inappropriate. Biometrics may furthermore feed into dynamic difficulty adjustment (DDA, Tijs et al. 2008), e.g., to adapt challenges presented in gamified driving apps to the current driver state so as to ensure optimal levels of engagement.

The research aim of this study is to explore how real-time driving data gathered from present day mobile and wearable devices can facilitate novel experiences such as gamified driving. To address this research aim, we sought to answer the following research questions.

  1. RQ1:

    How can we develop driving apps built around real-time vehicle and road data gathered from mobile devices?

  2. RQ2:

    To what extent can wearable devices be used as a data source in the design of engaging driving apps?

2 Contribution Statement

The contribution of our explorative work is threefold. First, we report on the design and implementation of the smartphone app BrakeMaster that makes use of vehicle and road data to provide an engaging driving experience. Second, we present an evaluation of the app in a driving simulator study. Third, we discuss to which extent data from consumer wearables, e.g., related to driver arousal, can be used to develop novel driving apps. We believe our work to be useful for both researchers and practitioners who aim to enhance driver engagement without compromising safety. The relevance of our contribution applies to manual as well as semi-automated driving as here the driving task is even less engaging and requires further research attention.

3 Related Work

Couben and Zhu (2013) suggested that technological capabilities should be used to render phones inoperable while cars are in motion to mitigate the risks of driver distraction. We argue that drivers are likely to continue bringing more consumer electronics into the car and use them, and it is our responsibility as human–computer interaction (HCI) researchers to address this scenario. We are not alone in this way of thinking. Insurance companies and software developers offer commercial apps that employ quantified-self and gamification approaches to improve driving behaviour. Axa DriveFootnote 1, e.g., reward good driving behaviour with points and allow users to share their accomplishments with their social networks. These apps, however, will only offer insights after the drive has been completed. Unlike our approach, they do not enhance safe-driving in-situ and in real-time. Other related applications do provide feedback during the drive but without taking into account when it is safe to do so (McCall and Koenig 2012; Prokhorov et al. 2011). As a consequence, they become distractions themselves.

In order to implement new driving apps, several enabling data streams are needed: access to vehicle information, context awareness for detecting road and traffic conditions, and, ideally, a means of detecting driver arousal in order to activate or mute the app when appropriate. The following subsections provide a review of three types of data relevant for providing feedback to drivers on their on-road behaviour:

  1. 1.

    Vehicle data (location, direction, speed, acceleration, etc.)

  2. 2.

    Road data (following distance, road signs, traffic situation, etc.)

  3. 3.

    Driver data (driver state, mental and physiological conditions, etc.)

3.1 Sensing Vehicle Data

Smartphones have previously been utilised to gather vehicle data relevant to safe driving, e.g., detecting speeding violations (Eren et al. 2012). Bluetooth connectors for on-board diagnostics (OBD), which are available at a cheap price (less than US$50), complement this set of information. Paired with a smartphone, they allow anybody to display accurate data such as current speed or fuel intake. OBD dongles such as AutomaticFootnote 2 and WayrayFootnote 3 track and visualise data in their respective smartphone apps, offering location information to family members and coaching features to improve driving skills. A study (Meng et al. 2014) shows that the various sensors found in smartphones can orchestrate information to achieve near complete similarity to OBD. Eren et al. (2012) utilised accelerometer, gyroscope and compass data to detect fatigue, inattention and speeding violations. Similarly, Dai et al. (2010) compared accelerometer and orientation data of Android phones with existing drunk driving patterns as part of accident prevention. All of the above examples illustrate the richness of vehicle data available from consumer electronics.

3.2 Sensing Road Data

Data about the driving environment can be derived in several ways. Camera imagery has previously been investigated to identify collision danger or traffic signals (Koukoumidis et al. 2012). Crowdsourcing data (e.g., traffic light schedules) can facilitate novel applications and benefit drivers by saving fuel or recognising changed road conditions. Another possible solution would be using OpenStreetMapFootnote 4 and its APIs to gather road data such as upcoming intersections or speed signs. Similarly, open data and smart city initiatives increasingly enable vehicles to receive real-time information from traffic management systems and other infrastructure elements. A combination of map data and smartphone sensors could furthermore detect the orientation of the car and whether the road network will lead the vehicle to the upcoming location in question. Furthermore, studies have shown how an array of GPS, accelerometer and microphone data can help in the detection of road bumps or vehicle braking (Eriksson et al. 2008; Mohan et al. 2008). More broadly, Andreone et al. (2005) envisioned an information manager that collects data about the vehicle and environment to estimate safety risks at any given moment to present to the driver.

3.3 Sensing Driver Data

Highly accurate and reliable physiology platforms are heavyweight and expensive (e.g., Liang et al. 2007), and therefore neither suitable nor affordable for deployment in vehicles. In the near future, however, advanced physiological measures are likely to become part of mainstream wearables such as fitness trackers and smart watches. Therefore, they provide real-time data streams and an ideal platform that we intend to capitalise on towards driver state detection. For example, driver states may serve as an indicator for the appropriateness of activating driving apps or for adjusting the difficulty in gamified driving challenges. Studies suggest that daily stress levels (Bogomolov et al. 2014) or daily moods (LiKamWa et al. 2013) can be accurately detected using smartphones. A problem with many of the methods employed is that they result in low granularity data (e.g., daily). In-vehicle biometrics need much higher granularity, ideally in real time. Therefore, researchers have looked into live imagery from smartphones, e.g., as a means to detect fatigue using blink detection algorithms (You et al. 2012; Schroeter et al. 2013). Dashboard or action cameras could potentially extend these capabilities. Hong et al. (2014) constructed a platform consisting of a smartphone and cheap sensors that assesses aggressive driving style. While this is not a heavyweight, expensive setup, it still requires additional components that are neither part of the car itself nor the driver’s everyday belongings. The automotive community has started to explore the potential of wearable technologies for in-car usage. Fitness trackers provide information such as heart rate activity and whether the user is seated or not. Smart watches provide biometrics that have been trialled as an indicator for driver drowsiness (Aguilar et al. 2015). Lastly, pattern recognition has been increasingly applied, e.g., to characterise driver skills (Zhang et al. 2010).

3.4 Research Gap

In summary, consumer electronics such as smartphones or fitness trackers have increasingly sophisticated sensing capabilities. Therefore, they present a largely unexplored potential to develop driving apps and to assess driver engagement. Rather than restricting their usage, we investigate how mobile and wearable devices can be considered allies in the quest towards safer driving. We argue that real-time driving data gathered from these devices can be taken advantage of for engaging safe-driving apps. Furthermore, the capabilities of such lightweight devices may create cheaper and increasingly accurate methods for assessing driver engagement, thereby laying the groundwork for affordable future safety interventions.

3.5 BrakeMaster: An App Built Around Vehicle and Road Data

Addressing RQ1, this step serves to explore the vehicle and road data streams provided by mobile devices. We developed BrakeMaster, a smartphone application that gamifies approaches to red lights. The app shows a black screen while the car is in motion to avoid unnecessary distractions. Upon approaching a red light, an audio cue signals the beginning of a new challenge. The driver is invited to match a deceleration curve instead of breaking abruptly. When the car has come to a halt, the app will display an assessment of the braking performance (Fig. 2.1).

Fig. 2.1
figure 1

Sample target curve (red) and braking performance (blue) shown in the prototype implementation

Full size image

3.6 User Experience Design

Designing engaging experiences in the safety critical space of the car requires a careful balance between fun and safety. BrakeMaster represents a first attempt at striking that balance and is an outcome from our design approach for driving gamification, where we defined conceptual layers for designing driving gamification such as verbs, mechanics, core, theme and concept (Steinberger et al. 2015). For this initial game, we picked the routine driving scenario of approaching a red light. At the verb layer of the game, which describes user input and simple actions associated with it, users control the app by applying force to the brake pedal and therefore slowing down the vehicle. This aspect is novel; existing driving apps do not read user input from pedals or the steering wheel.

BrakeMaster is a result of design activities such as storyboarding and sketching, which allowed us to explore combinations of existing videogame concepts and driving situations (Steinberger et al. 2015). Figure 2.2 shows an early version of BrakeMaster that was designed around an Angry BirdsFootnote 5 theme. The target in this version is a bull’s eye. The bird’s position on it reflects the smoothness of braking (y-axis) and steering (x-axis). It was later refined based on participant feedback gathered from an extensive qualitative user study. In that study, potential users expressed their interest in accessing more raw data about their driving performance and skills. As a result, BrakeMaster now offers a technical representation of the performance (Fig. 2.1) rather than an elaborate theme.

Fig. 2.2
figure 2

Excerpt of a storyboard illustrating an early version of BrakeMaster inspired by an Angry Birds theme

Full size image

Auditory instructions were chosen to avoid additional visual load, given driving is mostly a visual task (Sivak 1996). An assessment of the performance is conveyed visually as a graph (Fig. 2.1) and via audio feedback based on a matching score. The app distinguishes between 0–33% matches (e.g., “Try harder next time!”), 33–66% matches (e.g., “Close but not close enough!”), and 66–100% match (e.g., “Excellent”). Both the visual and auditory feedback allow users to quickly comprehend their performance before the traffic light turns green and the vehicle is set into motion again.

3.7 Prototype Implementation

BrakeMaster was prototyped as an Android application. In terms of gathering vehicle data, the app connects to on-board diagnostics (OBD). OBD is a prevalent interface for monitoring a wide range of vehicle parameters such as speed, pedal use, steering wheel angle, or fuel intake. There are many cheap adapters from different manufacturers offering USB, COM, or Bluetooth access to OBD data. We used the ELM327 OBD Bluetooth Interpreter,Footnote 6 which allows for a wireless connection, and an open source libraryFootnote 7 based on the OBD-II Java API to process vehicle data within the Android app. This implementation was used for initial test drives around a car park.

For the purpose of the driving simulator study (cf. next section), however, vehicle data had to be gathered in a different way. Since the OBD socket was already occupied as a result of the laboratory setup, speed data needed to be acquired through the simulation software. We therefore added functionality to the BrakeMaster code to allow connections from either Bluetooth (for the OBD adapter) or WiFi (to read network data transmitted by an Intempora RTMapsFootnote 8 middleware application). Figure 2.3 illustrates the hardware software mapping used in the implementation.

Fig. 2.3
figure 3

Interface connection allows input from two data sources: simulation software (WiFi) or OBD (Bluetooth)

Full size image

Relevant road data for BrakeMaster include locations of traffic lights as well as their status (green or red). Detecting traffic lights can be achieved in several ways. For example, vehicles are able to receive signal information from advanced traffic management systems in smart cities. This approach has recently been pursued by Audi for their traffic light information system, which indicates on the instrument cluster the time remaining until the signal changes to green.Footnote 9 Aside from vehicle-to-infrastructure integration, OpenStreetMap APIs could be utilised to identify nearby signalled intersections, in combination with camera image recognition as outlined in the related work section. The BrakeMaster implementation for use in the driving simulator gathered traffic light information from the simulation software (Fig. 2.4).

Fig. 2.4
figure 4

Red lights trigger BrakeMaster challenges

Full size image

Between the beginning of a braking challenge and stopping, the app records the speed of the vehicle. This data is used to display the braking curve and to calculate the performance score. Once the car has come to a stop, the user is presented a graph illustrating the desired pattern versus the user’s braking performance (Fig. 2.1).

The exact nature of desired braking patterns as well as the comparison algorithms could be based on transportation literature and/or be context-dependent. For example, for smooth braking aimed at optimising passenger comfort, a pattern matching algorithm could be used before comparing the two braking curves, while for economical braking, a dynamic time warping algorithm could be better suited. We did not take those into consideration at this point, but applied a software pattern that decouples relevant components and allows for future implementations of different target curves. Every target curve can present a different challenge or level in the game design.

4 User Study

We conducted a driving simulator study using the BrakeMaster prototype, which served two purposes: (a) identify performance or usability challenges in the prototype; and (b) learn about the user experience of the app’s gamification concept.

4.1 Participants

Overall, 10 people (5 female) aged between 21 and 37 (M = 29, SD = 4.42) participated in the study. Given the explorative nature of our approach, the only selection criterion was the possession of a valid driver’s license. Before commencing data collection, we obtained approval from the university’s ethics committee (approval number 1500000046 in accordance with the Australian Code for the Responsible Conduct of Research) and written consent from participants.

4.2 Procedure

The study took place in a motion driving simulator with six degrees of freedom, which presents a safe, yet immersive way to conduct controlled experiments. Each session lasted approx. ninety minutes. To begin with, two five-minute familiarisation drives ensured that participants were acquainted with the driving simulation and the app. Afterwards, participants were asked to complete a motion sickness survey to ensure they were feeling well and able to continue. We designed the evaluation as a within-subjects, repeated measures experiment with two counterbalanced conditions across participants, control and game, and one drive per condition. The two research drives (control and game) consisted of approximately 8 min suburban driving each. The speed limit was 60 km/h throughout the road scenario, which included trailing, oncoming and cross-traffic. Participants encountered nine signalled intersections and five red lights, which triggered challenges through the BrakeMaster app in the game condition (Fig. 2.4). A smartphone running BrakeMaster was placed behind the steering wheel where dashboard displays are usually positioned (Fig. 2.5).

Fig. 2.5
figure 5

Smartphone placement in the driving simulator study

Full size image

4.3 Data Collection

We acquired a combination of objective and self-reported data. The selected methods were chosen to gain insights related to app performance, usability, user experience and driver arousal.

To monitor app performance, we looked into three different metrics. First, we were interested in response time to see whether a change in vehicle status was detected and signalled to the user in a responsive manner. The vehicle status can vary between driving (>100 m from next red light), approaching (<100 m from the next red light), or stopped (stopped at red light). A fast response time is essential, because the transition from one state to another often takes only a few seconds and represents an indirect user input. Regarding throughput, the system should process data at a minimum rate of 10 Hz to project the braking curve and to support a response time of at least 0.1 s. Therefore, the third performance metric is accuracy. Invalid speed readings, noise and rounding errors should be avoided by checking the data for consistency upon aggregation.

We asked participants to fill in the system usability scale (SUS) questionnaire (Brooke 1996), which provides a metric for overall product usability and can be used on small sample sizes with reliable results. We were particularly interested in the interaction technique that takes user input from the brake pedal, which is a novel aspect compared to existing driving apps.

In order to explore the subjective experience with the app, participants were asked to self-report their affective state using a paper-based version of the Circumplex Model of Affect (Russell 1980). This was done after the control drive and after the game drive.

Lastly, semistructured interviews were conducted with five of the participants to further explore the experience with the app.

4.4 Results

4.4.1 Objective Data

In terms of app performance, response time and throughput was assessed post-experiment by comparing the application log with the driving simulator log. Based on these observations, the vehicle data was processed at a frequency of 20 Hz, exceeding our desired prerequisite. In terms of accuracy, the vehicle speed log revealed that the majority of erroneous data was received while the vehicle was stopped, in the form of negative values close to zero. These kinds of imprecise readings can be prevented in the user interface by, e.g., rounding up values.

4.4.2 Subjective Data

The mean SUS score across all participants is M = 78.5 (SD = 16.55), on a scale from 0 (worst) 100 (best). All individual scores can be seen in Fig. 2.6 as a boxplot diagram, as proposed (Young and Wessnitzer 2016). According to literature (Bangor et al. 2008; Lewis and Sauro 2009), scores above 68 are considered above average and systems scoring in the high 70s to upper 80s are considered to have above passable usability and below superior usability. Our results show superior usability for two participants (P2, P9), below average usability for another two participants (P3, P6), and scores in between for the remaining six participants. These results suggest good overall usability and indicate that the game objective was well understood and desirable enough to be pursued. P3’s score of 37.5 is particularly low. In the post-experiment interview, she revealed that she does not enjoy games and driving tests, and therefore she had a generally negative attitude towards her study participation.

Fig. 2.6
figure 6

Boxplot diagram showing the SUS scores distribution

Full size image

The Circumplex Model of Affect data indicate that, in general, participants perceived an increase in arousal and a more positive valence in the game drive. The aggregated data can be found in Fig. 2.7a, b. Looking back at the motivation behind the app, it can be argued that this result is ideal. That is, the game creates arousal and increases driver engagement, without over-catering to hedonistic needs, thus not creating too much distraction from the driving task.

Fig. 2.7
figure 7

a Individual data on the Circumplex Model of Affect. b Mean data on the Circumplex Model of Affect

Full size image

Finally, the interview data reveal participants’ subjective experience using BrakeMaster and simulated driving. P1 felt “happy to engage with the challenge and to get positive results.” His game performance was good overall, and he reported feeling “a small sense of accomplishment” when receiving positive feedback.

Similarly, P5 was deeply immersed in the driving simulation and enjoyed BrakeMaster. He said, “I felt like playing the game was raising the sense of awareness, I was committed to complete the task that I was assigned, and in doing that I was alert. So I was more aware of the obstacles and the traffic signs and very engaged in the idea of braking in a proper way.” Furthermore, the participant reported after-effects of the study and said, “days after this test, actually every time now I am more aware of my braking. I think it keeps on doing something good for me.” He felt it was owed to a “sense of competition with myself.”

P6 described herself as an easily bored person and felt that BrakeMaster targets an issue that she is familiar with. She said, “highway driving or typically monotonous driving is just repetitive, but you have to focus on it.” Furthermore, P6 said she is “fairly competitive” and “likes the idea of playing the game,” although in the long run, the game should change from time to time to remain interesting.

For P7, playing the game was a generally positive experience, “I think it improved my mood and my arousal.” He said that the visual feedback helped him improve his driving performance. However, he felt that the audio feedback was “a bit mean” at times and suggested using more positive audio messages.

P3 agreed as she expressed dissatisfaction with the audio feedback and stated that it felt discouraging. P3, as pointed out previously, began the interview by stating, “I don’t enjoy playing games, I don’t like driving tests.” This led to an overall frustrating experience. Lastly, some participants reported that the simulator brakes did not perform as expected based on their real-world driving experience, which emphasises the need for longer practice drives in future studies.

4.4.3 Discussion

Through developing BrakeMaster as a prototype and studying user interactions with it, we have seen promising results. Real-time vehicle and road data can be obtained and collected in smartphones and built upon for safe-driving apps as we have demonstrated with BrakeMaster. Vehicle data in particular can be gathered in a feasible and accurate way through the prevalent OBD interface. It is technologically more challenging to gather road data. Although much information can be pulled from OpenStreetMap, e.g., upcoming traffic lights or speed signs, a combination of this information with other data, e.g., the direction in which the vehicle is moving, is often required to make sense of the information in a useful way.

Furthermore, gamifying just one aspect of the drive may not be enough. A combination of several challenges might provide more stimulation and pleasure. BrakeMaster is just one example to illustrate the trajectory of our ongoing programme of research, but provides a platform for extensions. Gamifying driving can be spun further to incorporate more driving scenarios, other drivers, and challenges. For example, highway driving could gamify the keeping of accurate following distances relative to current speed to prevent tailgating, driving in start-stop peak hour traffic could turn into a game that facilitates the least amount of acceleration, braking and lane changes with the view to create a smoother traffic flow. In the future, the increased contextual awareness of connected and semi-automated cars will provide greater scope for exploring more alternatives.

5 Sensing Driver Arousal from Wearable Devices

Through the development and evaluation of BrakeMaster, we explored the challenges and opportunities in gathering road and vehicle data (addressing RQ1). We now explore to what extent wearables can be used to gather driver data (addressing RQ2). In particular, we are interested in the acquisition of driver arousal data, which is an indicator of task engagement (Yerkes and Dodson 1908), as a data stream in the design of engaging driving apps. Such biometrics may be useful to determine appropriate points in time for presenting driving games such as BrakeMaster or to dynamically adjust their difficulty. In the future, this type of driver data may be acquired through sensors integrated into steering wheels or seats, but in this study we are exploring if and what kind of information we may be able to gather from present day consumer wearables such as fitness trackers and smart watches.

We compare two consumer wearables to an advanced biofeedback system. The aim of this step is to understand in what ways they differ in terms of data accuracy as well as procedure and handling.

5.1 Requirements for Driver Arousal Detection Systems

The driving context is a unique and challenging space for acquiring physiological data. Unlike lab settings, the driving context is more constrained in a number of ways. For example, vehicles move during drives, just like participants move their arms and legs whilst steering and accelerating. Furthermore, there is limited space in a vehicle for instrumentation. Lastly, driving contains frequent situational changes caused by traffic conditions and driver behaviour, which underlines the necessity for highly granular data.

Based on the above constraints, we identified the following device requirements:

  1. 1.

    Portable and wireless

  2. 2.

    Robust (not affected by movement)

  3. 3.

    Real time and patterns

Regarding the first requirement, portability is necessary because of the nature of the driving environment. Data collection devices would have to be located in the vehicle. Wireless devices are portable and also provide convenience in regards to set up and positioning in the vehicle. Wired devices would be difficult to hook up, both to the driver and to the collection device, and having wires run through the vehicle is additionally troublesome, as any movement of the leads and the sensors would contribute to noise in the data.

Addressing the second requirement, it is vital that the data collection systems are robust and not easily susceptible to movement artefacts, such as those associated with driving, as this would also increase noise in the data (Stern et al. 2001; Baguley and Andrews 2016).

In terms of the third requirement, it would be valuable to collect physiological data in real time or to detect physiological patterns across drives. This allows apps to determine arousal at a particular time during the drive or for entire drives, e.g., if an app is meant to reflect or factor in driver states.

5.2 Devices Compared

We selected three devices to compare to represent the variety of biofeedback systems available today across different cost and portability factors: Polar H7,Footnote 10 Empatica E4Footnote 11 and Biopac MP150.Footnote 12

The Polar H7 is an affordable (approx. US$80) heart rate monitor mounted on a chest strap. It uses an electrocardiogram (ECG) heart rate sensor to deliver continuous and resting heart rate data.

The Empatica E4, which is more costly (approx. US$1700) but still available off-the-shelf, is a wireless wristband. It has four embedded sensors: photoplethysmograph (PPG), electrodermal activity (EDA), three-axis accelerometer and temperature.

Lastly, the Biopac MP150 is an advanced biofeedback acquisition system. It offers up to sixteen channels for data collection including ECG, HRV, electroencephalogram (EEG), electromyography (EMG) and electrogastrogram (EGG) and is an established system used in research laboratories. Unlike the Polar H7 and the Empatica E4, it is far less affordable (>US$10,000) and neither wearable nor lightweight.

5.3 Testing Procedure

In light of our interest in driver arousal, we focus on EDA and HR/ECG, which are established indicators of arousal (Stern et al. 2001). One of our team members (male, aged 27) wore the Empatica E4 on the right wrist and the Polar H7 was attached around the chest as directed. In terms of the Biopac MP150, two EDA electrodes were placed on the inner arch and sole of the participant’s left foot. For ECG, the ground electrode was placed on the forehead, the first electrode approximately 4 cm below the right clavicle, and the second electrode on the left side, just below the last rib.

Since the Biopac is a stationary device, we conducted the comparison in a lab setting. The participant completed two 4 min sessions of Need for Speed,Footnote 13 a driving video game that simulates typical movements while driving. The set up consisted of a desktop steering wheel and a two pedal attachment on the floor connected to an Xbox 360.Footnote 14 Note that automatic transmission was used to reflect the configuration in our driving simulator. Consequently, the participant’s left foot did not have to move for shifting gears, which we exploited in the placement of electrodes to avoid movement artefacts in the EDA data. We would expect more noise in the data in a moving vehicle.

5.4 Results

Unsurprisingly, the Polar H7 and Empatica E4 were substantially easier to use and less intrusive than the Biopac, whereas the Biopac provided the most accurate data for both EDA and ECG. A comparison of the data showed that the Polar H7 heart rate and heart rate variability data very closely resemble the Biopac data. The data collected from the Empatica E4 was not similar for both EDA and heart rate and sometimes was even in the opposite direction (see Fig. 2.8).

Fig. 2.8
figure 8

In our experimental setup, heart rate data from the Empatica E4 (red) often does not resemble Polar H7 data (blue)

Full size image

Table 2.1 summarises the key characteristics of the three biofeedback systems and presents the main insights from the comparison study.

Table 2.1 Main characteristics of the three biofeedback systems compared
Full size table

5.5 Discussion

Acquiring biometrics in the driving context poses various technological and logistical challenges. We particularly faced difficulties in separating arousal levels associated with game engagement from those associated with bodily movements. In the driving context, people move their arms and legs to manoeuvre the car. This makes particularly capturing EDA challenging, where electrodes that are susceptible to noise caused by movement artefacts need to be attached to participants’ hands or feet. Capturing HR is more feasible, and consumer wearables will do for certain use cases as trends and patterns are comparable with data acquired with the Biopac.

Our observations regarding varying HR data echo findings from a recent study by Nelson et al. (2016) who examined the accuracy of various FitBitFootnote 15 and JawboneFootnote 16 devices for estimating energy expenditure (EE) and step counts. They found that consumer-based physical activity monitors should be used cautiously for estimating EE, although they provide accurate measures of steps for structured ambulatory activity.

We propose that consumer wearables such as smart watches or fitness trackers may be used as a cost-effective and non-invasive means to derive arousal scores or patterns across entire drives. As a design implication, gamified driving apps cannot yet rely on biometrics as a means to determine appropriate points in time to activate driving games or to dynamically adjust their difficulty. However, apps could present post-drive feedback for reflection, leaderboards, or to unlock levels. More accurate values would have to come from advanced measures, which may be more integrated into future vehicles.

6 Conclusion

In this chapter, we explored the opportunities for gamified safe-driving experiences provided by real-time vehicle, road, and driver data gathered from mobile and wearable devices.

We developed BrakeMaster, a smartphone app for drivers based on vehicle and road data, and evaluated it in a simulator study. We laid out how these data can be obtained through a combination of OBD, map data and sensors built into smartphones and similar devices. Participants self-reported that arousal and pleasure increased when using BrakeMaster while driving.

Based on our comparison of different biofeedback systems, we found that capturing driver data reliably and accurately is challenging. In particular, biosignals such as EDA are susceptible to noise caused by movements that naturally occur while driving. However, there may be opportunities to use heart rate monitoring capabilities in fitness trackers and smart watches to indicate arousal patterns across drives. A major benefit is the small size and portability of such consumer wearables. More accurate data, e.g., to determine when to activate or dynamically adjust gamified driving challenges, would have to come from advanced sensors which may be integrated into future vehicles.

Taking these findings together, we conclude that road and especially vehicle data are most promising for developing novel driving experiences, whereas driver data is more challenging to gather in this unique design context. Smartphones in particular present an opportunity to develop driving apps for researchers and practitioners that aim to enhance safe-driving experiences. Future work should investigate how such experiences can be designed without causing distraction.