Enhanced Driver in Full Vehicle HIL-Simulator

(1)

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Enhanced Driver in Full Vehicle HIL-Simulator

Examensarbete utfört i Reglerteknik vid Tekniska högskolan vid Linköpings universitet

av Dennis Forsberg LiTH-ISY-EX–15/4882–SE

Linköping 2015

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

(2)

(3)

Enhanced Driver in Full Vehicle HIL-Simulator

Examensarbete utfört i Reglerteknik

vid Tekniska högskolan vid Linköpings universitet

av

Dennis Forsberg LiTH-ISY-EX–15/4882–SE

Handledare: Jonas Linder

isy, Linköpings universitet

Fredrik Glans Scania

Examinator: Svante Gunnarsson

isy, Linköpings universitet

(4)

(5)

Avdelning, Institution Division, Department

-Department of Electrical Engineering SE-581 83 Linköping Datum Date 2015-08-22 Språk Language Svenska/Swedish Engelska/English Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport

URL för elektronisk version

http://www.ep.liu.se

ISBN — ISRN

LiTH-ISY-EX–15/4882–SE

Serietitel och serienummer Title of series, numbering

ISSN —

Titel

Title Enhanced Driver in Full Vehicle HIL-Simulator

Författare Author

Dennis Forsberg

Sammanfattning Abstract

Tekniska framsteg och hög konkurrens innebär att de elektroniska systemen i fordon såsom lastbilar och bussar snabbt blir mer och mer avancerade. Detta leder till att det krävs kontin-uerlig utveckling och avancerad testning av dessa produkter. På Scania, som är en producent av lastbilar och bussar, har man valt att bygga en simulator för att utföra tester av elektron-iska system i ovan nämnda fordon. Ett komplett fordon skapas i simulatorn där den fyselektron-iska elektroniken testas och övriga signaler simuleras. En av de komponenter som idag simuleras är en föraralgoritm vars uppgift är att styra fordonet. Det faktum att denna föraralgoritm är en integrerad del av simuleringen gör det svårare att utföra förändringar och underhåll av denna. Man är därför intresserad av att skapa en extern föraralgoritm, det vill säga, en föraralgoritm som inte är en del av simulatorn. Under detta examensarbete har en sådan föraralgoritm skapats och testats.

Först har en förenklad fordonsmodell skapats för att kunna utföra tester av föraralgorit-men. Detta var för att förenkla implementeringen då fordonssimuleringen är en trång resurs. Två olika tillvägagångssätt har testats, dels att använda flera delmodeller och dels genom att använda en tidsvarierande fordonsmodell. Av dessa två uppvisade fordonsmodellen med den tidsvarierande modellen bäst resultat och denna användes under det resterande exam-ensarbetet.

Föraralgoritmen kan styra vinkeln på gas- och bromspedalen för att få fordonsmod-ellen att följa en önskad hastighet. För att få referensföljning används en regulator i förar-modellerna. Två olika regulatorer har testars i detta examensarbete, först en enklare PID-regulator och sedan en mer avancerad MPC-PID-regulator. Förutom att föraralgoritmen ska kunna följa en referenshastighet ska denna dessutom behandla pedalerna på ett mänskligt sätt, till exempel inte använda båda gas- och bromspedal på samma gång.

Slutligen har de båda konstruerade föraralgoritmerna jämförts med varandra och med den interna, redan existerande föraralgoritmen. I denna jämförelse uppvisade den MPC-baserade föraralgoritmen bäst resultat, vilken var nästan lika bra som den interna föraralgo-ritmen.

Nyckelord

(6)

(7)

Sammanfattning

Tekniska framsteg och hög konkurrens innebär att de elektroniska systemen i for-don såsom lastbilar och bussar snabbt blir mer och mer avancerade. Detta leder till att det krävs kontinuerlig utveckling och avancerad testning av dessa produk-ter. På Scania, som är en producent av lastbilar och bussar, har man valt att bygga en simulator för att utföra tester av elektroniska system i ovan nämnda fordon. Ett komplett fordon skapas i simulatorn där den fysiska elektroniken testas och övriga signaler simuleras. En av de komponenter som idag simuleras är en föra-ralgoritm vars uppgift är att styra fordonet. Det faktum att denna föraföra-ralgoritm är en integrerad del av simuleringen gör det svårare att utföra förändringar och underhåll av denna. Man är därför intresserad av att skapa en extern föraralgo-ritm, det vill säga, en föraralgoritm som inte är en del av simulatorn. Under detta examensarbete har en sådan föraralgoritm skapats och testats.

Först har en förenklad fordonsmodell skapats för att kunna utföra tester av föraralgoritmen. Detta var för att förenkla implementeringen då fordonssimule-ringen är en trång resurs. Två olika tillvägagångssätt har testats, dels att använda flera delmodeller och dels genom att använda en tidsvarierande fordonsmodell. Av dessa två uppvisade fordonsmodellen med den tidsvarierande modellen bäst resultat och denna användes under det resterande examensarbetet.

Föraralgoritmen kan styra vinkeln på gas- och bromspedalen för att få for-donsmodellen att följa en önskad hastighet. För att få referensföljning används en regulator i förarmodellerna. Två olika regulatorer har testars i detta examensar-bete, först en enklare PID-regulator och sedan en mer avancerad MPC-regulator. Förutom att föraralgoritmen ska kunna följa en referenshastighet ska denna dess-utom behandla pedalerna på ett mänskligt sätt, till exempel inte använda båda gas- och bromspedal på samma gång.

Slutligen har de båda konstruerade föraralgoritmerna jämförts med varandra och med den interna, redan existerande föraralgoritmen. I denna jämförelse upp-visade den MPC-baserade föraralgoritmen bäst resultat, vilken var nästan lika bra som den interna föraralgoritmen.

(8)

(9)

Abstract

The rate at which the electrical systems in vehicles such as trucks and buses ad-vance is increased due to technical improvements. This requires continuous de-velopment and advanced testing of these products. At Scania, which is a producer of trucks and buses, they have a simulator to test the electrical systems in these vehicles. A complete vehicle is created in the simulator where the psychical elec-tronics are tested and the rest of the signals are simulated. One of the simulated components is a driver algorithm which is used to control the vehicle. This driver algorithm is today an integrated part of the simulator, which makes it difficult to do maintenance and changes on the driver algorithm. Therefore they want to create an external driver algorithm, i.e. a driver algorithm that is not part of the simulator. During this thesis work this driver algorithm will be created and tested.

Firstly, a simplified vehicle model was created where it is possible to test the driver algorithm. This was to make the implementation of the driver algorithm easier, because the vehicle simulator is a narrow resource and to do all tests there would be difficult. Two different approaches were tested, firstly, a model consis-tent of submodels and secondly, a time varying linear model. The one that gave the best result was the driver algorithm with the time varying linear model, and this was used for the rest of the thesis work.

The driver algorithm can control the position of the gas and the brake pedals to make the vehicle drive at a desired velocity. To make the driver follow the desired velocity, a controller is used in the driver algorithm. Two different con-troller were tested in this master thesis, first a simple PID-concon-troller and then a more advanced MPC. In addition to the ability to follow a reference the driver algorithm is also able to behave as a human driver would, the driver algorithm do not for example use both the pedals at the same time.

