Effects of AI on driving experience

(1)

Effects of AI

on driving experience

Master Degree Project in Informatics One year Level 30 ECTS

Spring term 2013

Giulio Franco

Supervisor: Henrik Engström

(2)

Abstract

Realism is a very sought feature in interactive driving simulators for traffic studies, since a non- realistic simulation could produce non-realistic human drivers behaviours. Since cars driven by artificial intelligence (AI) are one of the main components of a traffic simulation, they play an important role in making up the overall sense of realism. A good understanding of how the AI influences human drivers is thus important in avoiding biases in traffic studies with simulators, and might also come useful in simulators for traffic education, in order to induce certain behaviours in the students.

The purpose of this study was to build a driving simulation with multiple AI-driven cars, and let human testers use it, in order to analyse if and how a more polite lane-change behaviour, a more realistic lateral alignment, and a slower average speed affect the perception and the behaviour of human drivers.

The simulator was developed upon low-cost hardware infrastructure previously used for other traffic studies. Since the existing software is very specific and hard to modify, a new simulation software was built from scratch for this study, using the Unity3D engine and implementing design patterns developed in previous studies, in order to produce a more flexible and modifiable infrastructure than what had been done in the past studies.

The test subjects gave a generally good feedback on the simulator as a whole, and cars which politely changed lanes were regarded as behaving in a slightly more realistic way. Some insights were also obtained about user perception, mainly consisting in a difficulty in perceiving absolute speeds, whereas relative speeds were estimated more accurately.

Keywords: driving simulator, artificial intelligence, driving behaviour, realism

(3)

1 Introduction

In 2006, Lebram, Engström, and Gustavsson developed a mid-range fixed-based driving simulator. Moreover, they developed an infrastructure on their own, based on an open source game engine, which allows the execution of custom made simulations and applications.

Thanks to the latter infrastructure, the simulator has then been verified (Backlund, Engström, Johannesson, and Lebram, 2010) to be a very useful training tool to help driving schools in providing better traffic education. Even so, some of the people who tested the simulator complained about the behaviour of computer-controlled road users, which disregarded traffic rules and acted in an unrealistic way.

Many simulation models, that can be used to simulate drivers' behaviour and improve the realism of computer-controlled cars, have been proposed in the past. Most of them are traffic simulation models, mainly developed and used in the field of road engineering, to study driving speeds, risk of accident, road wearing and other interesting factors in road planning. As shown by Maerivoet and Moor (2005) and Blatnig (2008), some difficulties arise, when trying to translate such models to artificial intelligences for a real-time simulator, some difficulties arise.

Nevertheless, very good results have been obtained by many functional interactive simulators (Champion, Mandiau, Kolski, Heidet, and Kemeny, 1999 and Al-Shihabi and Mourant, 2003).

In 2002, Wright, Ward, and Cohn studied how artificial intelligence in driving simulations affect the realism of the simulation itself. He found that realism is strongly related to the variability of behaviour among drivers. Al-Shihabi and Mourant (2001) also dealt with realism, by proposing a framework aimed at implementing artificial drivers that behave like humans and implement different behaviours, formalizing the method already used by Champion et al.

(1999).

The present work moves from these result, with the goal to further investigate the influence that the behaviour of AI-driven cars can have on the driving experience and on the behaviour of human drivers.

With more knowledge about the relations between drivers' behaviours, it could be possible to produce finely tuned simulations which induce the users in manifesting some bad driving habits, in order to show them how dangerous such behaviours can be and how to correct them.

Also, by further investigating the influence of behavioural features on the overall realism, it would be possible to better understand if the addition of some features can improve realism with little effort.

The goal of this study is thus to build a driving simulator software on the hardware set up by Lebram et al., and then use it to perform a user test, by which the data to be studied will be gathered. The simulation software has been be developed in Unity3D, with a flexible artificial intelligence, as proposed by Al-Shihabi and Mourant (2001), so that it allows to easily introduce multiple implementations with different parameters.

The thesis is structured as follows:

Section 2 will present previous work that has been performed on matters related to this one.

(6)

Then, Section 3 will give the details about the problem to be investigated and the research method that has been used. Section 4 will present the software infrastructure which was developed, while Section 5 will focus on the artificial intelligence implementation. The results obtained by means of the final test will be discussed in Section 6. Some final considerations will be made in Section 7, and the results of the work will be summarized.

(7)

Figure 1: The simulator car surrounded by screens (1-7).

(taken from Lebram et al. (2006, p. 152))

2 Background

This section will introduce previous results and studies on which this work is based. The discussion will start from the hardware infrastructure of the simulator that has been used and some previous work that analysed its potential as a traffic education tool. Then, the evolution of traffic simulation models will be summarized, up to the state of art. A brief introduction about the requirements of a realistic simulation will then follow.

2.1 Hardware Infrastructure

This work uses the very same hardware simulator as created by Lebram et al. (2006). It's based on a modified S80 (S80-Specs) by Volvo, connected to 7 projected screens, which surround the car and bear a horizontal field-of-view of 280°. Each projector is connected to a common mid- end desktop PC, with all the nodes running the simulation in parallel, while a server controls the positioning of the various game objects.

The simulator is fixed-based, so no G-forces are applied to the driver. The sense of speed is conveyed by using sound from the speakers and the fans, whose rotational speed is adjusted accordingly to the simulated speed of the car. Moreover, two force feedback systems simulate the feeling of the road.

The car has been modified so that it's detected by the server as a standard game pad. This allows many existent commercial games to be run on the simulator, though it's impossible to use all the screens, unless the source code of the game can be accessed and modified.

(8)

2.2 Games for Traffic Education

It has been already stated that this work is inspired by Backlund et al. (2010). In that case, an ad-hoc simulation software was developed, which required the player to drive on a five- lane highway while following a target. The game was planned so that an incorrect lane change procedure was very likely to result in a car crash, while lane changes themselves were needed to avoid losing sight of the target. As the player progressed through the game levels, the computer- drivers became more and more aggressive, with many cars running at high speeds.

The evaluation of the game was performed by letting driving school students use the software, between two reference driving sessions. To separate the effects of the simulator itself from the effects of the game, half of the participants used a non-game version, with no aim defined.

