final project report a 3d simulation environment for ...endler/students/... · this project...

Final project report

A 3D SIMULATION ENVIRONMENT FOR COORDINATION

AMONG AUTONOMOUS VEHICLES

Marcelo Paulon J. V.∗

Pontifıcia Universidade Catolica do Rio de Janeiro (PUC-Rio)

Advisor: Markus Endler

July 2018

Keywords: autonomous vehicles, simulator, testing environment, connected

vehicles, smart city, vehicle-to-vehicle, V2V, vehicle-to-infrastructure, V2I, vehicle-

to-everything, V2X, movement coordination

Abstract

Over the last years, the automotive industry has advanced significantly to-

wards a future without human drivers. Researchers are currently trying to over-

come the technological, political and social challenges involved in making au-

tonomous vehicles mainstream. These vehicles need to be safe, reliable and

cost-efficient. Connecting them and creating coordination mechanisms could

help in achieving these goals.

This project proposes a simulation environment where coordination proto-

cols can be evaluated (AVCP-Sim) and a vehicle-to-everything (V2X) coordi-

nation protocol for autonomous vehicles (AVCP: Autonomous Vehicle Coordi-

nation Protocol).

The AVCP-Sim aims to simulate multiple autonomous vehicles and different

traffic conditions, while also providing a message exchange system which can

be used to implement movement coordination protocols.

The AVCP protocol aims to significantly reduce travel time and increase

safety for autonomous vehicles by enabling them to exchange sensing and

routing information with each other and with roadside units (RSUs).

The AVCP-Sim was tested by implementing the AVCP protocol’s messages

and some of its movement coordination rules.

∗Electronic address: [email protected]

1

Contents

1 Introduction 6

2 Autonomous vehicle movement coordination - benefits and usage sce-

narios 7

2.1 Scenario 1: emergency lane changes . . . . . . . . . . . . . . . . . 7

2.2 Scenario 2: early obstacle avoidance . . . . . . . . . . . . . . . . . . 7

2.3 Scenario 3: temporary stops . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Scenario 4: junctions and intersections . . . . . . . . . . . . . . . . . 8

2.5 Scenario 5: emergency vehicles . . . . . . . . . . . . . . . . . . . . 8

2.6 Scenario 6: pile-up avoidance . . . . . . . . . . . . . . . . . . . . . . 8

3 Related work 8

4 Proposal and objectives 10

5 Schedule summary (timeline) 11

6 Schedule details 12

6.1 Phase 1: July 1, 2017, to September 30, 2017

Simulator+AI research . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.2 Phase 2: October 17, 2017, to November 05, 2017

Simulator+AI preparation . . . . . . . . . . . . . . . . . . . . . . . . 12

6.3 Phase 3: November 06, 2017, to November 16, 2017

Research on vehicle-to-vehicle coordination protocols . . . . . . . . 12

6.4 Phase 4: November 17, 2017, to December 05, 2017

AVCP protocol draft . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6.5 Phase 5: December, 2017

Final presentation of the project proposal . . . . . . . . . . . . . . . 12

6.6 Phase 6: December 06, 2017, to January 31, 2018

Proof of concept - development of the AVCP-Sim / integration with

the chosen self-driving car simulator . . . . . . . . . . . . . . . . . . 13

6.7 Phase 7: February 1, 2018, to February 7, 2018

Simulation execution and measurements . . . . . . . . . . . . . . . 13

2

6.8 Phase 8: February 8, 2018, to April 8, 2018

Optimizations on the AVCP specification . . . . . . . . . . . . . . . . 13

6.9 Phase 9: April 9, 2018, to May 15, 2018

Implementation of the revised AVCP specification . . . . . . . . . . . 13

6.10 Phase 10: May 16, 2018, to May 26, 2018

Simulation execution and measurements . . . . . . . . . . . . . . . 13

6.11 Phase 11: May 27, 2018, to June 30, 2018

Continuous improvements on the AVCP and the simulator . . . . . . 13

6.12 Phase 12: July 20, 2018

Final presentation of the project . . . . . . . . . . . . . . . . . . . . . 13

7 Simulator/AI research 14

7.1 Initial research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7.2 Detailed comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

7.3 F Udacity’s Self-Driving Car Simulator [17] . . . . . . . . . . . . . . 17

7.3.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.2 Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.4 Graphical Interface . . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.5 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.6 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.7 Autonomous driving . . . . . . . . . . . . . . . . . . . . . . . 17

7.3.8 Multi-core simulation . . . . . . . . . . . . . . . . . . . . . . . 17

7.4 Autoware, by Tier IV [18] . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.4.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.4.2 Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

7.4.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18


7.4.5 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

7.4.6 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19



7.5 Veins - Vehicular network simulation framework [27] . . . . . . . . . 20

7.5.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7.5.2 Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3

7.5.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20


7.5.5 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7.5.6 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20



7.6 TORCS - The Open Racing Car Simulator [33] . . . . . . . . . . . . 21

7.6.1 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.6.2 Sensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.6.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21


7.6.5 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

7.6.6 Licensing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22



7.7 Choosing the simulator . . . . . . . . . . . . . . . . . . . . . . . . . 22

8 AVCP Protocol 23

9 AVCP-Sim: implementation report 27

9.1 Udacity’s Self-Driving Car Simulator state . . . . . . . . . . . . . . . 27