Finally, both the driver algorithms will be compared with each other and with the internal, already existing driver algorithm. The MPC-based driver algorithm gave the best result, which was almost as good as the internal driver algorithm.

(10)

(11)

Acknowledgments

First of all I want to thank my supervisor at Scania, Fredrik Glans for the good dis-cussions and his support. I also want to thank the thesis’ examiner Svante Gun-narsson at Linköping University and the supervisor Jonas Linder at Linköping University for the technical help and the valuable comment on the thesis. Last but not least I want to thank my friends and family that have supported and helped me through my studies.

Linköping, June 2015 Dennis Forsberg

(12)

(13)

1

Introduction

This is the report for the master’s thesis Enhanced Driver in Full Vehicle

HIL-Simulator. This thesis has been conducted at the R&D department at Scania in Södertälje. It is a presentation of how a driver algorithm has been implemented in a HIL-simulator along with the associated results. This chapter presents the purpose and the method of the implementation.

1.1 Background

Scania’s HIL-simulator is one of the most advanced vehicle simulators in the world. The simulator includes a driver algorithm whose purpose is to control the vehicle model. The driver algorithm is at the moment integrated in the simu-lator and the simulation team at Scania is interested in constructing an external driver algorithm to replace the internal driver algorithm that is used today.

The HIL-simulator is a limited resource and in order to relieve the simulator, Scania wants a simple test environment where one can do proof of concept tests. This test environment should consist of the new external driver algorithm and a simplified vehicle model.

Today, the internal driver algorithm is implemented as a PI controller to-gether with a feed forward controller, but Scania is interested in examining if an MPC, Model Predictive Controller, or a PID, Proportional Integral Derivative, controller gives a better result.

(16)

2 1 Introduction

1.2 Purpose

The purpose of this thesis work is to develop a driver algorithm that is able to follow a setpoint better than the internal driver algorithm. It should also be easier to implement changes, and to do maintenance work on the driver algorithm in the future.

1.3 Objective

The objective is to develop and investigate a human-like driver algorithm used for longitudinal movement. The investigation should include testing of a PID-based and an MPC-PID-based driver controller for the driver. A simplified vehicle model is also to be developed during the thesis work to aid in tuning and testing the driver algorithm.

1.4 Goals of the Thesis

The objective can be divided into smaller tasks, and they all have to be achieved in order for the objective to be fulfilled.

• Develop a simplified vehicle model.

– Collect and analyze data.

– Build a model in Simulink.

– Test and evaluate the simplified vehicle model.

• Create an external driver algorithm based on a PID controller for longitudi-nal movement of vehicle models.

– Investigate how to implement the PID-based driver algorithm.

– Implement the algorithm in Simulink and convert it to C++ code.

– Create a shell in C++ code that can communicate with the HIL-simulator.

– Test and evaluate the PID-based driver algorithm.

• Create an external driver algorithm based on an MPC, Model Predictive Controller, that can be used to control longitudinal movement of vehicle models.

– Investigate how to implement an MPC-based driver algorithm.

– Implement an MPC-based driver in Simulink.

– Use the C++ code shell that communicates with the HIL-simulator.

– Test and evaluate the MPC-based driver algorithm.

• Compare the PID-based and MPC-based driver algorithms with the inter-nal driver algorithm.

(17)

1.5 Limitations 3

1.5 Limitations

In order to limit the work the external controller should only control forward longitudinal velocity of the vehicle model. The driver algorithm can only control a vehicle model with automatic transmission and only PID-based and MPC-based driver algorithms will be implemented in this thesis.

1.6 Method

At first a theoretical study of the behavior of a human driver and how previ-ous driver algorithms have been implemented was executed. Afterwards a sim-ple vehicle model was developed, and this was a iterative process and different approaches were tested. System identification was used on data from the HIL-simulator to create the model. The simple vehicle model was confirmed by com-paring its results with the result from the HIL-simulator.

The PID-based driver was developed and tested against the simplified vehi-cle model. When it gave a satisfying result, it was converted to C++ code, using Simulink coder. To set up a connection between the driver algorithm and the HIL-simulator a client was set up. The driver algorithm could now be tested and tuned for the HIL-simulator. This was an iterative process, and if problems oc-curred when the driver algorithm was used in the HIL-simulator, the driver algo-rithm was changed in Simulink and then converted to C++ code again. The MPC-based driver algorithm is developed in a similar way as the PID-MPC-based driver algorithm. To create a model for the MPC, system identification on data from the HIL-simulator was used.

The two approaches of the driver algorithm were then compared against each other and the internal driver algorithm.

1.7 Thesis Outline

This thesis is divided into seven chapters. Chapter 2 describes the HIL-simulator, the concept of the driver model, and the behavior of a human driver. The imple-mentation of the simplified vehicle model is presented in Chapter 3. Chapter 4 covers a short introduction to the PID controller, and the implementation along with the test results of the PID-based driver algorithm. Chapter 5 includes the basics for MPC, the implementation of the MPC-based algorithm, and the test results. A comparison between the three driver algorithms, the internal driver al-gorithm, the PID-based driver algorithm and the MPC-based driver alal-gorithm, is presented in Chapter 6. Chapter 7 summarizes the thesis with final conclusions along with possibilities for improvements and future work.

(18)

(19)

2

Background of the Driver Algorithm

In this chapter, there will be a short explanation of why the driver algorithm is needed and also how the HIL-simulator (Hardware-In-the-Loop) is used. The main purpose of the driver algorithm is to control the velocity of a vehicle model and in this case it is a simulation of either a truck or a bus. The input to the driver algorithm is the information displayed on a control desk in a vehicle, i.e. velocity, the currently used gear, and the engine rpm. In addition to these, the driver algorithm uses the desired velocity as an input, and for a human driver this would correspond to the speed limit signs. The driver algorithm controls the current velocity of the vehicle by manipulating the position of the gas and brake pedals. The driver algorithm should also be able to control the vehicle as a human driver would, i.e. the driver algorithm should follow the limitations of a human driver.

2.1 Usage of the HIL-Simulator

Scania’s strength is the modularity and the ability to combine all the different parts to build a unique vehicle that fulfills the customers’ demands. It is for example possible to combine almost any engine, gearbox, axles, and cabin to build a custom vehicle. This requires that all the components are compatible. To avoid building every possible combination of vehicles to test the modularity, the HIL-simulator has been constructed. In the simulator, it is possible to test all combinations of the electronic control units of the vehicles. In this simulator, all the electronics are real hardware, and all the other signals are simulated, for example, the vehicle velocity, engine rpm, and the air drag. The HIL-simulator is not the first or the last part in the test chain, and the first tests are done on every control unit individually. The second set of tests is performed in the HIL-simulator, where primarily the communication between all the control units is tested. The third test of a new control unit is done in a real vehicle before it is used in commercial vehicles. Because of the fact that all the vehicles are unique,

(20)

6 2 Background of the Driver Algorithm

Test of the individual control

units

Test of the complete electronic system in the HIL-Simulator

Test of the complete system in a real

vehicle Development of the

control unit

The control unit is used in production

Figure 2.1: The test flow at Scania. The first tests are done on every single

