Experiments with Vehicle Platooning

(1)

Technical report, IDE1047, June 2010

Experiments with Vehicle Platooning

Master’s Thesis in Embedded and Intelligent Systems

Essayas Gebrewahid & Fareed Ahmed Jokhio {essgeb08, farjok08} @student.hh.se

Supervisor: Veronica Gaspes

School of Information Science, Computer and Electrical Engineering

(2)

Experiments with Vehicle Platooning

Master’s Thesis in Embedded and Intelligent Systems

School of Information Science, Computer and Electrical Engineering Halmstad University

Box 823, S-301 18 Halmstad, Sweden

(3)

Description of cover page picture: Four scenarios of the project.

Scenario 1: Platoon stability Scenario 2: Joining a platoon

(4)

EXPERIMENTS WITH VEHICLE PLATOONING

Abstract

This thesis is concerned with an experimental platform for studying cooperative driving and techniques for embedded systems programming. Coop- erative driving systems use vehicle-to-vehicle and vehicle-to-infrastructure communication for safe, smooth and efficient transportation. Cooperative driving systems are considered as a promising solution for traffic situations such as blind crossings. For the thesis work we use a robotic vehicle known as PIE (Platform for Intelligent Embedded Systems) equipped with a wireless communication device, electrical motors and controlled via a SAM7-P256 development board. For the infrastructure side we use a SAM7-P256 development board equipped with nRF24l01. Vehicle to vehicle and base station to vehicle communication is established and different platooning scenarios are implemented. The scenarios are similar to platooning scenarios from the Grand Cooperative Driving Challenge GCDC¹. The performance of the platoon control algorithm is measured in terms of throughput (a measure of string stability), smoothness and safety, where the safety requirements serve as pass/fail criteria.

1http://www.gcdc.net/

(5)

Acknowledgements

We would like to express our appreciation to our supervisor Veronica Gaspes.

Thanks for giving us the opportunity to work under her supervision. She provided us with valuable information about TinyTimber, she guided us during the development of the thesis project, with her help we successfully completed this masters thesis project. Thanks to Tommy Salomonsson for providing material and valuable information about wireless communication between the robotic vehicles. Thanks to Josef Bigun for helping us with the image processing part and for getting the location of the robotic vehicles using spiral patterns.

(6)

List of Figures

1.1 Components of the experimental platform . . . . 6

2.1 Playground for autonomous vehicles running in limited space. The figure is taken form project description of the course “De- sign of Embedded and Intelligent Systems” . . . . 17

3.1 Platoon Stability . . . . 21

3.2 Desired Spacing . . . . 22

3.3 Joining a platoon . . . . 24

3.4 Joining a platoon at a traffic signal . . . . 25

3.5 Merging traffic at an intersection . . . . 27

4.1 Block diagram of the Project . . . . 30

4.2 Spiral pattern and colour dot on top of vehicles. . . . 31

4.3 Control structure of platooning System. a, v and d are acceleration, velocity and inter-vehicle distance. The subscript l, p and i indicated platoon leader, immediate leader and the vehicle itself . . . . 35

4.4 Tangential Angle and Radius of vehicle when it moves in circular path . . . . 36

4.5 Platoon control . . . . 39

(9)

LIST OF FIGURES

4.6 Acceleration and deceleration graph. Red color indicates platoon leader, blue indicates participant 1 and green indicate participant 2 . . . . 46 4.7 Velocity of Leader and Participant vehicles. Red color indi-

cates platoon leader, blue indicates participant 1 and green indicate participant 2 . . . . 47 4.8 Distance Error for participant vehicles. Blue indicates partic-

ipant 1 and green indicates participant 2 . . . . 48 4.9 String stability of participating vehicles. Blue indicates par-

ticipant 1 and green indicates participant 2 . . . . 49 4.10 Vehicle movement on circular path. Yellow represents platoon

leader and blue and green represent participants . . . . 52

(10)

Chapter 1 Introduction

Cooperative driving systems are one of the promising application fields of Intelligent Transportation Systems. In cooperative driving systems vehicles cooperate and organize their activities by exchanging information via the existing wireless communication infrastructure. A vehicle communicates with other vehicles and with roadside infrastructure to make decisions based on the current traffic situation. Due to the raise in the number of vehicles on roads, traffic congestion, high fuel consumption, air pollution and traffic accidents are common problems throughout the world. But a study made by TNO [5] shows that within the next 10 to 15 years, cooperative driving systems will reduce vehicle hour loss by 50%, traffic death rate by 25%, CO₂ emission by 10% and air pollution by 20% . This can be achieved by creating a platoon of vehicles that cooperate with each other to travel with minimum inter-vehicular distance. Especially for traffic congestion, platoon of vehicles is a promissing solution.

To speed up the development of cooperative driving systems GCDC arranges a contest in March 2011 in the Netherlands. This contest pre-defines four scenarios to test the efficiency of cooperative control algorithms [7]. After the competition in 2011 the GCDC organizers intend to conduct a series of international events at various continents and will gradually put more challenging traffic situations to improve cooperative driving technology in the future. GCDC is open for universities, research institutes and other companies for participation.

(11)

Introduction