9.1.1 Simulator interface (C# / Unity) . . . . . . . . . . . . . . . . . 27

9.1.2 Path planner/controller (C++) . . . . . . . . . . . . . . . . . . 28

9.2 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9.2.1 Controlling multiple cars on the road . . . . . . . . . . . . . . 29

9.2.2 Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

9.2.3 Vehicle communication . . . . . . . . . . . . . . . . . . . . . 30

9.3 Testing and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

10 Alternatives to measuring coordination protocols 31

11 Limitations 31

12 Challenges and difficulties 32

13 Future work 33

14 Conclusion 34

4

15 Appendix A: AVCP protocol 35

15.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

15.2 Syntax specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

15.2.1 File format and encoding . . . . . . . . . . . . . . . . . . . . 35

15.2.2 Vehicle/OBU Messages . . . . . . . . . . . . . . . . . . . . . 35

15.2.3 Controller/RSU Messages . . . . . . . . . . . . . . . . . . . . 36

15.2.4 Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

15.2.5 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

15.2.6 CruiseInformation . . . . . . . . . . . . . . . . . . . . . . . . 39

15.3 Behavior/Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5

1 Introduction

Automobile manufacturers such as Ford, General Motors, Tesla, and other

companies such as NVIDIA are investing billions of dollars in autonomous vehicle

driving research. According to Intel, by 2050, this fast-growing industry will be worth

$ 7 trillion [29]. Governments of countries in Europe and of the USA are creating

regulations for self-driving cars, as a result of the latest advances in the industry.

The benefits of fully autonomous vehicles can go way beyond removing the

need for a human driver. Transportation services such as Uber will start using self-

driving cars instead of human drivers and might become a cheaper and better alter-

native for end consumers than owning a car. This will represent a shift on the way

cities are planned, as fewer parking places will be needed, and most importantly,

in a smart city with most of its vehicles being connected and autonomous, traffic

optimization will be able to be heavily applied by coordinating movement. This will

result in a major decrease in travel time, and it will also save lives as emergency

services will be able to reach their destinations faster.

In contrast, there are many problems that need to be addressed regarding

autonomous vehicles. Tesla’s car autopilot first fatal crash in 2016 [12], for ex-

ample, brought up discussions about reliability, safety and legal liability regarding

autonomous vehicles among researchers. Other important topics, such as secu-

rity and transparency will need to be heavily discussed as these vehicles become

mainstream.

Another problem with this relatively new field is the lack of data sharing be-

tween vehicles. Autonomous vehicles are complex systems that rely heavily on

technologies such as LIDAR, GPS, high-definition maps, and artificial intelligence

for navigation and collision avoidance. This means that each autonomous vehicle

is constantly collecting and analyzing a very high volume of data, which according

to Intel is about 2.6 terabytes per hour [31]. If this data was shared between the

vehicles it could be used for coordinating movement, which could increase safety

and also optimize traffic on cities and highways.

This project focused on the creation of a simulation environment for move-

ment coordination among autonomous vehicles (which we called AVCP-Sim). The

idea is to simulate multiple autonomous vehicles and different traffic conditions,

while also providing a message exchange system which can be used to implement

6

movement coordination protocols.

2 Autonomous vehicle movement coordination - benefits

and usage scenarios

In this section, we will present possible scenarios of autonomous vehicle

movement coordination, and what benefits they would bring regarding traffic and

security.

2.1 Scenario 1: emergency lane changes

Whether on highways or two-lane roads it may happen that an obstacle will

suddenly require a lane change, for example, when an animal crosses the road,

or when a landslide occurs. This sudden lane change may represent a dangerous

situation, as it is possible that the vehicles in the other lane are approaching from

behind in a much higher speed.

By broadcasting a sudden lane change event for the vehicles behind, they

will be able to reduce their speed faster, before they can visually detect the car

changing lanes, reducing the risk of an accident.

2.2 Scenario 2: early obstacle avoidance

Obstacles such as boulders, broken vehicles, or road work can cause mas-

sive traffic as they usually involve obstructing an entire lane. On roads without

closed lane signals, by broadcasting the detection of an obstacle on the lane, the

vehicles behind would be able to change lanes before reaching the obstacle, re-

ducing traffic.

2.3 Scenario 3: temporary stops

Cars and buses can stop to pick up/drop passengers for short periods of time.

As in the last example, this could also increase traffic. These vehicles could send

a notification that they will stop for a short period of time, allowing vehicles that are

approaching from behind to decide whether or not to change lanes based on their

location and on how much time the vehicle is going to be stopped.

7

2.4 Scenario 4: junctions and intersections

There are many mathematical models for optimizing traffic in junctions and

intersections. These models could be optimized by making vehicles that are able

to coordinate their movement.

2.5 Scenario 5: emergency vehicles

An emergency vehicle could broadcast its presence for vehicles ahead so that

they could change lanes early to give priority to it. This will make the emergency

vehicles reach their destinations faster, something that could save lives.

2.6 Scenario 6: pile-up avoidance

In the unfortunate event of an accident, vehicles could broadcast a car crash

notification that will make vehicles approaching from behind reduce their speed,

decreasing the risk of a pile-up. Also, this will allow the other vehicles to reroute,

which may reduce the traffic generated by the accident.

3 Related work

Vehicular networks, both centralized and ad hoc (VANET), can highly improve

efficiency and safety for transportation. There are many challenges involved in

designing such networks, from concurrency and safety problems to high cost and

lack of standardization. Surveys such as [6] [24] map the different approaches that

are being researched in this field.

The article [20] propose the use of intelligent traffic lights (ITLs) on cross-

roads. These devices could gather traffic information such as traffic density, and

share it with the nearby vehicles so that they can choose a route with less traf-

fic. In case of an accident, the ITLs could also send warning messages to nearby

vehicles, which would prevent other collisions.

Work done in [9] propose using an RSU to manage traffic on intersections.

These RSUs, called intersection managers, can implement different policies but op-

erate on a common protocol proposed by the authors for managing reservations for

traversing the intersection. The vehicles can make, change, or cancel a reservation,

and it is up to the intersection managers to confirm, reject or call for emergency-

stops. The managers can also propose a counter-offer (crossing the intersection

8

through a different lane, for example). The authors claim that by having an RSU

all the information between the agents goes through one reliable and monitorable

channel.

The article [1] propose an interesting use for VANETs: infotainment and inter-

active applications and multi-hop Internet access. The authors address the problem

of high data volume and the consequent increase on communication delay, by giv-

ing low preference to more densely crowded routes.

The articles mentioned above have direct or indirect RSU involvement. The

work [2] addresses the high cost of having a centralized authority for efficiently

coordinating traffic for autonomous vehicles. The authors propose using formal

methods to verify the safety and correctness of a collaborative and decentralized

coordination protocol. They claim that vehicles using this protocol do not need to

fully agree on a shared state, by using a resource reservation protocol (CwoRIS

[26]) to collaboratively negotiate access to the intersection.

In [32], a protocol for vehicle merging on vehicular ad hoc networks (VANETs)

is proposed. This protocol calculates the other vehicles future positions instead

of using their current position, to support Cooperative Adaptive Cruise Control

(CACC).

The article [28] introduces the Veins [27] simulator and addresses some of the

issues of creating realistic simulations for VANETs. The author claims that many

simulators do not take into account driver behavior or characteristics of the urban

environment such as traffic lights and merge lanes. One of the examples used in a

proof-of-concept for Veins was early obstacle avoidance, described in section 2.2.

The Veins simulator does not integrate with path planning systems for autonomous

vehicles, which was one of the reasons why it was not chosen as a base for the

simulator we propose.

We chose the Udacity’s Self-Driving Car Simulator [17] (USDCS) as a starting

point for the AVCP-Sim. USDCS is a self-driving car 3D simulator that is used by

researchers to develop from lane keeping models to path planning systems. We

will discuss USDCS, Veins and other simulators in further sections.

9

4 Proposal and objectives

In this project, we propose creating a protocol (AVCP) that specifies how

autonomous cars can share their sensor data and use this information to collabo-

ratively optimize traffic and increase safety, without needing a central server. The

idea is to propose a standard set of messages for cars and RSUs, and rules for

their behavior. These rules take into account, for each vehicle, its received mes-

sages, its intent (e.g. avoid an obstacle, turn left in an intersection), and its sensing

information.

The tests for the AVCP protocol were performed on a simulated environment,

a virtual smart city where all vehicles are autonomous. We simulated some of the

scenarios described in section 2, using simulated self-driving cars, and tested their

navigation with and without the protocol being used to support each car’s decisions.

Thus, in addition to developing the AVCP specification, we created the sim-

ulation environment for the protocol. This involved modifying an autonomous car

driving simulator to use the protocol. The chosen simulator was written using the

C# programming language and the Unity 3D engine, and the path planner that con-

trols the autonomous car was written using the C++ programming language. The

simulator was modified to support controlling multiple autonomous cars, and the

path planner was modified to support the communication between them.

In short, the main goals of the project were:

• develop the AVCP protocol specification

• develop a simulation environment where cars can use the AVCP protocol to

communicate

• assess if by using the AVCP protocol the mean travel time of the vehicles is

reduced

We will discuss alternatives to travel time measurement for evaluating the

AVCP and other coordination protocols, such as distance driven, brakes usage and

tires stress, in section 10. We have added support for distance driven assessment

in the simulator.

10

5 Schedule summary (timeline)

Table 1: Schedule summary (timeline)

Time period Task description Deliverable

1 Jul 1-Sept 30, 2017 Simulator+AI research Research report

2 Oct 1-Nov 05, 2017 Simulator+AI preparation Implementation

report and code

3 Nov 06-16, 2017 Research on vehicle-to-vehicle

coordination protocols

Research report

4 Nov 17-Dec 05, 2017 AVCP protocol draft Specification

5 December, 2017 Final presentation of the project

proposal

Slideshow

6 Dec 06-Jan 31, 2018 Proof of concept - development

of the AVCP-Sim / integration

with the chosen self-driving car

simulator

Implementation

report and code

7 Feb 1-7, 2018 Simulation execution and mea-

surements

Testing report

8 Feb 8-Apr 8, 2018 Optimizations on the AVCP

specification

Implementation

report

9 Apr 9-May 15, 2018 Implementation of the revised

AVCP specification

Implementation

report

10 May 16-26, 2018 Simulation execution and mea-

surements

Testing report

and Paper

11 May 27-Jun 30, 2018 Continuous improvements on

the AVCP and the simulator

Implementation

report and Speci-

fication

12 July 20, 2018 Final presentation of the project Slideshow

11

6 Schedule details

6.1 Phase 1: July 1, 2017, to September 30, 2017

Simulator+AI research

Decide which open-source simulator and AI will be used to develop the project

and test the protocol.

6.2 Phase 2: October 17, 2017, to November 05, 2017

Simulator+AI preparation

Modify the simulator/AI to work in an online environment, allowing us to sim-

ulate multiple autonomous cars; Set up the environment where the simulations will

be performed.

6.3 Phase 3: November 06, 2017, to November 16, 2017

Research on vehicle-to-vehicle coordination protocols

Gather information about existing V2V standards that could inspire the AVCP

development.

6.4 Phase 4: November 17, 2017, to December 05, 2017

AVCP protocol draft

Create a draft of the protocol, containing the data format and simple criterion

that can be used to coordinate movement.

6.5 Phase 5: December, 2017

Final presentation of the project proposal

Showcase the problem, the simulator that is being used (and the modifica-

tions that were made to the original one), the initial protocol idea, the first proof of

concept that was made, and the planned next steps.

12

6.6 Phase 6: December 06, 2017, to January 31, 2018

Proof of concept - development of the AVCP-Sim / integration with

the chosen self-driving car simulator

On the simulator, implement basic data transmission/reception and simple

criterion to coordinate movement.

6.7 Phase 7: February 1, 2018, to February 7, 2018

Simulation execution and measurements

Execute the simulations and analyze its results

6.8 Phase 8: February 8, 2018, to April 8, 2018

Optimizations on the AVCP specification

With the initial results of the simulations, we will be able to improve the AVCP

by elaborating on the movement coordination criterion.

6.9 Phase 9: April 9, 2018, to May 15, 2018

Implementation of the revised AVCP specification

Update AVCP-sim to implement the new movement coordination criterion.

6.10 Phase 10: May 16, 2018, to May 26, 2018

Simulation execution and measurements

Execute the simulations and analyze its results. We will write a paper for

a conference/journal, detailing AVCP, its implementation and the results that were

obtained.

6.11 Phase 11: May 27, 2018, to June 30, 2018

Continuous improvements on the AVCP and the simulator

6.12 Phase 12: July 20, 2018

Final presentation of the project

Introduce the latest specification of the AVCP and the results of the simula-

tions.

13

7 Simulator/AI research

7.1 Initial research

The initial research was performed using the Google search engine [14],

Google Scholar [13] and the GitHub [15] repository search.

The search queries used were some combinations of the following terms:

”autonomous vehicle”, ”testing environment”, ”simulator”, ”self-driving car”, ”vehicle

coordination”. Most of the searches returned 600k-900k results on Google, 5k-6k

results on Google Scholar, and fewer than 70 repositories on GitHub (most of them

forks from other repositories).

After analyzing the search results, the following projects were selected for

comparison, using relevance, popularity and licensing as criterion:

1. F Udacity’s Self-Driving Car Simulator [17]

2. Autoware, by Tier IV [18]

3. Veins - Vehicular network simulation framework [27]

4. TORCS - The Open Racing Car Simulator [33]

7.2 Detailed comparison

For comparing the selected projects, the following features/characteristics

were taken into account:

(i) Mapping: the project should be able to simulate vehicles, multi-lane roads and

obstacles on a map

(ii) Sensing: the project should be able to simulate vehicle sensor data necessary

for autonomous driving, that is, for a given vehicle, detect its own position,

speed, the other vehicles around it, and obstacles

(iii) API: the project should provide an API for controlling the vehicle, also providing

its sensor data. Ideally, the API should support controlling multiple vehicles on

the simulation

(iv) Graphical interface: the project should provide a graphical interface capable of

displaying multi-lane roads, obstacles, vehicles on movement, and occasional

lane changes and crashes

14

(v) Community: projects with larger developer communities are usually more reli-

able and stable, reducing the risks of using them

(vi) Licensing: the project should have an open license, that allows its use, modifi-

cation, and redistribution for the AVCP project, for free

(vii) Autonomous driving: the project should have existing examples/implementa-

tions of autonomous driving, to be used as a starting point for the AVCP testing

environment

(viii) Multi-core simulation: ideally, the project should have the ability to execute the

simulations using multiple CPU cores.

The table 2, on the next page, summarizes the research results, and the next

sections go into further detail on each project that was evaluated.

15

Tabl

e2:

Sum

mar

yof

the

rese

arch

resu

lts

Pro

ject

nam

eM

appi

ngS

ensi

ngA

PI

Gra

phic

al

Inte

rface

Com

mun

ityLi

cens

ing

Aut

onom

ous

driv

ing

Mul

ti-co

re

sim

ulat

ion

Uda

city

’sS

elf-

Driv

ing

Car

Sim

ulat

or

Yes.

Mul

ti-

lane

road

s,

othe

rve

hicl

es

and

obst

acle

s

Yes.

Vehi

cle’

s

info

rmat

ion.

Yes

3DYe

sM

ITYe

sYe

s

Aut

owar

e,by

Tier

IV

Yes.

Mul

ti-

lane

road

s,

othe

rve

hicl

es

and

obst

acle

s

Par

tial.

Dat

a

need

sto

be

colle

cted

from

real

sens

ors.

No

3DYe

sN

ew

BS

D

Yes

Yes

Vein

s-

Vehi

c-

ular

netw

ork

sim

ulat

ion

fram

ewor

k

Yes.

Mul

ti-

lane

road

s,

othe

rve

hicl

es

and

obst

acle

s

Yes.

Lane

num

ber,

dete

cted

ob-

stac

les

and

traffi

clig

hts

Yes

2DYe

sG

PL

Yes

No

TOR

CS

-Th

e

Ope

nR

acin

g

Car

Sim

ulat

or

Par

tial.

Mul

ti-

lane

road

san

d

othe

rveh

icle

s

Yes.

Vehi

cle’

s

info

rmat

ion.

Yes

3DYe

sG

PL

Yes

Yes

16

7.3 F Udacity’s Self-Driving Car Simulator [17]

7.3.1 Mapping

The simulator already has examples of obstacles, multi-lane roads, and other

vehicles on the map.

7.3.2 Sensing

The simulator provides sensor fusion data that contains the other vehicle’s

information, including their speed and relative position. Non-vehicle obstacles in-

formation on sensor fusion would need to be implemented.

7.3.3 API

The simulator provides an API for controlling the vehicle, providing its sensor

data. There is no support for controlling multiple vehicles on the simulation.

7.3.4 Graphical Interface

The simulator provides a 3D graphical interface, capable of displaying multi-

lane roads, obstacles, vehicles on movement, and occasional lane changes and

crashes.

7.3.5 Community

The simulator has a growing community and has been updated frequently. It

is being used as the simulator for a self-driving car online course.

7.3.6 Licensing

The simulator has been released under the MIT License, which enables free

use, modification, and redistribution.

7.3.7 Autonomous driving

There are some implementations of autonomous driving using this simulator.

These implementations are publicly available on GitHub [15].

7.3.8 Multi-core simulation

The simulator takes advantage of multi-core processing.

17

Figure 1: Udacity self-driving car simulator

7.4 Autoware, by Tier IV [18]

7.4.1 Mapping

The project already has examples of obstacles, multi-lane roads, and other


7.4.2 Sensing

The project provides real sensor fusion data, but it requires previously col-

lected sensor data to be used as a simulator.

7.4.3 API

There is no API information on the documentation.


The project provides a very rich 3D graphical interface, capable of displaying

multi-lane roads, obstacles, vehicles on movement, and occasional lane changes

and crashes.

18

Figure 2: Autoware, by Tier IV

7.4.5 Community

The project is under active development and has a very wide community of

both companies and hobbyists that use it for simulation and field testing.

7.4.6 Licensing

The project has been released under the New BSD License, which enables

free use, modification, and redistribution.


There are several implementations of autonomous driving using the project,

most of them using a real car.



19

7.5 Veins - Vehicular network simulation framework [27]

7.5.1 Mapping

The project already has examples of obstacles, multi-lane roads, and other


7.5.2 Sensing

The simulator provides information about the vehicle’s current position, lane

number, detected obstacles and traffic lights.

7.5.3 API

The simulator provides an API for the graphical interface and a Traffic Con-

trol Interface (TraCI) that allows different commands such as changing traffic lights

states, changing routes and vehicle states.


The simulator provides a simple 2D graphical interface, capable of displaying

multi-lane roads, obstacles, vehicles on movement, and occasional lane changes

and crashes.

7.5.5 Community

The project is under active development and has been updated frequently.

7.5.6 Licensing

The project has been released under the GPL License, which enables free



The simulator can execute predefined VANET models, and it is possible to

change the simulation while it is running.


The simulator does not use multi-core processing.

20

Figure 3: Veins - Vehicular network simulation framework

7.6 TORCS - The Open Racing Car Simulator [33]

7.6.1 Mapping

The simulator already has examples of multi-lane roads, and other vehicles

on the map, but no examples of obstacles that aren’t vehicles.

7.6.2 Sensing

The simulator provides other vehicle’s information, including their speed and

relative position. Non-vehicle obstacles information on sensor fusion would need to

be implemented.

7.6.3 API

The simulator allows multiple ”robots” to be attached to it, via dynamic-link

libraries (Windows) or shared objects (Linux). The API allows access to the map,

car position, and other opponent’s position


The simulator provides a 3D graphical interface, capable of displaying multi-

lane roads, obstacles, vehicles on movement, and occasional lane changes and

crashes.

7.6.5 Community

The simulator has a large developer community, and it promotes a large an-

nual online contest for developers to build car agents that will race against each

21

Figure 4: TORCS - The Open Racing Car Simulator

other.

7.6.6 Licensing

The project has been released under the GPL License, which enables free



There are some implementations of autonomous driving using the project,

such as [5] and [11].



7.7 Choosing the simulator

After analyzing the four simulators, the Udacity’s Self-Driving Car Simulator

was chosen as a base for implementing the AVCP testing environment. Feature-

wise, one of the best options were the Veins simulator, but Udacity’s simulator sim-

plicity and extensibility for more realistic self-driving implementations were consid-

ered more relevant.

22

8 AVCP Protocol

The AVCP (Autonomous Vehicle Coordination Protocol) is an intent-based

(similar to an asynchronous Publish/Subscribe communication model) vehicle-to-

everything (V2X) coordination protocol. It aims to reduce travel time and increase

safety by enabling self-driving vehicles to exchange sensing and routing information

with each other and with RSUs (roadside units, such as intelligent traffic lights and

intersection managers).

For example, a route intention, such as stopping at a place to pick up a pas-

senger, would be broadcast by the vehicle so that the vehicles behind can decide

early whether or not to change lanes. Sensing information, such as an obstacle

detection (e.g. street work, broken vehicle) would also be broadcast and used by

vehicles behind to improve their navigation. A scenario that involves the cars ahead

would be an emergency vehicle requesting priority. In this case, the cars ahead

would give way to the emergency vehicle, so that it arrives faster at its destination.

These and other scenarios that the protocol might come into use are described in

section 2.

Each message contains the vehicle unique identifier (UID), the AVCP version,

the type of vehicle (land, air or sea), its length and width, its location (GPS coor-

dinates - latitude/longitude and altitude when it’s an air vehicle), its heading and

speed information.

The messages sent by vehicles to other vehicles or controllers (RSUs) nearby

can be of the following types:

• ”emergency”: an incident occurred that should make vehicles nearby take

emergency procedures defined by the manufacturer (e.g.: find an alternative

route, reduce speed)

• ”short-stop”: the vehicle will stop at a specific location for a short period of

time. Vehicles nearby can decide whether they should change lanes or not,

according to their distance.

• ”request”: a request for information of a nearby controller (e.g.: smart traffic

light). The controller will respond only if necessary, by verifying the location

of the vehicle that was sent on the request. The vehicle will send this request

whenever it detects that a controller can be available to support its decisions

23

(e.g.: when a car is approaching an intersection). The vehicle’s destination

must be provided in this message.

• ”avoidObstacle”: the vehicles behind should avoid the detected obstacle’s

location (specified on the message).

• ”priority”: the vehicle has priority thus the vehicles ahead should give it pref-

erence. The vehicle’s authority must be validated using the digital signature

of the message. Each manufacturer must update the list of valid authorities,

according to each country/region laws.

The messages sent by the controllers to vehicles nearby can be of the follow-

ing types:

1. ”proceed”: the vehicle can continue

2. ”change”: the vehicle must change its speed and/or direction. The new speed

and/or direction information must be provided in the message.

3. ”stop”: the vehicle should stop

4. ”emergency”: the vehicle should take emergency procedures defined by each

manufacturer (e.g.: a manufacturer can configure the vehicle to stop or to try

to find an alternative route depending on the controller distance)

The details and specifications of the messages are described in section 15.

The following rules define the behavior for vehicles and RSUs that are com-

pliant to the AVCP protocol:

24

Rule Conditions Effects

R1 vehicle detected an obstacle

on the road

send an ”avoidObstacle” message notify-

ing the others about the obstacle’s loca-

tion and avoid the obstacle

R2 vehicle stopped send a ”short-stop” message notifying the

others about its stop, and the time until it

will be stopped

R3 vehicle is an emergency vehi-

cle and needs priority

send a ”priority” request message every 5

seconds

R4 vehicle detected an emer-

gency state (e.g.: accident,

explosion, landslide)

broadcast an ”emergency” message ev-

ery 5 seconds until it avoids the emer-

gency. In case the emergency cannot be

avoided, the vehicle should make a full

stop, broadcasting both the emergency

and stop messages

R5 vehicle detected an intersec-

tion within 10 meters

send a ”request” message for any con-

trollers (RSUs) available to manage the

crossing

R6 vehicle received an ”avoidOb-

stacle” or ”emergency” mes-

sage, and the obstacle/emer-

gency is within its route

change lanes. If there are obstacles/e-

mergency events in all lanes, reroute

avoiding the obstacle, if possible. If not

possible to reroute, and the vehicle is

within 15 meters of the obstacle/emer-

gency, broadcast a stop intention (as the

vehicle won’t probably be able to proceed

further after 15 meters).

R7 vehicle received a ”short-

stop” message, and the

stopping vehicle still will

be stopped by the time the

vehicle is 10 meters behind it

change lanes to avoid it

25


R8 vehicle received a ”request”

message

ignore it, as it’s intended for an RSU

R9 vehicle received a ”priority”

message, is on the left lane,

and the vehicle requesting

priority is behind it

change lanes to give priority to the incom-

ing vehicle, if possible

R10 while approaching an inter-

section the vehicle received

a ”proceed” message by an

RSU, destined to its UUID

proceed on the intersection



a ”change” message by an


change lanes


section the vehicle received a

”stop” message by an RSU

stop, and make another request after 10

seconds

We have implemented all of the AVCP messages and the rules R1, R2, R3,

R4, R7, R8 and R9 in the AVCP-Sim, as a separate module that can be easily

modified/extended.

26

9 AVCP-Sim: implementation report

9.1 Udacity’s Self-Driving Car Simulator state

Udacity’s Self-Driving Car Simulator is available on Github [17] and it is used

worldwide by students enrolled on Udacity’s Self-Driving Car Engineer Nanode-

gree. The simulator was developed to enable students to test algorithms that are

used by car manufacturers such as Mercedes-Benz and Tesla Motors.

The project version that was chosen to be the base for the AVCP testing en-

vironment was the one that was used for the third project of Udacity’s nanodegree,

related to path planning. The code was located on the ”term3” branch. The goal

of this project was that students would create an algorithm capable of driving a car

along a highway with other vehicles, changing lanes when necessary and respect-

ing the speed limit.

The project consists of two main parts, which we will call client and server,

respectively:

1. the simulator interface [17], written in C# and using the Unity game engine

[30]

2. the path planning algorithm implementation [16], written in C++

9.1.1 Simulator interface (C# / Unity)

The simulator interface starts up with the car to be controlled positioned on a

two-way six-lane highway with other cars passing by. There is a button that enables

the ”Manual Mode”, in which the user can control the car manually using the arrow

keys. The project uses the RoadArchitect library [21] (that is able to generate com-

plex roads, bridges and tunnels in Unity) and the Unity3d SocketIO library [22] (for

WebSockets communications).

The data provided from the simulator to the C++ path planner/controller via a

”telemetry” event sent via WebSocket, according to the documentation [16]:

• ”x”: The car’s x position in map coordinates

• ”y”: The car’s y position in map coordinates

• ”s”: The car’s s position in frenet coordinates

27

• ”d”: The car’s d position in frenet coordinates

• ”yaw”: The car’s yaw angle in the map

• ”speed”: The car’s speed in MPH

• ”previous path x”: The list of x points previously given to the simulator

• ”previous path y”: The list of y points previously given to the simulator

• ”end path s”: The previous list’s last point’s frenet s value

• ”end path d”: The previous list’s last point’s frenet d value

• ”sensor fusion”: A 2d vector of sensor data about the cars nearby (car’s

unique ID, car’s x position in map coordinates, car’s y position in map co-

ordinates, car’s x velocity in m/s, car’s y velocity in m/s, car’s s position in

frenet coordinates, car’s d position in frenet coordinates).

The car received from the path planner a list of points (x,y) that it visited every

.02 seconds. The spacing of the points, in meters, determined the speed of the car.

9.1.2 Path planner/controller (C++)

The path planner needed to read a .csv file that contained the highway map

waypoints information.

The project [16] made available by Udacity contained only the skeleton code

that the students were to use to communicate with the simulator interface. Thus, it

was necessary to choose a solution from one of the nanodegree students, and re-

quest the author for authorization. The chosen solution [34] was used as a starting

point for developing the AVCP implementation.

The path planner was organized in the following classes:

• PathPlanner: path planning orchestrator

• Map: map waypoint information object

• Track: track information object (represented by a Spline)

• tools: helper functions and plotting utilities

28

The idea of this solution was basically to keep the car following the lane un-

til another car on the front was closer than the so-called ”secure distance”. This

secure distance got higher as the car speeded up, and when it was violated the

planner entered a state to change lanes. The software fitted a spline from the

current lane to the targeted lane to make a smooth transition.

9.2 Modifications

We performed the following modifications on Udacity’s Self-Driving Car Sim-

ulator, that resulted in the AVCP-Sim (available on GitHub [23] and released under

the MIT License):

9.2.1 Controlling multiple cars on the road

Udacity’s simulator was designed to support controlling only one vehicle at a

time, via Web Sockets communication between the Unity/C# interface (client) and

the C++ path planner/controller (server).

This modification involved changing the simulator’s client-server communica-

tion for ”telemetry” and for ”control” events. Both of them now contain an array with

the information for each car (and each car is assigned a UUID (v1), generated using

the sole library [25]).

9.2.2 Routing

Udacity’s simulator used a closed track, thus it could model the entire car tra-

jectory using spline interpolation. The AVCP testing environment needs to consider

intersections and multiple alternative paths, thus, we implemented a routing system

and added different goals for each car, such as arriving at a waypoint α or arriving

at another waypoint β.

The path planner execution originally read a static .csv file with the map way-

points information. We changed this mechanism for a more dynamic one, by cre-

ating an event of type ”mapData” sent by the simulator, that contained the map’s

waypoints information. We also changed the RoadArchitect library to support ex-

porting this data programmatically, which was a requirement for this dynamic map

modification.

Then, on the PathPlanner side, it was necessary to save the waypoints using

more efficient data structures. We stored the waypoints in a K-d tree [3], for fast

29

nearest neighbor search, using the nanoflann library [4]. The connections between

the waypoints were stored in a directed graph. After finding the nearest waypoint to

the car, the planner can now calculate the fastest route to its goal, using Dijkstra’s

algorithm [8]. Dijkstra’s algorithm implementation was based on an implementation

found on Quora [10].

After calculating the fastest route, the simulator uses the original Path Plan-

ner’s spline interpolation mechanism to guide the car through each of the route’s

waypoints.

9.2.3 Vehicle communication

Udacity’s simulator did not have any support for vehicle-to-vehicle (V2V) or

vehicle-to-infrastructure (V2I) communication, thus, it was necessary to implement

it.

We implemented the communication mechanism in the PathPlanner/Con-

troller, in C++. In each communication step between the server and the client (in

which the server receives localization and sensor information from each car), each

vehicle now receives and sends messages.

We used a K-d tree (implemented using the same library mentioned in section

9.2.2) to store the messages so that each vehicle can perform a fast radius search

for messages that were broadcast within a specified distance of its current location.

9.3 Testing and results

After performing the required modifications to the simulator and adding the

new features that were necessary to fulfill this research’s goals, we were able to:

• execute the original path planning solution using 25 vehicles being controlled

at the same time on a highway, with and without communications

• control one of the cars manually and trigger lane changes by the other vehi-

cles by moving to the front of them on the highway

• test vehicle routing on complex road networks, with multiple intersections and

bridges

• test multiple vehicles with different goals (different target destinations) on a

complex road network

30

• test message communication between vehicles using limited transmission

range

• implement the AVCP protocol messages and behaviors regarding obstacles,

integrated with the routing/path planning system

10 Alternatives to measuring coordination protocols

Apart from mean travel time, there are other criteria that can be used to mea-

sure coordination protocols. Chassis, battery (for electrical vehicles) and engine

stress, are examples of criterion that could be measured by the number of lane

changes, increases in speed (acceleration/jerk). Consumption metrics could also

be evaluated, such as distance driven, energy/fuel spent, and bandwidth usage.

Another possibility would be the brake usage, to assess the amount of stress im-

posed on the vehicle’s braking system.

Metrics for distance driven were implemented in the simulator (every car logs

the distance driven, in meters, and this information is available for use by the proto-

cols using the simulator), thus it can be used in future work as mentioned in section

13.

11 Limitations

This project did not consider many variables involved in vehicular commu-

nications such as radio interference, shadowing by static/moving obstacles and

message collisions, that the Veins [27] project supports.

The sensor data received by the server does not contain noise/sensor in-

terference, which are challenges that need to be dealt with in a real environment.

Although the AVCP protocol does have some fields related to precision in sensors,

such as the GPS maximum error, the implementation we made did not simulate

these possibilities.

31

12 Challenges and difficulties

The following challenges and difficulties were found during the execution of

the project:

• Lack of flexibility of both the simulator and the server to allow for the creation

of more complex routes.

• Difficulty in adapting the editor to modeling the map as a graph.

• Adding support to controlling multiple vehicles required changing the structure

of the RoadArchitect [21] library, the simulator, and the server/path planning

algorithm.

• As multiple car control increased the size of the messages, a hidden bug in

the original simulator’s implementation with WebSocket corrupted some of the

events exchanged between the simulator and the server.

• The version of Unity 3D engine [30] that was used to develop the project (Unity

2017.1) had an incompatibility with the JSON [19] parsing/serialization library

for operating systems in the Portuguese language, requiring us to modify this

library.

• Bugs were found in the RoadArchitect [21] library that compromised some of

the project’s use cases, making us need to fix some of them by modifying the

RoadArchitect library:

– intersections did not work correctly between roads with a different num-

ber of lanes.

– terrain data got corrupted each time the project was opened (there was

a serialization problem, that was fixed after we modified the library to

serialize terrain data to a JSON file instead of a custom binary file).

– assets (materials/textures) of the RoadArchitect library did not load cor-

rectly in the version that the simulator was originally published (2017.1),

and a rollback to the Unity 5.6 was not possible due to the fact that the

simulator was incompatible with it.

32

13 Future work

The project did not implement RSU communication, and it also did not com-

pare travel time with/without the protocol, due to unexpected increase on develop-

ment time to overcome the problems described in section 12. Both features would

be great contributions to this research, but they would require at least 3 months of

development time. Ideally, with RSU communication implemented (which would al-

low implementing centralized coordination protocols), every other coordination pro-

tocol could be simulated by the AVCP-Sim. This would help researchers to assess

the state of the art of coordination protocols.

Route sharing could be developed in the simulator so that protocols could

take advantage of analyzing the other vehicle’s routes more deeply (without de-

pending on them notifying about future intentions such as stops).

An interesting use case for self-driving car coordination is the formation of

convoys. By using vehicular communication/coordination, convoys could be opti-

mized to transport dozens of vehicles going to a common region/area of a map

faster. The AVCP protocol could be modified to handle this use case.

Random events such as accidents and animals/pedestrians crossing the road

could be added to the AVCP-sim, to avoid the need of programmatically adding

them to the scene (which consumes development time).

Many analyses could be made using logs from AVCP-Sim. One interesting

project would be to train a neural network to learn the behaviors/rules of a protocol

only by analyzing the AVCP logs of speed changing, lane changing, intersection

crossing, and message exchanging.

The AVCP-Sim has sensors that behave like cameras in the corners of each

vehicle. These sensor’s ”images” could also be shared between vehicles, to serve

as evidence in the event of an accident, for example.

33

14 Conclusion

Our initial main goal for this work was to develop and test a movement coor-

dination protocol that aimed to optimize traffic and increase safety for autonomous

vehicles. This protocol needed to be evaluated/benchmarked in a testing environ-

ment that simulates a virtual smart city where all vehicles are autonomous and are

able to communicate. We needed to develop this environment as we could not find

a simulator that met the quality criterion we discussed in section 7.2.

Due to the complexity of implementing the simulation environment, which

involved subjects such as computer graphics, networking, software engineering,

graph algorithms and probabilistic data structures, the implementation itself that we

made became the main subject and the main contribution of this work.

In summary, we discussed application scenarios for self-driving vehicles com-

munication, compared existing simulators for self-driving vehicles (assessing that

none of them were suitable for this research’s goals), developed a new simulator

(AVCP-Sim) that is able to simulate self-driving cars movement coordination in a 3D

environment, proposed a coordination protocol (AVCP protocol) and tested some

of its behavior using the AVCP-Sim.

This project was released under the MIT License, on GitHub [23], and hope-

fully will inspire, be used and modified by other researchers to develop, test and

improve autonomous vehicles movement coordination protocols.

34

15 Appendix A: AVCP protocol

15.1 Definitions

• UUID: Universal Unique Identifier

• OBU: On-Board Unit, a device inside the vehicle that allows its wireless com-

munication with other OBUs and RSUs

• RSU: Road-Side Unit, a device on the roadside that communicates with OBUs

15.2 Syntax specification

15.2.1 File format and encoding

Every AVCP payload must be in the ECMA-404 / JavaScript Object Notation

(JSON) format [19]. The data should be encoded using UTF-8 without BOM (byte

order mark) and can be compressed using gzip [7]. For security purposes, only

digitally-signed requests should be accepted, signed by each manufacturer.

15.2.2 Vehicle/OBU Messages

1 {

2 "uuid": String,

3 "avcpVersion": "1.0.0",

4 "operationType": OperationType,

5 "lengthMeters": Double,

6 "widthMeters": Double,

7 "cruiseInformation": CruiseInformation,

8 "location": Location,

9 "vehicleMessageType": VehicleMessageType

10 }

Notes:

1. The UUID must be unique for each vehicle

2. It is recommended that each manufacturer prefix it with its name (e.g.: ”ManufacturerName-

ABCXYZ123QWERTY”)

35

15.2.3 Controller/RSU Messages

1 {

2 "uuid": String,

3 "operationType": OperationType,

4 "location": Location,

5 "controllerMessageType": ControllerMessageType,

6 "toUUID": String

7 }

Notes:

1. The UUID must be unique for each controller

2. It is recommended that each manufacturer prefix the UUID with its name (e.g.:

”ManufacturerName-ABCXYZ123QWERTY”)

3. ”toUUID” can be a wildcard ”*” to match any vehicle UUID

15.2.4 Structures

15.2.4.1 VehicleMessageType

There are 5 types of messages that can be sent by vehicles:

1. Emergency: an incident occurred that should make vehicles nearby take

emergency procedures defined by the manufacturer (e.g.: find an alternative

route, reduce speed).

1 {

2 "action": "emergency"

3 }

2. Short stop: the vehicle will stop at a specific location for a short period of

time. Vehicles nearby can decide whether they should change lanes or not,

according to their distance.

1 {

2 "action": "short -stop",

3 "currentTimestampUnixGMT": Long,

4 "timeoutMilliseconds": Long

36

5 }

3. Request: a request for information of a nearby controller (e.g.: smart traffic

light). The controller will respond only if necessary, by verifying the location

of the vehicle that was sent on the request. The vehicle will send this request

whenever it detects that a controller can be available to support its decisions

(e.g.: when a car is approaching an intersection).

1 {

2 "action": "request",

3 "destination": Location

4 }

4. Avoid obstacle: the vehicles behind should avoid the detected obstacle’s lo-

cation.

1 {

2 "action": "avoidObstacle",

3 "obstacleLocation": Location

4 }

5. Priority: the vehicle has priority thus the vehicles ahead should give it pref-

erence. The vehicle’s authority must be validated using the digital signature

of the message. Each manufacturer must update the list of valid authorities,

according to each country/region laws.

1 {

2 "action": "priority"

3 }

15.2.4.2 ControllerMessageType

There are 4 types of messages that can be sent by controllers:

1. Proceed: the vehicle can continue

1 {

2 "action": "proceed"

3 }

37

2. Change: the vehicle must change its speed and/or direction

1 {

2 "action": "change",

3 "cruiseInfo": CruiseInfo

4 }

3. Stop: the vehicle should stop

1 {

2 "action": "stop"

3 }

4. Emergency: the vehicle should take emergency procedures defined by each

manufacturer (e.g.: a manufacturer can configure the vehicle to stop or to try

to find an alternative route depending on the controller distance)

1 {

2 "action": "emergency"

3 }

15.2.4.3 OperationType

Land operation:

1 "land"

Sea operation:

1 "sea"

Air operation:

1 "air"

15.2.5 Location

Land and sea operation:

1 {

2 "latitude": Double,

38

3 "longitude": Double,

4 "gpsMaximumErrorMeters": Double

5 }

Air operation:

1 {

2 "latitude": Double,

3 "longitude": Double,,

4 "gpsMaximumErrorMeters": Double,

5 "altitudeMeters": Double,

6 "altitudeMaximumErrorMeters": Double

7 }

15.2.6 CruiseInformation

Land and sea operation:

1 {

2 "speedMetersPerSecond": Double,

3 "headingDegrees": Double

4 }

Air operation:

1 {

2 "speedMetersPerSecond": Double,

3 "headingDegrees": Double,

4 "verticalSpeedMetersPerSecond": Double

5 }

39

15.3 Behavior/Rules


R1 vehicle detected an obstacle

on the road

send an ”avoidObstacle” message notify-

ing the others about the obstacle’s loca-

tion and avoid the obstacle

R2 vehicle stopped send a ”short-stop” message notifying the

others about its stop, and the time until it

will be stopped

R3 vehicle is an emergency vehi-

cle and needs priority

send a ”priority” request message every 5

seconds

R4 vehicle detected an emer-

gency state (e.g.: accident,

explosion, landslide)

broadcast an ”emergency” message ev-

ery 5 seconds until it avoids the emer-

gency. In case the emergency cannot be

avoided, the vehicle should make a full

stop, broadcasting both the emergency

and stop messages

R5 vehicle detected an intersec-

tion within 10 meters

send a ”request” message for any con-

trollers (RSUs) available to manage the

crossing

R6 vehicle received an ”avoidOb-

stacle” or ”emergency” mes-

sage, and the obstacle/emer-

gency is within its route

change lanes. If there are obstacles/e-

mergency events in all lanes, reroute

avoiding the obstacle, if possible. If not

possible to reroute, and the vehicle is

within 15 meters of the obstacle/emer-

gency, broadcast a stop intention (as the

vehicle won’t probably be able to proceed

further after 15 meters).

R7 vehicle received a ”short-

stop” message, and the

stopping vehicle still will

be stopped by the time the

vehicle is 10 meters behind it

change lanes to avoid it

40


R8 vehicle received a ”request”

message

ignore it, as it’s intended for an RSU

R9 vehicle received a ”priority”

message, is on the left lane,

and the vehicle requesting

priority is behind it

change lanes to give priority to the incom-

ing vehicle, if possible



a ”proceed” message by an


proceed on the intersection



a ”change” message by an


change lanes


section the vehicle received a

”stop” message by an RSU

stop, and make another request after 10

seconds

41

References

[1] N. Alsharif, S. Cespedes, and X. S. Shen. “iCAR: Intersection-based con-

nectivity aware routing in vehicular ad hoc networks”. In: 2013 IEEE Inter-

national Conference on Communications (ICC). June 2013, pp. 1736–1741.

DOI: 10.1109/ICC.2013.6654769.

[2] Mikael Asplund et al. “A Formal Approach to Autonomous Vehicle Coordi-

nation”. In: FM 2012: Formal Methods: 18th International Symposium, Paris,

France, August 27-31, 2012. Proceedings. Ed. by Dimitra Giannakopoulou

and Dominique Mery. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012,

pp. 52–67. ISBN: 978-3-642-32759-9. DOI: 10.1007/978-3-642-32759-9_8.

URL: https://doi.org/10.1007/978-3-642-32759-9_8.

[3] Jon Louis Bentley. “Multidimensional Binary Search Trees Used for Associa-

tive Searching”. In: Commun. ACM 18.9 (Sept. 1975), pp. 509–517. ISSN:

0001-0782. DOI: 10.1145/361002.361007. URL: http://doi.acm.org/10.

1145/361002.361007.

[4] Jose Luis Blanco and Pranjal Kumar Rai. nanoflann: a C++ header-only

fork of FLANN, a library for Nearest Neighbor (NN) wih KD-trees. https:

//github.com/jlblancoc/nanoflann. 2014.

[5] Chenyi Chen et al. “Deepdriving: Learning affordance for direct perception in

autonomous driving”. In: Proceedings of the IEEE International Conference

on Computer Vision. 2015, pp. 2722–2730.

[6] P. S. Nithya Darisini and N. S. Kumari. “A survey of routing protocols for

VANET in urban scenarios”. In: 2013 International Conference on Pattern

Recognition, Informatics and Mobile Engineering. Feb. 2013, pp. 464–467.

DOI: 10.1109/ICPRIME.2013.6496522.

[7] P. Deutsch. GZIP file format specification version 4.3. RFC 1952 (Informa-

tional). Internet Engineering Task Force, May 1996. URL: http://www.ietf.

org/rfc/rfc1952.txt.

[8] E. W. Dijkstra. “A Note on Two Problems in Connexion with Graphs”. In: NU-

MERISCHE MATHEMATIK 1.1 (1959), pp. 269–271.

42

[9] Kurt Dresner and Peter Stone. “A Multiagent Approach to Autonomous Inter-

section Management”. In: J. Artif. Int. Res. 31.1 (Mar. 2008), pp. 591–656.

ISSN: 1076-9757. URL: http://dl.acm.org/citation.cfm?id=1622655.

1622672.

[10] Michal Forisek. Short implementation of the efficient O(m*log(n)) version of

Dijkstra’s algorithm. URL: https://www.quora.com/What-is-the-most-

simple-efficient-C++-code-for-Dijkstras-shortest-path-algorithm

(visited on 07/15/2018).

[11] Adithya Ganesh et al. “Deep Reinforcement Learning for Simulated Autonomous

Driving”. In: ().

[12] The Guardian. Tesla driver dies in first fatal crash while using autopilot mode.

2016. URL: https : / / www . theguardian . com / technology / 2016 / jun /

30/tesla-autopilot-death-self-driving-car-elon-musk (visited on

07/08/2017).

[13] Alphabet, Inc. Google Scholar. URL: https://scholar.google.com (visited

on 07/08/2017).

[14] Alphabet, Inc. Google search engine. URL: https://google.com (visited on

07/08/2017).