control unit individually. Secondly, tests are done in the HIL-simulator of the communication between the control units. The third, and final, set of tests of the control units is done in a real vehicle. These tests are iterated until the control unit fulfills the requirements.

tests are also performed on every constructed vehicle. The flow of the tests can be seen in Figure 2.1.

2.2 Communication Between the Driver and the

Simulator

This section explains how the framework of the HIL-simulator is constructed and how the communication between the external driver algorithm and the simulator is implemented. It includes an introduction to Apache Thrift, an explanation of how the HIL environment is constructed and how the external driver is connected to this system.

2.2.1 Apache Thrift and the HIL-Simulator Environment

The HIL-simulator uses Apache Thrift which is an interface definition language and binary communication protocol [Prunicki, 2010]. Apache Thrift is used to set up and communicate between servers and clients that use different coding languages. Some of the supported languages are C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml and Del-phi, see [Slee, 2010]. The HIL-simulator mainly uses Python and C#.

The HIL-simulator communicates with several servers through direct commu-nication. The servers then use TCP/IP to communicate with clients. Examples of the different servers are a set/get server and a server that is logging data from the HIL-simulator, example of a client that is communicating with the set/get server is a client connected to a steering wheel and pedals that let an operator drive the vehicle model of the HIL-simulator, and a client that is used to run the test scripts. The client using the test scripts is written in Python. These clients work indepen-dently of each other which makes it possible to run the test scripts and the driver algorithm at the same time. However, the maximum number of read/write to a

(21)

2.2 Communication Between the Driver and the Simulator 7 Server Test scripts (Client) HIL-Simulator Client

...

Figure 2.2:This presents how the framework of the HIL-simulator is

imple-mented. The HIL-simulator communicates with several servers, but the only one of interest in this case is the one that is used to read/write values to the HIL-simulator. This server is in turn communicating with several clients. A client used to run the test scripts of the simulator is shown here as an exam-ple.

server is limited to 1000 per second. How the framework is implemented can be seen in Figure 2.2.

2.2.2 Implementation of the Driver

First, the driver is implemented in MATLAB [MATLAB, 2014a] and Simulink [MATLAB, 2014b], then the code is converted to C++ using Simulink Coder. Afterwards, the driver algorithm uses a client to communicate with the HIL-simulator. The communication between the driver algorithm and the HIL-simulator can be implemented in mainly three different ways. These alternatives are pre-sented in Figure 2.3 and discussed below.

The first alternative is to place the driver algorithm in the same client as the test scripts. The advantage with this implementation is that there is already a working client in place and thus no need to set one up, which would otherwise take time. A disadvantage with this implementation is the fact that the driver has to be written in Python or C#. This would require the driver code to be converted twice, first to C++ and then to Python or C#. This increases the possibility for errors in the code and increases the amount of work. Another drawback when using this driver algorithm implemented on a client is that the framework only allows 1000 read/write from/to the server per second. This limits the allowed frequency of the driver algorithm.

The second alternative is to create a new server that communicates directly with the HIL-simulator. In this case, the driver must be written in C# which is not a possible output when using Simulink Coder which would require the code to be converted. Another drawback is that a setup of a server requires more work

(22)

8 2 Background of the Driver Algorithm Server Driver (Client) Test scripts (Client) HIL-Simulator Driver (Server)

Figure 2.3:These are the alternatives of where the driver algorithm could be

implemented. The dashed boxes are rejected alternatives for where to place the driver algorithm. The first option is to implement the driver as a test script and use the same client as the test scripts are using to communicate with the HIL-simulator. The second alternative is to create a new server and communicate directly with the HIL-simulator. The third option is to create a new client for the driver algorithm.

compared to setting up a client. The advantage with this implementation is that the read/write to the HIL-simulator is around 3000 per second which is higher than for the two other alternatives.

The third option is to create a new client that communicates with the server which in turn communicates with the HIL-simulator. In this case, the driver can be written in any of the program languages that are compatible with Apache Thrift, for example, C++, which is compatible with the output of Simulink Coder. In comparison with the second alternative, which is to set up a new server, this requires less work. As in the first option, which also uses a client solution, the read/write limit is 1000 per second. This is the solution that was used to imple-ment the driver, even though it limits the possible control frequency.

2.3 Related work

Today, there is a vast variation of driver algorithms. An example is adaptive cruise control, see for instance Shengbo et al. [2011]. In this case, model predic-tive control is used to control the longitudinal movement and to optimize the distance to the next vehicle, together with the speed and fuel consumption of the truck. The driver algorithms that are presented in this report are also used only for longitudinal movements, but there are driver algorithms that are used for lat-itudinal movement as well. See for instance the thesis work Jansson and Olsson [2013], where the driver algorithms are used to control the steering wheel of a car. The latitudinal movement driver algorithms are however quite different from the longitudinal driver, and this work is therefore not relevant to this thesis. Besides

(23)

2.4 Simulated Longitudinal Driver 9

technical aspects of this thesis work it is also of interest to know the behavior of the human driver, for example the time it takes to move the foot from one pedal to the other, see Broen and Chiang [1997] and Macadam [2003].

2.4 Simulated Longitudinal Driver

Another example of a longitudinal controller of a vehicle is the existing one in the HIL-simulator at Scania. The problem with the internal driver is that it is hard to make changes due to the current implementation. Today it is implemented as a part in the HIL-simulator, see Figure 2.4, and the simulation time for the driver algorithm and the vehicle model is therefore the same. This is a limitation when designing the driver algorithm. The driver algorithm developed in this thesis will be external instead, see Figure 2.5. The design process of the external driver is presented in Figure 2.6. Firstly, the driver algorithm is designed in Simulink [MATLAB, 2014b], secondly, it is tested on the simplified vehicle model and when it works properly it is moved to the next step. Thirdly, the driver algorithm is converted to C++ code, and finally, the driver algorithm can be used with the HIL-simulator. The sample time can now be chosen for the external driver algorithm independently of the sample time in the vehicle model, as long as the sample time is allowed by the communication, which gives bigger freedom in the design of the driver algorithm.

The velocity and reference velocity together with the position of the pedals for the typical test case of the internal driver can be seen in Figure 2.7. The internal driver consists of a feedback loop, a PI controller and a feed-forward part, and the performance of the controller is satisfying. The feed-forward controller gives the internal driver algorithm a fast response to changes in the reference velocity and the PI controller complements this by compensating for the model error in the feed-forward-controller.

Vehicle Model Driver Model

HIL-Simulator

Figure 2.4: This is how the driver algorithm is implemented today. The

driver algorithm is a part of the simulation loop and there is direct commu-nication between the driver and the vehicle.

(24)

Vehicle Model Driver Model HIL-Simulator

Figure 2.5: The driver algorithm implemented as an external process and

the communication between the vehicle model and the driver algorithm per-formed through the HIL-simulator. The sample time does not have to be the same for the two models in this case, which gives more freedom when the driver algorithm is created.

2.5 Limitation of a Human Driver

A human driver includes sensors, senses, actuators, muscles, and nerves of the limbs. These have limitations in the reaction time and also limitations in the movement of the limbs. There are some limitations in a human driver that do not exist in a controller if it is not tuned in a specific way, and much work is required to mimic these limitations. Nevertheless these limitations must be incorporated in a driver algorithm to get realistic results.