In GCDC among the four scenarios, the first three scenarios are related to vehicle platooning and the fourth is for testing the efficiency of the algorithms at blind crossing. The 2010 GCDC focused on platooning with a short inter-vehicle distance [18]. The goal of vehicle platooning is to achieve better safety, efficient vehicle driving, reduction of travelling time, reduction of traffic congestion, comfort for driver and passenger, reduction of air pollution and maximization of highway throughput. In platooning there are fewer changes in acceleration / deceleration and vehicles are driven much smoother as compared with ordinary driving, hence it provides better comfort for driver as well as passengers. With vehicle platooning it is possible to drive vehicles close to each other and not compromising on safety. Vehicle platooning reduces drag and as a result less fuel is consumed and there is less pollution. Drag is a force that opposes vehicles motion, which is generated by interaction of the vehicle body with air flow. Drag reduction is possible due to less inter-vehicle distance.

In the 2010 GCDC contest the driver still had some role, like controlling the lateral movement. But on the other hand, the SARTRE (Safe Road Trains for the Environment) project[1] is developing and testing technology for automatic vehicles and they claim that

Cars that drive themselves can become reality within ten years.

If the SARTRE project succeeds and their claim becomes true then the technology will have the potential to improve traffic flow, it will reduce travelling times, there will be less accidents, and also less fuel consumption and hence lower CO₂ emissions.

In the context of cooperative driving wireless communication among vehicles plays an important role. CERES, the Centre for Research on Embedded Systems at Halmstad University in cooperation with other partners from industry, is working on a Vehicle Alert System project. The focus of the project is in the areas of wireless communication, wireless sensor networks, cooperating embedded systems and vehicular ad hoc networks (VANETs).

[11] discuses that, even if two vehicles can not communicate directly, they can still share their information via other vehicles. They can also use information collected by sensors of other vehicles and can avoid accidents in hazardous locations. Lidstr¨om [11] has worked on communication disturbance detection

(12)

which is an approach for estimating the reliability and availability of wireless communication at hazardous locations. If correct information is available on time then safe vehicle driving can be achieved. In [12] cooperating vehicle safety systems are discussed. To maximize traffic safety, application independent cooperative functions can be used to monitor and prioritize the use of wireless communication medium [12]. In order to avoid accidents the reaction time of a driver should be faster.

For platooning systems communication technology already exists and the cost of installing this technology in vehicles is not too much. For positioning systems infrastructure is already there and insurance companies are successfully using it. In 1996 at the university of California a project was carried out as part of the California PATH program in which safe platooning systems were designed for automated highway systems [4]. In the PATH program platoons of closely spaced vehicles were organized. Safety of the participating vehicles was investigated by avoiding collisions.

1.1 Motivation

Autonomous vehicles are very interesting research area. GCDC is conducting its first competition in March 2011 and the topic is vehicle platooning. Halm- stad University is participating in the Vehicle Alert Systems project and our faculty members are already conducting research in the area. Auto industry is also motivating researchers to carry on their research for autonomous vehicles, and VOLVO is involved research carried out in the Vehicle Alert Systems project at Halmstad University. To facilitate experimenting with algorithms for autonomous vehicles at Halmstad University we chose the PIE (Platform for Intelligent Embedded Systems) developed at the University. We decided to test our platform and algorithms with similar scenarios to those of GCDC.

In a programming course at Halmstad University we learned embedded systems programming and used the TinyTimber kernel[13] for scheduling and concurrency. We found it is very lightweight run time kernel and decided to experiment with it in this thesis.

(13)

Introduction

1.2 Project Description

The goal of this master thesis is to study vehicle platooning and its implementation on robotic vehicles. We implement real time vehicle to vehicle communication among the vehicles and four platooning scenarios similar to those of GCDC. The four scenarios are listed here and are discussed in more detail in chapter 3.

• Scenario 1: Platoon stability

• Scenario 2: Joining a platoon

• Scenario 3: Joining a platoon at a traffic signal

• Scenario 4: Merging traffic at blind-crossing

For the implementation of the above scenarios vehicle to vehicle and vehicle to infrastructure communication needs to be established. All four scenarios have different judgement criteria; hence control code for the implementation of each scenario is written separately. Scenario 1 is about platoon stability, means maintaining a stable platoon. In scenario 2 at first a platoon of vehicles has to join another platoon. In the joining process both platoons have to maintain platoon stability. After joining, both platoons work as a single platoon. In the third scenario a platoon is waiting at a traffic signal, and another vehicle is coming, as soon as the coming vehicle crosses a predefined position, the signal light becomes green and the waiting platoon starts moving, the incoming vehicle has to join the platoon before the signal becomes red. The fourth scenario is implemented at a blind crossing where vehicles can not see each other. Further details about this scenario and other scenarios are discussed in chapter 3.

In this thesis work we use The robotic vehicle known as PIE (Platform for Intelligent Embedded Systems) to experiment with vehicle platooning. PIE was designed at Halmstad University for education and research purposes in the field of embedded and intelligent systems. PIE has an nRF24l01 radio frequency board to exchange information. Control software for PIE is developed using C language and the kernel TinyTimber, a real-time kernel for event-driven embedded systems.

(14)

To get the position of the robotic vehicles one network camera is attached to the roof of the project room. Vehicles are positioned by capturing an image and then processing it in Matlab. Vehicle positions are sent to all vehicles by wireless radio link. Sending positions to the robotic vehicles is a periodic task and is performed every half second. The robotic vehicles are programmed to move with various velocities on a fixed circular path.

Every vehicle has to perform four periodic tasks 1. Get data coming from other robotic vehicles 2. Send data to other robotic vehicles