[15] GitHub, Inc. GitHub. URL: https://github.com (visited on 07/08/2017).

[16] Udacity, Inc. CarND-Path-Planning-Project. URL: https : / / github . com /

udacity/CarND-Path-Planning-Project (visited on 07/08/2017).

[17] Udacity, Inc. Udacity’s Self-Driving Car Simulator. URL: https://github.

com/udacity/self-driving-car-sim (visited on 07/08/2017).

[18] Tier IV. Autoware. URL: https://github.com/CPFL/Autoware (visited on

07/08/2017).

[19] The JSON Data Interchange Format. Tech. rep. Standard ECMA-404 1st Edi-

tion / October 2013. ECMA, Oct. 2013. URL: http://www.ecma-international.

org/publications/files/ECMA-ST/ECMA-404.pdf.

[20] G. S. Khekare and A. V. Sakhare. “A smart city framework for intelligent traf-

fic system using VANET”. In: 2013 International Mutli-Conference on Automa-

tion, Computing, Communication, Control and Compressed Sensing (iMac4s).

Mar. 2013, pp. 302–305. DOI: 10.1109/iMac4s.2013.6526427.

43

[21] MicroGSD. Road Architect. URL: https://github.com/MicroGSD/RoadArchitect

(visited on 07/08/2017).