During the reference drives, the students were required to change lane on command, while several traffic safety parameters were recorded: speed, use of turn signals, headway distance, use of rear-view mirrors. At the end of the test, the participants were also asked to fill in a questionnaire about their experience with the simulator.

The objective results showed a significant improvement in all the studied aspects, though no statistically significant difference was found between the students who played the free roaming version and those who played the game version. According to the authors, this is due to a lack of maturity in the game component.

On the other side, the user questionnaire showed that the game version did succeed in putting players in harder situations. Most of the participants also used almost all the time they were given, meaning that the environment was able to catch their attention. Some participants also requested a more accurate feedback about the errors they made, or claimed that computer- controlled cars were not respecting traffic regulations.

2.3 Traffic Simulation Models

Many models, that could be used to simulate drivers' behaviour and improve the realism of computer-controlled cars, exist in literature. Most of them are traffic simulation models, mainly developed as part of studies on traffic safety and road conditions. Some of these models have however been translated to artificial intelligence implementations for driving simulators, as in Olstam, Lundgren, Adlers, and Matstoms (2008) and Al-Shihabi and Mourant (2003).

A taxonomy of the different type of simulation models can be found in Cascetta (2001, p. 75), who distinguishes among the following categories, depending on the modelled level of detail:

Macroscopic models represent traffic as a fluid, and only trace global variables, like the flow or average speed;

Mesoscopic models deal with groups of entities, and may trace trajectories and speeds of individual cars, but it's based on aggregate performance measures;

Microscopic models represent traffic discretely, as a set of single cars; they keep track of variables of each individual car and explicitly model drivers' behaviours.

(9)

Among the three presented categories, only microscopic models carry the level of detail needed to build an artificial intelligence that can be confronted with a human driver, because the output of the simulation have to consist in actual movements of individual AI-controlled cars (Olstam et al., 2008).

In more detail, the simulated cars should exhibit several behaviours (Blatnig, 2008 and Ehlert and Rothkrantz, 2001):

Speed regulation Each driver must regulate the speed of his/her car depending on several factors, like the speed of the car preceeding him, the structure of the road, or the speed limit in force.

Headway distance In models which are physically correct, a car cannot decelerate more than to a fixed limit. So, a safe headway distance should be kept from the preceding vehicle.

Lane changing When driving on roads with two or more lanes, each driver must choose which lane to drive on, and eventually decide to change lane. Moreover, lanes should be used according to the traffic regulations in force.

Overtaking When two-way roads are simulated, a separate modelling should be done for the overtaking operation, when a driver temporarily occupies the opposite lane in order to overtake one or more vehicles that are preceding him.

Route planning If there is the possibility to choose among different possible roads, each driver should make choices about which route to take. This choice can either be based on pseudo-random factors or on a hypothetical destination point, which the driver strives to reach.

Behaviour at intersections If multiple roads can be chosen, there will be intersections along the road. So, the drivers should be able to drive across intersections according to regulations and the environment (other cars, pedestrians, traffic lights, etc.).

Roundabouts are not specifically addressed to, but they can be considered as a circular main road, with several intersections.

Higher-level models have been reconsidered by Burghout (2004) and Olstam et al. (2008), who propose an interesting optimization, which limits the microscopic simulation (computationally expensive) to the area nearby the human driver, while uses a mesoscopic model to simulate a broader area. A traffic generator, comparable to a macroscopic model (both take account of global data, like average car flow), is used to populate the mesoscopic modelled area.

Härri, Filali, and Bonnet (2009) present an extensive survey of microscopic simulation models.

Even if that work is focused on a different purpose, it nevertheless provides useful insights into the set of existing models, their features and their validation status. It also shows that it can be troublesome to use a simulation model for another purpose than the one it was originally developed for, due to simplifying assumptions that were harmless to the original purpose of the model, but cut off important aspects of the new domain.

A similar issue applies when trying to apply these models to a real-time simulation. Blatnig (2008), for instance, addresses the fact that many of the models developed for road studies

(10)

make the simplification of assuming instantaneous lane changes, which makes it impossible to directly transfer them into a realistic real-time agent. So, the need arises for a more accurate lane-change model. Even if it's not clearly stated in their work, Wright et al. (2002) confronted with a similar issue. In order to make a human driver interact with the simulation, they had to modify all of their virtual personalities to be more cautious when approaching intersections.

This happened because they could not have any information about future actions by the human, whereas computer drivers can communicate their intentions to each other and negotiate a non- conflicting behaviour.

2.4 Car-Following Models

Car-following models are the basic building block for a traffic simulator. They implement speeding and headway distance, if applicable. A categorization of such models is proposed by Brackstone and McDonald (1999). Four categories are proposed:

1. Collision-avoidance models define car motion as the result of trying to keep a given headway distance;

2. Linear models define acceleration as a linear combination of speed difference and distance to the preceding car;

3. Psychophysical models define car behaviour as the effect of several perceptions, which generate a reaction when they reach a given threshold (also called "action point");

4. Fuzzy models define car behaviours by means of several fuzzy sets, which are used to probabilistically trigger reactions by the AI.

Some previous car-following models, that could be useful for this very work, will now be presented, for use in Section 4. As it will be shown, complex models can be built on top of these simpler ones by combining multiple instances of a car-following model or by adding exceptions to it.

2.4.1 Wiedemann's Psychophysical Model

Wiedemann's model (Wiedemann and Reiter, 1992) belongs to the psychophysical class of models. It exploits a previous result by Michaels (1963), that shows how drivers perceive relative speed "through changes on the visual angle subtended by the vehicle ahead" (Wiedemann and Reiter, 1992, p. 190). A set of thresholds is identified, which is used to determine the driver's reaction, depending on the difference in speed and the distance with the preceding car:

• ax: Desired headway distance in stationary traffic.

• abx: Desired headway distance in moving traffic, depends on ax and on the current speed.

When this distance is undergone, the driver will brake.

• sdv: Function describing a distance at which the driver will start decelerating. This is highly dependent on the speed difference, and is derived from Michaels's results, that analyse how the perception of the visual angle is affected by speed.

(11)

Table 1: Gipps' model parameters.

Parameter Meaning

τ Driver reaction time (the same for all the drivers) an Maximum desired acceleration for car n

b_n Maximum desired braking for car n Vn Desired speed for car n

x_n(t) Headway distance of car n at time t

