Ecological Cooperative Adaptive Cruise Control for Autonomous Electric Vehicles BY LORENZO BERTONI Politecnico di Torino, Turin, Italy, 2016 THESIS Submitted as partial fulfillment of the requirements for the degree of Mechanical Engineering in the Graduate College of the University of Illinois at Chicago, 2017 Chicago, Illinois Defense Committee: Sabri Cetinkunt, Chair and Advisor Arunkumar Subramanian Marco Masoero, Politecnico di Torino
106
Embed
Ecological Cooperative Adaptive Cruise Control for ...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Ecological Cooperative Adaptive Cruise Control for Autonomous Electric
Vehicles
BY
LORENZO BERTONIPolitecnico di Torino, Turin, Italy, 2016
THESIS
Submitted as partial fulfillment of the requirementsfor the degree of Mechanical Engineering
in the Graduate College of theUniversity of Illinois at Chicago, 2017
Chicago, Illinois
Defense Committee:
Sabri Cetinkunt, Chair and Advisor
Arunkumar Subramanian
Marco Masoero, Politecnico di Torino
ACKNOWLEDGMENTS
Firstly, I express my gratitude to Jacopo Guanetti. This work would not have been possible
without his guidance, support and patience. I am also very grateful to Francesco Borrelli for
welcoming me in his lab and for his precious advices.
Furthermore, I would like to thanks my advisors Sabri Cetinkunt and Marco Masoero for
their cooperation and for providing me the possibility to conduct my research at the University
of California, Berkeley.
Another thanks goes to my colleagues in the Model Predictive Laboratory for being very
helpful. A special thanks goes to Valerio Turri, from KTH, for his valuable inputs.
I am very grateful to my parents for all the support the always gave me, that means a lot
FIGURE PAGE1 Linear approximation and regression curve of experimental data (1) . . . . 262 Powertrain scheme in an electric vehicle . . . . . . . . . . . . . . . . . . . . 293 Nominal torque for an electric motor of 12 kW . . . . . . . . . . . . . . . . 304 Powertrain model of an electric motor: experimental data (blue dots) and
5 Analytical optimal motor torque in its six different phases . . . . . . . . . 516 Analytical optimal speed (first plot) and position (second plot) profiles . . 527 Torque comparison using analytical solution and dynamic programming
using analytical solution and dynamic programming approach . . . . . . . 559 Relative speed between the ego and the target vehicle with and without
penalization of the kinetic energy . . . . . . . . . . . . . . . . . . . . . . . . 6310 Relative speed (first plot) and distance (second plot) between the ego and
the target vehicle with and without the terminal costs . . . . . . . . . . . . 6811 QSS outline and elements not included in the model adopted in the Eco-
the Silicon Valley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7213 Extract of speed profile of target and ego vehicles (first plot) and their
relative distance (second plot) of “Highway Scenario 1” . . . . . . . . . . . 7614 Speed profile of target and ego vehicles (first plot) and their relative dis-
tance (second plot) of “Highway Scenario 1” . . . . . . . . . . . . . . . . . . 7715 Comparison between the controller optimal torque and the QSS validation
using the same speed profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7816 Energy consumption comparison using the Eco-CACC and a traditional
ACC resulting in energy saving of 15.6 % . . . . . . . . . . . . . . . . . . . 7917 Speed profile of target and ego vehicles (first plot) and their relative dis-
tance (second plot) in “Highway Scenario 2” . . . . . . . . . . . . . . . . . . 8018 Speed profile of target ego vehicles (first plot) and their relative distance
(second plot) in an urban scenario . . . . . . . . . . . . . . . . . . . . . . . . 8219 Computational time in Matlab environment of ”Highway Scenario 2” with
Scenario 3” are shown in the first second and last plot respectively . . . . 8721 Computational time comparison between IPOPT and FORCES solvers. . 8922 Computational time during a Hardware in the Loop simulation with Ts=0.1
However, a terminal cost with a cubic function of the states such as Equation 6.12 makes
the problem too complex to be solved in a reasonable time.
The best solution would be to obtain a linear functon of the states. In this way the terminal
cost would not add any complexity to the optimization procedure.
For these purposes, it is possible to write p2(xt+N ) as function of the relative distance d
between the two vehicles, since:
d = smax,N − sN (6.15)
Substituting, we obtain the following expression of the terminal cost:
p2(xt+N ) = A(d3 − 3 d2 smax,N + 3 d s2max,N ) +B d (6.16)
67
Considering a prediction horizon of N = 10s and an average speed of the ego vehicle of
v = 20 ÷ 22m/s we obtain smax,N ≈ 200m while d can always vary from 2 to 20 meters.
Therefore, the first two terms in the expression are negligible since they appears to be two or
three orders of magnitude smaller than the third one, and the terminal cost can be written as:
p2(xt+N ) ≈ (3As2max,N +B)(smax,N − sN ) (6.17)
Equation 6.17 is now a linear function of the states, since the only variable is sN , the position
of the ego vehicle at the end of the horizon. A, B and smax,N are just constant values.
6.5 Results
Results on the impact of the terminal costs are now presented. The scenario considered
is again the one in which the target vehicle is traveling at a constant speed and no air drag
reduction is included in the simulation. The ego-vehicles starts at a intermediate relative
distance sin = 12m and the two vehicles starts at the same speed vin = 22m/s.
It is possible to note how in the baseline scenario (with no terminal costs) the ego vehicle
has the minimum possible speed at the end of the horizon and it has traveled the minimum
possible distance. Introducing the terminal cost on the kinetic energy, the vehicle would not
tend anymore to decrease its speed but still at the end of the horizon it is as far as permitted
from the target vehicle. Introducing both terminal costs, the ego vehicle follows the target
vehicle at a constant speed and at a constant distance.
68
Figure 10: Relative speed (first plot) and distance (second plot) between the ego and the targetvehicle with and without the terminal costs
The main goal of introducing terminal costs is to approximate the behavior of the vehicle
after the end of the horizon. Therefore, they will be use in every simulation from now on. Their
validity is general since the theory presented has nothing to do specifically with the scenario
presented.
CHAPTER 7
CLOSED LOOP SIMULATIONS WITH EXPERIMENTAL FORECAST
In this chapter simulation results of the Eco-CACC developed are presented. The scenarios
have been chosen in order to show the behavior of the powertrain controller in different situ-
ations. A comparison with a traditional Adaptive Cruise Control in terms of energy savings
is also presented. Forecast of position and speed of the target vehicle are obtained using ex-
perimental data. In particular, data from a real vehicle have been collected while driving in
different roads and highways around the Silicon Valley . Furthermore, an external Simulink
toolbox provides a better estimate of the energy savings of the Eco-CACC.
7.1 QuasiStatic Simulation Toolbox
QuasiStatic Simulation Toolbox (QSS TB) is a Simulink toolbox that permits to estimate
fuel consumption for the majority of powertrain systems, including the electric ones. It is very
simple and fast to use. At the same time, it provides quite accurate results [20].
It reverses the relationship of cause-effect that exists in a dynamic system: it does not
uses forces to determine accelerations and speed profiles but the exact opposite. It calculates
acceleration and it determines the necessary forces starting from a given speed profile.
The QSS TB approach can not capture dynamic phenomena (represented by differential
equations) since it is a QuasiStatic approach. However, it takes into account various elements
which are not considered in the powertrain model adopted in the controller.
69
70
7.1.1 QSS Outline
Figure 11: QSS outline and elements not included in the model adopted in the Eco-CACC
As it possible to see from Figure 11, QSS receives as an input the speed profile and it
provides the fuel consumption of the electric battery of the vehicle considered. To do so, it
takes into account different elements not included in the powertrain model.
The equations of the vehicle dynamics do not change but a non-linear air drag dependence
function of the distance instead of a linear one has been considered. There are not real-time
issues in the energy savings calculation, so accuracy can be increased.
Regarding the transmission part of the model, the idle power loss is here included and it
is also possible to take into account the switching model caused by the transmission efficiency
71
property. In the model adopted by the controller we included the transmission efficiency in the
efficiency map of the motor, but in this case is possible to include the switching model directly
in the transmission model.
The electric motor model considered is far more complex than the one adopted by the
controller since it takes into account inertia, an efficiency map and even an overload check which
prevents the motor from working out of its speed and torque boundaries. Battery efficiency is
also considered, function of the current i and of the state of charge (SOC). These dependences
are usually non-linear and too complex to be included in the controller model.
7.1.2 QSS Goals
QSS is used in this work for two main puroposes:
• Model validation
• Fuel consumption estimation
QSS TB can be used as a model validator since it reverses the cause-effect relationship of
the dynamic systems. The powertrain controller finds the optimal torque for a certain system.
The torque is then applied to the model and the consequent acceleration is obtained. From the
acceleration profile a consequent speed profile is finally determined. This speed profile can be
adopted as input of QSS TB. Reversing the usual cause-effect relationship, the toolbox obtains
the consequent torque. If the QSS torque is similar to the Eco-CACC one, it means that the
simplified model adopted in the controller is acceptable.
The main function of the toolbox is to provide the fuel consumption for a powertrain sys-
tem. In the case of electric motor it gives the battery consumption for a given speed profile.
72
We can compare the battery consumption obtained using the Eco-CACC with respect to the
consumption of a traditional ACC.
7.2 Simulation Setup
7.2.1 Forecast Data
Figure 12: Experimental speed profile collected driving in the Highway 101 around the SiliconValley
73
The results presented in this chapter are simulations obtained in a Matlab environment.
However, the forecast data that the ego vehicle receives from the target vehicles are experimental
data which have been collected driving a real car in the highway and in urban roads around the
Silicon Valley. The trajectory of the ego vehicle is always bounded by the position of the target
vehicle. Using real data we assure that the optimal trajectory obtained for the ego vehicle can
be associated with realistic scenarios.
Note that even if all the trajectory of the target vehicle is known in advance, the controller
is set up to receive just the portion of data within its prediction horizon.
7.2.2 Energy Savings
The total energy consumption of the vehicle is an important parameter but is more conve-
nient to analyze the energy savings that the Eco-CACC can perform with respect to a baseline
controller. We consider as a baseline controller an Adaptive Cruise Control that simply follows
the target vehicle at a fixed distance of 12 meters. In both cases, the fuel consumptions are
calculated using the QuasiStatic Toolbox.
7.2.3 MPC Parameters
A table with the MPC parameters used in all the simulations is presented.
The sampling time choice is a trade-off between computational power and accuracy. In
literature different choices are described; generally they go from 0.05 seconds [28] to 0.5 seconds
[29]. The smaller the sampling time the better it is. For our purposes, a sampling time of 0.5
seconds would not make the solution feasible, taking into account that a car would travel several
meters between one sample time and the other. On the other hand, the smaller the sampling
74
TABLE II: MPC PARAMETERS
Name Symbol Value
Prediction Horizon [s] N 10Sampling time [s] Ts 0.1Minimum relative distance [m] dmin 2Maximum relative distance [m] dmax 20Initial relative distance [m] din 12
time, the more computational power is required with the risk that the controller can not work
in real time. A sample time of 0.1 seconds is considered a good trade-off for this work: it makes
the solution feasible in all the scenarios adopted and the controller turns out to be powerful
enough to be able to work in real time.
A prediction horizon of 10 seconds is an optimistic assumption. It means that the ego
vehicle knows in advance the trajectory of the target vehicle for the future 10 seconds. This
assumption is not always realistic in case of traffic or with a non-autonomous target vehicles.
In those conditions, the simulations can fully show the potentiality of the Eco-CACC as well
as an upper bound on the energy savings.
A minimum distance of two meters between vehicles is commonly adopted in the platoon
literature [30]. High speeds, acceleration or decelerations of the vehicles and communications
delays can easily lead to safety problems. However, in this work, we do not take care of safety
issues at a deep level. We analyze the full potentiality of the controller, taking into account
that an emergency braking system can be necessary in order to guarantee safety.
75
A maximum relative distance of 20 meters has been chosen accordingly to the prediction
horizon of 10 seconds. In order for the controller to work at its full potentiality, the ego vehicle
needs to be able to have full capacity of movement within its position boundaries. The ego
vehicle should be able to pass from dmax to dmin or vice versa in 10 seconds. Otherwise, the
optimal solution of the controller would become too much sensitive to the horizon chosen. Note
that this powertrain controller is meant to be part of a hierarchical system of two levels. The
high level should decide whether or not the ego vehicle should platoon with the target vehicle.
The assumption considered in this work is always that platooning is the best solution.
7.3 Scenarios
In this section three different simulation scenarios are proposed and analyzed. The first two
are highway scenarios, in which the vehicles travel in the highway 101. The last one presents
an urban scenario which explicitly includes traffic.
7.3.1 Highway Scenario 1
In this first case, the vehicles are traveling in the highway and the target vehicle is acceler-
ating. As it possible to note from Figure 17, initially the ego vehicle catches up with the target
vehicle. The reason is that being at a close inter-vehicular distance permits to reduce the fuel
consumption. At the same time the controller performs a speed smoothing : it tries to avoid
every speed oscillation, since this behavior would increase the amount of energy dissipated. As
a consequence, once the ego vehicle has caught up, it does not follow the target vehicle at a
fixed distance, but it continuously varies its relative distance in order to save more energy.
76
Figure 13: Extract of speed profile of target and ego vehicles (first plot) and their relativedistance (second plot) of “Highway Scenario 1”
The entire simulation has a time frame of more than three minutes in which it is possible
to observe how the optimal solution is not just a simple catch up but it requires a continuous
variation of the distance between the target and the ego vehicle. As a result, the speed profile
of the ego vehicle is smoother.
77
Figure 14: Speed profile of target and ego vehicles (first plot) and their relative distance (secondplot) of “Highway Scenario 1”
7.3.1.1 Model Validation
In this scenario a model validation of the controller is also proposed. The model adopted
by the Eco-CACC is compared with the more detailed one used in QSS TB and differences are
analyzed. As it possible to note from Figure 15 the torque obtained by the controller and the
one used for validation are very similar. The QSS torque is always a little bit higher. This result
78
Figure 15: Comparison between the controller optimal torque and the QSS validation using thesame speed profile
was expected: QSS Toolbox takes into account elements not included in the model adopted by
the controller and the majority of those elements are extra-losses. Therefore, in the QSS model
a higher torque is necessary in order to travel the same distance with the same speed.
7.3.1.2 Energy Savings
The main aim of this work is to develop a controller which provides energy savings with
respect to a more traditional form of Cruise Control. Therefore, we compare the energy con-
sumption of the vehicle using the Eco-CACC and a traditional ACC. The ACC-based ego
vehicle just follows the target vehicle at a fixed distance of din = 12m. There is neither a initial
79
Figure 16: Energy consumption comparison using the Eco-CACC and a traditional ACC re-sulting in energy saving of 15.6 %
catch up, nor a smoothing of the speed profile. Therefore, the energy savings of the Eco-CACC
can be divided into two contributes in this scenario. The first one is the fact that being at a
closer inter-vehicular distance reduce fuel consumption. The second one is that accelerations
and decelerations leads to more dissipations and the Ego-CACC tries to avoid them.
As a result, using the powertrain controller developed, energy savings of 15.6% have been
obtained with respect to an Adaptive Cruise Control.
Energy savings have been calculated using QSS TB in order to obtain a more precise esti-
mation.
80
Figure 17: Speed profile of target and ego vehicles (first plot) and their relative distance (secondplot) in “Highway Scenario 2”
7.3.2 Highway Scenario 2
This scenario represents a slow-down scene in the highway. The target vehicle, after a first
acceleration, starts to decelerate. The optimal solution provided by the Eco-CACC has similar
characteristics of the one described in “Highway Scenario 1”. First, there is a catch up. After
that the ego vehicle does not follow the target one at a fixed distance but it continuously changes
81
the relative distance. Again, the ego vehicle speed profile is smoother than the one of the target
vehicle.
However, in this case, the first catch up would not be necessary. In the global optimal
solution, the ego vehicle would have waited more time before to catching up. This limitation is
given by the prediction horizon. The controller knows the behavior of the target vehicle for the
future 10 seconds, not for the whole trajectory and therefore, at time zero, it can not predict a
future deceleration of the target vehicle.
In this scenario, the energy savings obtained using the Ego-CACC with respect to an ACC
are 21.7 %. This value, as mentioned before, can be considered as an upper bound since it
is not always possible to know the behavior of the target vehicle in the future 10 seconds. At
the same time, the controller can work with any horizon. The shorter the horizon the less
the energy savings. In any case, the controller will compute the optimal trajectory using the
available data.
7.3.3 Urban Scenario
An urban scenario is now presented. In this case, the traffic conditions play an important
role in the simulation. The target vehicle speed profile presents wide oscillations due to the
traffic on the road. In this case, the optimal solution for the ego vehicle is not represented by an
initial catch up. The oscillations are too wide and the savings obtainable thanks to a reduced
aerodynamic force would be compensated by losses due to accelerations and decelerations. As
a consequence, the relative distance between the two vehicles varies a lot during the simulation.
82
Figure 18: Speed profile of target ego vehicles (first plot) and their relative distance (secondplot) in an urban scenario
Very high energy savings of 73.4 % with respect to the baseline ACC have been obtained.
However in this scenario, due to the traffic conditions, availability of forecast is not always
possible. Also, the flexibility of the ego vehicle in deciding its speed and position may be limited
by other closeby vehicles. On the other hand, this scenario fully underlines the potentiality of
the Eco-CACC in terms of energy savings.
83
It may be not possible to have a perfect forecast of 10 seconds due to the traffic but as an
alternative it is possible to consider an approximate forecast. For this case, the speed profile of
the target vehicle can be modeled as a sinusoidal trajectory. Even if the powertrain controller
does not receive a perfect forecast, it can still elaborate a future forecast using the frequency
and the amplitude of the modeled sinusoidal trajectory. Energy savings of 73.4 % demonstrate
that there is big room for acceptable results even without a perfect forecast. This topic will be
part of future work, though, and it is not discussed further in this thesis.
CHAPTER 8
EMBEDDED IMPLEMENTATION
All the simulations presented in the previous chapters have been developed using software
tools such as Matlab and Simulink, which are non-real-time environments. In this chapter,
the computational time issue is analyzed in more detail. A real software in a vehicle can not
run on Matlab environment, though. An embedded software has to be written for a particular
hardware. This fact usually implies time and memory constraints. The algorithm has been
rewritten in a suitable environment for embedded implementation and time issues have been
faced and solved. Moreover, hardware in the loop simulations have been tested, in order to
move a step forward for the implementation of the code in a real vehicle.
8.1 Time Constraint
One of the biggest issue in the development of a real-time algorithm is the time constraint.
In the previous simulations we adopted a prediction horizon of 10 seconds. Which means that
the controller needs to find an optimal solution for the next ten seconds. This procedure has
to be entirely repeated every sampling time, i.e. every 0.1 seconds. If the controller needs
more than 0.1 seconds to find the optimal solution, then it does not have time for the next
optimization. The controller can work in real-time only if every optimization requires less than
the sample time to be solved. If the condition is not satisfied, the only way is to increase the
84
85
sampling time or to decrease the prediction horizon with repercussions on the quality of the
solution.
The algorithm has been written trying to avoid as many non-linearities as possible in the
model in order to decrease the process time during the optimization. Prediction horizon and
sampling time have been chosen in such a way that the algorithm always works in real-time
when it runs on Matlab. In Figure 19, a graphical representation is shown.
However, for a given scenario, computational time depends on the hardware used and on
the solver chosen for the algorithm. For this reason, there is no guarantee that the solver can
really work on a real vehicle yet.
86
Figure 19: Computational time in Matlab environment of ”Highway Scenario 2” with N=10s,
Ts=0.1s
8.2 FORCES Pro Code Generator
FORCES Pro [31] is a tool for mathematical optimization. It converts a code written in
Matlab into a C-language code which can be implemented in an embedded system. In other
87
words, this tool is a code generator. The optimal problem needs to be rewritten using FORCES
syntax but still in a Matlab environment. Then, the optimal control problem is not solved
anymore using IPOPT [27] but always with interior point methods.
Figure 20: Optimal torque, speed and relative distance of the ego vehicle in ”Highway Scenario3” are shown in the first second and last plot respectively
88
Matlab environment is very convenient for pure software simulation but the code can not
be used for hardware simulation, in other words for real testing. The code needs to be written
using C language in order to be implemented on an embedded platform.
This tool has its own Matlab syntax and a new code has been developed. The main difference
with the previous one is the initial guess. The code generated by FORCES Pro requires an
initial guess for all the states of the system, not just for the initial ones. At any time different
from zero the initial guess is given by the optimal solution at the previous time step. At time
zero a input sequence of zero value is guessed and applied to the dynamic system.
The initial guess choice is important since it affects the computational time of the solution.
Once the optimal problem is written, the code is automatically generated on line using
FORCES Pro servers. It turns out that the solver, which uses C language is much faster that
the one created on Matlab environment. Furthermore, this code can be perfectly embeddable
on any implementation which has a C compiler.
In order to compare the two solvers and their computational time, we analyze a new scenario
(“Highway Scenario 3”). Similarly to the previous ones, a target vehicle is accelerating in the
highway and then suddenly decelerating. Every parameter is identical to the previous scenarios
except for the prediction horizon. It has been set to 12 s in order to stress more the time
constraints of the solvers.
As it is possible to note from Figure 20, both interior point solvers obtain an almost identical
solution for the same scenario. Since the problem is nonlinear, the same optimal solution is not
guaranteed and some small differences in the solution are expected. The most notable aspect
89
Figure 21: Computational time comparison between IPOPT and FORCES solvers.
is highlighted in Figure 22, though. FORCES solver is about five time faster with respect to
IPOPT one. This is a positive result, since it is the C code generated by FORCES the one that
can be actually implemented in an embedded machine.
90
8.3 Hardware in the Loop Simulation
Until now, a control software has been developed and tested in a non-real-time environment.
However, pure software based simulations can not capture sufficiently real-time conditions and
they can not provide enough confidence and reliability. Therefore, it is wise to consider an
intermediate phase in the middle between pure software and pure hardware testing on a real
machine. This phase is called Hardware in the Loop (HIL) Simulation.
This process consists in testing the control software on a target Electronic Control Module
(ECM) simulator in real-time. The hardware is then connected to another computer which
simulates the controlled process dynamics in real-time. In this way, it is possible to test the
control software on a real hardware without using a real plant (such as a real vehicle).
In this thesis we analyze the algorithm developed on the computational time point of view.
A dSPACE HIL simulator has been used in order to simulate an Electronic Control Module.
Until now, every simulation run on a generic computer processor and, therefore, it could not
provide a precise indication regarding whether or not the algorithm developed effectively works
in real-time.
dSpace MicroAutobox 1401, (IBM PowerPC processor capable of running at 800 MHz) has
been used for the HIL simulation.
The result obtained is shown inFigure 22 and it proves that the controller can be embeddable
in a real machine with a sample time of 0.1 and an horizon of 8 seconds.
91
Figure 22: Computational time during a Hardware in the Loop simulation with Ts=0.1 s andN=8 s
CHAPTER 9
CONCLUSION
This chapter presents general conclusions of the work developed.
Optimal control theory has provided the basis for the creation of an Ecological Coopera-
tive Adaptive Cruise Controller that aims to minimize fuel consumption of electric vehicles.
The main idea consists in taking advantage of platooning in terms of fuel consumption while
maintaining a spontaneous approach.
Various steps have been necessary in order to develop a real time optimal controller.
First, we have discussed the longitudinal dynamic of the vehicle, capturing elements which
play an important role in terms of fuel consumption. Air drag coefficient has been modeled as a
function of the relative distance between vehicles. The powertrain model of the electric vehicle
has been also developed using experimental data from a real electric motor.
Second, we have analyzed different optimization techniques, both analytical and numerical.
We have compared them and outlined their potentialities and drawbacks, and we have finally
chosen the technique which best address our needs.
Third, we have designed a model predictive controller for real-time implementations of
the Eco-CACC. The terminal costs have especially been designed to give the controller the
capability to anticipate what is gonna happen to the vehicle after the horizon.
At this point, once the optimization technique have been chosen and the control problem
defined, we have extensively tested the Eco-CACC. We have evaluated different highway and
92
93
urban scenarios using experimental data collected driving in the Highway 101 and in the urban
areas of the Silicon Valley around the city of San Francisco. Then, we have evaluated the
performances of the Eco-CACC in terms of fuel consumption, making a comparison with a
traditional ACC. Energy savings have been calculated using a high-accuracy model. The same
model has been used also to validate the simplified model adopted in the powertrain controller.
Finally, we have addressed the problem of computational time. We made sure the con-
troller is able to work in real-time, and not just during simulations in a Matlab environment.
Hardware in the loop simulations have been performed implementing a C-language code into
HIL simulator. The positive results make the controller ready to be tested on real autonomous
vehicles.
CITED LITERATURE
1. Hucho, W.-H.: Aerodynamics of road vehicles. Butterworth-Heinemann, (1987).
2. Environmental Energy Agency: Eurostat Statistics. url: http://ec.europa.eu/eurostat/.
3. Association For Safe International Road Travel: Annual global road crash statistics.[Online]. http://asirt.org/initiatives/informing-road-users/road-safety-facts/road-crash-statistics.
4. Sciarretta, A., De Nunzio, G., and Ojeda, L. L.: Optimal ecodriving control: Energy-efficient driving of road vehicles as an optimal control problem. IEEE ControlSystems, 35(5):71–90, Oct 2015.
5. Dib, W., Chasse, A., Moulin, P., Sciarretta, A., and Corde, G.: Optimal energy manage-ment for an electric vehicle in eco-driving applications. Contr. Eng. Prac., 29:299–307, Aug 2014.
6. Chang, D. and Morlock, E.: Vehicle speed profile to minimize work and fuel consumption.Journal of Transportation Engineering, 18:173–182, 2005.
7. Shladover, S.: PATH at 20. history and major milestones. IEEE Transactions on IntelligentTransportation Systems, 8:584–592, 2007.
8. Turri, V., Besselink, B., and Johansson, K. H.: Cooperative look-ahead control for fuel-efficient and safe heavy-duty vehicle platooning. IEEE Transaction on ControlSystem Technology, PP(99):1–17, April 2016.
9. Turri, V.: Fuel-efficient and safe heavy-duty vehicle platooning through look-aheadcontrol. SE-100 44 Stockholm, Sweden, KTH School of Electrical Engineering,(2015). Licentiate thesis.
10. Argonne National Laboratory USA: [Online]. http://energy.gov/eere.
11. Basso, M.: Eco Platoon Formation For Autonomous Electric Vehicles. Politecnico diTorino, (2016). Licentiate thesis.
94
95
CITED LITERATURE (continued)
12. Guo, J. and Balon, N.: Vehicular ad hoc networks and dedicated short-range communica-tion. Technical report, University of Michigan, Deaborn, MI, USA, 2006.
13. Santa, J., Gomez-Skarmeta, A. F., and Sanchez-Artigas, M.: Architecture and evaluation ofa unified V2V and V2I communication system based on cellular networks. ComputerCommunications, 31(12):2850–2861, 2008.
14. Sahlholm, P. and Johanson, K. H.: Road grade estimation for look-ahead vehicle controlusing multiple measurement runs. Control Engineering Practice, 18(11):1328–1341,2010.
15. Borrelli, F., Bemporad, A., and Morari, M.: Predictive control for linearand hybrid systems. (2015). In preparation, available online at
http://www.mpc.berkeley.edu/mpc-course-material.
16. Bellman, R.: Dynamic Programming. Princeton, NJ, USA, Princeton University Press,(1957).
17. Bertsekas, D.: Dynamic Programming and Optimal Control, volume II. Belmont, Mas-sachusetts, USA, Athena scientific, 2001.
18. Richalet, J., Rault, A., Testud, J. L., and Papon, J.: Model Predictive Heuristic Control:Applications to Industrial Processes. Automatica, (1978).
19. Guzzella, L. and Sciarretta, A.: Vehicle Propulsion Systems, Introduction to modeling andoptimization. Springer, (2005). Third edition.
20. Guzzella, L. and Amsutz, A.: The QSS Toolbox Manual. Institute of Energy TechnologyETH Zurich, 2005.
21. Wipke, K. B. and Cuddy, M. R.: Using an Advanced Vehicle Simulator ADVISOR toGuide Hybrid Vehicle Propulsion System Development. National Renewable En-
ergy Laboratory, Golden, CO, USA, 1996. http://www.hev.doe.gov.
22. Bryson, A. E. and Ho, Y. C.: Applied optimal control: optimization, estimation andcontrol. Washington, D.C., Hemisphere, (1975).
23. Pontryagin, L. S., Boltyanskii, V., Gamkrelidze, R. V., and Mischchenko, F.: TheMathematical Theory of Optimal Processes. New York, Interscience, (1962).
96
CITED LITERATURE (continued)
24. Sundstrom, O. and Guzzella, L.: A generic dynamic programming matlab function. ControlApplications, (CCA) & Intelligent Control (ISIC), IEEE, jul 2009.
25. Sundstrom, O. and Guzzella, L.: DPM-function. Institute for Dynamic Systems andControl Department of Mechanical and Process Engineering, ETH Zurich, 2009.http://www.idsc.ethz.ch/research/downloads.
26. Lofberg, J.: YALMIP: a toolbox for modeling and optimization in MATLAB. IEEEInternational Symposium on Computer Aided Control System Design, Sept 2004.
27. Wachter, A. and Biegler, L. T.: On the implementation of a primal-dual interior pointfilter line search algorithm for large-scale nonlinear programming. MathematicalProgramming, 106(1):25–57, 2006.
28. Turri, V., Besselink, B., Martesson, J., and Johansson, K. H.: Fuel efficient heavy dutyvehicle platooning by look ahead control. 53rd IEEE Conference on Decision andControl, December 2014.
29. Santin, O., Pekar, J., Beran, J., and D’amato, A.: Cruise controller with fuel optimiza-tion based on adaptive nonlinear predictive control. SAE Int. J. Passeng. Cars -Electron. Electr Syst., May 2016.
30. Alam, A., Gattami, A., Johannson, K., and Tomlin, C. J.: Guaranteeing safety forheavy duty vehicle platooning: Safe set computations and experimental evaluations.Contr. Eng. Prac., 24:33–41 2014.
31. Domahidi, A. and Jerez, J.: FORCES Professional. embotech GmbH (url:http://embotech.com/FORCES-Pro), July 2014.
32. Bertoni, L.: Ecological Cooperative Adaptive Cruise Control for Autonomous ElectricVehicles. Politecnico di Torino, (2016). Licentiate thesis.
33. Zheng, Y., Li, S. E., Li, K., Borrelli, F., and Hedrick, J. K.: Distributed model predictivecontrol for heterogeneous vehicle platoons under unidirectional topologies. In IEEETransaction on Control System Technology, 2016.
VITA
NAME Lorenzo Bertoni
EDUCATION
Master of Science in “ Mechanical Engineering ”, University of Illinoisat Chicago, Dec 2016, USA
Specialization Degree in “ Energy and Nuclear Engineering ”, Oct 2016,Polytechnic of Turin, Italy
Bachelor’s Degree in Energy Engineering, Jul 2014, Polytechnic ofTurin, Italy
LANGUAGE SKILLS
Italian Native speaker
English Full working proficiency
2014 - IELTS examination (7.0)
A.Y. 2015/16 Two semesters of study abroad at University of Califor-nia, Berkeley
A.Y. 2015/16 One semester of study abroad in Chicago, Illinois
SCHOLARSHIPS
Fall 2015 Italian scholarship for final project (thesis) at UIC
Fall 2015 Italian scholarship for TOP-UIC students
TECHNICAL SKILLS
Advanced level Matlab and Simulink
Average level ERP SAP SD
WORK EXPERIENCE AND PROJECTS
2017/Present Consultant at Oliver Wyman
2014/2015 Research Assistantship (RA) position (10 hours/week) at Polytechnicof Turin, Italy
2014/2015 Co-Founder of a startup (Corner Pop)
97
98
VITA (continued)
Ago 2014 Volunteer in Africa. Hospital La Croix, Cotonou (Benin)