2.5.1 Limitation in Actuators

A human driver does not usually push both the gas and the brake pedals at the same time, because they are contradictory. This is not necessarily true for a com-puter that is controlling a vehicle, because it might be possible to find the desired speed by using both the gas and the brake pedal at the same time. Another limi-tation of a human driver is the time it takes to move hands and feet. For example,

The driver algorithm is tested in the simplified vehicle

model

The driver algorithm is converted to C++

code

The driver algorithm is tested and used in the HIL-simulator Design of the driver

algorithm using simulink

Figure 2.6: This is the intended design process of the external driver

al-gorithm. These steps will be iterated until a satisfying driver algorithm is created.

(25)

2.5 Limitation of a Human Driver 11 Time [s] 0 50 100 150 200 250 300 350 Velocity [m/s] 0 10 20 30 velocity velocity reference Time [s] 0 50 100 150 200 250 300 350 Position [%] 0 50 100 gas pedal brake pedal

Figure 2.7: Presented here is the velocity of the vehicle and the pedal

po-sition in a test case where the internal driver algorithm model drives the HIL-simulator. As can be seen in the upper plot the driver algorithm follows the reference well. In the lower plot it is possible to see that the steps of the pedals are too fast for a human to perform.

it takes some time to press the pedal from 0 to 100 percent, unlike a controller that can do this instantly. It also takes time for a human driver to switch pedals. According to Broen and Chiang [1997], a fast movement from one pedal to the other is approximately 0.17 s.

(26)

2.5.2 Limitations in Sensors

A human is using a combination of senses when driving a vehicle. The ones that are primarily used are

1. Vision - It is primarily used to collect data of the environment of the vehicle. 2. Tactile - This is mostly used to feel the vibrations from the vehicle in the

steering wheel and the pedals.

3. Auditory - This is often used as a supplement to the vision sense to react to the environment and a supplement to the tactile sense to hear the engine. and they are presented in the order of importance according to Macadam [2003]. The visual system has a reaction time of roughly 180 ms, while the auditory and tactile systems both have a reaction time of roughly 140 ms. The reaction times are defined as the time between stimulus and response. These numbers are ap-proximations and estimated under ideal conditions.

2.6 Discussion

The time delay would be more interesting to include if the simulation was sup-posed to simulate accidents or sudden events. However, to get a human-like behavior, a number of limitations are vital for the application. Firstly, that only one pedal is used at a time. Secondly, the time it takes to change pedal.

The signal of the pedal position of the internal driver algorithm is quite noisy and it makes changes in the pedal position faster than a human would. It can be difficult to match the results of the internal driver algorithm with just a PID or MPC controller because of the fact that the internal driver algorithm uses a PI as well as a feed-forward system which is a useful combination. However, the driver developed in this thesis will hopefully be a more human-like driver algorithm.

(27)

3

Vehicle Model

This chapter explains how the simplified vehicle model is implemented and the results of the implementation. For a full explanation of the simplified vehicle model see Appendix A. The simplified vehicle model should primarily be used for quantitative tests of the driver algorithm, in order to avoid the use of the HIL-simulator for every small test. The simplified vehicle model is partly constructed by linear black box models and partly by physical models.

3.1 Implementation of the Vehicle

In this thesis, two different approaches will be tested to create a vehicle model. The first approach consists of three submodels, two linear time-invariant black-box models and one physical model. The second alternative uses a time-varying linear system model.

3.1.1 Identification of the Simplified Vehicle Model

In both of the simplified vehicle model approaches, linear black box models are used to describe the system. The data used when estimating the models is col-lected in the HIL-simulator. The simulated models are either physical or based on data from real vehicles. The relation between the different domains can be seen in Figure 3.1. This means that the simplified vehicle model is subject to simplifications first from the real vehicle to the HIL-simulator and then from the HIL-simulator to the simplified vehicle model, and it may therefore not be an accurate model and far from the real vehicle. However, the HIL-simulator is verified by engineers at Scania and they have compared data from tests in real ve-hicles and data from the HIL-simulator which shows good resemblance. Thus the step between the real vehicle and the HIL-simulator is considered to be accurate.

(28)

14 3 Vehicle Model

Simplified

Vehicle Model

A real vehicle

HIL-Simulator

Figure 3.1: The models in the HIL-simulator are partly created out of data

from tests in a real vehicle and partly made out from physical modelling. The simplified vehicle model is partly created out of data from tests in the HIL-Simulator.

3.1.2 Simplified Vehicle Model Using Three Submodels

The system is too complex to describe with a single linear model and a full phys-ical model would require too much work. Instead, the submodel approach uses three submodels.

Firstly, there is one model for how the signal behaves between the gas pedal and the rpm out from the engine. This model is a black box model estimated from HIL-simulator data.

Secondly, there is a model for the gearbox, which changes the gear and con-verts the input rpm to the value after the gearbox. This model is built of two parts, one that recommends a gear, i.e. if the gearbox should shift gear up, down or keep the current gear. The other part is a model that shifts gear and calculates the output rpm.

The last model is also a black box model and it calculates the speed of the vehicle based on the position of the brake pedal and the rpm from the gear box. The two black box models are both continuous-time state-space models estimated from data. The structure of the vehicle can be seen in Figure 3.2.

Engine Model

The model of the engine is a linear black box model that was estimated from HIL-simulator data. The position of the gas pedal in the data was stepped up from 0% until a gear change was executed. The data was collected on one gear to avoid gear changes in the data, and in this case the eleventh gear was used. The data is presented in Figure 3.3. The estimation of the model was done in MATLAB by converting the data to an iddata-object, removing the mean in the data and then using the System Identification Toolbox [Ljung, 1988]. First, an ARX-model was created and by iterative testing the best fit to the validation data was found for the model

y(t) = b8q

−₈

+ b9q−9+ ... + b19q−19+ b20q−20

1 + a1q−1+ a2q−2+ a3q−3+ ... + a10q−10+ a11q−11

(29)

3.1 Implementation of the Vehicle 15

where u(t) is the position of the gas pedal. The model was then converted to a discrete state-space model out of the ARX-model using the MATLAB command

ss. Finally, the model was converted into a continuous-time model by the

com-mand d2c which in this case was using the Tustin transformation. The resulting continuous-time state-space model has 13 states and the input of the model is the position of the gas pedal, and the output is the rpm of the engine. The model is estimated from half of the data in this test, and the other half is used as validation data. The data used in the estimation and validation is presented in Figure 3.3.

In Figure 3.4 the fit between the model output and the validation data is pre-sented, this plot is produced by the MATLAB command compare. The fit be-tween the model and the data is 50.99%, but despite this relatively high fit it is possible to see that the model does not capture all the dynamics of the engine. This is however not a big problem because this model is primarily used for quali-tative tests, and the performance of the model is therefore not very important.

Gearbox Model