ˆb Maximum desired braking estimation for other drivers

• opdv: Function describing a distance at which the car will increase its acceleration, because it notices that the car ahead of him is getting far away, and a higher speed can be used.

• sdx: Maximum (fixed) following distance. When below this distance, even if the two previous thresholds have not been triggered, the driver will unconsciously tune his/her speed to avoid dropping below abx or getting farther than sdx.

Behavioural variability can be implemented by applying per-driver perturbations to the functions described above.

Wiedemann also proposed an adaptation of the model to roads with multiple lanes (Wiedemann, 1991). The modified model has then been used in Gorgorin, Gradinescu, Diaconescu, and Cristea (2006), to build a simulator that has been validated as generating a realistic highway traffic.

2.4.2 Gipps' Model

In 1981, Gipps proposes a time-discrete car-following model, which falls under the collision avoidance category.

Unlike the preceding models, which aimed at simplification, Gipps introduces several mitigating factors, which makes the drive smoother. These consist in each virtual driver estimating a maximum desired braking force ˆb and a reaction delay θ for the car following him, and taking these values into account while deciding the speed to adopt. It is shown that, if θ≥ ^τ₂, τ being the actual reaction time of the driver, then Gipps' model is collision-free.

In more detail, the speed v_n(t + τ ), adopted by driver n after the (t+τ )-th speed update, is given by the equation below, whose parameters are explained and summarized in Table 1.

vn(t + τ ) :=min



vn(t) + 2.5anτ (

1−vn(t) Vn

) √

0.025 +vn(t) Vn

, (1)

b_n+ vu

utb²_nτ²− bn

[

2 [x_n₋₁(t)− sn−1− xn(t)]− vn(t)τ−v_n²₋₁(t) ˆb

]



(12)

Table 2: IDM model parameters.

Parameter Meaning

a^(α) Maximum desired acceleration for car α b^(α) Maximum comfortable deceleration for car α v₀^(α) Desired speed for car α

s^(α)₀ Desired headaway distance, in stationary traffic, for car α s^(α)₁ Desired headaway distance, in congested traffic, for car α T^(α) Desired headaway time (reaction time + braking time) for car α

δ Acceleration exponent

It can be noticed that Gipps' model assumes each driver can accurately measure headway distance and speed of both himself and the driver behind him, which is the case in simulation software. Moreover, even if the simulation is time-discrete, time slots are assumed to be smaller than a typical reaction time, which should pose no problems for implementation in a real-time simulator. In fact, Gipps' model and its modifications are used by many simulators (Brackstone and McDonald, 1999).

Gipps himself also provides a modification of its model, for dealing with multiple lanes (Gipps, 1986). This version is used as a basic building block for the UDel Models¹ simulator(Härri, Filali, and Bonnet, 2009, pp.36-37).

2.4.3 IDM

IDM is a quite simple acceleration model (Treiber, Hennecke, and Helbing, 2000), which expresses a car's desired acceleration in terms of the car preceding it. According to Brackstone and McDonald's classification, it can be described as a collision avoidance model. Even though it belongs to the same family as Gibbs' model, its form is much simpler, because it only considers the preceding car, whereas Gibbs also considered influence on the following one.

In more detail, according to IDM a car α will use an acceleration ˙v_α

˙vα: = a^(α)



1− ( vα

v^(α)₀ )_δ

−

(s^∗(vα, ∆vα) sα

)2

 (2)

with s^∗(v, ∆v): = s^(α)₀ + s^(α)₁

√ v

v^(α)₀

+ T^(α)v + v∆v 2√

a^(α)b^(α) (3)

The meaning of the customizable parameters is described in Table 2, while v_α is the current speed of car α, and s_α is the current headway distance from car α and the one preceding it.

Thus, the formula applies a maximum acceleration of a^(α), reduced by a factor which depends on current/desired speed ratio and desired/current headway time to the preceding car.

Here, s^∗ is a function defining the desired gap, depending on a car's current speed and on the difference in speed with the car ahead of it. This way of defining the acceleration is needed to

1http://udelmodels.eecis.udel.edu/

(13)

depict two similar situations, that require different reactions. When a car α is very close to the car preceding it:

• If ∆v ≤ 0, the preceding car is running faster than α, then α has no need to brake, as the headway gap will soon reach an acceptable value;

• If ∆v > 0, on the contrary, the gap is shortening, and so there is a urge to brake and avoid a collision.

Since the authors suggest a zero value for the parameter s₁ in normal traffic conditions, the desired gap function can be used in the simpler form

s^∗(v, ∆v): = s^(α)₀ + T^(α)v + v∆v 2√

a^(α)b^(α) (4)

IDM has been further extended by the MOBIL model, which extends it to multi-lane roads, and IDM-IM, which deals with road intersections with either stop signs or traffic lights, free intersections are not supported, though. IDM-LC then puts these two together, handling both multiple lanes and intersections.

MOBIL(Kesting, Treiber, and Helbing, 2007) models a road as a bank of single lanes, each used according to the unmodified IDM model. Then, for each car, a utility value is computed for its current lane and the adjacent ones. If an adjacent lane would bear a utility increment greater than a given threshold, then the car changes lane. Collisions upon lane change are avoided, because the utility function takes into account the deceleration the new following car would undergo.

IDM-IM(Fiore, Harri, Filali, and Bonnet, 2007), on the other side, handles intersections by placing a fictitious obstacle at the beginning of the intersection, that is removed when the car is allowed to cross it according to traffic regulations. This behaviour is further extended by IDM-LC, which integrates MOBIL into the model, and allows modifications of the utility function near intersections, to implement selection of the most appropriate lane, according to the planned road. The VanetMobiSim simulator (VanetMobiSim), which uses IDM-IL as its car-following model, has also been validated against a realistic traffic flow (Härri, Filali, and Bonnet, 2009, pp. 36-37).

2.5 Microscopic Traffic Simulators

The first model used for vehicle mobility simulation is probably the one by Fukui and Ihibashi (1996). It uses a cellular automaton to microscopically simulate the flow of traffic on a single- lane road loop. Wolfram (1983) gives a definition of cellular automaton as an abstraction of a physical system, with discrete time and space. The automaton consists in a matrix of cells, each represented by a discrete variable, and the state of the automaton is specified by the state of its cells. It evolves through discrete time steps. At each step, all the cells are updated in a synchronous fashion, based on their current value and on the current values of their

