STOCKHOLM SVERIGE 2016 ,
Longitudinal Control of a Heavy-Duty Vehicle
JONATHAN FAGERSTRÖM
Abstract
Platooning and cooperative driving can decrease the emissions of greenhouse gases and increase the traffic capacity of the roads. The Grand Cooperative Driving Challenge, GCDC, is a competition that was held in May 2016 on highway A270, between Helmond and Eindhoven in the Netherlands. The competition is focused on cooperative driving.
The participating teams are constellations of students and faculty from different uni- versities in Europe. A cornerstone in the GCDC is autonomous platooning. The main objective of this thesis is to design a state feedback controller for longitudinal control of a Scania truck, i.e., engine and braking control. This was done so the truck can keep an inter-vehicle distance and velocity. A linear quadratic regulator (LQR) for the platooning is derived. the controller is designed in MATLAB Simulink and implemented on a real time target, Speedgoat. For simulations of the regulator, Scania supplied a pre-compiled Simulink model of a similar truck, a G480 mining truck. The results of the competition show that the controller is capable of platooning based on RADAR (adaptive cruise con- trol) and vehicle to vehicle communication (cooperative adaptive cruise control). In the highway scenario the maximum deviation from desired distance in steady state was less than 4 m and the maximum deviation in velocity was less than 1 m/s. The controller is able to keep the truck at a certain distance from the preceding vehicle as well as keeping the same velocity. If the distance is decreased the truck will brake in a controlled manner to keep the distance. The KTH team finished in third place out of ten participating teams.
I
Konvojkörning och kooperativ körning kan minska utsläpp av växthusgaser och öka trafikkapaciteten på vägarna. Tävlingen The Grand Cooperative Driving Challenge, GCDC, är en tävling som hölls i maj 2016 på motorväg A270, mellan Helmond och Eindhoven i Nederländerna. Tävlingen är i kooperativ körning. De deltagande lagen är konstellationer av studenter och fakultetspersonal från olika universitet i Europa.
Grunden för GCDC är autonom konvojkörning. Målet med den här examensjobbet är
att utforma en tillståndsåterkoppling för longitudinell kontroll av en Scania-lastbil, med
andra ord, motor- och bromskontroller. Det utfördes så att lastbilen kunde hålla ett
bestämt avstånd till, och samma hastighet som, ett framförvarande fordon. En linjärk-
vadratisk regulator (LQR) för konvojkörning härleds. Regulatorn utformades i MATLAB
Simulink och implementerades i ett realtidssystem, en Speedgoat. För simuleringar av
regulatorn bistod Scania med en förkompilerad Simulink-modell av en liknande lastbil,
en G450 gruvlastbil. Resultaten av tävlingen visar att regulatorn kan utföra konvojkörning
med RADAR-mätningar (adaptiv farthållare) och med fordon-till-fordon kommunikation
(kooperativ adaptiv farthållare). I motorvägsscenariot i tävlingen är maximal avvikelse
från önskat avstånd till framförvarande fordon i jämvikt mindre än 4 meter och den
maximala avvikelsen i hastighet var mindre än 1 m/s. Regulatorn kan hålla lastbilen på
ett visst avstånd från framförvarande fordon och samtidigt hålla samma hastighet. Om
avståndet skulle krympa så bromsar regulatorn lastbilen på ett kontrollerat sätt för att
behålla avståndet. Laget från KTH slutade på tredje plats av tio medverkande lag.
Acknowledgements
I would like to thank my examiner Jonas Mårtensson for valuable insight in implementations of control systems in a real vehicle. To my supervisor Pedro Lima, for always pushing me. To the team members Stefanos Kokogias, Lars Svensson, Rui Oliveira, Gonçalo Pereira, Benjamin Nordell, Xinhai Zhang and Xinwu Song for always helping out and making everything work and for keeping a smile on my face even in tough times. I would also like to thank Henrik Pettersson at Scania for helping with valuable insight of the truck, and putting aside his important work to help me. Professional driver Chris Tamimi at Scania acted as test driver and also helped with understanding how a truck should behave. Last, I would like to thank all the people at ITRL for giving me a welcoming place to work.
III
Abstract I
Sammanfattning II
Acknowledgements III
Table of Contents IV
1 Introduction 1
1.1 Background . . . . 1
1.2 Problem formulation . . . . 1
1.3 GCDC . . . . 2
1.4 Scania truck . . . . 4
1.5 Related work . . . . 5
2 Overview 10 2.1 Platooning logic . . . 10
2.2 Scania truck . . . 12
2.2.1 Brake management system . . . 12
2.2.2 Engine management system . . . 13
2.2.3 Gear management system . . . 13
2.3 Hardware and system architecture . . . 13
2.4 Modeling . . . 15
2.5 Platoon model . . . 17
2.5.1 Engine management system model . . . 17
2.5.2 Brake management system model . . . 18
2.6 Control design . . . 18
2.6.1 LQR . . . 18
2.6.2 Bumpless switching . . . 20
3 Results 22 3.1 System identification . . . 22
3.2 Simulation . . . 23
3.2.1 Scenario 1, highway platooning and merging . . . 23
3.2.2 Scenario 2, T-intersection . . . 25
3.3 Experimental results . . . 27
3.3.1 Scenario 1, highway platooning and merging . . . 28
3.3.2 Scenario 2, intersection . . . 33
4 Conclusions and discussion 40 4.1 Conclusions . . . 40
4.2 Discussion . . . 40
4.3 Future work . . . 41
Bibliography 43
Appendix A Results, Highway 45
Appendix B Results, Intersection 47
V
1.1 B ACKGROUND
Cooperative driving is a promising technology that can significantly increase traffic through- put and improve traffic safety[11], [15]. Driver assistance systems already help make vehicle navigation safer and more comfortable by reducing accidents due to the human factor. How- ever, vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) connectivity offers more information on road conditions and vehicle’s intentions. This enables vehicles to coopera- tively maintain a certain distance and speed. The advantage of Cooperative Adaptive Cruise Control (CACC) over Adaptive Cruise Control (ACC) is that incorporating the communication one can make a platoon string stable, i.e., spacing errors are guaranteed to diminish as they propagate toward the tail of the platoon.
To accelerate legislation and development of automated driving the Grand Coopera- tive Driving Challenge (GCDC) took place in May 2016. The main focus of GCDC was to demonstrate the benefits of cooperative driving by letting 10 teams from universities compete with each other. The GCDC is a part of the i-GAME project, an European research project, supported by the European Commission, in which the next step towards the cooperative au- tomation of vehicles is explored. KTH participated with two vehicles in this competition, one Scania truck and an in-house developed Research Concept Vehicle (RCV). The competition took place on highway A270, between Helmond and Eindhoven in the Netherlands.
1.2 P ROBLEM FORMUL ATION
As a part of the KTH and Scania GCDC team, the topic of this thesis is to investigate and
implemented a controller for CACC in a Scania truck. The developed controller should be
able to maintain a desirable speed or desired inter-vehicle distance, in a safe and human-
comfortable way. So, CACC when communication and RADAR readings from preceding
jonfag@kth.se Jonathan Fagerström September 23, 2016
vehicle is available, adaptive cruise control (ACC) when communication is lost, and cruise control (CC) when none of these are available. The controller is developed with the main goal of being used in the GCDC competition, and as such, it must be able to:
• Maintain a reference speed (CC)
• Maintain a desired inter-vehicle distance and velocity (ACC)
• Maintain a desired inter-vehicle distance and velocity (CACC)
1.3 GCDC
In total, three scenarios have been defined by the organisers, two competitive scenarios and one for demonstration. In the first scenario, two platoons are approaching a construction site on a two-lane highway. The left platoon and the right platoon receive a message from a road side control unit saying that they are approaching a construction site with information about the position of and the speed limit on the construction site. The participating vehicles must merge into one platoons on the available lane for passing the site. This is depicted in Figure 1.1.
Figure 1.1: Scenario 1, Highway. In this scenario two platoons of vehicles merge to pass a construction site with reduced velocity in a cooperative fashion.[9]
In the second scenario, as seen in Figure 1.2 and 1.3, three vehicles approach a T-intersection.
All vehicles enter the competition zone (CZ) at the same time with the same velocity. The
Page 2 of 49
CZ is a circle centred in the intersection with a radius of 50 m, inside which the grading of performance is done. Once the vehicles are in the CZ, they will in a collaborative manner allow the vehicle coming from the side road (V1) to pass onto the main road without stopping.
This implies that the vehicles traveling on the main road slows down and let V1 onto the road and then accelerate to leave the intersection as soon as possible.
Figure 1.2: Scenario 2, T-intersection. Three vehicles enter into an intersection, PC1 and PC2 slows down to let the priority vehicle, V1, pass.[9]
Figure 1.3: Scenario 2. Exiting the intersection and PC1 will speed up and leave the CZ and PC2 will follow priority vehicle V1.[9]
The demonstration scenario is similar to the first scenario, an emergency vehicle (EV)
approaches a congested highway situation and signalise the intent to pass the traffic conges-
tion in a given position (left / middle / right side). The cooperating vehicles know at which
time the EV will be close and act in a cooperative manner to create room for the EV. Vehicles
continue with reduced speed during the manoeuvre. After the EV has passed the vehicles
resume position within their lanes and resumed speed as seen in Figure 1.4
jonfag@kth.se Jonathan Fagerström September 23, 2016
Figure 1.4: Scenario 3, let emergency vehicle passed.[9]
The scenarios requires longitudinal and lateral control. However the truck is not fitted with active steering, i.e. only a driver can control the steering. This is resolved by having a professional driver controlling the steering while the truck automatically controls longitudinal motion. The basis of these scenarios is platooning. Platooning is used for all of the scenarios, elaborated in Section 2.1. The longitudinal controller is optimised for the competition with simulations and testing.
1.4 S CANIA TRUCK
The truck used was a Scania R450. The R450 is a three axle, 450 horse power truck. It is equipped with 8 t extra weight on the bed to emulate load. One challenge of working on the truck is availability of the truck, as Scania uses it for other research and development.
Another challenge is the slow dynamics of the truck. The computational complexity of the controller needs to be sufficiently low so it can run at specified rate on the hardware. The truck’s gear shifting system may cause some problems as it will be uncontrollable when shifting. Moreover, the acceleration of the truck cannot be controlled directly but rather one has to request a desired speed to the trucks engine management system (EMS). In similar fashion, the braking is handled by a low-level controller, brake management system (BMS), by inputing desired deceleration. The Scania truck used in the competition is shown in Figure 1.5.
Page 4 of 49
Figure 1.5: The Scania truck used in the competition, at ATC test track in Aldenhoven, Germany.
1.5 R EL ATED WORK
There are numerous ongoing research projects in autonomous vehicles. Autonomous vehicles can outperform humans in multiple ways, such as reaction time and detection of obstacles [15]. In [13] it is shown that total brake response time for a human is between 0.8-1.8 s, independent of age which is long compared to a computer which would have a reaction time in milliseconds.
In particular, a special case of autonomous driving has undergone extensive research, cooperative driving, or more specific cooperative platooning. In the GCDC, cooperative platooning is extensively used for longitudinal motion.
In most cooperative platooning research, homogenous platoons are considered. However
in the GCDC the platoon is heterogeneous and therefore the control needs to be decentralised,
jonfag@kth.se Jonathan Fagerström September 23, 2016
i.e., each vehicle is implemented with a stand-alone controller, as opposed to a centralised controller taking command of all vehicles. This is due to not having complete information of other vehicle dynamics and corresponding controllers in the platoon. The difference in dynamics of two cars from one manufacturer can be very large, for example a small two- seated sports car does not have the same dynamics as a mini-bus or a heavy-duty truck.
And since the dynamics differ, control design might vary much. Also, one car manufacturer might have a preference of using one specific controller and a second car manufacturer might have a different preference. This makes it vary hard to create a centralised control. In a real world scenario, decentralised control is more feasible. Maybe in the future, governments and car manufacturers might come to the conclusion that centralised control is more efficient for traffic throughput, however, there will always be a need for lower level decentralised controllers in the vehicles.
The first type of longitudinal control, the Cruise Controller (CC), was patented in 1950 by Ralph Teetor [14]. Even though speed controllers had been used in other applications such as steam engines, Teetor’s was the first automotive application. Since then CC has been been common in automotive vehicles.
Later in the early 90’s, Mitsubishi developed the Adaptive Cruise Controller (ACC) which relied on LIDAR or laser to measure distance to preceding vehicle as to maintain a safe distance [10]. While ACC is common in cars today it has a drawback of not being string stable, i.e., distancing oscillations do not attenuate as they propagate down the platoon [11].
Cooperative Adaptive Cruise Control (CACC) is an extension of ACC which make use of Vehicle to Vehicle (V2V) communication. Vehicles can communicate different states, such as position, velocity, and acceleration via V2V with surrounding traffic. This makes it easier to achieve a string stable platoon with small gap which also increases traffic throughput [11]. In [11] it was also shown that a time headway of as little as 0.7 s rendered a platoon of six cars with identical dynamics and controllers, string stable.
One benefit of CACC is reduced drag in platoons. Automatically controlled vehicles can reduce reaction time and hence reduce time headway distance which leads to lower aerodynamic drag [1]. This reduces fuel consumption. Time headway is the time it will take for a trailing vehicle to cover the distance to preceding vehicle if the velocity is kept constant.
In [1] it is also shown that an LQ state feedback control of a Heavy Duty Vehicle (HDV) is sufficient for controlling longitudinal motion in a platoon with a small time headway.
The previous GCDC was held in 2011 and consisted of one highway scenario where two platoons approach two other platoons from behind and settles in behind the previous platoons. For the previous GCDC, a comparison of platooning controllers was done in [2].
Page 6 of 49
It compares the computational complexity and performance of Model Predictive Control (MPC), Proportional-Integral-Derivative control (PID), and Linear Quadratic Regulator (LQR).
It was shown that while MPC and LQR perform better than PID, LQR and PID is far less computationally heavy than MPC. A qualitative comparison between these controllers can be seen in table 1.1. Given that in automotive industry one would like to have a small, energy efficient system that runs the control of the vehicle, LQR would be a good choice. Concerns were also raised if there is not enough computational power for a long enough horizon in the MPC would cause instability.
Controller type: PID LQR MPC Performance: OK Good Very good Computations: Very low Low Heavy
Table 1.1: Qualitative comparison of controllers.
MPC is a controller that uses a model of the vehicle to predict future states of the vehicle.
MPC is optimal in the sense that it calculates the control action given a set of constraints and some cost function J , often it is a linear problem and a quadratic cost is used:
J = min
u∈U N
X
k=0
¡x(k) T Qx(k) + u(k) T Ru(k)¢ ,
s.t . Wx(k) ≤ b, (1.1)
x(k + 1) = Ax(k) + Bu(k),
where x(k) is the states at time k, u(k) is the corresponding control. Matrices A and B are the dynamics and input matrices. Matrices W and b are the constraint matrices. The main advantage of MPC is the fact that it allows the current time slot to be optimised, while keeping future time slots in account. This is achieved by optimising over a finite horizon but only implementing the control in the current time slot. Because of this, it has the ability to anticipate future events and make control actions accordingly. MPC uses a dynamic model chosen by the user, e.g., kinematic model of the system and measurements of the states to calculate future outputs. MPC can also handle non-linear time-varying models together with constraints.
In [6] a Linear Time Varying (LTV) MPC is considered for control of a HDV. It covers both
longitudinal and lateral control as well as going in depth with all systems of a truck such
as drive train. Concluding that a LTV-MPC performs very good with a maximum lateral
deviation of 0.1 m
jonfag@kth.se Jonathan Fagerström September 23, 2016
LQR is a state feedback controller. Also developed from an optimal point of view. LQR is calculated from some cost function, with different weight on states and control, and state space matrices. The main difference from MPC is the absence of constraints. Below a general problem of a LQR problem can be seen.
J = min
u∈U
X ∞ k
0¡x(k) T Qx(k) + u(k) T Ru(k)¢ d t, (1.2) s.t . x(k + 1) = Ax(k) + Bu(k),
where notations is consistent with equation 1.1. With the feedback law minimising the const function is calculated from the Algebraic Ricatti Equation (ARE). There has also been extensive work done in stability analysis of LQR compared to MPC.
Considering [2], LQR has similar performance as MPC, and with the lower complexity of the controller it is a good choice. Reports concerning LQR controlled platooning have been done; [5] shows reduced fuel consumptions and systematic decrease in distancing errors.
In [12], controller structure in the case when the information from the preceding vehicle is missing. Shows as reliable for a systematic and efficient design of platoon controllers.
The chosen controller for this thesis is an LQR, The predictive powers of MPC will not be as crucial with longitudinal control as in lateral. In lateral control, ending up in the other lane without exceeding the limits in jerk and in the proper amount of time is important. In Longitudinal control, the predictions are harder to achieve as the communication protocol does not support exchange of future states.
Since the V2V communication protocol does not share any information about the con- troller used or some intended trajectory. The vehicles are interconnected systems and the MPC would greatly benefit from such protocol. The gear changes in the truck are time consuming and one cannot know when they happen, this will make the prediction in an MPC difficult. MPC is also computationally heavy and might be difficult to implement in a production HDV that is lacking powerful hardware.
To get an insight of the different strategies in the competition, participants from last GCDC can be considered. The winning team "Team AnnieWay" [3] chose to only consider one vehicle in their control. This was done in the sense that the control was considering the preceding vehicle in the platoon which was most conservative, i.e., the one which had the most most positive distancing error to the car in front. If there was no distancing errors in the platoon, it would follow the platoon leader.
Proposed by the GCDC organisers [9], a number of control "agents" could be used in the
GCDC for to switch between controllers. One agent for CACC, one for CC, one for Obstacle
Page 8 of 49
Avoidance (OA), etc. this is further investigated in the thesis [7] as a part of KTH team that participated in the 2011 GCDC.
The Scania truck considered in this thesis relies on a low level controller (EMS) that determines the amount of torque needed at any given time for a desired velocity. Using system identification one can determine the dynamics of this low level controller with the system identification toolbox in MATLAB [MATLAB].
In [1] an initial guess of the low level EMS is shown together with system identification
based on some test runs resulted in a good estimation of the controller.
2 Overview
In this chapter the hardware and logic behind the competition scenarios is presented, to- gether with the model of the truck used. Also control design and LQR method is shown.
2.1 P L ATOONING LOGIC
The scenarios described in Section 1.3 can all be approached from a platooning point of view.
Scenario 1, highway with merging two platoons into one, starts off as two platoons in two lanes. Before vehicles are able to merge, they pair up with each other so that all vehicles know which vehicle merges between which vehicles. In Figure 2.1 is depicted the merging procedure. the backward right vehicle (Bwd_R) shifts from platooning with forward right (Fwd_R) to backward left (Bwd_L). The merging vehicle, Bwd_L, switches from platooning with forward left (Fwd_L) to forward right (Fwd_R). This creates a gap between Fwd_R and Bwd_R in which the Bwd_L vehicle merges.
10
Fwd_R
Bwd_L
Bwd_R
Fwd_R
Bwd_L
Bwd_R
Fwd_L Fwd_L
Fwd_R
Bwd_L
Bwd_R Fwd_L
Fwd_R
Bwd_L
Bwd_R Fwd_L
A B C D
Figure 2.1: A) Two platoons in a highway. B) Bwd_R pair and platoons with Bwd_L. C) Bwd_L pairs and platoons with Fwd_R, thus making a gap in the right lane where Bwd_L merges. D) Merging complete
In Scenario 2, T-intersection, virtual platooning is used when entering the competition
zone. First a planning algorithm needs to make sure that V1 and V2 is at the CZ after 20 s
and at 30 km/h. After entering the CZ, V1 and V2 platoons with the pace car (PC) based on
travelled distance in the CZ (virtual platooning), sent over V2V. When PC turns onto the lane,
V2 platoons with it instead. This is illustrated in Figure 2.2.
jonfag@kth.se Jonathan Fagerström September 23, 2016
PC
V2 V1
PC V2 V1
CZ
CZ
A B
Text
PC V2
V1 CZ
C
Figure 2.2: A) Use planning algorithm to be at CZ with 30 km/h after 20 s. B) Virtual platooning with PC based on travelled distance in CZ. C) V1 speeds back up to 30 km/h, V2 platoons with PC.
The third and final scenario, emergency scenario depicted in Section 1.3, will rely on normal platooning. Since this scenario was for demonstrative purposes, it will not be handled further in this thesis.
2.2 S CANIA TRUCK
Modern HDVs in general have two separate low-level control systems for governing the longitudinal propulsion and deceleration of the vehicle, the engine management system (EMS) and the brake management system (BMS). These are the available interfaces to control the truck. BMS and EMS together with the gear management system (GMS) are described in Sections 2.2.1-2.2.3.
2.2.1 B RAKE MANAGEMENT SYSTEM
There are several brake systems in a modern HDV, ranging from the weaker exhaust brake
to the strong brake discs. The BMS receives a deceleration request and typically blends the
Page 12 of 49
brake power from the different systems depending on the magnitude of the requested signal.
It also assures that the system does not overheat. Therefore, the achieved braking force varies with respect to the current state of the system. Even though braking is managed by a low level controller, it can be assumed that deceleration is directly controllable.
2.2.2 E NGINE MANAGEMENT SYSTEM
The EMS controller receives a velocity request as an input. It then calculates the required fuelling amount for obtaining the necessary torque to obtain the requested velocity. The EMS also assures that no oscillations arise in the powertrain. It monitors the turbo pressure and limits the fuelling in case a sufficient amount of air is not available for the combustion process. Hence, the achievable torque might be limited.
2.2.3 G EAR MANAGEMENT SYSTEM
The GMS is an automated gear changing system that enables the driver to devote more attention to handling the vehicle and to traffic. Monitoring the RPM and the engine torque request, it is designed to change the gear quickly and comfortably in a fuel-efficient manner.
Note, however, that a delay typically arises when disengaging and engaging a new gear. Gear changes are performed based on the state of the truck and engine. A typical switch between gears lasts around 2 s, rendering the truck uncontrollable during this time. This challenge can be overcome by for example forcing the truck into utilising only one gear when at steady highway velocity. After simulation and initial testing it was concluded that the gear changes would not cause many problems at high speed, but getting up to speed will require multiple gear changes and hence acceleration may be slow compared to conventional vehicles such as cars.
2.3 H ARDWARE AND SYSTEM ARCHITECTURE
In this section, the hardware used in the project is discussed. To be able to communicate
with the truck systems and control EMS and BMS, a gateway was installed by Scania. This
gateway allows the hardware installed by the team to be able to control EMS and BMS whilst
receiving data from the trucks sensors, such as RADAR, accelerometer, tachometer, etc. In
Figure 2.3 the high level system architecture is depicted.
jonfag@kth.se Jonathan Fagerström September 23, 2016
Cohda SpeedGoat PC
Tablet
Truck Gateway
Ethernet Ethernet
CAN bus Serial
Driver HMI
Passenger GUI Monitoring
Logging Control
Estimator Supervisor platoon logic V2X com. protocol
Sensors GPS Accelerometer
Radar
Figure 2.3: Hardware architecture. The real time target Speedgoat runs the control which is communi- cated to the BMS and EMS through the truck gateway.
The Cohda is a wireless communications hardware and it handles all wireless communication with other vehicles (V2V) and infrastructure (V2I), the Speedgoat is a real time target machine for running MATLAB Simulink code in real time. The supervisor, Estimator and controller are all implemented in the Speedgoat. A tablet was used for displaying information to the driver, including position in platoon, when it is safe to merge, and when the truck is in automated/manual mode. A PC is connected to the Speedgoat for continuously monitoring the sytem.
The supervisory layer decides which vehicle to platoon with, what kind of control agent to use and if the vehicle is in a safe state. The supervisor also contains a Kalman filter used for estimations of vehicle speed and accelerations.
EMS
BMS Control Supervisor
CACC
ACC
CC Radar
GPS
C-ITS
Estimator
Figure 2.4: Control supervisor.
Page 14 of 49
In Figure 2.4 the control supervisor is depicted. RADAR and GPS measurements together V2X communication is fed to the estimator. The control supervisor decides when to use CACC, ACC, or CC. The supervisor determines which vehicle to use as target based on scenario and V2I.
2.4 M ODELING
In this Section the models that serve as basis for the controller design are presented. In Figure 2.5 is illustrated the forces acting on a heavy-duty vehicle on a road which has road grade α. The forces F d , F g , F r , F e , and F b denote air drag, gravitational force, rolling resistance, driving force produced by engine, and braking force produced by the different brake systems, respectively.
?
Fd
Fg
Fr
Fe
Fb
Fg
Figure 2.5: Forces acting on truck in longitudinal direction.
Applying Newton’s second law of motion along with external forces a non-linear vehicle
jonfag@kth.se Jonathan Fagerström September 23, 2016
model can be derived as:
x = v, ˙
m t v = F ˙ e − F b − F a (v) − F r ( α(s)) − F g ( α(s)), (2.1)
= m
r t T e − F b − 1
2 ρC D Av 2 −C r cos( α(s))mg − sin(α(s))mg,
where m t is the total inertial mass, F e is the force produced by the engine, F b is the braking force. s is the absolute travelled distance from some common reference point, α(s) is the road grade. The external forces F a , F r , and F g represents drag, rolling resistance, and gravitational forces acting on the the truck respectively. The variable r t is the radius of the wheels, ρ is air density, C D is drag coefficient of the truck, C r is rolling resistance coefficient, A is frontal area.
v and m is velocity and mass, respectively.
The EMS produces torque and we assume that the torque produces an acceleration, independent of velocity. The input to the EMS is required velocity, the velocity change will not happen instantaneously, so there is some extra dynamics in the EMS. The modeling of the extra dynamics of the EMS is based on [1]. The acceleration model is based on a PI controller and can be formulated as
a = K c
µ e i + 1
T I Z
e i d t
¶
, (2.2)
where K c and T I is determined by fitting data to the model and e i = v i ref − v i is the difference between requested velocity and actual velocity. By inserting this into (2.1) we get:
v = K ˙ c
µ e i + 1
T I Z
e i d t
¶
= K c
r t v r e f i − K c
r t v i + z v , (2.3)
˙ z v = K c
T I
e i ,
where z v is the integral state in the acceleration model.
Since the deceleration is controlled by a low level controller it is assumed that deceleration can be controlled directly, i.e., the truck’s deceleration will be the required deceleration sent to the BMS. This gives
˙
v i = a r e f i . (2.4)
And hence no integral state for extra dynamics is needed.
Page 16 of 49
2.5 P L ATOON MODEL
In this section a platoon system model is derived. Since the controllable inputs for the EMS and BMS are different, two platoon models are presented, one for engine control and another for braking control.
2.5.1 E NGINE MANAGEMENT SYSTEM MODEL
First a model to describe the platoon dynamics is derived in (2.5). Let i = 1 be the leader of the platoon and i = 2,3,..., N . be the following vehicles in the platoon. Let the heavy-duty truck be i .
˙
v i = K c (v r e f i − v i ) + z v ,
˙
z v,i = K c
T I (v i r e f − v i ),
d ˙ i −1,i = v i −1 − v i , (2.5)
˙
v i −1,i = −a i ,
z ˙ d = d i −1,i − τv i ,
where d i −1,i = s i −1 − s i is the longitudinal distance between two vehicles in the platoon, s i −1 and s i is the distance from a common point to vehicle i − 1 and i . v i −1,i = v i −1 − v i is the difference in vehicle speed. Since no information of the dynamics of the preceding vehicle is communicated over V2V, there is no knowledge of vehicle i − 1 acceleration state. Hence the change in relative velocity is assumed to only be affected by the trucks acceleration. The discretised states are
v i (k + 1) = v i (k) + T s
³ K c ³
v i r e f (k) − v i (k) ´
+ z v (k) ´ , z v (k + 1) = z(k) + T s
K c T I
³
v i r e f (k) − v i (k) ´ ,
d i −1,i (k + 1) = d i −1,i (k) + T s ¡v i −1,i (k) − v i (k)¢ , (2.6)
v i −1,i (k + 1) = v i −1,i (k) + T s
³
K c (v r e f i (k) − v i (k) + z v (k)
´
,
z d (k + 1) = z d (k) + T s ¡d i −1,i (k) − τv i (k)¢ ,
jonfag@kth.se Jonathan Fagerström September 23, 2016
where T s is the sampling time, z v,i is the integral state due to extra dynamics in the EMS.
z d ,i is an integral state for maintaining the desired distance, d desired = r 0 + τv i . r 0 is the standstill distance, τ is the time headway. The resulting platoon states are then given by x e = [v i z v d i −1,i v i −1,i z d ].
2.5.2 B RAKE MANAGEMENT SYSTEM MODEL
Since the BMS is a low level controller, applying braking torque to achieve a reference deceler- ation, the deceleration is directly controllable. The system under braking is given in (2.4). The discrete linear platoon system is chosen as a subset of (2.6) since the BMS has acceleration as input, and is given by
v(k + 1) = v(k) + T s
³
a r e f (k) ´ , v i −1,i (k + 1) = v i −1,i + T s
³
−a r e f (k)
´
, (2.7)
d e (k + 1) = d e (k) + T s ¡v i −1,i (k)¢ ,
where d e = d i −1,i − (r 0 + τv) is the error in desired distance. Hence giving the states as x b = [v v i −1,i d e ].
2.6 C ONTROL DESIGN
We aim at developing a cooperative longitudinal control of an autonomous heavy-duty vehicle. Furthermore, the controller should respect the GCDC regulations as we are one of the participants. The chosen control method of LQR is deduced as the most suiting in Section 1.5. In this chapter the basis of LQR is addressed.
2.6.1 LQR
In LQR the control problem is formulated as an optimisation problem. The optimal control law is found by using an optimisation algorithm that minimises a cost function with weighting factors, which need to be designed in such a way that the system behaves according to specifications. For a discrete time system on the form
x l (k + 1) = A l x l (k) + B l u l (k), (2.8)
Page 18 of 49
where l ∈ {e,b} defines either EMS control (e) or BMS control (b), a cost function is defined as
min
u
lX ∞ k=0
x l (k) T Q l x l (k) + u l (k) T R l u l (k). (2.9)
The optimal linear feedback controller that minimises the cost function is given by
u l ∗ (k) = −L l x l (k), (2.10)
where the feedback gain is given by:
L l = (R l + B l T P l B l ) −1 B l T P l A l . (2.11)
Where P l is the unique positive definite solution of the Discrete time Algebraic Riccati Equation (DARE):
P l = A l T P l A l − (A l T P l B l )(R l + B l T P l B l ) −1 (B l T P l A l ) +Q l (2.12)
From this it follows that it has all values inside the stability region. However the truck is a non-linear system, so stability of the linear model cannot be generalised for the non-linear model.
The workflow of designing controller is such that first one choose Q l positive semidefinite and R l positive definite. Then require (A l , B l ) stabilisable and (A l ,Q l ) detectable. The optimal feedback controller, u l is then calculated by solving (2.11) and (2.12). If simulation result of this controller is insufficient, R l and Q l is set to other values and the feedback is recalculated.
when simulations results are satisfactory the controller is then tested in the real system. The
weighing matrices are experimentally tuned in order to get desired performance for distance
and velocity keeping.
jonfag@kth.se Jonathan Fagerström September 23, 2016
2.6.2 B UMPLESS SWITCHING
The objective for introducing a bumpless transfer is to avoid uncomfortable behaviour, e.g., large jerk when switching from EMS to BMS actuation. The switching guards g n n ∈ {1,2} are the conditions for switching to BMS actuation (n = 1) and EMS actuation (n = 2), and are given by:
g 1 : (v i −1 < v i ∧ d i −1,i < (r 0 + τv i )β 1 ) ∨ (a i −1 < k 1 a ∧ d i −1,i < (r 0 + τv i )β 2 ) g 2 : (v i −1 ≥ v i ∧ d i −1,i ≥ (r 0 + τv i )β 3 ) ∨ (d i −1,i ≥ (r 0 + τv i )β 4 ∧ a i −1 > k 2 a )
where β m ∈ (0, 1] and k n a is design parameters. The agents are designed in such a way that it switches to EMS actuation if ego velocity is lower than preceding vehicle and distance is larger than the desired distance scaled by β 3 or if acceleration of preceding vehicle is larger than threshold k 2 a and distance is larger than the desired distance scaled by β 4 . The switch to BMS actuation is executed if ego velocity is larger than preceding vehicles and the distance is smaller than desired distance scaled by β 1 or if acceleration of preceding vehicle is lower than threshold k 1 a and distance is smaller than the desired distance scaled by β 4 . To avoid acceleration jerks and facilitate smooth switching from EMS to BMS control, a low pass filter, F (z) = 1−k z−k
ffwas implemented after the switch, where k f ∈ [0, 1) is a design parameter for setting the rise time of the filter. In Figure 2.6 the control architecture can be seen.
Le
Lb vi
vi-1,i
ziv di-1,i
zid
Vi vi-1,i
de
W
sat.
?
?
Filtervi-1 di-1,i ai-1
- +
? = v
ref? = a
refg1
g2
vref
aref aref
vLQR
vref B
Figure 2.6: Overview of proposed LQR with bumpless switching.
The controller seen above, where L e and L b are established in section 2.6.1, and σ is the
output of the switching between EMS and BMS. A maximum velocity is enforced due to
Page 20 of 49
limits in speed demand to the EMS and legislation, which might saturate the control demand produced by L e . Hence, to not saturate the signal W is implemented as:
z v (k + 1) = z v (k) + T s
K c
T I (e i (k) + 1
T t e s (k)), (2.13)
where e s = v r e f − v LQR , e i = v r e f − v and T t is a design parameter.
The vehicle does not behave in similar fashion when requesting a lower set-point velocity compared to a higher, when at some current velocity. This manifests itself as not coasting when vehicle i − 1 slows down gently. To facilitate this an extra scaling function, B, on the feedback gain for velocity was implemented as:
Algorithm 1 Scaling function B
1: if v i −1,i < v t hr eshol d then
2: v i −1,i = v i −1,i · k sc al e 3: else
4: v i −1,i = v i −1,i
5: end if
where k sc al e is a design parameter, to make the control more aggressive when target is slowing
down.
3 Results
In this chapter, the results of the thesis are presented. Results from simulation are presented together with results from the scenarios in the competition.
3.1 S YSTEM IDENTIFICATION
As described in Section 2.4, the modeling of the dynamics in the cruise controller can be described as:
a i = K c
à e i + 1
T i I Z
e i d t
!
, (3.1)
where the acceleration produced by a difference in set speed and actual speed, e i = v i r e f − v i . The acceleration and velocity is measured while increasing reference speed in the cruise controller with 10 km/h when the truck levels out at previous set speed, which is 15 s. By using the MATLAB toolbox system identification [MATLAB], one can calculate coefficients of a model based on actual inputs and outputs. Prediction Error Method is used for calculating the coefficients. When using the generic first order model (equation 3.1) the result is a fit of 44.48 % and a mean square error (MSE) of 0.02342, as visible in Figure 3.1. In the lower plot the gear changes are distinctive. The GMS changes gear when the truck levels at a set speed.
22
0 10 20 30 40 50 60 70 [s]
-0.5 0 0.5 1
[m/s
2]
10-60kph, 10kph/15s step
acceleration simulated acc.
0 10 20 30 40 50 60 70
[s]
0 5 10 15 20
[m/s]
-1 0 1 2 3
velocity velocity error
Figure 3.1: System identification, Fit of 44.48%. Step response of cruise controller from 10-70 km/h.
The oscillations when the velocity levels off is gear changes.
3.2 S IMUL ATION
For simulation, Scania supplied a pre-compiled model of a G480 mining truck. Not much is known about this model however it was a good start for designing the controller. Described in Section 1.3 is the scenarios, in the next Sections simulation results of these scenarios can be seen.
3.2.1 S CENARIO 1, HIGHWAY PL ATOONING AND MERGING
The highway scenario consists of first two platoons in two lanes and merging into one lane,
which is depicted in Figure 1.1. To simulate this, a reference vehicle travelling at speeds
ranging from 0-70 km/h is followed. There are no disturbances in the simulation as the
tracked vehicle is the same model of a truck as the one being simulated, which will introduce
some disturbance when changing gears. When settling in speed the reference jumps to a
vehicle in the next lane, which is 10 m behind the first reference, at the same speed. The
jonfag@kth.se Jonathan Fagerström September 23, 2016
simulation is depicted in Figures 3.2-3.3, at 60 s the switch of references is clearly visible in the lower plot.
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 time [s]
0 2 4 6 8 10 12 14 16 18 20 22 24
Velocity [m/s]
Highway scenario, simulated
Vego Vtgt
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 time [s]
10 12 14 16 18 20 22 24 26 28 30
Distance [m]
Distance Desired distance
Figure 3.2: Simulation of highway scenario. Velocity and target velocity in the upper plot, and distance to target and desired distance in the lower.
Page 24 of 49
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 time [s]
-1 0 1 2 3
Velocity error [m/s]
Highway scenario, simulated
0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 time [s]
-12 -10 -8 -6 -4 -2 0 2 4 6
Distance error [m]
Figure 3.3: Simulation of highway scenario. In the upper plot the error in velocity is shown, and in the lower, error in distance.
The controller keeps distance in a safe way and slows down in a safe manner to make a gap to the second reference. The distance keeping during acceleration is off, this makes for safer platooning as the distance to preceding vehicle is larger.
3.2.2 S CENARIO 2, T- INTERSECTION
The intersection scenario consists of two parts, first the planning stage for to get to the
competition zone, and then virtual platooning. In order to simulate this a planning algorithm
emulating a vehicle is set for the HDV to platoon with until the entrance of the CZ, see Figure
2.2. Then a reference vehicle entering the competition zone, emulating the priority vehicle is
used as reference. The planning algorithm creates a velocity profile, first between 5-9.6 s the
velocity is zero. After 9.6 s the reference is a constant acceleration of 0.6 m/s 2 up to 30 km/s,
and after that the velocity is constant. The switch to following the priority vehicle reference
can clearly be seen in Figure 3.5 at 25 s as the distance error jumping to −9 m.
jonfag@kth.se Jonathan Fagerström September 23, 2016
8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 time [s]
0 2 4 6 8 10 12 14
Velocity [m/s]
Intersection scenario, simulated
Vego Vtgt
8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 time [s]
8 10 12 14 16 18 20 22 24
Distance [m]
Distance Desired distance
Figure 3.4: Simulation of intersection scenario. The velocity and target velocity is shown in the upper plot, and distance to target and desired distance in the lower plot.
Page 26 of 49
8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 time [s]
-2 -1 0 1 2 3
Velocity error [m/s]
Intersection scenario, simulated
8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 time [s]
-12 -10 -8 -6 -4 -2 0 2 4 6
Distance error [m]
Figure 3.5: Simulation of intersection scenario. Upper plot depicts error in velocity and the lower, error in distance.
The controller is conservative with keeping distance, however it eventually levels out.
Since the reference distance is a function of the HDV velocity, it varies with speed.
3.3 E XPERIMENTAL RESULTS
In the following Sections the results from the GCDC competition in Helmond, Netherlands,
are presented. The controller used for the competition is different from the one designed in
simulation. In simulation, one can not feel how the truck behaves and it is important that the
truck behaves in such a way that the driver trusts it and feel comfortable. As previously stated
the simulation model is not a model of the truck used in the competition and thus changes
needed to be done to enforce comfort and performance. However these changes are very
small.
jonfag@kth.se Jonathan Fagerström September 23, 2016
3.3.1 S CENARIO 1, HIGHWAY PL ATOONING AND MERGING
As described before the first scenario is the highway platooning with merging. In Figures 3.6-3.11, the three heats of highway scenarios are depicted. In Figure 3.6 a comparison between the speed of the HDV and the target vehicle can be seen in the upper plot, and in the lower plot the distance to target and desired distance. In Figure 3.7 the velocity errors, v i −1 − v i , and distance, d i −1,i − d desired are visible.
60 80 100 120 140 160 180 200 220 240 260 280 300 320 time [s]
8 9 10 11 12 13 14 15 16 17
Velocity [m/s]
Highway scenario, Heat 1
Vego Vtgt
60 80 100 120 140 160 180 200 220 240 260 280 300 320 time [s]
15 20 25
Distance[m]
Distance Desired distance
Figure 3.6: Highway scenario, heat 1. Upper plot: velocity and target velocity. Lower plot: distance to target and desired distance. At 60 s the HDV starts platooning with target vehicle. The target vehicle brakes at four points during the scenario, at 70 s, 110 s, 140 s and 180 s
Page 28 of 49
60 80 100 120 140 160 180 200 220 240 260 280 300 320 time [s]
-3 -2 -1 0 1 2 3
Velocity error [m/s]
Highway scenario, Heat 1
60 80 100 120 140 160 180 200 220 240 260 280 300 320 time [s]
-5 0 5
Distance error [m]
Figure 3.7: Highway scenario, heat 1. The distance and velocity errors during the highway scenario.
Error in velocity, upper plot. Error in distance, second plot.
The four drops at 70 s, 110 s, 140 s and 180 s in the bottom plot in Figure 3.7 is due to the controller being conservative of using the brakes when vehicle in front is reducing it’s speed.
Using the brakes will dissipate the energy produced by the engine in form of heat in the brake disks, which is not desirable. However the HDV utilises the brakes when distance to target is too small. The oscillations visible are small and not high frequency, typically around 5 s, and caused by the target vehicle’s oscillating velocity. The motion was perceived as smooth.
In Figure 3.8, the second heat of the highway scenario is depicted. One can clearly see the target braking two times in the upper plot, the two drops in target velocity at 232 s and 245 s.
The controller handles this braking and accelerating and smoothens out the sudden change
in target velocity. The slow diminishing of distance error is due to giving the controller higher
emphasis on velocity tracking rather distance tracking. When tuning the controller for tighter
distance keeping it was perceived as too aggressive by the driver.
jonfag@kth.se Jonathan Fagerström September 23, 2016
110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 time [s]
8 9 10 11 12 13 14 15 16 17 18 19 20
Velocity [m/s]
Highway scenario, Heat 2
Vego Vtgt
110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 time [s]
15 20 25 30
Distance[m]
Distance Desired distance
Figure 3.8: Highway scenario, heat 2. Start of heat at 15 m/s and a large deceleration towards the end. The offset in distance at the beginning is due to initialising the control around 4 m from desired distance. When levelling out at lower speed at 250 s the controller overshoots around 2 m from desired distance.
Page 30 of 49
110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 time [s]
-3 -2 -1 0 1 2 3
Velocity error [m/s]
Highway scenario, Heat 2
110 120 130 140 150 160 170 180 190 200 210 220 230 240 250 260 270 280 time [s]
-5 0 5
Distance error [m]
Figure 3.9: Highway scenario, heat 2. The oscillations in velocity are induced by target vehicle. The sinks in distance errors at 232 s and 245 s are agin due to being conservative of braking and only applying the brakes when distance to target is too small. The oscillations in target vehicle speed efter 230 s is the target vehicle first applying breaks then acceleration for a short period and then again breaks.
The third and final highway scenario can be seen in Figures 3.10-3.11. As in Figures 3.6-??,
one can see that the system is conservative of using the brakes.
jonfag@kth.se Jonathan Fagerström September 23, 2016
160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460 time [s]
0 2 4 6 8 10 12 14 16
Velocity [m/s]
Highway scenario, Heat 2
Vego Vtgt
160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460 time [s]
10 15 20 25 30
Distance[m]
Distance Desired distance
Figure 3.10: Highway scenario, heat 3. The heat starts at low velocity and accelerates up to 14 m/s.
After that there is some reduction in velocity until the end of the scenario.
Page 32 of 49
160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460 time [s]
-3 -2 -1 0 1 2 3
Velocity error [m/s]
Highway scenario, Heat 2
160 180 200 220 240 260 280 300 320 340 360 380 400 420 440 460 time [s]
-7 -6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6 7
Distance error [m]
Figure 3.11: Highway scenario, heat 3. In the upper plot it is visible that the velocity keeping is good with a maximum deviation of less than 2 m/s during braking and acceleration.
In appendix A the plots of the highway scenario with higher resolution are presented.
3.3.2 S CENARIO 2, INTERSECTION
Until the vehicle enters the CZ, the controller tracks a speed profile given by a planner, which
is required such that all vehicles get into the CZ at the same time. After entering the CZ the
controller tracks the speed and distance of the priority vehicle. The planning can be seen in
Figure 3.12 as v t g t from 30-44 s. When entering the competition zone the HDV switches from
following the planner to follow the pace car, this is visible as the vertical line at 38.6 s, when
target is switched from the planner to the pace car. As the pace car and the truck enters the
CZ at the same time the truck is virtually "on" the pace car, this is represented by the distance
error being ca. −20 m in the lower plot in Figure 3.13. When this happens the truck begins to
brake until the pace car has passed the intersection.
jonfag@kth.se Jonathan Fagerström September 23, 2016
26 28 30 32 34 36 38 40 42 44 46
time [s]
0 2 4 6 8 10 12 14
Velocity [m/s]
Intersection scenario, Heat 1
Vego Vtgt
26 28 30 32 34 36 38 40 42 44 46
time [s]
-10 -5 0 5 10 15 20 25 30 35
Distance[m]
Distance Desired distance
Figure 3.12: Intersection scenario, heat 1. First a constant acceleration reference from the planner and then switch to virtual platooning with priority vehicle.
Page 34 of 49
26 28 30 32 34 36 38 40 42 44 46 time [s]
-3 -2 -1 0 1 2 3 4 5 6 7
Velocity error [m/s]
Intersection scenario, Heat 1
26 28 30 32 34 36 38 40 42 44 46
time [s]
-25 -20 -15 -10 -5 0 5 10 15
Distance error [m]
Figure 3.13: Intersection scenario, heat 1. Due to the delay of the driver the controller is not able to catch up properly and hence is 5 m from the CZ.
When the logic switches from tracking the planning to tracking the priority vehicle there are two samples that are wrong, this is possibly some bug. It is visible at 38.6 s in Figures 3.12 and 3.13 were V tgt goes to minus infinity during these two samples, and desired distance switches from infinity to minus infinity. This is thought to be in the software keeping track of targets, and could not be resolved in the time frame, since the there was no impact in performance it was not investigated further. This phenomena is too short to have any impact in performance and is occurring in all three heats.
It is not possible to control the truck’s EMS when at standstill. The clutch in the gearbox must be fully engaged in order to send velocity requests to the EMS. This resulted in when the planner started, the passenger monitoring the system, had to tell the driver to push the accelerator pedal until the clutch was fully engaged. This results in a delay visible from 30 s in Figure 3.12. This delay was typically around 2.5 s. Furthermore it is visible in the Figure that gear changes are slow and result in not desirable behaviour when accelerating, as seen in the same Figure at 35 s.
In Figures 3.14-3.15 the second heat of the intersection scenario can be seen. Compared
jonfag@kth.se Jonathan Fagerström September 23, 2016
to Figures 3.12-3.13, the truck behaves similarly in this heat. The overshoot in velocity is due to the fact that the truck is too far back from the desired distance to the planner. The time to reach the competition zone was set to 20 s, thus requiring large acceleration effort from the truck. This is not enough time for the truck to reach 30 km/h in a calm way, hence the overshoot.
30 32 34 36 38 40 42 44 46 48 50 52 54
time [s]
0 2 4 6 8 10 12 14
Velocity [m/s]
Intersection scenario, Heat 3
Vego Vtgt
30 32 34 36 38 40 42 44 46 48 50 52 54
time [s]
-10 -5 0 5 10 15 20 25 30 35
Distance[m]
Distance Desired distance
Figure 3.14: Intersection scenario, heat 2. Due to driver delay the controller overshoots velocity to keep the distance, resulting in the HDV being 4 m from CZ with 9 m/s rather than 8.33 m/s. The slowing down to let priority vehicle pass is clearly visible from 44-54 s
.
Page 36 of 49
30 32 34 36 38 40 42 44 46 48 50 52 54 time [s]
-4 -3 -2 -1 0 1 2 3 4 5 6 7
Velocity error [m/s]
Intersection scenario, Heat 3
30 32 34 36 38 40 42 44 46 48 50 52 54
time [s]
-25 -20 -15 -10 -5 0 5 10 15 20
Distance error [m]
Figure 3.15: Intersection scenario, heat 2. Velocity error and Distance error during the heat. The erroneous samples visible at 44 s are two samples and hence not enough to make an impact in performance.
In Figure 3.16 the planner was set to accelerate with 1.2 m/s 2 compared to the other heats
were the acceleration was set to 1 m/s 2 . The acceleration of 1.2 m/s 2 is too much for the truck
to handle and, together with driver delay, therefore lags behind and is not able to catch up
when entering the competition zone.
jonfag@kth.se Jonathan Fagerström September 23, 2016
106 108 110 112 114 116 118 120 122 124 126
time [s]
0 2 4 6 8 10 12 14
Velocity [m/s]
Intersection scenario, Heat 2
Vego Vtgt
106 108 110 112 114 116 118 120 122 124 126
time [s]
-10 -5 0 5 10 15 20 25 30 35 40 45
Distance[m]
Distance Desired distance