3. Run code for motion control on circular path with various velocities 4. Run code for platoon control

1.3 System Architecture

Figure 1.1 shows the working environment of the project. Here project PC receives images from the camera; these images are processed in Matlab to calculate the positions of the vehicles. The camera is used for position systems instead of GPS (Global Positioning System) that is prescribes in GCDC. This is because the accuracy we need is in pixels (0.4cm) and GPS accuracy is measured in meters. The camera is attached to the roof of the project room and it can cover only limited area of playground. So it was decided to move the robotic vehicles in circular paths to get results for longer time periods.

The project PC sends vehicles’ location information and disturbances for the leading vehicle to base station. The base station broadcasts this information to all vehicles. Vehicles exchange their driving profile, like acceleration and velocity, via a wireless communication network.

Network Camera An ATAXIS 223M network camera is fixed to the roof of the project room. It is connected with the project PC via Ethernet. Hence it is possible to capture images of the playground at any time. The size of the image is 800*600 pixels which is equivalent to 3.2 ∗ 2.4m² on the playground.

(15)

Introduction

Figure 1.1: Components of the experimental platform

Project PC The project PC is a desktop Personal Computer with Intel Core 2 Due CPU and 3.21 Giga Hz of RAM. It captures images of the playground via the camera, processes them and sends location information to every robotic vehicle via the base station.

Base Station The base station is a SAM7-P256 board with an AT91SAM7S256 microcontroller and a nRF24L01 radio device. The base station is used to maintain the communication between the project PC and the vehicles.

The communication between base station and vehicles is maintained via the nRF24L01 2.4 Giga Hertz radio link. The base station to project PC communication is realized via the RS 232 interface.

Robotic Vehicle PIe includes an Atmel ARM 32 bit RISC AT91SAM7S256 microcontroller mounted on a SAM7-P256 development board. There are two EMG30 motors and 2 wheels connected to the motors. An MD23 board is connected to the microcontroller via the I2C to control the motors. The

(16)

robotic vehicle is equipped with a nRF24L01 radio device for sending and receiving data.

1.4 Outline of the thesis

The rest of the thesis is organized as follows

• Chapter 2 Background: this chapter introduces vehicle paltooning, embedded systems and embedded system programming. The TinyTimber kernel is described in more detail.

• Chapter 3 Vehicle Platooning Scenarios: this chapter describes four platooning scenarios toghether with their judgment criteria.

• chapter 4 Implementation and Results: this chapter describes the implementation of the control algorithms, wireless communication and image processing. In addition, the results of the project are presented.

• Chapter 5 Conclusion and Future work.

(17)

Introduction

(18)

Chapter 2 Background

2.1 Platooning Systems

A platoon is a group reacting in a coordinated way. Establishing vehicle platoons can result in increased road capacity, better efficiency due to less air resistance, less consumption of fuel, reduced congestion, less air pollution and better comfort for passengers and driver. In a platoon of vehiccles there is one vehicle that leads the platoon while all other vehicles follow it with the same velocity within a certain range of inter-vehicle distance. In the GCDC competition follower vehicles are termed as participants. Inter-vehicular distance is measured in terms of headway distance or headway time. There are several different ways of defining headway distance. For example tip to tip distance, tip to tail distance, tail to tip distance, and tail to tail distance.

Headway time is time taken by a follower vehicle to cover the headway distance. In this project just like in the GCDC competition, headway distance is measured from tip of follower to tail of immediate leader. In addition, platooning vehicles are expected to cooperate with each other to maintain stability of vehicle string: string stability is a measure of how errors are circu- lated from one vehicle to another in a platoon. These errors can be distance or velocity errors. In a string stable platoon, these errors have to decrease while moving down the platoon from vehicle to vehicle [21].

One aim of platooning systems is to increase road capacity by following a vehicle with minimum inter-vehicular distance while maintaining the same

(19)

Background

level of smoothness and safety. Platooning systems can be classified into two different groups according to their requirement on the desired following distance. In the first group the following distance is dependant on velocity i.e, headway time remains constant. In the second group velocity is computed in accordance with constant headway distance. Various platoon control algorithms have been designed for both platooning policies. [22] describes the string stability of a platoon with constant spacing. [21], [9], [10] and scenarios of this project deal with speed dependant inter-vehicular distance.

Platoon control systems give proper instructions to throttle and break a vehicle based on the driving profile of the other vehicles in the platoon, like relative distance, speed and acceleration. Autonomous cruise control and adaptive cruise control use environmental sensors to gather the driving profile of other vehicles. Here vehicles do not cooperate with each other by exchanging information. Thus, these systems are vulnerable to string instability [9]. On the other hand, cooperative adaptive cruise control (CACC) algorithms uses wireless communication network among vehicles to exchange driving profile. CACC is capable to look further ahead and to preserve stable behaviour even with short time headway. The algorithm which is implemented in this project is based on CACC.

A platooning system that is founded on cooperative driving systems is very much dependent on the wireless communication among the vehicles and between vehicles and infrastructure. Thus, the communication network should have standard format, efficient protocol, good organization, minimum packet loss and small errors. Packet loss and communication errors result in unstable and unsafe platoons. Vehicles must have a shared perception of the information exchange in order to cooperate successfully and this can be achieved by using efficient protocols with standard message formatting. In addition, the current driving profile of each vehicle has to be transmitted over the communication network on a real-time manner. There are many causes which decrease the reliability of wireless communication like weak signal strengths due to propagation conditions, multipath fading, Doppler shifts due to the movement of vehicles, and interference signals due to noise. Therefore, a capable control algorithm should consider limitations of the wireless communication. The effect of communication delay on string stability is investigated in [14]. The effects of packet loss on vehicle control systems are discussed in [19].