"neighbours". A set of "local rules" controls the way such updates are performed.

In an analysis of many cellular automata-based models for traffic simulation, Maerivoet and Moor (2005) partition them in three categories, depending on the simplicity of the model:

(14)

Deterministic models, like the ones by Wolfram (1983), have a set of fixed rules, hence deterministic, that control the movements of the cells;

Stochastic models, opposed to the deterministic ones, use a set of rules that includes one or more random variables, which make movements less uniform and predictable;

Slow-to-start models are basically stochastic, but their peculiarity is that "cars" have an initial inertia in accelerating when a space in front of them becomes available.

The reason for such a classification is that cellular automata models are meant to reproduce congested traffic conditions. So, stochastic models manage to create a more irregular traffic, by introducing random slowdowns in cells. Slow-to-start models, instead, are aimed at stabilising traffic jams, meaning that their incoming flow should be at least as big as their outgoing flow (Krauß, 1998).

Even if some of the simplest cellular automata models can successfully reproduce known traffic phenomena, like start/stop waves and the backwards moving of traffic jams (May, 1990), this family of models seems too abstract to be used in a real-time driving simulator. In the first place, cellular automata are time- and space-discrete. This means that some workaround would be needed for them to produce a real-time simulation, and that non-straightforward conversions would be needed to translate cell coordinates to world coordinates and vice-versa, as stated in Maerivoet and Moor (2005, sec. 2.4). Further adaptations would be needed, since, in general, traffic simulations do not take place on road loops. Though, in a system similar to that proposed by Olstam et al. (2008), some cellular automata may be used as a mesoscopic model, due to their good performance (Maerivoet and Moor, 2005).