The gearbox is divided into two parts, see Figure 3.2. The first part, the gear selector, calculates the most efficient gear based on the rpm of the engine. If the engine rpm exceeds the maximum allowed rpm a higher gear is chosen such that the highest gear for which the engine rpm is still above the minimum limit. The opposite is the case for when the engine rpm is below the minimum limit, see Algorithm 1. Because of this, a gear shift can be of more than one gear at a time. The selected gear enters the transmission where the gear shift is executed. When a gear shift is executed the clutch is pressed down, and when the clutch is down the output rpm from the transmission is the same as the latest output multiplied with a constant. The clutch is pressed for a selected time which is typically around 0.5 seconds. When the clutch is released a new gear shift cannot be executed for a time. Thus giving the system a chance to stabilize after the gear shift. This time is between 0.5−1 seconds. The algorithm for the shift can be seen in Algorithm 2.

Engine

Gas Pedal Position

Brake Pedal Position

Gear Selector Transmi-ssion Axle to Wheel Velocity RPM Engine RPM Gearbox Desired Gear Gearbox Gear

Figure 3.2: This figure describes the structure of the simplified vehicle

model implemented with three submodels. The parts are, the engine model, the gearbox model, and the axle to wheel model. The inputs to the vehicle model are the gas pedal position and the brake pedal position. The output of the model is the vehicle velocity and the current gear.

(30)

16 3 Vehicle Model

Axle to Wheel Model

The estimation of the axle to wheel model was created in MATLAB by first con-verting the data to an iddata-object, removing the mean in the data, and then using the System Identification Toolbox in MATLAB. The data that was used to estimate the model is presented in Figure 3.5. The input of the model is the brake pedal position and the output is the rpm from the gearbox. The output of the model is the vehicle velocity which also is the final output of the vehicle model. Tests with state-space models showed a fit with the validation data that was acceptable and this kind of model was chosen. Continuous-time state-space models produced using subspace algorithms with different orders are presented in Figure 3.6. The performance of the model was usually better for a higher order but the calculations also take more time which is a drawback. The chosen model

0 500 1000 1500 2000 N engine[rpm] 200 400 600 800 1000 1200 1400 1600 1800 0 50

100 Position Gas Pedal[%]

Input-Output Data

Time (seconds)

Amplitude

Figure 3.3:This is the data used to estimate and validate the model of the

en-gine. The first part, until roughly 700 seconds, is used to estimate the model while the second part is used to validate the model. This data is collected on just one gear to avoid gear change in the estimation data. In this case higher gears are used to collect as much data as possible without a gear change. Since the data is collected from an automatic vehicle the HIL-simulator ex-ecutes gear shifts if the engine rpm is too high or too low. The data in this plot is extracted using only one gear, the output of the HIL-simulator is not always the same although the configuration is the same.

(31)

Time Response Comparison

Time (seconds) Amplitude 100 200 300 400 500 600 700 800 900 1000 -1000 -800 -600 -400 -200 0 200 400 600 800 validation data model data

Figure 3.4: This plot shows the fit between the model and the validation

data for the engine. The fit is 50.99%. The unit on the y-axis is rpm out of the engine. The mean is removed in the plot which is why some of the rpm is negative. The linear model do not success to include the non linearities of the vehicle. The non linearity in this case is due to the fact that the torque of the engine has to pass a certain value before it starts to move.

if(rpm from engine > rpm max limit AND current gear != max gear) then

Recommend the highest gear that would fulfil the condition ((ratio of current gear)/(ratio of recommended gear)*rpm from the engine > rpm min limit)

else if(rpm from engine < rpm min limit AND current gear != 0) then

Recommend the lowest gear that would fulfil the condition ((ratio of current gear)/(ratio of recommended gear)*rpm from the engine < rpm max limit)

else

Recommend the current gear end

Algorithm 1:Pseudo code that represents the gear selector block. Where rpm

max limit is the maximum allowed rpm before an up shift is initiated and rpm min limit is the lowest rpm before a downshift is initiated.

(32)

18 3 Vehicle Model

ifdesired gear != current gear then

/* The clutch has been pressed long enough to make

the gear shift _*/

if(clutch == 1 AND the clutch has been pressed enough time) then

change gear and set the clutch = 0

/* The clutch has not been pressed long enough for

the gear shift. _*/

else ifclutch == 1 then

do nothing this iteration

/* There is a new desired gear */

else

set the Clutch = 1 end

/* A gear change has been initiated but the rpm from the engine has changed and the current gear is the

desired gear. _*/

else if(desired gear == current gear AND clutch == 1) then

change gear back to the previous gear

/* The part of the function that computes the output

rpm of the transmission. */

if(current gear == 0 || clutch == 1) then

the output rpm = 0 else

the output rpm = (the ratio of the current gear)*(rpm from the engine) end

Algorithm 2: This shows the algorithm of the box transmission. Where the

variable clutch indicates that a gear change is ongoing.

order was twelve because the step of the logs of singular values between the or-ders eleven and twelve was relatively large and the step to thirteen order was relatively small. This means that the difference in performance is larger between eleven and twelve order models than between twelve and thirteen order models. Figure 3.7 shows a comparison between the estimated model and validation data. The validation data was extracted from the same test as the estimated data but for another time. The fit between the model and the data is 63.33%, which was deemed good enough for this application.

3.1.3 Simplified Vehicle Model Using Time-Varying Linear

System

The vehicle is, as stated before, a nonlinear system primarily because of the gears which give different velocities for the same gas pedal position. The solution, in this case, is to use a linear model from the first gear and then multiply the output with the ratio for the current gear for each gear, i.e. a time-varying linear system.

(33)

3.1 Implementation of the Vehicle 19 0 20 40 60 80 100 120 140 160 180 200 -10 0 10 20 Vehicle Velocity[m|s] 0 50 100 150 200 0 500 1000 N Axle[rpm] 0 50 100 150 200 0 10 20 30

40 Position Brake Pedal[%]

Input-Output Data

Time (seconds)

Amplitude

Figure 3.5: This is the data used to estimate and validate the model of the

brake position and the axle rpm to the vehicle velocity. The first half, un-til around 105 seconds is used to estimate the model, and the second half is used to validate the model. The spikes in the lower left are due to gear changes. The part of the data where the brake pedal is used can seem too small, but the dynamics of the brake pedal is not as complex as the axle.

Here, a discrete time state-space model is used to describe the vehicle

xk+1 = Axk + Bf (ck)uk

yk = CV (nk)xk (3.2)

where xk is the state of the model, uk is the input signal, and yk is the output

signal, at time k. In this case, the direct effect of the control signal uk on the

output is assumed to be zero. The vector V contains the gear ratio of each gear,

nk is the current gear at time k. The variable ck indicates if it is a gear change at

time k, and the function f eliminates the effect of the gas pedal on the vehicle if there is a gear change, i.e.

f (ck) =        0 0 0 1 ! , if the clutch, ckis 1 1 0 0 1 ! , if the clutch, ckis 0 (3.3)

(34)

20 3 Vehicle Model

Model Order

0 5 10 15 20 25

Log of Singular Values

-15 -10 -5 0 5 10

Gear to Wheel model

Figure 3.6: The performance of the different model orders from 1 to 20 is

displayed in this plot. The model with order twelve is chosen in this case. Be-cause the difference in singular values between the eleventh and the twelfth is relatively big, and the difference between the twelfth and the thirteenth is quite small.