[22] Fabio Panettieri. Socket.IO client for Unity3d. URL: https://github.com/

fpanettieri/unity-socket.io-DEPRECATED (visited on 07/08/2017).

[23] Marcelo Paulon. AVCP-Sim. URL: https://github.com/marcelopaulon/

AVCP-Sim (visited on 07/17/2018).

[24] J. Rios-Torres and A. A. Malikopoulos. “A Survey on the Coordination of Con-

nected and Automated Vehicles at Intersections and Merging at Highway On-

Ramps”. In: IEEE Transactions on Intelligent Transportation Systems 18.5

(May 2017), pp. 1066–1077. ISSN: 1524-9050. DOI: 10.1109/TITS.2016.

2600504.

[25] r-lyeh. sole - a lightweight C++11 library to generate universally unique iden-

tificators (UUID), both v1 and v4. URL: https : / / github . com / r - lyeh -

archived/sole (visited on 07/15/2018).

[26] M. L. Sin, M. Bouroche, and V. Cahill. “Scheduling of Dynamic Participants

in Real-Time Distributed Systems”. In: 2011 IEEE 30th International Sym-

posium on Reliable Distributed Systems. Oct. 2011, pp. 245–254. DOI: 10.

1109/SRDS.2011.37.

[27] Christoph Sommer. Veins - Vehicular network simulation framework. URL:

http://veins.car2x.org/ (visited on 07/08/2017).

[28] Christoph Sommer, Reinhard German, and Falko Dressler. “Bidirectionally

coupled network and road traffic simulation for improved IVC analysis”. In:

IEEE Transactions on Mobile Computing 10.1 (2011), pp. 3–15.

[29] The Telegraph. Self-driving cars will add $7 trillion a year to global economy,

says Intel. 2017. URL: http://www.telegraph.co.uk/business/2017/06/

02/self-driving-cars-will-add-7-trillion-year-global-economy-

says (visited on 07/08/2017).

[30] Unity Game Engine. “Unity game engine-official site”. In: (). URL: https://

unity3d.com (visited on 07/08/2017).

[31] Kathy Winter. For Self-Driving Cars, There’s Big Meaning Behind One Big

Number: 4 Terabytes. https://newsroom.intel.com/editorials/self-

driving - cars - big - meaning - behind - one - number - 4 - terabytes. Ac-

cessed: 2017-09-30.

44

[32] W. K. Wolterink, G. Heijenk, and G. Karagiannis. “Constrained geocast to

support Cooperative Adaptive Cruise Control (CACC) merging”. In: 2010 IEEE

Vehicular Networking Conference. 2010, pp. 41–48. DOI: 10.1109/VNC.2010.

5698268.

[33] Bernhard Wymann et al. TORCS, The Open Racing Car Simulator. 2014.

URL: http://www.torcs.org (visited on 07/08/2017).

[34] yosoufe. CarND-Path-Planning-Project. URL: https://github.com/yosoufe/

CarND-Path-Planning-Project (visited on 07/08/2017).

45

final project report a 3d simulation environment for ...endler/students/... · this project...

Documents