Thes 448

CZECH TECHNICAL UNIVERSITY
IN PRAGUE
Faculty of Electrical Engineering
MASTER’S THESIS
Collision Avoidance of Highway Traffic
Prague, 2014 Author: Bc. Martin Schaefer

Poděkovánı́
Na tomto mı́stě bych rád poděkoval všem, kteřı́ mě při zpracovánı́ této práce pod-
porovali. Dı́k patřı́ zejména vedoucı́mu práce Ing. Jiřı́mu Vokřı́nkovi PhD., který mi
umožnil věnovat se zajı́mavému projektu a provázel mne svými radami. Dále bych
poděkoval svému kolegovi Bc. Pavlu Janovskému za podporu a cenné diskuze. Na závěr
patřı́ dı́k i mé rodině za veškerou podporu při studiu, které si velice vážı́m.
ii
Abstrakt
Tato práce se věnuje návrhu a implementaci systému integrujı́cı́mu simulátor řı́zenı́ s
modulem pro předcházenı́ kolizı́m. Systém simuluje jı́zdu po dálnici v provozu. Modul
pro předcházenı́ kolizı́m zahrnuje dvě implementace metod zabraňujı́cı́ kolizı́m. Prvnı́
z metod je založena na principu sledovánı́ a udržovánı́ bezpečné vzdálenosti, druhá je
aplikacı́ metody ORCA. Modul komunikuje se simulátorem a poskytuje instrukce pro
řı́zenı́ vozidel. Vozidlo řı́zené řidičem tyto instrukce zobrazuje a navrhuje tak řidiči
dalšı́ manévry. Vozidla okolnı́ho provozu se řı́dı́ autonomně plněnı́m těchto instrukcı́.
Jednoduché experimenty ukazujı́ smysluplnost konceptu a možnosti jeho využitı́ pro sim-
ulace s řidičem - člověkem. Dále na základě experimentů ukazujeme dalšı́ směr aplikace,
kterým jsou studie metod zabraňujı́cı́ch kolizı́m pro silničnı́ vozidla v dálničı́m provozu.
iii
Abstract
The thesis deals with the design and implementation of a system integrating driving
simulator with a collision avoidance module. The system performs simulation of driving
on the highway with traffic. There are two integrated collision avoidance methods in the
module. One is based on the observance of the Safe Distance and the second implements
ORCA algorithm. The module communicates with the driving simulator and provides
instructions for vehicles. Traffic vehicles execute instructions autonomously. The driven
vehicle visualize the instruction for a human driver. The proof-of-concept experiments
show the possibilities of application of the system for a human-in-the-loop simulations as
well as for studies of collision avoidance techniques for traffic vehicles on a highway.
iv
Contents
List of Figures ix
List of Tables x
1 Introduction 1
1.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1.1 Additional Requirements . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Highway Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2.1 Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Thesis Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 5
2.1 Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Driving Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Sensor Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Collision Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1 Velocity Obstacles . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2 Reciprocal Velocity Obstacles . . . . . . . . . . . . . . . . . . . . 10
2.2.3 Optimized Reciprocal Collision Avoidance . . . . . . . . . . . . . 10
2.2.4 ORCA-based Methods for Non-Holonomic Robots . . . . . . . . 13
2.2.5 Non-Homogeneous Non-Linear Reciprocal Collision Avoidance . . 13
3 Implementation 14
3.1 OpenDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1 Traffic in OpenDS . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Collision Avoidance Module . . . . . . . . . . . . . . . . . . . . . . . . . 17
vi
3.2.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Agent Implementations . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2.1 ORCA Agent . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2.2 SafeDistance Agent . . . . . . . . . . . . . . . . . . . . . 19
3.3 Collision Avoidance and Simulator Integration . . . . . . . . . . . . . . . 22
3.3.1 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1.1 Protocol Buffers . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1.2 Communication Protocol . . . . . . . . . . . . . . . . . . 24
3.3.1.3 Update Message . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1.4 Plans Message . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2 Extensions in OpenDS . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.2.1 Communication . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2.2 Plan Executer . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3 Human-Machine Interaction Interface . . . . . . . . . . . . . . . . 27
4 Experiments 29
4.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Settings and Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Imminent Collision Experiments . . . . . . . . . . . . . . . . . . . 30
4.2.2 Driver Assistance System Experiments . . . . . . . . . . . . . . . 33
4.3 Results and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1 Imminent Collision Experiments . . . . . . . . . . . . . . . . . . . 34
4.3.1.1 Experiment I . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3.1.2 Experiment II . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3.1.3 Experiment III . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1.4 Experiment IV . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1.5 Summary of the Experiments I - IV . . . . . . . . . . . . 37
4.3.2 Driver Assistance System Experiments . . . . . . . . . . . . . . . 38
4.3.2.1 Experiment V . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2.2 Experiment VI . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2.3 Experiment VII . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.2.4 Summary of the Experiments V - VII . . . . . . . . . . . 40
5 Conclusion 41
References 46
vii
A Protocol Buffers - SIMPLAN protocol I
B Contents of attached CD IV
B.1 Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
B.2 Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV
viii
List of Figures
2.1 Driving Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Collision Cone [Fiorini and Shiller(1998)] . . . . . . . . . . . . . . . . . . 9
2.3 Velocity Obstacle [Fiorini and Shiller(1998)] . . . . . . . . . . . . . . . . 9
2.4 Geometry construction of Velocity Obstacle [Berg et al.(2010)Berg, Guy,
Lin, and Manocha] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5 Orca lines [Berg et al.(2010)Berg, Guy, Lin, and Manocha] . . . . . . . . 12
3.1 Simplifed System Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Follow Box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3 Alite - simplified agent simulation [ATG(2013b)] . . . . . . . . . . . . . . 18
3.4 ORCA Agent operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.5 Safe distance method - control loop . . . . . . . . . . . . . . . . . . . . . 20
3.6 Safe distance method - critical distance . . . . . . . . . . . . . . . . . . . 21
3.7 Safe distance method - critical distance - lane change . . . . . . . . . . . 21
3.8 OpenDS - Highway platform integration scheme ( FB = Follow Box, PB
Comm = Protocol Buffer Communicator ) . . . . . . . . . . . . . . . . . 23
3.9 OpenDS - Plan Executor ( FB = Follow Box Interface, Comm = Commu-
nicator, WP = OpenDS Waypoint, Plan = List of Maneuver / Waypoint
Actions ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.10 HMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1 Simulator setting for the driving experiments . . . . . . . . . . . . . . . . 31

4.2 ICE braking - initial setting . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 ICE - braking - the moment of the incident . . . . . . . . . . . . . . . . . 32
4.4 ICE - slow vehicle - initial setting . . . . . . . . . . . . . . . . . . . . . . 32
5.1 Screenshots of the simulation . . . . . . . . . . . . . . . . . . . . . . . . 42
ix
List of Tables
4.1 Imminent Collision Experiments (vD0 and vDi is the initial and final speed
of the dummy vehicle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Driver Assistance System Experiments (vD0 and vDi is the initial and final
speed of the dummy vehicle) . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Results of the Experiments I - IV . . . . . . . . . . . . . . . . . . . . . . 38
4.4 Results of the Experiments V - VII . . . . . . . . . . . . . . . . . . . . . 40
x
Chapter 1
Introduction
Road safety is an issue that is often spelled to be a priority for automotive manufactur-
ers, governments as well as for the drivers themselves. The effort is well motivated by
the Global Status Report on Road Safety [WHO(2013)] presented by the World Health
Organization. It estimates the number of road traffic deaths to be 1,240,000 per year in
2013.
Nowadays computer science, robotics and artificial intelligence are just some of over-
lapping areas that automotive industry benefits from. The driver assistance systems [Eu-
roFOT(2013)] or autonomous vehicles [Guizzo(2011)] are examples of the applications
aiming to improve road safety.
Accident-free traffic or at least limitation of the number of accidents is an actual
challenge in the related research areas. Accidents are caused by the collisions of a vehicle
with other vehicles, pedestrians, animals or infrastructure. And the prevention of these
collisions is the purpose of the collision avoidance.
1.1 Requirements
This section presents requirements and specification of the assignment. The tasks of
assignment are listed in this section. Further requirements of the assignment follows.
1. Review existing techniques for collision avoidance of mobile robots focusing on road
vehicles.
2. Analyze possibilities of a selected technique for dynamic planning with uncertain
1
CHAPTER 1. INTRODUCTION 2
execution.
3. Implement the selected techniques in a drive assistance system in a simulator.
4. Implement the extension and experimentally evaluate.
1.1.1 Additional Requirements

The assignment requires implementation of a collision avoidance technique in a drive
assistance system in a simulator. Additional specifications and requirements for the
implementation are defined as follows.
1. The implementation should consider the need of a modular system that would allow
to prototype new strategies of collision avoidance easily.
2. The algorithms of the strategies should be experimentally evaluable via simulation.
3. The collision avoidance technique implementation should not be dependent on the

simulator used. Modularity should bring the possibility of usage of the collision
avoidance module in various simulators.
4. Specifically driving simulators are considered to be used. The driving simulators

offer the desired human-in-the-loop simulation.
5. The collision avoidance module should be able to control the traffic in the simulator
as well as it should provide assistance to the driver via driver assistance system.
6. The execution of commands by driver and by traffic vehicles bring the uncertainty
in execution.
7. The experiments should show possibility of testing various algorithms for collision
avoidance. Simple experiments should provide general information about perfor-
mance of collision avoidance algorithms on highway, allow to compare various con-
figuration of parameters for these algorithms.
8. Proof-of-concept experiments with a driver should reveal possibilities of user testing

of the driver assistance system using various collision avoidance algorithms.
1.1.2 Highway Domain

The domain of this work is highway traffic. The additional specification of this domain is
the purpose of this section. The domain of highway is meant to be simple, dynamic and
eventually extensible to more general cases. The domain of the highway is simpler than
general driving in the way that we do not need to deal with crossroads. Merging and
highway exits can be omitted for the first approach, as these are more complex situations
that are not needed for basic collision avoidance scenarios. The highway is also supposed
to be straight. The curvature of the highway can be omitted. We refer to a solution of a
control architecture that justifies the omitting. There is proposed layered architecture of
highway vehicle control, where lower layer deals with the curvature so that higher layers
can operate on an abstract straight highway [Schaefer(2011)].
1.1.2.1 Traffic
The vehicles are supposed to move in one direction, more than one lane is needed to allow
vehicles to overtake. Vehicles are supposed to model real cars. The physical model should
be part of the simulator used. The vehicles are controlled by a driver (e.g keyboard, game-
pad or steering wheel) or the vehicles drive autonomously (i.e. are driven by software
agents).
Sensing is assumed to be perfect and complete (i.e. vehicle is able to sense locations
and velocities of itself, other vehicles and obstacles).
1.2 Approach
This section outlines a chosen approach to the assignment in general. Nevertheless, the
scope of the assignment is relatively broad. Separation of work into parts dealing with
simulator related issues and collision avoidance module seems reasonable. This text is
organized in this way if it is possible to separate these areas.
Now let as discuss the assignment and reveal the ways to satisfy the desired require-
ments. The implementation will be done using portable Java programming language [Or-
acle(2013)]. The motivation for this choice is a previous experience and the fact that
Java dominates the development at the Agent Technology Center at the Department
of Computer Science [ATG(2013a)] (including implementation of some collision avoid-
ance algorithms). Previous experience allows to build on the knowledge and code-base
gained by working on the bachelor’s thesis [Schaefer(2011)]. The knowledge of simula-
tion toolkit Alite [ATG(2013b)] is welcome as well as the fact that the Safe Distance
Observance method [Schaefer(2011)] can be adapted to be used as one of the collision
avoidance algorithms.
There are specific requirements on the simulator (e.g. possibility of controlling traffic
vehicles or driver’s mode that would allow to visualize driver assistance system). The
simulator satisfying the requirements must also allow the integration of a collision avoid-
ance module. The integration of a simulator and a collision avoidance should remain
general enough to allow modularity, i.e. to offer possibility to switch the simulator or the
collision avoidance module.
1.3 Thesis Organization

In this section we provide a reader with a structure of this thesis. Chapter 2 presents
related work in the collision avoidance techniques (see 2.2) and in the simulators’ domain
(see 2.1) separately. The Chapter 3 describes the implementation. The selected simulator
for the implementation is more described in Section 3.1. Selected collision avoidance
techniques and their implementation in the collision avoidance module is the topic of
Section 3.2. The Section 3.3 deals with the integration of the collision avoidance module
and the simulator. The proof-of-concept experiments, the methodology and the results of
the experiments are presented in Chapter 4. The conclusion of the work is in the Chapter
5.
Chapter 2
Related Work
Related Work chapter is divided into two main parts. First part is related to the simu-
lators. Second part deals with the collision avoidance techniques in robotics.
2.1 Simulators
Simulation is an instrument used in a variety of disciplines. The Nobel Prize in Chemistry
was awarded for development of multiscale models of complex chemical systems [RoyalA-
cademy(2013)], crowd simulations help to optimize emergency plans [Almeida(2013)] or
simulators are used for training of drivers, pilots or soldiers. Safety and economic reasons
motivate usage of simulators for wide spectrum of the applications where direct deploy-
ment of new technologies is risky or expensive. Collision avoidance system is a convenient
technology to be simulated before deployment in the real world.
2.1.1 Driving Simulators

Automotive industry benefits from usage of simulators as well. There are high-end simula-
tors in research laboratories of many manufacturers. Daimler [Mercedesclass.net(2013)],
Toyota [Toyota(2013)] (see in Figure 2.1(a)) or Ford [Howard(2012)] are just few ex-
amples. These high-end simulators are equipped with large motion platforms providing
realistic accelerations. The main disadvantage of these simulators is the cost of acquisition
and operation.
Professional simulation companies provide usually a scale of solutions (see [Vires(2013)],
5
CHAPTER 2. RELATED WORK 6
(a) Toyota High-end Simulator (b) Oktal Compact Simulator

(http://www.toyota-global.com/) (http://www.oktal.fr/en/automotive/range-
of-simulators/range-of-simulators)
Figure 2.1: Driving Simulators
[Oktal(2013)]). High-end simulators with a cabin on a motion platform are the most ad-
vanced, realistic and expensive solution e.g. Figure 2.1(a). Simpler solution is a static
cabin or only seats equipped with visual projection e.g. Figure 2.1(b). The basic solution
is the simulation software without any special peripheries. The [OSS(2013b)] offers recent
market overview in the field and claims simulators are expensive or not using state-of-the-
art technologies. Interesting projects in the area seem to be OpenDS and OSS Driving
Simulator. Both of these simulators are supposed to be released as open-source projects.
OpenDS is the driving simulator selected to be used for the implementation in this work.
More details about OpenDS are provided in Section 3.1.
OSS Driving Simulator is probably still not yet realized project, but the ideas and
planned features are promising for the field of driving simulation. So far the team around
OSS Driving Simulator published ideas and plans for a new open-source driving simulator
[OSS(2013a)]. The simulator should be built on a Unity game platform [Unity(2013)].
The authors claim that: We think everyone, from a big corporation to group of students
in a dorm working on a startup to the individual inventor, should have access to simulation
technology and methodology. Open Source is a natural way to do this. It allows low cost,
broad experimentation and contributions back to the project from many people and corners
of the world. An open platform for driving simulation could bring a stable and up-to-date
underlying core for various applications of driving simulators.
2.1.2 Sensor Simulation

A specific sensor simulation tool developed mainly for the car manufacturers is called
PreScan [Tass(2013)]. PreScan offers easier development of Advanced Driver Assistance
Systems (ADAS) by physics-based simulation. Systems to allow vehicles to communicate
with infrastructure or with each other are another applications to be simulated by the
tool. Linkage with the industry brings the need of validating new concepts by software-in-
the-loop and hardware-in-the-loop simulation. Both is claimed to be enabled by PreScan.
Sensor simulation is more sophisticated tool than the need of this thesis. Nevertheless the
intelligent systems that could implement collision avoidance techniques in real vehicles
are assumed to be tested in simulators like PreScan.
The simplified simulation assuming perfect sensing can be used for the development
of the collision avoidance techniques. While the important thing is to realize that to
provide collision avoidance system the sensor and hardware related issues in general are
crucial for its proper functionality in the real-world deployment.
2.2 Collision Avoidance

Collision avoidance is one of the fundamental problems studied in robotics. Particularly
local collision avoidance can be defined as a problem of navigating a robot in an envi-
ronment with obstacles and/or other moving entities. The goal is to navigate a robot
so that no collision occurs while the robot continues on approaching to it’s desired goal
destination. We assume reactive robots i.e. performing sensing and acting in cycle [Berg
et al.(2010)Berg, Guy, Lin, and Manocha]. Here we would like to highlight the differ-
ence between collision avoidance and motion planning. The problem of (local) collision-
avoidance differs from motion planning, where the global environment of the robot is
considered to be known and a complete path towards a goal destination is planned at
once [LaValle(2006)].
Control theoretical point of view on the problem is presented in [Lalish(2009)]. Dis-
tributed Reactive Collision Avoidance algorithm (DRCA) is presented and complete guar-
antees are given for n vehicles in the presence of acceleration and/or force limitations.
Restriction of DRCA seems to be not possible movement in formations. The vehicles tend
to move away from each other. Nevertheless a possible solution is outlined in Future work
section of [Lalish(2009)] but just for the price of loosing safety guarantees.
Dynamic Window approach was used for high-speed navigation in [Brock and Khatib(1999)].
Another method using Ripple Tantacles was deployed on the BIT unmanned vehicle plat-
form [Yu et al.(2012)Yu, Gong, Iagnemma, Jiang, and Duan]. In spite of the method is
considered to be motion planning method, it is eligible to smoothly control vehicle in
unknown or partially unknown environments. Another example of a motion planning for
high-speed driving is [Cowlagi and Peters(2013)] using RRT*.
Recently approaches based on Velocity Obstacles (VO) [Fiorini and Shiller(1998)]
became popular. We focus on these methods, particularly Optimized Reciprocal Colli-
sion Avoidance (ORCA) [Berg et al.(2010)Berg, Guy, Lin, and Manocha] is the selected
method to be used in implementation (see 3.2). The basic roadmap of the development
of the methods based on the VO is addressed by the following Section.
2.2.1 Velocity Obstacles

Concept of velocity obstacles is presented in [Fiorini and Shiller(1998)]. Let us assume
a circular robot A and an moving circular obstacle B with known or measurable posi-
tions, radii rA , rB and velocities vA and vB respectively (for more details and additional
assumptions see [Fiorini and Shiller(1998)]).
We first need to define Collision Cone, CCA,B . We map B to Configuration Space of
A, by reducing A to Â and transforming B to B̂ with radius of rA + rB . Then CCA,B is
a set of colliding relative velocities between Â and B̂ [Fiorini and Shiller(1998)].
CCA,B = {vA,B | λA,B ∩ B̂ 6= ∅}, (2.1)
where λA,B is the line of vA,B . In Figure 2.2 the tangents λf ,λr delimiting the CCA,B
are shown.
^
B
λ V
r B
λ
CC f
A,B
-VB
V
A,B
^ V
A A
Figure 2.2: Collision Cone [Fiorini and Shiller(1998)]
Then the Velocity Obstacle of A induced by the obstacle B is defined as a Minkowski

sum of CCA,B and vB .
V OA|B = CCA,B ⊕ vB = {c + vB | c ∈ CCA,B } (2.2)
^
B
Figure 2.3: Velocity Obstacle [Fiorini and Shiller(1998)]
We introduced a velocity obstacle that represents a static or dynamic obstacle for A.

The principle of the velocity obstacle is to split the space of velocities to collision safe
and colliding velocities. This would allow a robot to avoid collisions by choosing new
velocities from the collision safe velocities (outside the velocity obstacle) under condition
the obstacles would remain in the constant movement in the known direction.
We just described a creation of a velocity obstacle for a single obstacle, let us consider
a set of obstacles M in the environment. Each obstacle generates a velocity obstacle, the
union of velocity obstacles determines the colliding velocities for the robot A.
V OA = ∪o∈M V OA,o (2.3)

As we mentioned earlier using VO principle a robot considers other entities as pas-
sive obstacles. The phenomenon appearing in multi-robot settings (more robots applying
similar collision technique) is known as oscillations. Let us consider two robots approach-
ing to a mutual collision on their desired directions. Both of these robots would try to
avoid collision by choosing a new velocity out of the respective velocity obstacle. That
would lead to the avoidance but the robots would be separated unnecessary more than
needed. The separation would allow to choose next velocities again in original directions
leading to a collision. We just described a single oscillation loop. The solution to avoid
the oscillations are reciprocal velocity obstacles.
2.2.2 Reciprocal Velocity Obstacles

Reciprocal velocity obstacles (RVO) in addition to velocity obstacles consider that other
0
robots perform similar collision avoidance technique. So the new velocity vA is not
selected to be outside the velocity obstacle. A velocity in VO can be selected. The
RVO is considering that the other half of responsibility has the other robot. The RVO is
defined in [van den Berg and Manocha(2008)]:
0 0
RV OA|B = {vA | 2vA − vA ∈ V OA|B } (2.4)
The responsibility can be split among two robots in arbitrary ratio αA|B . Than the
generalization of RVO is:
0 1 0 1
RV OA|B,αA|B = {vA | vA + (1 − )vA ∈ V OA|B } (2.5)
αA|B αA|B
The RVO concept is used for other robots, VO is still used for passively moving
obstacles. The union of obstacles delimits the colliding velocities. Minor extension of
RVO is hybrid reciprocal velocity obstacle (HRVO) which deals with a problem of so-
called reciprocal dances [Snape and van den Berg(2011)].
2.2.3 Optimized Reciprocal Collision Avoidance

The [Berg et al.(2010)Berg, Guy, Lin, and Manocha] claims the RVO concept is safe only
under specific conditions. The newly proposed concept is called optimized reciprocal
collision avoidance (ORCA). The ORCA is claimed to be locally optimal collision avoid-
ance method for robots in multi-robot environment with static and dynamic obstacles.
The ORCA is used in our collision avoidance module implementation (see 3.2.2.1). The
ORCA is based on the RVO but the formulation is slightly different. Let us redefine some
of the terms as it is used in [Berg et al.(2010)Berg, Guy, Lin, and Manocha].
The velocity obstacle for A induced by B for time window τ is defined as:
τ
V OA|B = {v | ∃t ∈ [0, τ ] :: tv ∈ D(pB − pA , rA + rB )}, (2.6)
where D(p, r) is an open disc with center at p and radius r. The geometrical construction
of a velocity obstacle for ORCA is shown in Figure 2.4. In contrast to RVO velocity
obstacle does not delimit colliding and collision-free space. For this purpose are designed
so-called ORCA lines.
Figure 2.4: Geometry construction of Velocity Obstacle [Berg

et al.(2010)Berg, Guy, Lin, and Manocha]
Let us cite the description of the construction in Figure 2.4, [Berg et al.(2010)Berg,
τ
Guy, Lin, and Manocha]: Geometric construction of the velocity obstacle V OA|B (shown
gray on right) for the configuration of robots A and B shown on left. The velocity obstacle
V OA|B can geometrically be interpreted as a truncated cone with its apex at the origin (in
velocity space) and its legs tangent to the disc of radius rA + rB centered at pB + pA . The
amount of truncation depends on the value of τ , the cone is truncated by an arc of a disc
of radius (rA + rB )/τ centered at (pB − pA )τ . The velocity obstacle shown in the figure
is for τ = 2.
Let u be the smallest change to the relative velocity of A and B to avoid collision.
opt opt opt opt

u = ( arg min ||v − (vA − vB )||) − (vA − vB ) (2.7)
τ
v∈∂V OA|B
Figure 2.5: Orca lines [Berg et al.(2010)Berg, Guy, Lin, and Manocha]
Then we consider the robots share the responsibility equally so each of them takes
care of a half. The ORCA line splits the space and delimits a half-plane of collision
avoiding velocities within τ time . The ORCAτA|B is formally specified as follows:
opt 1
ORCAτA|B = {v | (v − (vA + u)) · n ≥ 0} (2.8)
2
The intersection of the collision avoiding half-planes induced by the respective robots
delimits the safe velocities in multi-robot setting. For the completeness we provide the
equation as it was presented in [Berg et al.(2010)Berg, Guy, Lin, and Manocha] with an
additional constraint to the maximum speed.
\
ORCAτA = D(0, vAmax ) ∩ ORCAτA|B . (2.9)
B6=A
The selection of the closest velocity, among collision safe velocities, to the originally
pref
preferred velocity vA is solved by linear programming. That is based on the claims
that ORCAτA is a convex region and the quadratic optimization function has only one
local minimum [Berg et al.(2010)Berg, Guy, Lin, and Manocha]. If the linear program is
infeasible (densely packed conditions - empty ORCAτA ), then the safest velocity possible
is chosen (see [Berg et al.(2010)Berg, Guy, Lin, and Manocha] for more details).
Let us note that a passive obstacle must be avoided in a slightly different way. The
difference is that the robot most take full responsibility for the avoidance with the passive
obstacle.
The ORCA is presented without considering kinematics and dynamics of the robot.
The application of the ORCA on non-holonomic robots is the subject to the following
methods.
2.2.4 ORCA-based Methods for Non-Holonomic Robots

There are works on B-ORCA (bicycle model) [Alonso-mora et al.(2012)Alonso-mora,
Breitenmoser, Beardsley, and Siegwart] and NH-ORCA (Non-holonomic) [Alonso-Mora
and Breitenmoser(2010)] based on the same principle. The ORCA method is used to
calculate holonomic velocity and then controllers are used to follow the holonomic path
with a non-holonomic robot. The tracking error is bounded. The addition of the maximal
error to the radius of the robot is the way to deal with the error. Then the computed
collision-free holonomic path by ORCA tracked with the bounded error can be considered
collision-free even for non-holonomic robots.
2.2.5 Non-Homogeneous Non-Linear Reciprocal Collision

Avoidance
1
The most recent method is described in the [Bareiss and van den Berg(2014)].
The generalization of Velocity Obstacles the Control-Obstacles are introduced. Recip-
rocal Control-Obstacles are corresponding generalization of RVO. The advantage to the
previous methods is possibility of collision avoidance among robots with various dynamics
(non-homogenous and non-linear). The authors present the application of the method
on the differential-drive and car-like robots. Collision avoidance method with claimed
real-time computation rates is promising. The method is general enough to cover wide
range of applications. The robot must be able to observe state and preferred velocities of
other robots or to be able to estimate it, then no communication is needed. The general
approach can cause slower computation rates. The performance is dependent on time
horizon τ . This fact can be positive, the trade-off between ’safety’ and the performance
can be adjusted for non-critical applications.
1
At the time of writing this thesis the paper is under review for ICRA 2014, published on the author’s
website http://arl.cs.utah.edu/research/nhnlrca/. The proposals in this paper are not considered
during implementation, the paper is presented to introduce the most recent ideas in the relevant research
field.
Chapter 3
Implementation
There is the approach to the assignment composed in Section 1.2 with respect to the
requirements presented in Section 1.1. The implementation of a modular system to
allow to implement and to test collision avoidance techniques in a driving simulator is
desired. This chapter describes the architecture of the system and its components. The
system consists of two main components: a driving simulator (Section 3.1) and a collision
avoidance module (Section 3.2).
OpenDS CA
CAModule
Traffic Module
Steering vehicle HMI

SD
Agent
Traffic car1 Comm. SD
Plan Comm Protocol Comm
Traffic car2 Executer
ORCA
Traffic car3 Agent
ORCA
Figure 3.1: Simplifed System Architecture
The Figure 3.1 presents the simplified architecture of the system. Our thesis con-
tribution in implementation is marked by the red color. The OpenDS simulator (see
[OpenDS(2013)]) is described as it is released by its developers (see 3.1) and then the
our implementation of the extensions needed to integrate the simulator into our system
is described in the Section 3.3.2. The collision avoidance module (see 3.2) is already
14
CHAPTER 3. IMPLEMENTATION 15
designed and developed to be a part of the system. The integration of the OpenDS and
the collision avoidance module is described in Section 3.3. The communication and com-
munication protocol SIMPLAN designed to be used in the system is presented in Section
3.3.1.
3.1 OpenDS
OpenDS is an open-source driving simulator [OpenDS(2013)]. OpenDS is based on a
game engine jMonkeyEngine (jME) [JME(2013)]. The jME provides the simulator with
a visualization and physics (via jBullet Physics library [JBullet(2013)]). Rendering is
provided by the Lightweight Java Game Library (LWJGL) [LWJGL(2013)]. OpenDS
uses a possibility importing various 3D models in jME. All scenes can be prepared in
advance and loaded. Individual models can also be added using related XML format
setting files or loaded directly in source code.
OpenDS is not a simulator itself, it contains also so-called Drive Analyzer. Drive
Analyzer allows to replay a drive and to realize further analysis after the simulation run
itself.
OpenDS is a driving simulator aiming mainly on human-machine interaction commu-
nity. There are several preprepared scenarios and drive tasks in OpenDS, nevertheless
creation of a new experiment in OpenDS is possible. As we already mentioned earlier,
settings is based on XML format files. The presence of XML Schema is rewarding and
necessary for creating new scenarios.
3.1.1 Traffic in OpenDS

Vehicle driven by a human driver is called a steering vehicle in OpenDS. OpenDS is pre-
dominantly a driving simulator so the steering vehicle has many features added compared
to other traffic vehicles. Nevertheless the steering vehicle and traffic vehicles are based
on the same car model (i.e. extending class Car).
The traffic vehicles in OpenDS are implemented to follow the predefined waypoints
given in configuration files. The waypoints are defined by positions in simulator coordi-
nates and by speed values not to be exceeded at the corresponding waypoints. The traffic
is supposed to behave to some extend autonomously.
Figure 3.2: Follow Box
So far smooth trajectories and basic collision preventing by speed adjustment is pro-
vided by using so-called follow boxes. A follow box is a virtual object tracking the
desired smoothed trajectory between waypoints of a vehicle. The speed of the follow box
is adjusted according to the desired speed at the next waypoint and the position of the
following vehicle. The follow box is also extended to observe the situation ahead the
vehicle and to adjust the velocity (i.e. to slow down) if it is needed to prevent a collision
with a vehicle ahead. The Figure 3.2 visualizes the described technique: waypoints are
shown in red, a follow box is green tracking the green dot-dashed line. The line illustrates
Catmull-Rom spline that is used by default in OpenDS implementation of motion path of
the follow box. The traffic vehicles are supposed to be extended to even more autonomous
so-called AI vehicles. This would allow the traffic simulation with autonomous vehicles.
3.1.2 Integration
The communication extension of OpenDS is implemented to allow integration of the col-
lision avoidance module and the simulator. The implementation is dependent on the
communication protocol presented in Section 3.3.1.2. The communication protocol is
a part of the Section 3.3 that deals with the integration of the system. Design of the
communication extension is presented there when the communication protocol is already
presented. The extension of control mechanism in OpenDS to allow execution of instruc-
tions received by collision avoidance module is also described there in Section 3.3.2.
3.2 Collision Avoidance Module

Collision avoidance module (CA module) is a part of the system responsible for reacting
on the state of vehicles with appropriate proposal of actions to avoid collisions of vehicles.
The input of the module is a state of the vehicles (e.g. information gathered by sensors
and sent via a communication channel to the module). The module is assuming the state
information to be perfect and in our case the information is actually perfect according to
requirements 1.1. The output of the module are proposed actions, let us now only specify
an action to be an instruction for a driver of the vehicle.
3.2.1 Architecture
The module implementation is based on a simulation toolkit Alite [ATG(2013b)]. The
Figure 3.3 illustrates the typical architecture of a simulation based on Alite. We used
a simulation toolkit to create a module that is a simulator itself. The module performs
a multi-agent simulation. Each agent represents an entity responsible for the collision
avoidance of the related vehicle. The multi-agent simulation allows to use distributed
collision avoidance methods as well as the centralized ones. An agent in this context is
specified as an entity that can perceive and act on the environment. The sensors and
actuators respectively are used to provide interactions with the environment. We consider
the agent to be the intelligent, decision making entity. The agent then implements a
specific collision avoidance method. We use a new agent implementation for each collision
avoidance method (see Section 3.2.2).
The simulation environment is supposed to be updated by data received via com-
munication from an external simulator. The output of the agents is also to be sent to
the external simulator. The simulation is event-based, so the core of the module is the
event processor responsible for the simulation to be running. In fact, the simulation to be
updated is dependent on the communication (external simulation) i.e. there is no update
of the environment on a local simulation timestep event. The communication in general
is described in more detail in related Section 3.3.1.
It is possible to visualize the environment of collision avoidance module. The visual-
ization is independent from the simulation and can be easily switched off. The visualiza-
tion is also easily expandable by new layers. New layers can be registered by an agent
implementation for example, so any method used for collision avoidance can provide
visualization specific for the method (e.g. velocity obstacles, potential fields, etc.).
Figure 3.3: Alite - simplified agent simulation [ATG(2013b)]
3.2.2 Agent Implementations

There are two implementations of the agent in the module: ORCA agent and SD agent.
The agents are described in the following related sections. An agent can register sen-
sors to perceive the environment and actuators to act on the environment. Both of the
following implementations are in principle reactive agents. The agents register callback
sensors to be notified when the environment is updated. Then the agents execute a reac-
tion depending on the specific implementation. The description of the implementations
follows.
3.2.2.1 ORCA Agent
ORCA agent is based on the Optimized Reciprocal Collision Avoidance described in Sec-
tion 2.2.3. The implementation of the method is published in RVO2 Library [RVO2(2011)].
The library is written in C++ and C#, for our purpose we need the implementation in
Java. For the purpose of the [Janovský(2014)] Pavel Janovsky implemented RVO library
in Java. The library is used in our implementation.
The ORCA algorithm provided by the library is integrated into the agent in our col-
lision avoidance module. The ORCA as it is described in 2.2.3 requires specific input.
The environment is specified by the static obstacles. The static obstacles in our case are
delimiting the highway. The positions and velocities of agents are provided via commu-
nication from the driving simulator. Preferred velocities are needed to be specified to
allow ORCA algorithm to optimize the output new velocity. The Figure 3.2.2.1 shows
UPDATE Preferred
velocity
RVO
Simulator
ORCA
New
ORCA
Comm. velocity
Agent
Plan - Waypoint
Figure 3.4: ORCA Agent operation
the principle of the ORCA agent’s operation.

RVO Simulator is the component of the CA module, the component that holds the
data representation needed as an input for ORCA. Note that the RVO Simulator is shared
for all the agents. The motivation of the centralized representation is not to duplicate
the data for all agents, while the update of agents’ states is also received at once. The
individual agents need to specify the preferred velocities, then the ORCA can operate.
The output is a new velocity. The ORCA does not consider the dynamics of vehicles.
It assumes the holonomic robots. We presented methods based on ORCA (2.2.4) for
non-holonomic robots. Similar approach is applied in ORCA agent. The ORCA outputs
a new velocity vector, the vector is transformed to a waypoint. The waypoint is sent as
a plan by CA module to a driving simulator. We refer to the integration related Section
3.3 where the communication layers are described and the Waypoint layer is one of those.
The collision avoidance is not guaranteed by this ORCA agent implementation, even
the output, the waypoint, is not guaranteed to be reached. There is a strong dependence
on the executer of the plan - the controller or driver of the vehicle.
3.2.2.2 SafeDistance Agent
SafeDistance (SD) agent is based on the Safe Distance Observance method originally
described in [Schaefer(2011)]. The brief summary of the principle is to repeatedly find a
maneuver which execution leads to a safe state.
The important feature of the method is that it can ensure the safe state after maneuver
Maneuver
execution
try first maneuver to maneuver to

be checked be executed
no no
Possible is highway is vehicle
maneuvers collision collision
try next yes

yes
Figure 3.5: Safe distance method - control loop
execution. This is guaranteed because the safe distance is checked on the distance between
the position after maneuver and the initial position of the vehicle ahead. The safe state
means the possible safe maneuver in the next step. Let the initial state be safe and all the
future states are safe as well. [Schaefer(2011)].
The input of the method is a set of possible maneuvers with priorities and the current
state of the vehicle and of the other vehicles. The output is a safe maneuver with the
highest priority. Conditions to be satisfied to say a certain maneuver is safe are described
in the Section 3.2.2.2. The method works on the level of maneuvers. Maneuvers are
presented in the following section.
Maneuvers
Maneuvers are designed to correspond basic maneuvers needed to drive on a highway.

A maneuver represents a discretization unit and serves to simplify the problem. Set of
maneuvers used is finite. The basic set of maneuvers used in [Schaefer(2011)] contains:
Straight, Acceleration, Deceleration, Lane-left change and Lane-right change. In general
maneuvers can be parametrized to allow desired level of discretization. We demand the
possibility to evaluate whether a certain maneuver is safe. Maneuver should be atomic in
meaning the execution of the maneuver should not be interrupted. It is mostly important
for lane changing maneuvers to actually change the lane.
Safe Maneuver Conditions
The finding of the next safe maneuver is done repeatedly after previous maneuver exe-
cution. The set of maneuvers is checked one by one in order of descending priority. The
control loop of the method is shown in Figure 3.5. There are several conditions to be
Critical distance
Rear
vehicle Front
vehicle
maneuver to be Operating
checked vehicle
Figure 3.6: Safe distance method - critical distance
Critical distance
Rear
vehicle
Front
vehicle
maneuver to be critical Operating

checked maneuver vehicle
Figure 3.7: Safe distance method - critical distance - lane change
satisfied so we can say a maneuver is safe. The conditions are following:
1. Highway condition A - The desired lane must exist at the related highway segment.
2. Highway condition B - The end lane of the maneuver must continue far enough to
allow the vehicle to stop until the end of the lane is reached.
3. Vehicles condition - The maneuver is acceptable for a vehicle if all other vehicles
that the vehicle can endanger are in safe distance from the vehicle.
Safe Distance
The critical distance is examined to decide whether the distance between vehicles is safe.
The critical distance is get as is shown in the Figure 3.6 and Figure 3.7. To decide whether
the critical distance is safe we need to count the value of the minimal safe distance ds .
The situation at time t0 is shown in the Figure 3.6. We can use basic motion laws. The
maneuvers are defined with constant acceleration a so we use it as well.
vA1 = vB0
vA0 + a · TS = vB0
TS . . . maneuver duration
vA1 . . . velocity of the rear vehicle at the end of the maneuver at t0 + TS
vB0 . . . velocity of the front vehicle at t0
Now we get the minimal safe braking period TS . The minimal safe distance dS is defined
by the following equation.
1 v 2 − vA0
2
dS = vA0 · TS + a · TS2 = B0
2 2a
The critical distance d is safe if d > dS + , where is an emergency reserve. The
emergency reserve comprises for example dimensions of the vehicles that are omitted
during the computation.
3.3 Collision Avoidance and Simulator Integration

There is a driving simulator OpenDS enhanced by basics needed for a traffic simulation
of autonomous vehicles. The integration of collision avoidance into the OpenDS simu-
lator can be done by connecting a collision avoidance module to OpenDS by external
communication. The main reason for the option of using external communication is the
independence of a simulator and a collision avoidance system. The independence provides
modularity allowing possible usage of multiple simulators or collision avoidance systems
(see requirements in 1.1). Further it allows independent development and distribution of
computational costs. On the other hand communication delay occurs.
There is the collision avoidance module for implementing collision avoidance tech-
niques. The module can be used to implement a collision avoidance system for OpenDS.
The protocol for the communication must be defined. The communication technology
and the protocol specification is described in the 3.3.1.2 section. The protocol design
depends on the desired level(s) of control of the vehicles. There is a Figure 3.8 showing
the simplified resulting scheme of OpenDS and Highway platform integration.
OpenDS CA Module
Traffic
Storage
Steering vehicle FB
Traffic 1 FB
PB Protocol PB
Traffic 2 FB
Comm Buffers Comm
Traffic 3 FB
Agent 1
Agent 1
Agent 1
Figure 3.8: OpenDS - Highway platform integration scheme ( FB = Follow

Box, PB Comm = Protocol Buffer Communicator )
3.3.1 Communication
Communication between the simulator and collision avoidance module is addressed in
this Section. Communication is TCP socket-based and uses binary streams to send data.
The serialization and deserialization of structured data is done by Protocol Buffers (see
3.3.1.1). Communication protocol designed for the communication between a simulator
and a collision avoidance module is described in Section 3.3.1.2.
3.3.1.1 Protocol Buffers
Protocol Buffers is a mechanism for serializing structured data. Protocol Buffers are
developed by Google [Google(2013)]. Protocol Buffers aim to simplicity and performance.
It allows developer to define a protocol in a text .proto file. By compiling .proto file
developer can generate data access classes in various programming languages. Java, C++
and Python are supported by Google but even other languages are available using third
party contributions. The Protocol Buffers messages are not self-describing in general
but there are ways how to achieve it. The data is easily accessible via API. Serialized
data is sent in a binary form for example via sockets as it is done in OpenDS - CA
module integration. For implementation of communication we use Communicator and
ProtobufFactory libraries. ProtobufFactory is a library developed at ATG by Michal
Stolba. Communicator is our lightweight implementation of socket-based communicator
for receiving and sending data. Communicator is based on ProtobufFactory and provides
developer with easy-to-use interface to configure desired communicator instance (e.g.

define protocol, register callbacks, etc.).
3.3.1.2 Communication Protocol
The specific protocol used in OpenDS - Highway platform integration we named SIM-
PLAN and is described in this section. The Message container is used in our example, the
Message contains optional fields Update, Plans and Init messages. Optional field usage is
technique called Union Types, one of the commonly used design patterns of using Proto-
col Buffers [Google(2013)]. It allows to send messages of various types using one protocol.
Init message can be used in the beginning of a communication to provide information
needed to initialize internal system states of communicating systems (e.g. highway road
structure). The Update message is used to provide information about traffic in simulator
to the CA module and in the opposite direction the Plans are sent from CA module to
the simulator.
message Message {
// One of the following will be filled in.
optional Update update = 1;
optional Plans plans = 2;
optional Init init = 3;
}
3.3.1.3 Update Message
Update message contains data going from a simulator to a collision avoidance module
and/or other module that would need the data. Update message instance is specified by
an updateTime value. The content is a repeated field of VehicleUpdate - type representing
state data of a related vehicle in the simulation.
message Update {
required double updateTime = 1;
repeated Vehicle_update updates = 2;
}
3.3.1.4 Plans Message
Plans message contains data going from a collision avoidance module to a simulator.
Timestamp value allows to link a Plans message to a specific Update message. The Plans
message timestamp specifies what received Update message the Plans message was gen-
erated from. The repeated field of message type Plan contains plans for related vehicles.
The Plan is a list of actions of type Action. Action is an abstract type implemented by
Maneuver, Waypoint and Actuator message type. The protocol allows to send an action
in three different ways. The Maneuver, Waypoint and Actuator message represent layers
of controlling the vehicles. The layered design allows to use collision algorithms working
on one of the specified layers. On the other side the simulator must be able to control
vehicles on the basis of these layers. The complete protocol files are listed in an Appendix
A.
message Plans {
required double timestamp = 1;
repeated Plan plans = 2;
}
message Plan {
required int32 vehicleId = 1;
repeated Action actions = 2;
}
message Action{
optional Maneuver maneuver = 1;
optional Waypoint waypoint = 2;
optional Actuators actuators = 3;
3.3.2 Extensions in OpenDS

Traffic vehicles in OpenDS can be controlled directly using actuators (e.g. setting steer-
ing angle or pedal intensity). Other possible option is to use higher level of control
as dynamic generating of waypoints. The higher level can take advantage of already
implemented techniques in OpenDS. These techniques are described in the Section 3.1
related to OpenDS. This section deals with the implementation of communication and
the interface with these already implemented OpenDS controlling techniques.
We provide a description of the implementation of communication and further exten-
sions to enable integration of collision avoidance in OpenDS simulator.
3.3.2.1 Communication
The communication in the OpenDS simulator is based on the techniques described in

communication related Section 3.3.1. The instance of Communicator is used in OpenDS.
Let us just remind that the Communicator embodies the serialization, sending and reading
of the data. The communication is desired to be independent from the simulation loop
of the simulator not to slow down the simulation itself. Otherwise the communication,
for example regular creating and sending of the Update messages (see 3.3.1.2), could
cause freezing of the simulation. The receiving of the communication is also executed
in the related thread to allow the simulator to run even when the communication fails.
The response of the collision avoidance module from the simulator’s point of view is in
general irregular and unpredictable. The simulator is notified when the new Plan message
(see 3.3.1.2) is received. The notification of the new message is handled according to the
content. The extension of control mechanism is needed to execute the desired plan.
3.3.2.2 Plan Executer
The communication protocol SIMPLAN (see 3.3.1.2) enables to send plans in several
ways. The 3 layers correspond to the levels of control. Let us remind that there are
Maneuver, Waypoint and Actuator layers.
The Plan Executer that is a component responsible for the execution of a plan defined
in one of the levels. There are also two ways of the execution. First, there are traffic
vehicles driven autonomously by the plan. Second, there is a so-called steering vehicle
driven by a driver, to whom the plan is proposed via human-machine interaction interface
(HMI).
Let us describe the update loop of the traffic vehicles. As we mention in Section 3.1
the traffic in OpenDS is controlled using so-called Follow Boxes (FB). The vehicle simply
steers and set the speed to follow the FB. We use this interface between a traffic vehicle
and its FB, so we can control the vehicle in fact on the Waypoint level.
The Figure 3.9 shows the principle of the plan execution in OpenDS. The commu-
nicator receives the plans from collision avoidance module. The OpenDS waypoints are
WP generator Plan
Traffic Car
Comm
WP Queue
WP FB
steerTo(WP)
setSpeed(v)
next check if WP
speed WP reached
state
state
Figure 3.9: OpenDS - Plan Executor ( FB = Follow Box Interface, Comm

= Communicator, WP = OpenDS Waypoint, Plan = List of
Maneuver / Waypoint Actions )
generated according to the level of the individual actions in the plan. The original
OpenDS simulator offers a control mechanism able to steer to a waypoint. The current
waypoint is provided by the Plan Executer. The executer offers a new waypoint from the
waypoint queue when the previous waypoint was reached or overwritten by the new plan.
3.3.3 Human-Machine Interaction Interface

The Human-Machine Interaction Interface (HMI) is designed to present the plan proposed
by the collision avoidance module to the driver of the steering vehicle. The simulator offers
the possibility of implementing HMI in various ways. The OpenDS visualize a simple
dashboard on the screen. The other option is the visualization of the plan proposal using
augmented reality. We mean to visualize the HMI output in the simulation scene.
In general the designing of the HMI requires a lot of effort. The usability testing,
driver distraction studies are just examples of the processes to be done to evaluate the
HMI interface. These requirements are not in the scope of this work. We prototype
an ’augmented reality’ based HMI interface in OpenDS simulator to demonstrate the
concept of presenting proposed plans by CA module.
The output of the HMI is designed to present the plan. The plan is mapped to the
unified output instruction. We mean that there is no difference in the output visualization
of various plans. We remind that the plan can be defined on several action levels. An
action is mapped to the instruction. An instruction embraces the desired speed and lane.
An action of the lower level (e.g. waypoint) is mapped to a lane. We assume that the
lane instruction can provide stable HMI output by filtering possible dynamically updated
waypoints.
(a) HMI - keep speed and lane (b) HMI - accelerate
(c) HMI - braking (d) HMI - change lane
Figure 3.10: HMI
The lane is proposed by the blue colouring of the lane of the proposed lane. See
the Figure 3.10(a), where the driver is instructed to keep current speed and lane. The
changle lane instruction is shown in the Figure 3.10(d). The speed instruction is projected
into a rectangle in the heading direction. The transparency of the rectangle is being
adjusted. The rectangle is red if braking is proposed (see Figure 3.10(c)) and is green if
the accelerating is proposed. The color intensity is proportional to the proposed speed
change.
Chapter 4
Experiments
This chapter is dedicated to the experiments. First we specify what are the features we
want to study, what is the purpose of the experiments. We provide the motivation for
the experiments in the Section 4.1. The experimental scenarios settings are described
in Section 4.2, there is also the methodology of the evaluation of the results of the
experiments. At last we provide the results of the experiments. The discussion of the
results is also the part of the Section 4.3.
4.1 Motivation
The motivation of the experiments is based on the requirements specified in the Section
1.1. The requirements number 2,7 and 8 are related to the experiments.
The demand to allow to evaluate the collision avoidance techniques in the simulation
is the general requirement. We provide a set of scenarios in the experiment named the
Imminent Collision Experiments (ICE). The set of experiments is described in the related
Section 4.2.1.
The ICE should provide the insight into the behaviour of the vehicles. The ICE
experiments can be either executed on the scenarios without the steering car - without
the human driver. Or either on the scenarios with the driver. The scenarios without
the driver are more suitable for the analysis of the features of the implemented collision
avoidance methods. The behaviour is less influenced by the uncertain execution of the
plans.
The experiments with the driver are mainly based on the requirement to reveal pos-
29
CHAPTER 4. EXPERIMENTS 30
sibilities of the user testing of the driver assistance system. The proof-of-concept exper-
iments are meant to show whether the evaluation of driver assistance systems can be
done using the studied system. The experiments with the just described purposes are
presented in the Section 4.2.2.
4.2 Settings and Methodology

The experiments are performed using the versions of the software provided in the Ap-
pendix B.1. The OpenDS simulator and the collision avoidance module are released
separately. There is variety of the parameters and settings of both of the systems. The
specific parameters important for the experiments are eventually mentioned in the related
section.
The general settings are defined in the related configuration files. Let us now briefly
introduce the basic configuration common for the following experiments. The scene in
OpenDS is simple. There is a 2-lane straight highway on the flat plane. The environment
is minimalistic not to slow down the simulation. All the vehicles have the same dynamics
of the default OpenDS vehicle.
The experiments are perform using a laptop with Intel(R) Core(TM) i5-3210M 2.5
GHz CPU and 4GB of RAM running the 64-bit Windows 7 operating system. For the
driving experiments we used an older Logitech Formula Force EX wheel with the pedals.
See the simulator setting in Figure 4.1.
4.2.1 Imminent Collision Experiments

The Imminent Collision Experiments (ICE) are designed to show the capability of col-
lision avoidance algorithms to navigate vehicles. The scenarios are designed to model
situations when there is an potential imminent collision. The experiments demonstrate
the potentials and limitations of the tested collision avoidance techniques. In our case
SafeDistance agent and ORCA agent are studied. The agents are tested separately. The
group of vehicles in the experiment is homogeneous, using the same collision avoidance
technique. There are 15 autonomous traffic vehicles in the experiments. The driven ve-
hicle is not studied in the experiment. The driven vehicle is in the simulation (the red
car out of the highway) only to allow easy way to control the camera.
Figure 4.1: Simulator setting for the driving experiments
500 meters
Incident area
Direction of the movement
Figure 4.2: ICE braking - initial setting
The Figure 4.2 illustrates the basic initial setting of the braking experiments. The
blue vehicles are the vehicles driven by the collision avoidance agents. The black vehicle
is a dummy vehicle. The dummy vehicle is not driven by the collision avoidance agent but
it is driven by the predefined waypoints. The dummy vehicle in the ICE context causes
the potential imminent collision. The Figure 4.3 illustrates the moment of an incident.
The dummy vehicle suddenly brakes. The agents of other traffic vehicles are supposed to
ensure collision avoidance.
Incident area
Direction of the movement
Figure 4.3: ICE - braking - the moment of the incident
A slightly different initial setting is used for the experiments with constantly slow
dummy vehicle (ICE - slow vehicle). There is no sudden braking of the dummy vehicle
in the scenario, but the dummy vehicle is slower than the other vehicles. The Figure 4.4
illustrates the setting of the dummy vehicle ahead the others.
Direction of the movement Slow vehicle
Figure 4.4: ICE - slow vehicle - initial setting
Let us now introduce the particular scenarios. The ICE - braking experiments are
instantiated in two variants. The ICE - slow vehicle experiments are also in two variants.
For both pairs one of them is an extreme case. The extreme ones in the sense that braking
is performed until the vehicle is stopped and in the ICE - slow vehicle case the constant
speed of vehicle is equal to zero. The Table 4.1 summarizes the experiments.
Evaluation Methodology
The main source of the information is the record of the experiment execution (the list
of videos is in Appendix B.2). The experiments are recorded to allow to visually study
the behaviour of the vehicles driven by the collision avoidance agents. There are features
we extract from the experiments and present them as the quantified results. We observe
if there is a collision during the experiment. Above that, let us remind that one of the
Experiment ID vD0 [ms−1 ] vDi [ms−1 ] # of vehicles driven

I 35 20 15 no
II 35 0 15 no
III 20 20 15 no
IV 0 0 15 no
Table 4.1: Imminent Collision Experiments (vD0 and vDi is the initial and
final speed of the dummy vehicle)
requirements on the collision avoidance is that the entity continues on approaching to

its desired goal destination. So we also give a number of vehicles that get stuck (e.g.
vehicle is unable to overtake another vehicle). The following discussion of the individual
experiments offers the possibility to describe the specific features of the behaviour of the
agents.
4.2.2 Driver Assistance System Experiments

The proof-of-concept experiments of the simulation with the human-in-loop are described
in this section. The purpose is to show how a driver deals with the collision-imminent
situations with the assistance of the CA module. The experiments are not meant to
be user testing of the driver assistance system. Experiments just reveal if the following
of the instructions is feasible. Secondly, if the execution of the instructions lead to the
desired destination without collisions. By reflecting the experiment we should describe
the possibilities of future user testing of the driver assistance system.
The setting of the experiments is similar to the previous experiments described in the
Section 4.2.1. The difference is that the driven vehicle drives behind the dummy vehicle
instead of the traffic vehicles. There are also two scenarios where the driven vehicle is
among other traffic vehicles. The set of scenarios is again summarized in the Table 4.2.
4.3 Results and Discussion

The results and the discussions of the results are presented in this section. The imminent
collision experiments are described in Section 4.3.1 and the experiments of the driver
Experiment ID vD0 [ms−1 ] vDi [ms−1 ] # of vehicles driven

V 20 20 1 yes
VI 35 0 1 yes
VII 35 20 15 yes
Table 4.2: Driver Assistance System Experiments (vD0 and vDi is the ini-
tial and final speed of the dummy vehicle)
assistance system are in Section 4.3.2. The Appendix B.2 is also referred, as it contains
a list of videos attached to this thesis. The following sections describes the behaviour of
the vehicles that is advised to be watched on the video. The text then offers an additional
description or eventual clarification of the observed features.
4.3.1 Imminent Collision Experiments

Discussions of the individual experiments are presented one-by-one. For the description
of the experiments, let us refer to the one of the previous sections (4.2.1). Summary of
the results presented in this section follows. Please note that the videos of this section
are taken using the driven vehicle for controlling the dynamic camera (the red vehicle
driving next to the highway).
4.3.1.1 Experiment I
The scenario models a situation when a vehicle on a highway suddenly slows down from
130 km/h to 72 km/h. Other traffic vehicles should safely overtake the slow vehicle.
SD Agent
SD agent method is able to deal with the incident of sudden braking. No collision of
vehicles is detected and the motion of the traffic is smooth. The traffic vehicles in the
lane behind the braking vehicle slow down, overtaking is not possible because of the
vehicles in the second lane. When the second lane is free, the vehicles behind change
the lane and overtake. Interesting situation appears when two of the vehicles begin to
overtake at almost the same time. In this case the vehicle that is ahead perceives the
overtaking vehicle behind and interrupts the overtaking maneuver and gives way to the
vehicle behind. All vehicles overtake the slow dummy vehicle in the end.
The SD agents performed well in this scenario and subjectively the vehicles behaved
naturally.
ORCA Agent
ORCA agents also avoided collisions and let all the vehicles to overtake the slow vehicle.
The process of experiment is different. First the fact, that the ORCA agent does not
consider lanes is observable. So the passing close to the slow vehicle is performed. The
close passing make the overtaking vehicle to slow down. The slowing down causes a
so-called traffic wave (also called traffic shock) that almost lead to a collision.
The ORCA agent navigates the vehicle without considering lanes. The experiment is
collision free but the observed traffic shock caused less smooth performance.
4.3.1.2 Experiment II
This experiment is an extreme variant of the previous one. The dummy vehicle brakes
from 130 km/h until it is stopped.
SD Agent
There is also no collision in this experiment, on the other hand there are 4 vehicles that
get stuck.
The experiment progresses similarly to the previous one. The difference is that the
vehicles just behind the stopped vehicle must stop too. Then the vehicles are not capable
to accelerate again and overtake. This is the limitation of the method that is caused
partially by the reactive nature of the method and also by the fact that the set of possible
maneuvers is finite. The SD agent does a safety check of a maneuver but no planning
to detect possible deadlock after performing the maneuver. It can happen after stopping
that the only defined acceleration maneuver is not safe.
ORCA Agent
The summary of the experiment is that all the vehicles avoid collisions and are able to
overtake the stopped vehicle.
The video (for all videos see Appendix B.2) shows how the method can benefit from
not considering the lanes. The vehicles from both lanes behind the braking vehicle are
able to overtake at the same time. The stopped vehicle is positioned near the edge of the
highway, so the overtaking is possible for two vehicles in parallel.
Let us note that the observed close passing by the stopped vehicle at high speeds is a
potential risk.
4.3.1.3 Experiment III
In this experiment the dummy vehicle models a slow vehicle (72km/h) on a highway. The
other vehicles are approaching at the speed of 130 km/h.
SD Agent
The experiment is collision free with no vehicles being stuck. The vehicles in the lane
behind the slow vehicle are again made to slow down. The vehicles in the faster lane do
not give them way. Not even the vehicles behind the slow vehicle take the risk to join
the faster lane. The behaviour is non-cooperative.
ORCA Agent
The ORCA agents are not able to prevent some collisions in this experiment. The collision
than causes a blockage on the highway.
The vehicles already experience troubles to approach the slow vehicle. The vehicles get
close to each other and slow down. Then the aggressive braking in the dense conditions
causes a collision of 5 vehicles. The maneuvers of a vehicle driven by ORCA agent are
quite aggressive. And the other vehicles have a problem to react to these aggressive
maneuvers.
4.3.1.4 Experiment IV
The last of the Imminent Collision Experiments is the experiment with a static vehicle.
The dummy vehicle is stopped in the right lane.
SD Agent
SD agent experiment is again collision free. The 4 stuck vehicles correspond to the
Experiment II where the dummy vehicle after braking stopped too.
We already mentioned that the SD agents are non-cooperative when merging, so the
vehicles in the lane behind the stopped vehicle must stop too.
There is another potential collision situation revealed. We already described that it
can happen that two vehicles decide to change lane simultaneously. Both of the vehicles
are assuming the other lane is free. When one of the vehicles changing the lane perceives
the other one, it interrupts the lane change maneuver. This interruption makes the
vehicle to remain in the current lane. By that time it can be late to slow down to avoid
a collision with a vehicle ahead in the current lane. The time spent on the interrupted
lane changing can be then missing for the sufficient braking. The potential collision can
be seen in the end of the related video (see Appendix B.2).
ORCA Agent
There is no collision in this experiment. In contrast there are 6 vehicles unable to pass
by the stopped vehicle. The ORCA agents deals with the other vehicles close around by
slowing down. The vehicles perceive the stopped vehicle but are unable to overtake the
stopped vehicle. Here we should note that the stopped vehicle is perceived as an agent,
meaning that reciprocity is assumed by other agents. So no reciprocity from the stopped
vehicle complicates the task of the others. Second thing is that not even ORCA agent
is using long-term planning to avoid deadlocks. The current higher-level planner used
to provide the desired direction is only visibility graph planner considering only static
obstacles. The deadlocks are not avoided.
4.3.1.5 Summary of the Experiments I - IV
The extracted results of the experiments are summarized in the Table 4.3. We can
compare the tested collision avoidance methods by the criteria of collision presence and
by the count of vehicles that got stuck.
To summarize we can say that SD agent is better in preventing collisions with no
collision occurrence. ORCA agent does not prove to be collision free in scenarios similar
to our experiments. By observing ORCA agent driving, we state that ORCA control
actions are aggressive. The SD agent’s driving is smoother. For the purpose of modelling
natural behaviour of the traffic we would also choose SD agent for its smoother and
predictable behaviour.
SD agent can suffer from getting stuck as it is demonstrated in Experiments II and
IV. An application of a special maneuver designed to avoid getting stuck behind stopped
vehicle is our fture proposal to solve this problem.
Another discovered weakness is a simultaneous lane changing. Resolving this weakness
should not lead to the extensive restriction of the lane changing. Proper solution requires
deeper analysis of the lane change maneuver in future.
Experiment ID SD - collision SD - # stuck ORCA - collision ORCA - # stuck

I no 0 yes 0
II no 4 no 0
III no 0 yes 9
IV no 4 no 6
Table 4.3: Results of the Experiments I - IV
4.3.2 Driver Assistance System Experiments

The discussions of the experiments specified in the Section 4.2.2 are individually presented
in this section. The conclusion of these results is at the end of this section.
4.3.2.1 Experiment V
The scenario of this experiment is simple. The driven vehicle accelerates up to 130km/h
and approaches slower vehicle ahead. There is no other traffic.
SD Agent
SD agent proposes to accelerate by visualizing a green ray in the heading direction. The
proposed lane is highlighted by the blue color. The green ray looses intensity as the
vehicle reaches the desired speed. The lane change proposal appears in advance while
approaching the slow vehicle.
ORCA Agent
Despite the simplicity of the experiment the output of the HMI interface is substantially
different. ORCA agent keeps distance between the driven and dummy vehicle. Driver
is instructed to approach dummy vehicle slowly. In meanwhile sudden hard braking
proposals appear. The navigation is less stable and mainly it does not instruct driver
to change lane. The driver is proposed not to overtake but to slow down and follow the
dummy vehicle.
The problem of no lane change proposal is related to the level of plan the ORCA agent
sends (see 3.2.2.1 for more details). ORCA agent sends plan on the Waypoint lavel. The
HMI interface is proposing speed and lane which is corresponding to the Maneuver level of
plan. A waypoint proposed by the ORCA agent must be mapped to a lane. The mapped
lane is usually the current lane because the lane is given according to the waypoint’s
location. The waypoint usually doesn’t reach another lane.
4.3.2.2 Experiment VI
Experiment VI is similar to the previous experiment. Only the dummy vehicle is not
driving constantly slowly but breaks suddenly and stops.
SD Agent
SD agent reacts to the braking immediately by proposing lane change maneuver. In our
opinion the proposal comes earlier then a driver can realize the dummy vehicle is actually
braking.
ORCA Agent
The ORCA agent is not expected to propose a lane change maneuver after the findings
from the previous experiment. Nevertheless the instruction to apply brakes is clear and
convincing so the vehicle is stopped in time.
4.3.2.3 Experiment VII
The Driver Assistance System is also tested with the traffic vehicles in this experiment.
The traffic is driven by the same agent that is used for HMI. The dummy vehicle slows
down from 130km/h to 72 km/h.
SD Agent
The navigation works in an expected way even in the presence of the traffic. The driven
vehicle is notably slower, it is overtaken by all the vehicles before it reaches the dummy
vehicle. Several times short braking is proposed. The driven vehicle is following the
dummy vehicle for a while before the instruction to change the lane appears. The execu-
tion of the plan by the driver is not so exact as is in the the autonomous traffic vehicles.
It leads to the slower drive and later overtaking in this experiment.
ORCA Agent
The most interesting in this experiment is to observe other traffic vehicles. The experi-
ment offers an insight to the group of vehicles driven by ORCA agent. When the vehicles
overtake in the second lane nothing abnormal is registered. Interesting is the behaviour
of a vehicle behind the driven vehicle, that tries to closely overtake the driven vehicle.
Similar oscillating behaviour can be observed on the vehicle in front of the driven vehicle.
The vehicles accelerate, get closer to the other vehicle and at the level of the rear bumper
of the other vehicle suddenly slow down. In the end the situation leads to a collision of
the two traffic vehicles.
4.3.2.4 Summary of the Experiments V - VII
The experiment shows that driving by following the proposals of the driver assistance
system is feasible. The simple experiments reveal the differences in the navigation by
two different collision avoidance methods. The concept of the eventual user testing of the
HMI interface and connected CA module in this system is in our opinion applicable.
The Table 4.4 shows that following instructions of SD agent prevented collisions.
Using ORCA agent we observe a collision in the Experiment VII, but in this experiment
the collision is caused by the other traffic vehicles.
ORCA agent do not propose lane change maneuvers so no overtaking is possible
when the driver would strictly follow its instructions. OpenDS agent’s proposals lead to
more cautious driving (Experiment VII) but the driver is still approaching the desired
destination. SD agent proposes lane change if it is assumed to be safe.
Experiment ID SD - collision SD - # stuck ORCA - collision ORCA - # stuck

V no 0 no 1
VI no 0 no 1
VII no 0 yes 6
Table 4.4: Results of the Experiments V - VII

Chapter 5
Conclusion
In this chapter we summarize the contents of this thesis. We conclude the outputs of the
work. General results of the experiments are followed by the ideas and proposals for the
future work.
The goal of this thesis was to design and to implement a system that would allow
to integrate a collision avoidance techniques in a driving simulator. The purpose of the
concept is to allow to develop various collision avoidance techniques and to allow to
apply these techniques in an arbitrary driving simulator. The application of the collision
avoidance techniques is to control autonomous traffic and/or to advise a driver via a
driver assistance system interface in the simulator.
We studied and described state-of-the art of the driving simulators and also the re-
search on collision avoidance techniques relevant for our application. We implemented
a collision avoidance module and integrated and adapted two collision avoidance tech-
niques into the module. The module is developed as a part of the designed system.
Second main component of the system is the OpenDS simulator where we implemented
only the extensions to enable the integration. Our extensions implement: communica-
tion, plan execution for traffic and HMI interface for a driver. We also prepared a scene
and several scenarios to run the experiments in OpenDS. All the system is build on the
communication protocol we designed and implemented.
The experiments in general show that the system as it is designed can be used for re-
quired purposes. Collision avoidance module is able to navigate traffic using two different
methods of the collision avoidance. The safety and specific features of navigation depend
on the CA method implementation. The Safe Distance technique performed better than
the ORCA-based technique in the presented experiments. The comparison of the meth-
ods is possible in the system and possibilities of analysing the methods is revealed. The
41
CHAPTER 5. CONCLUSION 42
concept of the driving with the driver assistance system presenting the outputs of the
CA module is shown to be relevant. The system can be used for studies on the used CA
method suitability for HMI and even for HMI interface user testing.
(a) Bird’s view (b) Cockpit view
Figure 5.1: Screenshots of the simulation

Bibliography
[Almeida(2013)] JE Almeida. Crowd Simulation Modeling Applied to Emergency and

Evacuation Simulations using Multi-Agent Systems. In DSIE’11 - 6th Doctoral
Symposium on Informatics Engineering, 2013. URL http://arxiv.org/abs/1303.
4692.
[Alonso-Mora and Breitenmoser(2010)] J Alonso-Mora and Andreas Breitenmoser. Opti-

mal reciprocal collision avoidance for multiple non-holonomic robots. . . . Autonomous
Robotic . . . , pages 1–14, 2010. URL http://link.springer.com/chapter/10.
1007/978-3-642-32723-0_15.
[Alonso-mora et al.(2012)Alonso-mora, Breitenmoser, Beardsley, and Siegwart] Javier

Alonso-mora, Andreas Breitenmoser, Paul Beardsley, and Roland Siegwart. Re-
ciprocal Collision Avoidance for Multiple Car-like Robots. Proceedings of the
IEEE International Conference on Robotics and Automation ICRA, pages 360–366,
2012. doi: 10.1109/ICRA.2012.6225166. URL http://www.disneyresearch.com/
research/projects/DisplaySwarm/alonsomora12icra_paper.pdf.
[ATG(2013a)] ATG. ATG website, 2013a. URL www.agents.cz.
[ATG(2013b)] ATG. Alite project website, 2013b. URL http://jones.felk.cvut.cz/

redmine/projects/4/wiki/Alite_Overview.
[Bareiss and van den Berg(2014)] Daman Bareiss and J van den Berg. Recipro-
cal Control-Obstacles for Collision Avoidance of Multiple Robots with Non-
Homogeneous Non-Linear Dynamics. arl.cs.utah.edu, 2014. URL http://arl.cs.
utah.edu/pubs/ICRA2014-nhnlrca.pdf.
[Berg et al.(2010)Berg, Guy, Lin, and Manocha] Jur Van Den Berg, SJ Guy, Ming Lin,
and Dinesh Manocha. Reciprocal n-body collision avoidance. Robotics Re-
43
BIBLIOGRAPHY 44
search, pages 1–16, 2010. URL http://link.springer.com/chapter/10.1007/

978-3-642-19457-3_1.
[Brock and Khatib(1999)] O. Brock and O. Khatib. High-speed navigation using the
global dynamic window approach. Proceedings 1999 IEEE International Conference
on Robotics and Automation (Cat. No.99CH36288C), 1(May):341–346, 1999. doi: 10.
1109/ROBOT.1999.770002. URL http://ieeexplore.ieee.org/lpdocs/epic03/
wrapper.htm?arnumber=770002.
[Cowlagi and Peters(2013)] RV Cowlagi and SC Peters. Optimal motion planning with
the half-car dynamical model for autonomous high-speed driving. American Con-
trol . . . , 2013. URL http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=
6579835.
[EuroFOT(2013)] EuroFOT. EuroFOT - ADAS, 2013. URL http://www.eurofot-ip.

eu/.
[Fiorini and Shiller(1998)] P Fiorini and Z Shiller. Motion planning in dynamic envi-
ronments using velocity obstacles. The International Journal of Robotics Research,
1998. URL http://ijr.sagepub.com/content/17/7/760.short.
[Google(2013)] Google. Protocol Buffers - website, 2013. URL https://developers.

google.com/protocol-buffers/docs/overview.
[Guizzo(2011)] Erico Guizzo. How Google’s Self-Driving Car Works, 2011. URL
http://spectrum.ieee.org/automaton/robotics/artificial-intelligence/
how-google-self-driving-car-works.
[Howard(2012)] Bill Howard. Inside Virttex, Fords amazing driver distrac-

tion simulator, 2012. URL http://www.extremetech.com/extreme/
133549-inside-virttex-fords-amazing-driver-distraction-simulator.
[Janovský(2014)] Pavel Janovský. Increasing Coverage of Reactive Techniques for Colli-

sion Avoidance. 2014.
[JBullet(2013)] JBullet. jBullet Library, 2013. URL http://jbullet.advel.cz/.
[JME(2013)] JME. jMonkey Engine, 2013. URL http://jmonkeyengine.org/.
[Lalish(2009)] Emmett Lalish. Distributed Reactive Collision Avoidance. 2009.

BIBLIOGRAPHY 45
[LaValle(2006)] Steven M. LaValle. Planning Algorithms. 2006. doi:

10.1017/CBO9780511546877. URL http://ebooks.cambridge.org/ref/id/
CBO9780511546877.
[LWJGL(2013)] LWJGL. Lightweight Java Game Library, 2013. URL http://lwjgl.

org/.
[Mercedesclass.net(2013)] Mercedesclass.net. Mercedes - driving simulator, 2013.

URL http://www.mercedesclass.net/safety-2/driving-simulator-2/
driving-simulator/.
[Oktal(2013)] Oktal. Oktal simulators, 2013. URL http://www.oktal.fr/en/

automotive/simulators-operational-needs.
[OpenDS(2013)] OpenDS. OpenDS, 2013. URL http://opends.eu/.
[Oracle(2013)] Oracle. Java, 2013. URL http://www.java.com/en/.
[OSS(2013a)] OSS. OSS simulator website, 2013a. URL http://www.

transportationtechnologyventures.com/simwiki/index.php?title=Main_
Page.
[OSS(2013b)] OSS. Driving simulators overview, 2013b. URL http://www.

transportationtechnologyventures.com/simwiki/index.php?title=Other_
Simulators.
[RoyalAcademy(2013)] RoyalAcademy. Scientific Background on the Nobel Prize in

Chemistry 2013 DEVELOPMENT OF MULTISCALE MODELS FOR COMPLEX
CHEMICAL SYSTEMS. Technical report, The Royal Swedish Academy of Sciences,
2013. URL http://www.nobelprize.org/nobel_prizes/chemistry/laureates/
2013/advanced-chemistryprize2013.pdf.
[RVO2(2011)] RVO2. RVO2 Library, 2011. URL http://gamma.cs.unc.edu/RVO2/.
[Schaefer(2011)] Martin Schaefer. Noncooperative collision avoidance of road vehicles,

2011.
[Snape and van den Berg(2011)] Jamie Snape and J van den Berg. The hybrid reciprocal
velocity obstacle. . . . , IEEE Transactions on, 27599(October):1–11, 2011. URL
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5746538.
BIBLIOGRAPHY 46
[Tass(2013)] Tass. PreScan, 2013. URL https://www.tassinternational.com/

prescan.
[Toyota(2013)] Toyota. Toyota - Driving simulator, 2013. URL http://www.

toyota-global.com/innovation/safety_technology/safety_measurements/
driving_simulator.html.
[Unity(2013)] Unity. Unity Engine, 2013. URL http://unity3d.com/unity.
[van den Berg and Manocha(2008)] Jur van den Berg and Dinesh Manocha. Recip-
rocal Velocity Obstacles for real-time multi-agent navigation. 2008 IEEE Inter-
national Conference on Robotics and Automation, pages 1928–1935, May 2008.
doi: 10.1109/ROBOT.2008.4543489. URL http://ieeexplore.ieee.org/lpdocs/
epic03/wrapper.htm?arnumber=4543489.
[Vires(2013)] Vires. Vires, 2013. URL http://www.vires.com/Products_ToolChain.

htm.
[WHO(2013)] WHO. Global status report on road safety. 2013. URL http://www.who.
int/violence_injury_prevention/road_safety_status/2013/en/.
[Yu et al.(2012)Yu, Gong, Iagnemma, Jiang, and Duan] Hongxiao Yu, Jianwei Gong,
Karl Iagnemma, Yan Jiang, and Jianmin Duan. Robotic wheeled vehicle rip-
ple tentacles motion planning method. 2012 IEEE Intelligent Vehicles Sympo-
sium, pages 1156–1161, June 2012. doi: 10.1109/IVS.2012.6232292. URL http:
//ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6232292.
Appendix A
Protocol Buffers - SIMPLAN

protocol
message Header{
required fixed32 size = 1;
}
message Message {
// One of the following will be filled in.
optional Update update = 1;
optional Plans plans = 2;
optional Init init = 3;
}
message Update {
required double updateTime = 1;
repeated Vehicle_update updates = 2;
}
message Vehicle_update{
required Vector position = 2;
required Vector velocity = 3;
optional int32 lane = 8; // number of lane from right to left
I
APPENDIX A. PROTOCOL BUFFERS - SIMPLAN PROTOCOL II
optional double acceleration = 9; // meters per second^2

}
message Plans {
required double timestamp = 1;
repeated Plan plans = 2;
}
message Plan {
repeated Action actions = 2;
}
message Action{
optional Maneuver maneuver = 1;

optional Waypoint waypoint = 2;
optional Actuators actuators = 3;
}
message Maneuver {
required double speed = 1;
required int32 lane = 2;
required double duration = 3;
}
message Waypoint{
required Vector position = 1;
required double speed = 2;
}
message Actuators{
optional double steer = 1;
optional double gas = 2;
APPENDIX A. PROTOCOL BUFFERS - SIMPLAN PROTOCOL III
optional double brake = 3;

optional double duration = 4;
}
Appendix B
Contents of attached CD
B.1 Sources
Sources of implemented system and other software used in the thesis is provided on the
attached CD.
B.2 Videos
All the videos are provided on the attached CD in the videos folder.
IV

Thes 448

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Thes 448

Transféré par

Droits d'auteur :

Formats disponibles

CZECH TECHNICAL UNIVERSITY

Collision Avoidance of Highway Traffic

Prague, 2014 Author: Bc. Martin Schaefer

2.1 Driving Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1 Simplifed System Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Simulator setting for the driving experiments . . . . . . . . . . . . . . . . 31

5.1 Screenshots of the simulation . . . . . . . . . . . . . . . . . . . . . . . . 42

2. Analyze possibilities of a selected technique for dynamic planning with uncertain

3. Implement the selected techniques in a drive assistance system in a simulator.

4. Implement the extension and experimentally evaluate.

1.1.1 Additional Requirements

2. The algorithms of the strategies should be experimentally evaluable via simulation.

3. The collision avoidance technique implementation should not be dependent on the

4. Specifically driving simulators are considered to be used. The driving simulators

8. Proof-of-concept experiments with a driver should reveal possibilities of user testing

1.1.2 Highway Domain

1.3 Thesis Organization

2.1.1 Driving Simulators

(a) Toyota High-end Simulator (b) Oktal Compact Simulator

Figure 2.1: Driving Simulators

2.1.2 Sensor Simulation

2.2 Collision Avoidance

2.2.1 Velocity Obstacles

CCA,B = {vA,B | λA,B ∩ B̂ 6= ∅}, (2.1)

Figure 2.2: Collision Cone [Fiorini and Shiller(1998)]

Then the Velocity Obstacle of A induced by the obstacle B is defined as a Minkowski

V OA|B = CCA,B ⊕ vB = {c + vB | c ∈ CCA,B } (2.2)

Figure 2.3: Velocity Obstacle [Fiorini and Shiller(1998)]

We introduced a velocity obstacle that represents a static or dynamic obstacle for A.

V OA = ∪o∈M V OA,o (2.3)

2.2.2 Reciprocal Velocity Obstacles

2.2.3 Optimized Reciprocal Collision Avoidance

Figure 2.4: Geometry construction of Velocity Obstacle [Berg

opt opt opt opt

2.2.4 ORCA-based Methods for Non-Holonomic Robots

2.2.5 Non-Homogeneous Non-Linear Reciprocal Collision

Steering vehicle HMI

Figure 3.1: Simplifed System Architecture

3.1.1 Traffic in OpenDS

Figure 3.2: Follow Box

3.2 Collision Avoidance Module

Figure 3.3: Alite - simplified agent simulation [ATG(2013b)]

3.2.2 Agent Implementations

3.2.2.1 ORCA Agent

Figure 3.4: ORCA Agent operation

the principle of the ORCA agent’s operation.

3.2.2.2 SafeDistance Agent

try first maneuver to maneuver to

try next yes

Figure 3.5: Safe distance method - control loop

Maneuvers are designed to correspond basic maneuvers needed to drive on a highway.

Safe Maneuver Conditions

Figure 3.6: Safe distance method - critical distance

maneuver to be critical Operating

Figure 3.7: Safe distance method - critical distance - lane change

satisfied so we can say a maneuver is safe. The conditions are following:

vA1 . . . velocity of the rear vehicle at the end of the maneuver at t0 + TS

vB0 . . . velocity of the front vehicle at t0

3.3 Collision Avoidance and Simulator Integration

Figure 3.8: OpenDS - Highway platform integration scheme ( FB = Follow

3.3.1.1 Protocol Buffers

developer with easy-to-use interface to configure desired communicator instance (e.g.

3.3.1.2 Communication Protocol