Time (seconds) Amplitude 10 20 30 40 50 60 70 80 90 100 -20 -15 -10 -5 0 5 Vehicle Velocity[m|s]

Figure 3.7: The fit between validation data and the estimated model that

corresponds to the axle out of the gearbox to the wheels can be seen in this plot. The fit is 63.33%. The mean is removed in the data which is why the velocity in this plot is sometimes negative.

(35)

The quantities A, B and C are the model matrices. The gear is necessary in this vehicle implementation and it was approximated by the gearbox used in the pre-vious approach, see Section 3.1.2. The gearbox is based on the engine rpm and this is calculated from the vehicle velocity and the current gear using the formula Nengine= velocity ∗ axle ratio/gear ratio(n), (3.4)

where axle ratio is the ratio between the output rpm of the gearbox and the vehicle velocity, and gear ratio is a vector containing the ratio for every gear. The full implementation can be seen in Figure 3.8.

Data Collection for the Time-Varying Linear System

The model was created from data collected in the HIL-simulator. The data can be seen in Figure 3.9. Since the data was collected from a simulated vehicle auto-matic gearbox where the gear changes depends mainly on the rpm out from the engine, it was difficult to collect data for only one gear. To get as much useful data as possible, the position of the gas pedal was stepped one percent every tenth sec-ond until the gearbox shifted gear. To get data for the brake pedal, several steps were made on the pedal position. This was done twice to get data that could be used in the estimation and validation. Because the model was to be based only on the first gear the data for the rest of the gears was dismissed. The data used in the model estimation is presented in Figure 3.10.

Vehicle Model Gas Pedal

Position

Brake Pedal Position

Gear Selector Transmi-ssion Velocity to engine rpm Velocity

RPM Engine Desired Gear

Gearbox

Gear f

Clutch

Figure 3.8: This is the implementation of the time-varying linear system.

The inputs of the system are the position of the gas and brake pedals, and the ignition time. The output of the model is the vehicle velocity.

(36)

22 3 Vehicle Model

The Estimation of the Time-Varying Linear System

To create the model the System Identification Toolbox in MATLAB was used. At first an ARX-model was created. When creating a model there is a trade-off be-tween the model fit to the validation data and the order of the model. A higher order often leads to a higher fit but also to higher calculation time, which cannot be too long in this case since it is used online. The chosen model was

yk=

(b1,12q−12+ b1,13q−13+ ... + b1,21q−21uk1) + (b2,1q−1+ b2,2q−2+ ... + b2,7q−7)uk2

1 + a1q−1+ a2q−2+ a3q−3+ ... + a10q−10+ a11q−11

, (3.5)

where uk1 is the position of gas pedal, uk2 is the position of the brake pedal,

yk is the velocity of the vehicle, and a and b are constants. This ARX-model is

then converted to a discrete state-space model using the MATLAB command ss. The model was also order-reduced using the option minimal. This results in a state-space model with order eleven. The fit to the validation data is 48.46% and plotted in Figure 3.11. Time [s] 0 200 400 600 800 1000 1200 [km|h] 0 10 20 v Total Vehicle Time [s] 0 200 400 600 800 1000 1200 [%] 0 50 100 Pos BrakePedal Pos AccPedal Time [s] 0 200 400 600 800 1000 1200 [] 0 5 Gear

Figure 3.9:The raw data used to create the model used in the time-varying

linear system. The data is collected in the HIL-simulator. The data collected for any other gear than the first has to be filtered away before the model estimation.

(37)

3.2 Comparing the Simplified Vehicle Model Approaches 23 100 200 300 400 500 600 700 800 900 0 0.5 1 1.5 2 2.5 3 Vehicle Velocity[m|s] 200 400 600 800 0 5 10 15 20

25 Position Gas Pedal [%]

200 400 600 800 0 5 10 15 20

25 Position Brake Pedal [%] Input-Output Data

Time (seconds)

Amplitude

Figure 3.10:In this plot the data collected on any other gear than the first has

been dismissed. This data is used to create the time-varying linear system. The first part, until around 430 is used to estimate the model and the second part is used to verify the model.

3.2 Comparing the Simplified Vehicle Model

Approaches

To decide which approach to use when testing the drivers both the vehicle mod-els are tested with the same data, which can be seen in Figure 3.13. This data was used because it was collected using different gears and a varying of the gas and brake pedals. The inputs from the HIL-simulator were used as inputs to the simplified vehicle models. The output of the simplified vehicle models were then compared with the corresponding output from the HIL-simulator. The test of the submodels approach can be seen in Figure 3.12. The fit for this test is 5.12% which is really low. The result from the other approach is presented in Fig-ure 3.14, and the fit from this test is 57.27% which is enough for this application of the model. The bad fit for the higher gears is probably because the model is estimated using only the first gear. If more data is used the model would prob-ably improve. The obvious choice for the model was the second approach, the time-varying linear system, because of the better fit. This model will be used in the rest of the thesis and referred to as the simplified vehicle model.

(38)

24 3 Vehicle Model

Time (seconds) Amplitude 50 100 150 200 250 300 350 400 -0.5 0 0.5 1 1.5 2 2.5 3 validation data model data

Figure 3.11:This figure shows the fit between the model and the validation

data. The unit on the y-axis is the vehicle velocity in m/s. The data both for the estimation and validation are only collected for the first gear. That is why the velocity of the vehicle is quite low. The model used in the plot has the order 11.

3.3 Discussion of the Vehicle Implementation

The fact that the simplified vehicle model is created based on data that is col-lected from another model decreases the reliability of the model. Another thing that could have been done to make the model more realistic is if the torque had been used instead of the rpm between the models. The weight of the vehicle and the slope of the road could then have been taken into account in a better way. However, this would have required a more advanced model and the current model is sufficient for its intended purpose. One probable reason for the bad re-sult of the engine model presented in Section 3.1.2 is that the load of the engine is not included in the model.

The bad result from the submodel approach for the simplified vehicle models, can perhaps be explain by the fact that this lacks information about the current acceleration. It cannot be one of the states in the engine model neither in the gearbox or the axle to wheel model, because none of these models include the full dynamics of the vehicle. However the other alternative, the time-varying linear system, is a model of the whole vehicle and it is possible that some state in the model is corresponding to the acceleration of the vehicle. This might explain that the result from the time-varying linear model is better.

The result of the time varying linear system could probably get even better if more data was used in the estimation of the model.

An alternative to using the state-space model (3.2) in the time varying vehi-cle could have been to estimate a model for each gear and switch between them

(39)

3.3 Discussion of the Vehicle Implementation 25 Time [s] 0 100 200 300 400 500 600 700 800 Velocity [m/s] 0 2 4 6 8 velocity validation velocity Time [s] 0 100 200 300 400 500 600 700 800 Pedal Position [%] 0 50 100 gas pedal brake pedal

Figure 3.12:This is the result from the submodel approach for the simplified

vehicle models. As can be seen, the result is not that good, as the fit for is 5.12% which is really bad.

giving the model,

xk+1 = A(n)xk + B(n)uk

yk = C(n)xk (3.6)

where A, B, and C are functions that returns a matrix for each gear n. This method was evaluated, but it was rejected since the states in the estimated black-box

mod-els were not equivalent. For example x1is the position and x2 is the velocity in