(20)

Platoon stability and smoothness is highly affected by the efficiency of the control algorithm. The competence of control algorithm is judged in view of platoon stability, smoothness and safety.

2.2 Embedded systems programming

In this days’ technology embedded systems are used almost everywhere, e.g.

mobile phone, cameras, CD players, bar code readers, telephone switches, medical equipment etc. Basically, “an embedded system is a computer system designed to perform one or few dedicated functions often with real-time computing constraints”¹. For embedded systems real time response is cru- cial. For example, in vehicle platooning there are many timing requirements that have to be fulfilled, such as time to measure current speed of vehicle, time to give command to throttle and brake, time to send vehicle driving profile and so on. Embedded systems also come with some programming interface, but in many cases they come without operating system.

Simple embedded system applications without embedded operating system or kernel typically structured usinga cyclic-executive forever loop. This is to prevent the system form going to some unknown random behaviour while the system power is on. Using a forever loop is simple and efficient, but it does not fit well with concurrent real time applications. For real-time applications a loop can be introduced to get time delay, but it is very difficult to estimate accurately timed delays. A compiler may also remove this delay loop during optimization process. So, usually timer based hardware interrupts are used to produce timed response. Actually hardware and software interrupts are the heart beat of most embedded systems.

Embedded systems programming involves access to hardware. Thus, resources like processor time, memory, communication channels etc need to be managed. They also have to be extremely predictable and reliable. Pro- gramming languages for embedded systems typically have features that help to access hardware device interfaces directly. These hardware devices can be computers and several external elements like robots, sensors and actu- ators. The computer program must interact with these external real-world

1According to the Wikipedia http://en.wikipedia.org/wiki/Embedded system accessed on July 2nd 2010.

(21)

Background

elements simultaneously. Real-world elements can exits in parallel by nature.

Therefore, the programming language for embedded systems must provide the programmer with primitives that can support concurrent programming.

Execution of a concurrent program is not as straightforward as is execution of a sequential program. Processes must be created and terminated; dispatched to and from the available processors. These tasks are usually delegated to a real-time kernel. Such a kernel has many of the properties of the scheduler in an operating system and sits logically between the hardware and the application software. For concurrent programming kernel has to provide three things [6]

1. the expression of concurrent execution through the notion of process

2. process synchronization

3. interprocess communication

In addition, an embedded system has to respond to events generated by the interface of the processor with the rest of the system and that these are occurring in a world that evolves concurrently. If there will be no concurrency, then the system will not be able to respond on the incoming events and hence the response of the system will be incorrect.

C, C++ and Real time Java are the most common embedded system programming languages. In this project, the C programming language is used to simulate cooperative driving systems. C, besides its popularity and efficiency, gives a good access to hardware and it also has high-level features like functions which make it suitable for embedded system programming. But in C we do not have access to an object oriented programming style, which would suit the problem domain. Fortunately, kernels like TinyTimber make it possible to program in object-oriented style while using the C programming language. In this project the difficulty in resource management and task scheduling is handled by the TinyTimber kernel. Even if embedded and non-embedded software share the same development constraints and goals, embedded software needs more carefulness and due to resource constraints.

(22)

2.2.1 Embedded systems programming with TinyTim- ber

The TinyTimber kernel is suitable for event driven embedded systems [16].

The design of TinyTimber is based on reactive objects. Each reactive object maintains an internal state and responds with a set of methods to incoming events [17]. Sending a message is inter-process communication. TinyTimber uses EDF (Earliest Deadline First) scheduling to schedule messages onto execution threads. If there is no ready message, the system will be in idle state [3] and the processor can be put to sleep. TinyTimber provides synchronous and deadline based asynchronous method calls. It also provides protection to shared resources while calling two methods of different objects concurrently.

The resources can be global variables accessible via various methods. For an object only one method is executed at a time i.e., it does not allow concurrency for method calls from the same object. It supports inheritance. It is essential that all reactive objects in TinyTimber must be child of top level Object class. Methods in TinyTimber can have only one integer argument.

Object Orientation in C with TinyTimber

To define the variable structure of classes, a combination of a typedef and a struct is used. here is an example of a class ‘COMM’:

typedef s tr u c t { O b j e c t s u p e r ; i n t P i e R a d i u s ;

i n t PieTangentAngle ; i n t P i e L o c a t i o n A n g l e ; i n t P i e A c c e l e r a t i o n ; i n t PieAccTime ;

i n t t i m e r ;

i n t d i s t r u b a n c e N o ; i n t P i e S p e e d ;

i n t ID ; // p i e ID

char TX [ 3 2 ] ; // To s e n d d a t a

char RX [ 3 2 ] ; // g e t d a t a form b a s e s t a t i o n } COMM;

(23)

Background

Inheritance from the predefined class ‘Object’ is reflected in the field ‘super’.

Variable initialization by init

To initialize variables of an object of COMM class a pre-processor macro initCOMM is used. Here we are initializing variables by their default values.

#define initCOMM ( ) { i n i t O b j e c t ( ) }

In TinyTimber there is no dynamic object creation. Instead all objects are created on program initialization. Here is how objects of the COMM class are created:

COMM communicate = initCOMM ( ) ;

Methods in TinyTimber

To each of the structures that introduce a class we can associate a set of methods. The interface used by TinyTimer for this uses functions with one extra argument for the object to which the method is called. Functions introducing methods can have inly one more argument and return ‘int’ as in i n t s e t v e l o c i t y ( L e a d e r ∗ s e l f , i n t ∗ v e l ) ;

Methods are invoked by self-application[16], meaning that method invocation is done by the self of the receiver or by applying it to the address of the receiving object. Here is a the body of the methods introduced before:

i n t s e t v e l o c i t y ( L e a d e r ∗ s e l f , i n t ∗ v e l ) { i f ( ∗ v e l < 0 )

∗ v e l =0;

i f ( ∗ v e l > 4 0 )

∗ v e l =40;

s e l f −>v e l o c i t y =∗ v e l ; }

(24)

Synchronous and asynchronous method calls in TinyTimber To call a method there are two options: asynchronous and synchronous calls.

Method calls with SYNC (synchronous) proceed in the same thread of execution as the caller. Their execution is purely sequential. A message call using synchronous call operates under mutual exclusion, thus using SYNC to a method in the same object as the caller leads to deadlock. During run time the presence of deadlock can be detected by TinyTimber. Methods invoked by SYNC call may return a value. Instead, methods that are called with ASYNC (asynchronous) are executed concurrently with the caller method.

Asynchronous calls of methods can also be performed by using the following TinyTimber directives AFTER (call after given baseline), BEFORE ( call before a deadline) and WITHIN ( after a baseline and before a deadline) that include time information that can be used by the scheduler. Further information about the TinyTimber interface can be found in [16]. Here is how these primitives are used:

ASYNC(&communicate , i n i t i a l i z e R F , NULL ) ;

where ‘communicate’ is an object of some class, ‘ initializeRF ’ is one of its methods and ‘NULL’ is the other argument to the method. If any method needs to be called inside the body of any other method which is invoked by same object then keyword self can be used instead of object name as shown below:

ASYNC( s e l f , s e t v e l o c i t y ,& v e l ) ;

Here is example of synchronous call to method ‘setSpeedMotor0’ on object

‘ self −>md23’ with argument ’ self −>zeroSpeed’:

SYNC( s e l f −>md23 , setSpeedMotor0 ,& s e l f −>z e r o S p e e d ) ;

Performance Measurements for TinyTimber

Performance measurements of TinyTimber version v0.3.0 on an ARM7 microcontroller and other platforms are discussed in [13]. Table 2.1 shows the TinyTimber overhead for an ARM7 microcontroller. In the table best case for the overhead cost of performing various kernels operations is presented.

(25)

Background

kernel mechanisms ARM7 instruction count

a Synchronous call 50

b Asynchronous call 74

c Save context 23

d Release message 37

e Allocate thread 8

f Restore context 15

g Critical section 224

Table 2.1: TinyTimber instruction count for an ARM7

2.3 Related works

In [2] ² the PIE platform was used as a robotic vehicle. A set of vehicles shared a common space and carried out their individual transportation tasks avoiding collision. Each vehicle only knew about its own part of the tasks. A network camera was used to get the position of all robotic vehicles. The test scenario was a common spaced divided into two rooms separated by a narrow passage. Vehicles were getting periodic information from base stations via wireless communication. There were separate base stations for each robotic vehicle. There was no vehicle to vehicle communication. See figure 2.1 In [20] two different algorithms are used for one for single vehicle line tracking and for multiple vehicle collision avoidance. And just like this project they have three different actions drive straight, turn left, or turn right. Overhead vision system and desktop PC is also used. But for line tracking vehicle’s speed is assumed to remains constant. In this platooning project we also have two algorithms one for path tracking and another for controlling the platoon. But the path tracking can work with change in speed.

2“Design of Embedded and Intelligent Systems” is advanced level project course in two year Masters program “Embedded and Intelligent Systems” at Halmstad University. In fall 2009 the project was about “Autonomous vehicles running in limited space”

(26)

Figure 2.1: Playground for autonomous vehicles running in limited space.

The figure is taken form project description of the course “Design of Embed- ded and Intelligent Systems”

(27)

Background

(28)

Chapter 3 Vehicle Platooning Scenario

As we explained in Chapter 1, the scenarios for this project are taken from the GCDC. These scenarios could also be applied in a mine or in a parcel storage compartment. In GCDC the scenarios are modelled to test longitudinal platoon control, which means the road is a straight line. In our scenarios we chose a circular path instead, due to the limited playground size and to the fact that a circle gives us an infinite path by keeping angular velocity and acceleration constant. The criteria to measure the platoon are also similar to GCDC. Table 3.1 shows the allowed vehicle acceleration for all scenarios.

Characteristic Specification maximum acceleration 2m/s² least acceleration 1m/s² maximum deceleration -3m/s² least deceleration -2m/s²

Table 3.1: Allowed vehicleoperating range of acceleration

3.1 Judgement criteria

The performance of the control algorithms is measured in terms of throughput (measure of string stability), smoothness and safety, where the safety requirement serves as pass/fail criteria. A successful control algorithm will

(29)

Vehicle Platooning Scenario

produce smooth and safe platoon with high throughput.

Safety To avoid collision among vehicles a minimum safe distance has to be maintained. This safe distance will depend on the speed of the vehicles, for higher speeds it will be more and for less speeds it will be less. The safe distance corresponds to a time headway of one second.

Throughput Throughput is the main criteria to assess platooning. Through- put can be defined as the total number of vehicles which cross a lane in a given time. To increase throughput, space between vehicle must be mini- mized smoothly without violating safety rules. The two parameters that are used to weight up throughput are:

1. Headway distance: each PIE should remain within minimum and maximum headway distances, which correspond to minimum headway time of 1.6sec and maximum headway time 3sec.

2. String stability: measures the ability of the vehicles to diminish the change in velocity introduced by the leading vehicle.

Smoothness Smooth driving is a calm driving style without sudden speed changes, even in the presence of disturbances. It is measured by change in acceleration. Smooth reaction to disturbances results in stable platoons with high throughput.

3.2 The Four Scenarios

3.2.1 Scenario 1: Platoon stability

Description

In this scenario the ability of participant vehicles (PIEs) to maintain a stable platoon and to use the road efficiently is examined while driving at alter- nating velocity and acceleration. We distinguish one of the vehicles as EVP

(30)

(special PIE which run by predefined acceleration and speeds) to lead all participant PIEs. At the beginning the vehicles will accelerate and start driving with constant velocity of 10 pixel/sec. Here 1 pixel corresponds to 4 mil- limetres. Then EVP will introduce instability and disturbances by varying its speed and acceleration. The degree of this instability must be dimin- ished when it propagates to the following vehicles in the platoon; this is the property of string stability. See Figure 3.1.

Figure 3.1: Platoon Stability

Judgement criteria 1. Throughput

Desired Spacing (C1 ) The maximum following distance (fd^max_i ) and minimum following distance (fd^min_i ) are described as:

fd^min_i = r_i^min+ h^min_d,i xi (3.1) fd^max_i = r_i^max+ h^max_d,i x_i (3.2) where r^min (50pixel) and r^max(100pixel) are defined as mimimum and maximum distance at standstill, h^min (1sec) and h^max (3sec)

(31)

are defined as minimum and maximum desired haeadway time and x_i is the velocity of its own vehicle. Penalty for not maintaining

Figure 3.2: Desired Spacing

desired space depend on the distance and time of the participant outside the desired spacing.

C1_i = Z

toutside

e²_i(t)dt (3.3)

where ei and toutside are the distance and time of the participant outside the desired spacing.

String stability (C2 ) After a disturbance is introduced by the leader (EVP) the other PIEs will have 15 seconds to act on the disturbance. To quantify this the 2-norm of the accelerations are compared to the predecessor for a given time horizon t_{C2 ,i}. The time horizon starts at the beginning of each disturbance and ends 15 seconds after the disturbance. The string stability is expressed as

C2_i = kaik₂

ka_i−1k₂, f or t_i = t_C2,i (3.4) 2. Smoothness

Acceleration variance (C3 ) The variance of the acceleration is de- termined as the total sum of all accelerations during the entire phase of the scenario.

C3_i =

tend

X

tstart

a²_i (3.5)

(32)

where t_start and t_end are the strat and end time of the judgement phase.

The total Score of each participant PIEs will be

S1 = k₁C1 + k₂C2 + k₃C3 (3.6) where k₁, k₂, and k₃ are weighting factors for each of the individual criteria.

The one with lowest S1 is the winner.

3.2.2 Scenario 2: Joining a platoon

Description

In this scenario a platoon of vehicles joins another platoon of vehicles. The smoothness of the platoons will be judged in the joining process. During the joining process both platoons should be stable. EVP will operate as the last vehicle of the first platoon. Due to this, the first platoon can be considered as a virtual platoon. Participant PIEs will line up in the second platoon at large distance behind EVP. When EVP starts to accelerate, the leader of the participant PIEs will start to join the firstl platoon represented by EVP. The other participants will follow the leader by using their cooperative control algorithm. The leader of the participant PIEs should join EVP as soon as possible, without exceeding the maximum velocity of 80pixel/sec, without violating the safety distances and smoothly. The leader of the participant PIEs should stay on the desired space at least for 10sec after joining EVP platoon. Other participants will follow the platoon leader in the desired headway distance while maintaining platoon stability. See Figuer 3.3

(a) Platoon leader

The throughput of the leader is measured differently before and after it joins the first paltoon.

(33)

Figure 3.3: Joining a platoon

Before joining: The throughput is measured in terms of t_C4, the time taken by the leader to join the prior platoon.

C4_i = t_C4 (3.7)

After joining : The throughput is measured along with the criteria mentioned on section 3.2.1.

(b) Other vehicles

For other participant PIEs the throughput is measured along with the criteria mentioned on section 3.2.1.

2. Smoothness The criteria for smoothness are the same as section 3.2.1.

Total score of each participant PIEs will be

S2 = u1C1 + u2C2 + u3C3 + u4C4 (3.8) where u₁ .. u₄ are weighing factors for each of the individual criteria The one with lowest S2 is the best.

(34)

3.2.3 Scenario 3: Joining a platoon at a traffic signal

Description

This scenario takes place at an intersection with a traffic signal. At the be- gining all but one of participant vehicles and EVP will line up and wait at a red traffic light as shown in figure Figue 3.4. And the remaining participant vehicle (participant 3 in the below figure) will be placed on predefined distance far away from traffic light. The goal of the participant vehicles is to maximize throughput at traffic signal and participant 3 (in the below figure) will go to join the platoon before the light turns to yellow. When remaining participant PIE pass certain the threshold, the light will turn to green and EVP will accelerate and lead the participants. The participants accelerate as well, and will cooperate to increase the throughput at the traffic light. The remaining participate vehicle should join smoothly and pass the traffic signal before it turns to red.

Figure 3.4: Joining a platoon at a traffic signal

(35)

(a) Remain participant vehicle It is judged in the same way as Platoon leader of scenario 2, both before and after joining the platoon.

(b) Other vehicles For other participant PIEs the throughput is measured along with the criteria mentioned on section 3.2.1.

Total score of each participant PIEs will be

S3 = b₁C1 + b₂C2 + b₃C3 + b₄C4 (3.9) where b1 .. b4 are weighing factors for each of the individual criteria The one with lowestS3 is the best.

3.2.4 Scenario 4: Merging traffic at blind-crossing

This scenario tests the efficiency of the cooperative driving system at blind- crossing (crossings without traffic lights and with an obstructed view). As can be seen from the below figure, at the start two EVP vehicles will be positioned on one road and one participant vehicle will be placed in other road where the view is obstructed. But the participant vehicle can get all driving information of EVP vehicles, like location, velocity and acceleration, via vehicle-to-vehicle communication. The participant vehicle has to determine whether it is possible to merge between the EVP vehicles or to follow the second vehicle. The participant vehicle should pass through the intersection within short period, without exceeding the maximum velocity of 40pixel/sec, without violating the safety rule and smoothly.

Judgement criteria

1. Throughput The throughput in this scenario is measured as the time it takes the participants to cross the intersection:

C6_i = tC6 (3.10)

(36)

Figure 3.5: Merging traffic at an intersection Total score of each participant PIEs will be

C6 = µ₁C6 + µ₂S4 (3.11)

where µ₁ and µ₂ are weighing factors for each of the individual criteria The one with lowest S4 is the best.

(37)

(38)

Chapter 4 Implementation and results

To implement the four platooning scenarios which were described in the previous chapter, three main things has to be considered.

• Efficient image processing to locate and track each vehicle.

• Reliable wireless communication network for both vehicle-to-vehicle and vehicle-to-base station communication.

• Competent vehicle control to keep the vehicle in track and to create a smooth stable platoon.

Figure 4.1 shows the overall hardware components and algorithms of the system.

4.1 Image processing

As discussed in the project description in Chapter 1, a network camera captures the playground image and sends it to the project PC periodically. The project PC then analyses the image and positions each vehicle. To identify each vehicle uniquely, every vehicle has a unique spiral pattern and colour dot on its top. Figure 4.2 shows the pattern three of the vehicles. Since each vehicle have unique spiral pattern and colour dot, a vehicle can be identified

(39)

Implementation and results

30

(40)

by using two different ways. The first approach is to uses colour threshold and the second approach is to uses spiral patterns to find out vehicles location.¹ Here are the steps to identify and locate vehicles.

1. Capture image by camera. This will give us an image in RGB (red, green and blue) colour model.

2. Convert all elements of the image to type double.

3. Convert RGB (red, green and blue) image to HSV (Hue Saturation Value) colour model.

4. Compute the generalized structure tensor for a symmetry order.

5. Use spiral patterns to locate each vehicle.

6. Convert HSV image to RGB

7. Using appropriate colour threshold values identify the location of the robotic vehicle and get its central point.

Figure 4.2: Spiral pattern and colour dot on top of vehicles.

After getting the position by both spiral pattern and colour, model level fusion is used to get the final location of the vehicle. Since colour threshold values are varied for different lighting effects, 30% weighting is given to colour and 70% weighting is give to spiral pattern. If any vehicle’s location is not identified by colour then 100% weighting is given to spiral pattern and if vehicle’s location is not identified by pattern then 100% weighting is give to

1The coding for spiral patterns to find out vehicles locaion was written by Josef Bigun (Professor at the Signal Analysis Chair, at Halmstad University and Chalmers Institute of Technology)

(41)

colour. Instead of processing the whole image to locate vehicle, a separate small region of interest (ROI) is created around each vehicle and the image processing is be carried out on this region. At the beginning the whole playground is searched for vehicles and then a separate ROI is created around every vehicle. When the next image is captured vehicles will be searched in their ROI and a new ROI will be created based on its current location. But, if any vehicle is not found in its ROI then again whole playground is analysed and new ROI will be created around the vehicle. To avoid missing vehicles in their ROI, the size of ROI is bigger than the actual size of the vehicle.

4.2 Implementation of wireless communica- tion network

4.2.1 nRF24L01 Transceiver

As can be seen in Figure 4.1 the wireless link is set up among microcontrollers via nRF24L01 2.4 GHz wireless chip with an SPI (Serial Peripheral Inter- face). SPI makes it possible to do anything internal to nRF24L01 like read or write registers, transmit data and receive data. The timing requirements of nRF24L01 SPI interface are compatible with the speed of ARM7TDMI Pro- cessor (the processor in the robotic vehicle). ARM7TDMI Processor runs up to 0.9 MIPS/MHz, which is less than the maximum nRF24L01 SPI data rate.

SPI timing requirements are presented on page 47 of [15]. The NRF24L01 can operate in any one of the following modes

• Power Down Mode

• Standby Modes( Standby-I and Standby-II)

• TX Mode : Transmision mode

• RX Mode reciving mode.

If there are packets in TX FIFO and NRF24L01 is in TX mode, then it will transmit packets. If TX FIFO becomes empty, then NRF24L01 goes in standby-II mode. Packets are received in RX mode. If device neither

(42)

transmits nor receives any packet then it is possible to put it in standby-I mode for energy efficiency. The air data rate can be 1Mbps or 2Mbps. The nRF24L01 can operate on 2.400GHz to 2.525GHz frequencies. If we go to chapter 8 of [15] we can get two digital signals IRQ and CE beside the four SPI signals. CE is used to control transmission and reception of data. And IRQ is an active low interrupt pin which is activated when

1. data with valid address and payload is received 2. transmission of data is completed

3. number of retransmissions exceeds the number of allowed retries

4.2.2 Wireless communication

Since nrf24L01 chip raises hardware interrupts on the presence of data, the chip is kept in receiving mode most of the time. If any data is available, an interrupt will be generated and contents of RX FIFO will be stored. When vehicle wants to transmit data, nrf24L01 will be set to TX mode, and after transmission again it will be changed back to RX mode. Communication based on interrupt is reliable and as can be seen in table 4.4.2 the number of packet lost is very less.

Basestation to Vehicle communication

ID Acc/Dess Time of Acc/Dess Disturbance No Packet counter Vehicles Location

Table 4.1: Basestation to Vehicle communication packet format A base station is connected with the project PC and is responsible to send periodic information about the locations of all vehicles in the playground.

Base station broadcasts information to all vehicles. In order to create controlled disturbances in the platoon, the base station also sends acceleration and deceleration to the leader of the platoon. Here is the explanation of the packet format used:

(43)

• ID: represents the ID of the source i.e. base station.

• Acc/Dess: The disturbance may be acceleration or deceleration in speed. Valid values for acceleration are 1 and 2. and valid values for deceleration are -2 and -3. But to save space 4 is send instead of -2 and 6 in place of -3.

• Time of Acc/Dess: The time of disturbance indicates for how long the leader should apply the given disturbance.

• Disturbance Number: It is a counter of disturbances. This will help to calculate String stability of each time zone since each time zone have one disturbance.

• Packet counter: this indicates the packet number. If this counter reaches to 99 then it is again reset to 1. It is used to see loss ratio of packets during communication.

• Remaining 27 bytes are used to send the location of PIEs. It is possible to send location of 6 PIEs. The location includes radius and polar angle of PIE with respect to centre of the playground, and tangential angle of the PIE for navigational control

Vehicle to Vehicle communication

ID Velocity Acc/Dess Time of Acc/Dess Timer

Table 4.2: Vehicle-to-Vehicle communication packet format

Vehicle to vehicle communication is essential, because vehicles must have real-time information about the driving profile of the other vehicles, like velocity and acceleration. Here is format of vehicle to vehicle communication.

• ID: It represents the ID of participant vehicles. The ID for leader vehicle is L and for participant vehicles the ID is 1,2,3, and so on.

• Current Velocity: It represents the current velocity of the vehicles.

(44)

• Acc/Dess: it indicates the value with which vehicle is accelerating or decelerating.

• Time of Acc/Dess: This indicates the time for which the vehicles will accelerate or decelerate.

• Timer: This is the counter for packets and its value is same as that of the packet counter.

4.3 Implementation of vehicle control

Figure 4.3: Control structure of platooning System. a, v and d are acceleration, velocity and inter-vehicle distance. The subscript l, p and i indicated platoon leader, immediate leader and the vehicle itself

As explained in [8] a vehicle platooning system can be controlled in two layers:

the inner loop to control nonlinear behaviour of the vehicle and an outer loop to control the platoon. That is, the inner loop deals with throttle and break control and outer loop controls string stability by following safety rule. This project implements two algorithms as well, path tracking to control which

(45)

acceleration and to keep the vehicle in proper path an platoon control to pass appropriate acceleration to the path tracking control. An overview of vehicle control is shown in figure 4.3.

4.3.1 Path tracking

Figure 4.4: Tangential Angle and Radius of vehicle when it moves in circular path

This algorithm has two duties. The first one is to give appropriate speed for both right and left motors of PIE based on the velocity and acceleration which is passed from the platoon control algorithm. The second duty is to keep the vehicle in the proper path by using one of the proper actions among this three alternative actions turn left, turn right or move on the circle.

Table 4.3 shows the dynamic and calibration model of PIE to convert vehicle velocity to left and write motor speed. In the calibration model to compute the scale factor (kv), first left and right motor speed are kept constant (w) and velocity (v) is sampled each half second. Then since the motors have 128 forward and 128 backward speed k_v will be given by k_v = (w − 128)/v.

The control parameters to keep the vehicle in circular path are radius of rotation, tangential angle and polar angle. See figure 4.4. As explained in chapter 3 the path for the scenarios is a circle. But the radius of the

Experiments with Vehicle Platooning

Experiments with Vehicle Platooning

Experiments with Vehicle Platooning

Contents

List of Figures

Chapter 1 Introduction

1.1 Motivation

1.2 Project Description

1.3 System Architecture

1.4 Outline of the thesis

Chapter 2 Background

2.1 Platooning Systems

2.2 Embedded systems programming

2.3 Related works

Chapter 3

Vehicle Platooning Scenario

3.1 Judgement criteria

3.2 The Four Scenarios

Chapter 4

Implementation and results

4.1 Image processing

4.2 Implementation of wireless communica- tion network

4.3 Implementation of vehicle control