One more recent, and among the most used ways to build driving artificial intelligence is to model the traffic as a multi-agent system (probably because microscopic models, modelling individual drivers' behaviour, can be naturally mapped onto a system of agents). Blatnig (2008, p. 55) presents a survey on some existing agent-based models. In a multi-agent system, each car has a logic on its own, and it pursues its objectives on a local basis. A more general definition of intelligent agent is that of a computer system that exhibits the following behavioural features (Wooldridge and Jennings, 1995):

Autonomy capacity to operate without the need for user intervention, and to control own state and actions;

Social ability interaction with other agents and/or with humans;

Reaction perception of the world and ability to react to its changes;

Pro-activeness behaviour aimed at fulfilling one's goals or to maximize a utility function, without the need for triggering changes in the external world;

Mobility ability to move in an electronic network;

Veracity an agent will never communicate information that it regards as false;

Benevolence agents don't have conflicting goals, and will help each other as requested;

(15)

Rationality the agent will pursue its own goal, and will not behave in ways that prevent its fulfilment;

In the particular context of traffic simulation, the benevolence requirement is usually somehow relaxed, for the sake of realism, because aggressive, distracted and egoistic drivers also need to be simulated (as in Lacroix, Mathieu, and Kemeny (2012)). This is not a major issue, since Wooldridge and Jennings themselves consider the last four requirements to be less universal.

Two main approaches to the development of agent-based simulations can be isolated in previous work(Al-Shihabi and Mourant, 2001)², which are rule-based and probabilistic (or fuzzy). The former aims at coding the agent's behaviour as a set of if-then rules, which state to perform an action if a triggering condition is verified. On the other side, probabilistic agents base their decisions on random variables, whose distribution is derived from statistical data.

Unsurprisingly, hybrid models exist, too, that either apply hard-coded rules through a fuzzy decision or apply different probabilistic models by means of a state machine. Al-Shihabi and Mourant (2003) also suggest a more general architecture for defining human-like driving agents, similar to what was already described by Champion et al. (1999). It consists of 4 modules:

• A perception unit gathers input from the simulation world, and conveys them to the other modules;

• An emotional unit decides which high-level action to undertake, according to some rules which define the agent's desires and objectives;

• A decision making unit analyses the state of the world, and formulates a strategy to achieve the objectives outputted by the emotional unit;

• A decision implementation unit translates the directives of the decision making unit to actual physical actions (controls the agent's actuators).

Here, the emotional unit would encapsulate the personality of the driver, while the decision making unit would implement the so-called tactical knowledge, needed to implement cooperative behaviours, as well as long-term thinking, needed to avoid pointless actions.

2.6 Driving Behaviour

In order to discuss realism of a driving agent, a short discussion is needed about what is to be considered a realistic behaviour.

From a general point of view, a behaviour can be regarded as realistic if it passes the Turing test, i.e. if an interacting human is not able to discern between the agent and another human driver. So, what's actually needed is to understand how people drive, in order to feed the agent with these data, like in probabilistic models. Moreover, as pointed out by Wright et al. (2002), a fundamental factor in conveying a realistic experience is behavioural variability among the agents. They also test how realism is affected by behavioural variability of single agents, but

2Al-Shihabi and Mourant also identify a third "state-machine based" approach, which is not explicitly considered here, since it consists in an extension of the rule-based approach, where rules are grouped into different states.

(16)

they find its importance is not significant, though a well-tuned amount of internal variability can improve the experience.

Many other useful works exist, concerning this matter. They mainly consists in traffic safety studies, which try to describe human behaviours, to understand how roads can be made safer or cheaper. As an example, Blab and Litzka (1995) analyse lateral alignment of heavy vehicles, and show how a Laplace distribution can effectively model tires' position on the road.

Godthelp (1986) and Fitzsimmons (2011), on the other end, make an extensive analysis of speed and trajectories of cars in horizontal curves. Further information about macroscopic and microscopic traffic phenomena can be found in May (1990).

(17)

3 Problem

This study is focused on examining the influence of a number of micro-behavioural factors on the user's perception of the simulated world, as well as on his own very behaviour. In particular, the study is focused on the following behavioural aspects of the AI:

Speeding

As pointed out by Felipe (1996, p. 35), 87% of the 85th percentile speed depends on the

"curve's first encountered radius", while another 4% is determined by the lane width.

The remaining 9% is due to other minor unmentioned factors. The same thesis, p. 64, also shows how the dependence between speed and curve radius can be modelled as a logarithmic function and how the speed limit often coincides with the 85th percentile of the speed distribution (pp. 29--30). Olstam (2006) states that average speed is an important factor in determining the realism of a simulation, because human drivers, even if unable to accurately estimate the speed of nearby cars, would notice if the ratio of overtaking/overtaken cars is too far from reality. That's why it seems worth to analyse how different average speeds influence both the perception of realism and the behaviour of the driver.

Lane-change behaviour

Champion et al. (1999) and Olstam et al. (2008) point out how traditional simulation models usually fail at conveying a realistic lane-change behaviour, which brought to the definition of more sophisticated lane-change models (Champion et al., 1999 and Al- Shihabi and Mourant, 2003). This is because agents in the simulation are collaborative, and thus know how other cars will behave, without the need of visual communication.

Once a car decides to change its lane, it can do it atomically, because of the time-discrete nature of the simulation. In the real world, instead, a visual lane change protocol has to be honoured, which requires the use of directional lights before another lane is invaded.

The test for this behaviour will compare "dumb" cars, which just change their lane with no hint to the human driver, to cars that use conventional visual hints, and pay attention to the cars behind them.

Lateral positioning

As shown in Backlund et al. (2010), human drivers tend to stick to the centre of the lane they are following with a sharply peaked distribution. A similar result is achieved by Blab and Litzka (1995), who found the Laplace distribution to be a statistically accurate model of drivers' position. Though the latter is focused on heavy vehicles, and finds that they tend to drive more on the left side of the lane. Opposed to this, standard simulation models make cars drive stuck on a fixed positions of the lane they're using. It would be interesting to verify how much this factor can influence the simulation.

Curve trajectory

In Godthelp (1986) and Fitzsimmons (2011), it is shown how humans don't usually drive along curves following the so-called "ideal" trajectory. Rather, they tend to slightly overestimate the curvature angle at the entry of the curve, and then adjust the steering angle afterwards (the "normal" trajectory). The two trajectories could be compared to check if a more familiar trajectory influences drivers.

(18)

These aspects will then been analysed with respect to user perception. In more detail, the work is focused on:

• Perception of realism, intended as the feeling of being surrounded by other human drivers. This is an extension to Wright et al.'s work (2002), in that it's focused on which parameters are more effective for realism, rather than analysing the overall effect of variability.

• Reflection on human behaviour, by analysing if and how a change in one of the above parameters affects the same parameters in human drivers. The existence of such influences has been already hypothesized, though not formally verified, by Olstam (2006), while Wright et al. (2002), explicitly suggests such an investigation as an extension to its work.

This study is made up of three main phases:

1. Development of an ad-hoc simulation through the Unity3D engine;

2. Implementation of the artificial intelligence to be used;

3. Execution of the required tests and analysis of the results.

The following subsections analyse each of the points above, describing and motivating the research method which will be used.

3.1 Simulation Software

The test has been conducted by means of the hardware infrastructure illustrated in Section 2.1.

As already analysed, it is not possible to fully adapt closed-source software to the simulation, because of its client-server multi-screen architecture, as well as because ad-hoc output from the game is required to control the car's dashboard.

In previous studies, such as Backlund et al. (2010), the open source game VDrift has been modified to fully support the simulator, but this approach falls short in terms of reusability, since the modifications are embedded in the game:

• It's not straightforward to add new scenarios to the game;

• Building new component for further studies requires a considerable integration effort.

Moreover, it suffers from physics inaccuracies, because the original game is a drifting game, and the car tend to drift when they run over a certain speed. For the above reason, this work is also aimed at building the simulation game in Unity3D, which should allow for easier modifications and reuse. This is further motivated by the fact that this work has been carried out in parallel with Procaccini (2013), that is using the same simulation hardware. So, it seemed more natural to build a common infrastructure, that could simplify the implementation of both simulations.

Unity3D is a cross-platform game engine for developing 3D games, first published in 2004 by Unity Technologies, which is still owning it. Its development environment enables direct

(19)

graphical editing of game scenes, and allows developers to "attach" behaviours to game object.

Three programming languages are supported: C#, Javascript and Boo.

Even if it is not an open source platform, its completeness, flexibility and ease of use has earned it a good reputation in both the gaming and the scientific community, as testified by Labschutz et al. (2011),who explored the possibility of Unity3D in supporting a professional game development workflow; and Indraprastha and Shinozaki (2009), who even found it a useful tool in urban design study, while providing useful insights about the performance of the engine itself and of the file formats it can use.

3.2 Artificial Intelligence

By using Unity3D, the artificial intelligence could be implemented as a set of behavioural scripts, that can later be attached to a car, meant as a game object which has got an engine model attached to it.

The AI was implemented according to the framework proposed by Al-Shihabi and Mourant (2003), and already summarized in Section 2.5.

The perception unit (PU) communicates with an abstract representation of the road, which makes interaction with the world easier. This approach is much easier and accurate than using an optical recognition module.

The emotional unit (EU) encapsulates the behavioural model, which acts as a parameter base for the decision-making unit (DMU). Here the main mobility model was implemented, which determines most of the driving behaviour.

Finally, The decision implementation unit (DIU) interacts with the car model, in order to translate decisions to actual actions.

3.2.1 Generic mobility model

The IDM-LC model, defined and implemented by Fiore et al. (2007), was used as the fundamental building block for the AI. An implementation of the mobility model was available as a Java class, in the VanetMobiSim environment. Since Unity3D does not allow the use of Java, and the previous implementation relies on parts of the CanuMobiSim framework, it could not be directly integrated into the new environment. So, two approaches have been investigated:

1. Use of a modified version of CanuMobiSim with VanetMobiSim as a standalone process, that communicates with the main game process. This choice would have allowed for better exploitation of the hardware resources (Unity3D relies on a single-threaded model) while bearing minimum modifications to an already working framework. Though it's not sure if such a choice would have produced acceptable performance, due to communication delays, and as much flexibility as needed for the successive evaluation.

2. Translation of the existing classes to C# and embedding in the Unity3D environment.

This choice was basically the opposite as the previous one, as it would have granted the

(20)

maximum flexibility, but it would have costed more in terms of implementation effort.

In the end, the second option was chosen, as will be explained in Section 5.

As already described in Section 2.4.3, the IDM model and its extensions require several parameters. So, a calibration process was needed, in order to achieve a realistic behaviour.

Since IDM parameters are very descriptive, some possible values could already be found by analysing the works referenced in Section 2.6 or other works of similar nature. The parameters could also have been extracted from already existing simulators, that make use of IDM, like the ones analysed by Härri et al. (2009).

3.2.2 Behavioural Features

The additive behavioural features, described in Section 3, were implemented by extending the base components of the behavioural architecture depicted above.

• Lateral positioning was implemented by adding a Gaussian steering error to the DIU module, while making the DMU periodically adjust the desired lateral position. Lateral position control, in general, is a DMU matter, as it has to be modified, for instance, in undertaking a lane change operation.

• Curve trajectory was implemented in the DMU, too, as a bias to the desired position. In fact, curve trajectory is just a special case of lateral positioning that applies to horizontal curves.

• Speeding behaviour was achieved in a way similar to what described by Wright et al.

(2002), by means of variations in theEU of each driver.

• Lane change behaviour is triggered by the DMU, depending on the parameters provided by theEU, as required by the IDM-LC mobility model.

3.3 Test Method

In order to gather the required data for the proposed analysis, an experimental test was set up, in which a sample of human drivers was asked to singularly drive in the traffic, trying to act as they would have done in a real car.

During the test, the driving behaviour of the human subject was analysed through the gathering of some data. For the sake of simplicity and completeness full traces were recorded of the whole test sessions, including user input, the position of all the cars and their behavioural parameters.

Moreover, the subjects were asked for their impressions on the overall realism of the traffic, by means of the questionnaire which can be found in Appendix B.

The requirements for the test were that the drivers should be encouraged to:

R1. drive along the traffic as naturally as possible, because the way their behaviour is affected by other drivers need is be measured. It would be pointless if they, for instance, just drive by the traffic at full speed, without even looking at other cars.

(21)

Table 3: Organization of the test sessions

Session Traffic #1 Traffic #2

A Blank Realistic lane change

B Blank Lateral positioning

C Blank, with different speed Blank, with different speed

R2. interact with the traffic, in order to get an idea of its behaviour. Clearly, it should be avoided that such interactions become so frequent to make results over-sensitive.

R3. avoid car accidents, as an algorithm for handling them is not used. Even if this requirement should be implied by the fulfilment of R1, it is stated separately for greater clarity.

The test approach which has been used is somewhat analogous to that used by Wright et al.

(2002) to obtain their results. In their third user test, they let human drivers freely interact with homogeneously typed traffic, and then asked him to rate the realism of his/her experience.

In this context, a variant of such test was used, in which human subjects were asked to freely interact with the traffic (like in Wright's third user test), but this traffic contained drivers with two different kinds of AI (like in Wright's first user test), identified by different colours, whose meaning the users were not aware of. The subjects were then asked to rate the different kinds of traffic against each other, by determining which one they found to be more realistic.

Since the drivers had to stay focused on their drive, it seemed more suited to only use two different kinds of traffic per test, while letting each user participate in multiple sessions. In order to give enough time to a subject to judge the realism of the traffic, it was roughly estimated that each session needed to last for at least 2-3 minutes³. With such constraints, 6 sessions is the maximum that can be safely accomplished by a single subject in a reasonable time (Backlund et al., 2010, point out that simulator sickness can be developed after 20-30 minutes). Since the test subjects were shared with another study, and considering also that the whole test should not take too long, the number of available sessions was reduced to 3.

Due to this limitation, the features of lateral alignment and curve trajectories were collapsed and tested together, as they are conceptually similar (they both concern horizontal positioning on the lane). Table 3 summarizes the organization of the test sessions. In order to avoid any bias caused by the presentation order, the three sessions were be presented in a varying order, so that each of the 6 possible presentation orders was experienced by an almost equal number of subjects.

Two sessions were organized so that in each of them two kinds of traffic are compared:

1. A "blank" traffic, which implements none of the tested features;

2. A "test" traffic, which implements one extra feature.

On the other side, a slightly different approach was needed to handle speeding behaviour, because altering the average speed of just one kind of traffic would actually produce an overall

3The minimum required time has been roughly estimated by means of early tests.

(22)

average speed which is the mean between the speed averages of the two kinds. To avoid this kind of effect, the third session used two blank traffics, both with a different mean speed. In this way, this third session was also acting as a control session, to check whether the subjects could critically analyse the two kinds of traffic or if they were just guessing.

Some early tests were performed, in order to determine if it was better to use a higher or lower average speed in the third session. It was then decided to use a lower speed mean, as will be discussed in Section 6.4.

Another approach that was considered consisted in using a complete AI (which implemented all of the analysed features) in every session, comparing it with another one that lacked a single feature. Even if this would have allowed to verify the effects of multiple overlapped features, it was discarded, because it would have made it much harder to isolate the effects of each single feature, which was the very point of this work.

3.3.1 Ethical Considerations

The results and the essence of this very work do not seem to pose complex ethical problems.

Even so, some ethics related matters need to be taken into account for what concerns the test method. In particular, two critical areas have been identified:

Personal data During the test phase, data concerning the driving attitude of the test subjects were gathered. Even if such data cannot be regarded as sensitive, they may provide information that the subject didn't want to disclose. Since this kind of information is not likely to be useful to the study, all the gathered data were treated anonymously.

Simulator sickness It is known that some people can suffer from simulator sickness when exposed to the simulator, even if for short times. For this reason, it's important that the subjects knew that they could stop the test whenever they wanted. Moreover, the questionnaire to be filled between the sessions included some control question to check if the subject was starting to feel sick.

(23)

InputProvider CarPhysics

«delegate»

Transform

RemoteCar

EngineModel DataGatherer

Unity

«delegate»

Rigidbody

Figure 2: Principal components which make up the base simulation software.

4 Base Simulation Software

As anticipated in section 3.1, an ad hoc simulation software has been developed for this study, by means of the Unity3D engine. The following subsections are thus aimed at describing the structure, as well as some more specific issues, that either were characteristic of the choice of Unity3D or played an important role in the successive phases of the work.

The software is based on the CarTutorial demo, which can be found in the Unity AssetStore.

This demo was customized on two fundamental aspects, which are the physics engine, that was heavily modified, and the networking component, that was absent in the demo, but needed for our purposes. Moreover, a separate set of road pieces, which is available athttp://www.

3dmodelfree.com/models/18622-0.htm, was used to build the tracks. The different parts of the work are implemented in different Unity scripts, which correspond to C# or Javascript classes, as illustrated by Figure 2. In the following, each of these components will be described in more detail.

4.1 Physics Engine

The physics model that shipped with the demo presented many inaccuracies, and it was thus adapted to be more realistic. Road friction and air drag model were re-implemented, as they suffered from severe physical inaccuracies, while engine friction was added, as it was absent. Calibration of the model was made using the technical specifications available at www.volvoclub.org.uk/pdf/s80/S80_2009_techspecs.pdf. Gear ratios were faithfully reproduced, as well as engine torque. The other parameters related to air drag and road and engine friction were adapted to reproduce the maximum speed and the 0-100 acceleration time reported on the technical data sheet.

(24)

In the following, a short description is given on the implementation strategy that was used for each of the simulated components:

Engine torque is modeled by a custom function, mapping the engine angular speed to the torque. The functions we used are rough interpolation of the actual torque and power curves, in order to minimize the computational effort. A comparison of the original curves again the interpolations is presented in Figure 3

Engine friction is implemented as a linear function of the engine angular speed. The parameters of this function were not available in the specifications, so they were adapted in order to achieve a believable deceleration without accelerating;

Road friction is implemented by Unity's WheelColliders, which use a slip-based function to model the force exerted by the wheels on the asphalt. The parameters for this model were adapted in order to obtain both the 0-100 km/h acceleration time and the maximum speed reported on the specifications;

Air drag is implemented realistically as ⃗F = −k ⃗dv², where ⃗dis the direction of the car and kis a vector of multiplicative factors, which embed all the constant factors of the drag formula; these factors have been calculated using the size of the car;

Gravity relies on Unity's Rigidbody implementation, using the actual mass of the car, as found in the technical specifications.

4.2 Network Communications

The multiscreen infrastructure of the simulator, already described in Section 2.1, is based on multiple desktop computers, which communicate through a dedicated ethernet network. So, a server and client class have been implemented inside the Unity game, which offer a buffered asynchronous communication service through UDP sockets. Such a choice is analogous to what have been done by (Lebram et al., 2006) on the same hardware⁴.

Since Unity3D does not offer any utility class for concurrent operations, a dedicated producer-consumer queue needed to be implemented, in order to offer an asynchronous communication protocol. Anyway, asynchronous communications were needed because synchronous communications showed to heavily penalize the performance of the simulator.

Another viable alternative would have been to implement an external dynamic link library by means of the Microsoft compiler, and then link to it from Unity, but several forum discussions about the topic made us think that Unity is not fully compatible with external DLLs.

The communication infrastructure uses a singleton RemoteNode object, which encapsulates the sending (on the server) or receiving (on the clients) thread. Objects that wish to communicate across the network must use a unique identification number and register with the RemoteNode.

The node will then dispatch messages to objects and accept and send the messages relayed to it. For the purposes of the basic engine, the human-driven car is the only object which needs to

4The use of UDP messages is not mentioned in the article. The information has been provided by the Lebram et al. during an oral interview.

(25)

Power, kW 275

250

225

200

175

150

125

100

75

50

25

0

1000 2000 3000 4000 5000 6000 7000

Engine speed RPM Actual curve Interpolation

Torque, Nm 500

475 450 425 400 375 350 325 300 275 250 225 200 175 150 125 100 75 50 25 0

1000 2000 3000 4000 5000 6000 7000

Engine speed RPM Actual curve Interpolation

Figure 3: Comparison between the original engine power and torque curves and the interpolation used for the simulation.

(26)

transfer data over the network. In more detail, the position and orientation of the car are relayed to the sending node every 20ms. Instead, no data transfer is issued by the camera, which just follows the car as it moves. RemoteNode also provides access to a per-node configuration file, where various properties can be set. This feature is used by the camera to obtain the correct projection parameters on each client when the simulation starts.

4.3 Input Collection

The collection of inputs from the car has been factored out in separate classes, implementing the InputProvider interface. Such a choice was mainly needed because Unity cannot correctly handle input from steering wheels. So, a dedicated function has been implemented to correct the input values before returning them to the application. The presence of this function made it impossible to use the software with a keyboard just by editing Unity's settings. In order to easily swap between the car and other more common controller, the functionality of input gathering was factored out.

4.4 Information Logging

A DataGatherer script is attached to the human-driven car. This script periodically fetches data about user inputs and car position and speed, and logs them to a file. The actual logging is performed on a separate thread to minimize the impact on performances.

4.5 Road pieces

The set of road we used contains different road pieces for highway, offroads and urban roads.

We mainly focused on the highway components, which consist of straight roads with a varying number of lanes, and left/right curves of 15°, 30°and 45°. Other eye-candies are included in the bundle, like lateral barriers and road signs. The bundle also included normal maps, which we did not use, because Unity3D could not correctly recognize them. .

A very long straight plane road was built and used to calibrate the car model without influences from the gravity, while a sloped road was used to test interactions with the gravity. This last kind of test was not carried on thoroughly, since we only used a straight road for our evaluation.

The track used for the evaluation test, on the other side, consists of an oval highway segment with two lanes in each direction. Both the curves have a radius of approximately 165m on the most external lane, and of approximately 140m on the most internal one. The straight segments are 960m long. The lanes are approximately 4m wide and the two directions are separated by a guardrail.

By using the inverse of equation 1.3 from Felipe (1996), it can be derived that the design speed for the two curves would have been of 120km/h approximately. We though needed to slightly increase the lateral friction of the car, so that it's also possible to handle the curve up to 150km/h, in order to prevent the test subjects from crashing and invalidating the test session.

(27)

This is probably due to a bias in the perception of speed on the simulator, which encourages the subjects to drive at higher speeds.

(28)

SpeedProvider Transform

AlignmentManager position DDDDDDDDDDDDDDDDlateralAlignment

AISpinner

DDDDDDDDDDDDDDDDlateralAlignment

DDDDDDDspeed Rigidbody

D D Unity D

RemoteCar

DDDDDDDDDDDDDDDposition DDDDDDDDspeed CarMarker

DDDDDDDDDDDDDdesiredSpeed changeWish

IDMLC

Figure 4: Principal components of the artificial intelligence implementation

5 Artificial Intelligence

This section describes how the artificial intelligence component has been implemented, as well as how it has been integrated into the basic simulation.

The implementation uses the MOBIL mobility model, which is a multi-lane variation of the IDM model. Both models have already been introduced in Section 2. More details specific of this implementation will be given in Section 5.1. Section 5.2 will then show how the new components have been integrated in the previously described infrastructure.

5.1 Model Implementation

Even though a Java implementation of the model was available, its use without major modifications would have been impossible. That's because AI-controlled cars need to know the position and speed of the human-driven car, in order to correctly interact with it. On the contrary, the Java implementation didn't allow to inject data about the human-driven car in its road model. Because of this issue, it has been chosen to build a fresh implementation inside of Unity.

The framework described in Section 2.5 has been used as a guideline:

• The AISpinner component acts as the decision implementation unit, by controlling the actual movements of the car on the road.

• This component is then used by the IDMLC and AlignmentManager components, which together constitute the decision making unit. The two components are separated, because

(29)

Table 4: MOBIL model parameters.

Parameter Value Meaning

a(·) IDM Acceleration function, describing the acceleration adopted by a car at any given moment

∆a_th 0.75 Lane change threshold, which limits lane changes by means of a lower bound on the utility increment

∆a_bias 0.76 Threshold bias, that makes rightmost lanes more interesting (for the asymmetric model)

p 0.2 Politeness value , indicating the extent to which a driver takes into account the impact of his/her actions on the cars following him d_safe 4 Maximum safe deceleration: a driver will never change lane, if that

requires the following car to brake more than this

this work requires the lane-change behaviour to be changed, and such a modularization makes it easier.

• Information about the situation of the world is delivered by the LaneModel, which contains data about the relative position of cars, and by the actuators associated with other cars, that provide information about the speed of each car.

• No real emotional unit exist, but the SpeedProvider component periodically changes the desired speed of each car, to adapt to regulations and simulate emotional variability.

5.1.1 IDM Implementation

The IDM parameters reported on Treiber et al. (2000) were used at first, but they were altered afterwards, because the acceleration of cars seemed to be too slow. A maximum acceleration of 0.73m/s², which is the value suggested by Treiber et al., would yield a 0-100km/h acceleration time of more than 40s, whereas the human driven car can do the same in 6.5s. A value of 3 has experimentally shown to produce a more realistic acceleration. Due to this alteration, the desired braking has also been modified to 6.

5.1.2 MOBIL Implementation

Table 4 presents the parameters used by the MOBIL model which are not present in the simple IDM model, together with the values that were used in this implementation.

As anticipated by Blatnig (2008), a more sophisticated mechanism needed to be implemented, because MOBIL assumes that lane-changes can happen instantaneously when the model decides to perform them. Unfortunately, this is not how interactive simulations work. In interactive scenarios, moving from one lane to another requires a certain time, depending on the speed at which the operation is performed.

In order to adapt the model to the simulation, it has been decided that the moment when the MOBIL model would have required a lane-change will instead correspond to a decision by the

(30)

A A' B

A B

(a) (b) (c) (d)

Figure 5: Illustration of an overtaking procedure by car A on car B:

The dotted arrow represents car A's intentions, while the quota represents the headway distance perceived by A. (a) Car A decides to overcome car B, because the left lane would allow

it to accelerate more;

(b) Car A starts moving towards left, but it still considers car B to be its leader, and regulates its speed accordingly;

(c) Car A occupies the left lane and can thus accelerate freely. But it's also still occupying the right lane;

(d) Car A completely leaves the right lane, completing the lane change procedure.

car to move from an initial lane to a target lane. The car will continue to behave like it was on the initial lane, until it actually invades the target lane. Then, it will consider itself as being on the destination lane, while the other cars will behave like the it was occupying both lanes, until it will have completely left the initial one. This process is also described by Figure 5.

5.2 Integration with the Engine

Figure 4 schematically shows the relationships between the components involved in the AI implementation and the previously described infrastructure.

Integrating the artificial intelligence into the simulation mainly involved three problems:

1. Creating a logical road model corresponding to the physical road (the cars should know what the road looks like);

2. Integrating the human-driven car into the logical road model (the cars should know where the human-driven car is);

3. Integrating the AI component into the networking infrastructure (the movements of the cars should propagate from the server to the clients).

Each lane of the logical model includes a ordered list of the cars occupying it. Computer-driver cars rely on this information to find their leader and follower. So, it was pretty straightforward to add a CarMarker to the human-driven car, which deals with inserting the car in the logical model and updating the metadata related to it. More details about the implementation of the logical model are given in Section 5.2.1.

The implementation of the network part was also simple, as it lies on top of the networking

(31)

CarPlaceholder LaneModel

RoadModel

1..* 1..*

*

Curve

Figure 6: Classes implementing road and lane models.

infrastructure already described in Section 4.2. The only addition needed was a manager object, that creates computer-driven cars on the clients, ensuring their object IDs correspond to the ones on the server.

5.2.1 Logical Road Model

The Unity3D editor allows scenes to be created by assembling prefabricated objects and adding extra components to them. This kind of work flow is very intuitive and fast, and one of the goals of the implementation was to preserve this simplicity.

So, the idea underlying the logical road model is that each piece of road will have a partial model attached to it, and then all the partial models will recombine upon game start, in order to reconstruct the global road model. Each "partial" road model is statically linked to the lanes it contains. Each lane can then contain one or more curves, that represent the different trajectories a car can follow. Thanks to the prefab system of Unity3D, human designers only need to define the lanes once for each kind of road piece they intend to use. The lanes also dynamically keep track of the cars which are occupying it, so that every car can easily find its leader and follower.

The actual curves representing the trajectories are implemented by using Catmull-Rom splines, as already accomplished by Wang, Shen, and Khwang Teoh (1998). Catmull-Rom splines, initially defined by Catmull and Rom (1974), are curves that interpolate a sequence of point, by passing through all of them. The generated curve is continuous and has got a continuous derivative, which allows cars to move without sudden turns. The curves are used in the form (x, y, z) = f (p), with 0 ≤ p ≤ 1. This form also allows to easily determine the next target position, once the real length of the curve is known.