the first model, then in the second model, x1could be the velocity and x2could be

the position or any linear combination of these states. Another alternative would be to estimate a grey-box-model for each gear. This would solve the issue with the states but would however require additional physical modelling.

(40)

26 3 Vehicle Model Time [s] 0 100 200 300 400 500 600 700 800 [m/s] 0 0.1 0.2 0.3 0.4 Vehicle Velocity Time [s] 0 100 200 300 400 500 600 700 800 [%] 0 50 100 Pos BrakePedal Pos AccPedal

Figure 3.13:This data is used to test both of the approaches to the simplified

vehicle models. The data is collected on three different gears, the gas pedal is ramped up until a gear shift is executed. The brake pedals are then pushed to stop the vehicle model. This data is used because the varying gears and gas pedal. The reason that the vehicle do not move between when the gas pedal position is low is because the torque of the engine is too small.

(41)

3.3 Discussion of the Vehicle Implementation 27 Time [s] 0 100 200 300 400 500 600 700 800 Velocity [m/s] 0 2 4 6 velocity validation velocity Time [s] 0 100 200 300 400 500 600 700 800 Pedal Position [%] 0 50 100 gas pedal brake pedal

Figure 3.14:Here the result from the time-varying linear model is presented.

This result is quite good, as the fit for this model is 57.27% which is sufficient for the intended purpose. The difference between the model and the valida-tion data for small values of the gas pedal posivalida-tion is due to non linearities that the linear model can not capture. The reason that the validation data has zero velocity is due to the small torque of the engine for small gas pedal positions.

(42)

(43)

4

PID-Based Driver Algorithm

This chapter contains a description of the driver algorithm based on two PID (proportional-integral-derivative) controllers. The purpose of the driver algo-rithm is to control the position of the gas and brake pedals, and also to drive the vehicle as a human would. This is achieved by using PID controllers and some ad-ditional heuristic components. The chapter includes a short introduction to PID controllers, how the driver algorithm is implemented, the design choices, and it ends with the result of the driver algorithm used in the HIL-simulator and the simplified vehicle model. A schematic description of the driver algorithm can be seen in Figure 4.1. A complete description of the driver algorithm implementa-tion can be found in Appendix B.

4.1 The PID Controller

A model of a driver is in essence a controller and there are thus many options to use as a starting point. One simple approach is to use a PID controller which is widely used, and is therefore a natural starting point. A PID controller is a feedback mechanism that controls, for example, actuators to a desired value. It is the most common controller in many industries and other applications. The mathematical description of a discrete-PID controller can, according to Glad and Ljung [2006], be written as uk= KPek+ KI k X j=0 ej+ KD(yk−yk−1), (4.1)

where uk is the control signal, yk measured output, k is the kthtime instant and

ekis the error. The error at time k is defined as

ek= rk−yk, (4.2)

(44)

30 4 PID-Based Driver Algorithm Velocity Ref Current Velocity PID Gas PID Brake Filter Filter Lock Lock Gas Pedal Position Brake Pedal Position Saturation Saturation Gear Stimuli Gear

Figure 4.1:This figure shows how the driver algorithm is implemented. The

inputs to the driver algorithm are the desired velocity, the current velocity and the current gear. The filters smoothen the signals and the lock functions are used to allow a maximum of one signal at a time to be used. The driver algorithm outputs are the position of the gas and the brake pedals. The block gear stimuli makes the driver algorithm respond to the gear changing.

where rk is the desired output value and yk is the actual value of the output.

The constants in (4.1) are different tunable parameters. The parameter Kpis the

proportional gain , KI is the integral gain and the parameter KD is the derivative

gain. The reason that the derivative gain is multiplied with the actual output and not the difference between the desired and current output is to avoid a very large value when a new reference velocity is chosen [Enqvist et al., 2014].

4.1.1 Integrator Windup

When the integrator part adds up to a very big value it is called integrator windup. This can occur when the control signals of a system are saturated. Since both a sat-uration and different modes are used in the driver algorithm integrator windup is possible. To avoid this, conditional integration has been used. A possible imple-mentation of this is according to Enqvist et al. [2014] to exchange the integration

part in (4.1) to Ik as

uk= KPek+ Ik+ KD(yk−yk−1), (4.3)

where Ik is defined as Algorithm 3. Another solutions to the integrator windup

problem could be to implement the integration on differential form which can result in a controller that can converge to any value of the error. Conditional integration does not have this problem and it also makes the settling time smaller in addition to being slightly more simple than the third alternative, adjustment of the integrator part.

(45)

4.2 Implementation of the Driver Algorithm 31

if(the output signal of the driver algorithm is not 0 or 100) AND (the

pedal is used) AND (There is no gear shift) AND (The vehicle reacts as it should on the gas pedal) then

Ik= Ik−1+ KI∗Ts

else

Ik= Ik−1

end

Algorithm 3:This is used to eliminate the integrator windup that can occur in

a PID controller. This implementation is used to calculate the integration part of the PID controller and it is called conditional integration.

4.2 Implementation of the Driver Algorithm

In this implementation, there is a separate controller used for each of the pedals. Another approach could be to use one controller and switch between gas and brake depending on whether the signal is positive or negative. The benefit of using two different controllers is the possibility to tune the pedals differently.

A filter has been applied to make the control signals more human-like. An-other alternative to solve this problem could be to tune the controllers differently, but the drawback with this solution is that it requires more competence and time for the operator. The filter is a combination of a low-pass filter and a function that limits the maximum change for every iteration. A human driver does not use both pedals at the same time, and to achieve this, a lock function is implemented that only allows one signal to be used at a time. Since the effect the pedals have on the vehicle is insignificant when the pedal angle is small, the definition of a used pedal in this thesis is if the pedal is used more than 7% of its maximum. The time of a quick movement of the foot from one pedal to the other is presented in Section 2.5.1. In this solution, the longer time of, 0.4 s is used as the time to move the foot from one pedal to the other to mimic the behavior of an average driver.

Sometimes the HIL-simulator tries to shift gear but fails and is therefore stuck in neutral. This problem is solved in the gear stimuli block. The output of the block gear stimuli is two boolean signals.

One of them indicates if the vehicle responds to the input of the gas pedal. That signal is called vehicle accelerates which indicates that the vehicle can accelerate, not necessarily that the vehicle is accelerating at the moment. If the vehicle is started, i.e. a gear has been used and the gear is shifted to neutral for long enough, the boolean is set to false. If the boolean is false, the gas pedal is released until it is not pressed at all. The driver algorithm then waits a short while and tries to press the gas pedal again, and if the vehicle does not accelerate the pedal is released again. This behavior is repeated until the vehicle starts to accelerate again and then the boolean vehicle accelerates is set to true.

(46)

32 4 PID-Based Driver Algorithm

ifvehicle started then

if(gear == 0) AND (enough time has passed since the gear was set to

zero) then

vehicle accelerates = 0 gear shift = 1

else ifgear == 0 then

vehicle accelerates = 1 gear shift = 1 else

vehicle accelerates = 1 gear shift = 0 end

else

ifcurrent gear > 0 then

vehicle started is true else

vehicle started is false end

end

Algorithm 4:This is the algorithm used to decide if the vehicle is accelerating

and if a gear is active. The variable vehicle accelerates here means that the acceleration is possible and not necessarily that the vehicle is accelerating at the moment.

The other output signal of the gear stimuli block is gear shift which in-dicates that a gear shift is ongoing. When this is true, the integrator windup, see Section 4.1.1, is turned off until a gear is engaged again. It can be seen in Algorithm 4 how the block gear stimuli is constructed.

4.3 Results for the PID-Based Driver Algorithm

Some tests are done in the simplified vehicle model and these tests are primarily done in order to see that the driver algorithm responds with reasonable results. When the driver algorithm showed reasonable results in the simplified vehicle model, the tests in the HIL-simulator were executed.

4.3.1 Results of the PID Driver Algorithm in the Simplified

Vehicle Model

To see that the driver gives a result that is reasonable the first tests are done in the simplified vehicle model, see Chapter 3. This is to avoid unnecessary use of the HIL-simulator which is a limited resource. The results of one of the tests are presented in Figure 4.2, which shows the velocity of the vehicle and the position of the pedals. It can be seen in the plot that the velocity follows the desired velocity well. To reach the desired velocity as fast as possible the driver gives a full throttle when the desired velocity is increased. When the velocity is high enough the pressure on the pedal is released and set on an appropriate level.

(47)

4.3 Results for the PID-Based Driver Algorithm 33 Time [s] 0 50 100 150 200 250 300 350 Velocity [m/s] 0 10 20 30 velocity velocity reference Time [s] 0 50 100 150 200 250 300 350 Pedal Position [%] 0 50 100 gas pedal brake pedal

Figure 4.2: This shows a test when the PID-based driver algorithm control

the simplified vehicle model. The fit of current velocity and the desired ve-locity is high. The spikes that can be seen in the upper plot occurs when a gear shift is executed. The black dotted line in both the plots indicates a gearshift.

The spikes that can be seen in the upper plot are due to gear changes. This is because the gear shifts are triggered by values in engine rpm which is estimated by using the velocity, and the velocity is estimated using the current gear. After a gear change the velocity need time to converge to the desired velocity.

4.3.2 Result of the PID Driver Algorithm in the HIL-Simulator

The main purpose of this thesis work is to present a good driver algorithm for the HIL-simulator. The test case executed in the HIL-simulator is the same as for the simplified vehicle model in Section 4.3.1. The result of the test is presented in Figure 4.3. The driver algorithm follows the reference velocity with some errors. There is a long rise time followed by an overshoot for every step and the settling time is also too long. It is possible to increase the speed of the driver algorithm to decrease the rise time, but this leads to a greater overshoot instead.

To test the robustness of the PID-based driver algorithm another test was done in the HIL-simulator with the same tuning but controlling another vehicle model.

(48)

34 4 PID-Based Driver Algorithm Time [s] 0 50 100 150 200 250 300 350 Velocity [m/s] 0 10 20 30 velocity velocity reference Time [s] 0 50 100 150 200 250 300 350 Position [%] 0 20 40 60 gas pedal brake pedal

Figure 4.3: This figure shows the output, along with the corresponding

control signals, of the vehicle in a test of the driver algorithm in the HIL-simulator. As can be seen in the upper plot, the result of the driver algorithm is not that good, the rise time is long, there is an overshoot, and the settling time is also quite long. In the braking that can be seen in the lower plot at 300 seconds it might looks like both pedals are used at the same time but when zoomed it is possible to see that this is not the case.

This vehicle uses a 16L engine instead of the first vehicle that used a 9L engine. The result of the test is presented in Figure 4.4. The difference between this and Figure 4.3 is not significant. It is mainly the braking that is worse for the vehicle with the bigger engine.

Problem With the Gearbox

The problem with the gearbox that was mentioned in Section 4.2 is solved and the result can be seen after 320 seconds in Figure 4.5. The driver algorithm does not continue to push the pedal, instead the driver algorithm releases the pedal until either the vehicle succeeds to find a gear or the position of the gas pedal is zero. This is done repeatedly until the vehicle succeds to engage a gear again.

(49)

4.3 Results for the PID-Based Driver Algorithm 35 Time [s] 0 50 100 150 200 250 300 350 Velocity [m/s] 0 10 20 30 velocity velocity reference Time [s] 0 50 100 150 200 250 300 350 Position [%] 0 20 40 60 80 gas pedal brake pedal

Figure 4.4: This is a test done on a vehicle with a 16L engine instead of a

9L engine in the HIL-simulator. The driver algorithm is tuned for another vehicle that is lighter. The result in this test is not satisfactory. There is a slow rise time and an overshoot, especially when the brakes are used.

4.3.3 Tuning the PID-Based Driver Algorithm

A PID-controller can behave very differently depending on how the controller is

tuned. The tunable parameters in this case are the KP, KI and KD for both the

gas and the brake pedals, see Section 4.1. Their values are chosen by iterative testing. The tuning of the simplified vehicle model was not that difficult, as the model is quite forgiving. The HIL-simulator on the other hand was more difficult

to tune. If the KP or KI of the gas pedal is increased the controller reacts faster

to changes of the velocity reference, but this however increases the overshoot as

well. Increasing KD eliminates the overshoot, but it makes the settling time of

the driver algorithm longer. The values of the tuning that are used in the final result of the PID-based driver algorithm, see Figure 4.3, can be seen in the second column in Table 4.1.

The result in Figure 4.6 is tuned differently, and the tuning can be seen in the

third column in Table 4.1. The parameter KP of the gas pedal is larger in this case,

which makes the movement on the gas pedal faster but it also leads to a bigger

overshoot. The breaking is also worse than the final result, the small KP and KD

Enhanced Driver in Full Vehicle HIL-Simulator

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Enhanced Driver in Full Vehicle HIL-Simulator

Enhanced Driver in Full Vehicle HIL-Simulator

Examensarbete utfört i Reglerteknik

vid Tekniska högskolan vid Linköpings universitet

av

Sammanfattning

Abstract

Acknowledgments

Contents

1

Introduction

1.1

Background

1.2

Purpose

1.3

Objective

1.4

Goals of the Thesis

1.5

Limitations

1.6

Method

1.7

Thesis Outline

2

Background of the Driver Algorithm

2.1

Usage of the HIL-Simulator

2.2

Communication Between the Driver and the

Simulator

2.2.1

Apache Thrift and the HIL-Simulator Environment

...

2.2.2

Implementation of the Driver

2.3

Related work

2.4

Simulated Longitudinal Driver

2.5

Limitation of a Human Driver

2.5.1

Limitation in Actuators

2.5.2

Limitations in Sensors

2.6

Discussion

3

Vehicle Model

3.1

Implementation of the Vehicle

3.1.1

Identification of the Simplified Vehicle Model

Simplified

Vehicle Model

A real vehicle

HIL-Simulator

3.1.2

Simplified Vehicle Model Using Three Submodels

3.1.3

Simplified Vehicle Model Using Time-Varying Linear

System

Gearbox

3.2

Comparing the Simplified Vehicle Model

Approaches

3.3

Discussion of the Vehicle Implementation

4

PID-Based Driver Algorithm

4.1

The PID Controller

4.1.1

Integrator Windup