Design and Deployment of a Nonlinear Model Predictive Controller for Motion Planning

Hello, and welcome to this seminar on design and implementation of Model Predictive Controllers on embedded hardware. My name is Christoph Kammer. I'm an application engineer at The MathWorks in Bern in Switzerland and my background is in robust control And model predictive control, which is also why I'm here today to talk about this topic. I'm joined by 3 colleagues-- Gernot from The MathWorks as well as Tiva and Stefano from Embotech. And I'd now like to ask my three colleagues to quickly introduce themselves before we dive into the topic. Gernot, why don't you go first?

Hello, my name is Gernot Schraberger. I'm an application engineer at The MathWorks in the Munich office in Germany. And my main focus is on physical modeling and on control design. And I have a special focus on electrification topics.

My name is Tiva Albin and I'm the head of the industrial automation team at Embotech. From my background, I'm a control engineer with a PhD. I held several positions in academia, and now I've worked for more than two years at Embotech.

So first, some words about Embotech. Our core product, FORCES Pro is an numeric solver that is dedicated for application in model predictive control. We offer this numeric solver, and also work together with customers on developing MPC applications for Siri deployment.

Additionally, we have owned products that are based on MPC such as motion planning software for autonomous driving. As the industrial automation team, we work on applications in the area of industrial robots and also production machines. So for example, CNC machines. Now, I pass over to Stefano for an introduction.

Hello, everyone. My name is Stefano Longo and I'm the head of automated driving at Embotech. My background is control engineering and optimization and MPC in particular. And I've always applied these techniques to automotive systems. On this presentation today, I will show you some applications for MPC to autonomous driving and, in particular, trajectory generation tracking.

All right, so that's the agenda for today. So we're going to talk about designing a model predictive controller with MATLAB and Simulink. So Gernot will walk us through a bunch of the theory of model predictive control. And then I would like to show you cool demo of design simulation and validation of a nonlinear MPC controller for a vehicle lane following application. And then, Embotech will follow up, and they will talk about their toolbox FORCES Pro and how to deploy model predictive controllers to embedded devices.

So, I would like to quickly give you a great demo effect. Just to show you a bit what we're going to look at when I will run my example. So hopefully, you'll stay excited.

But here we see a virtual environment. We're going to have a model predictive controller, which will guide this car to stay on the lane. And there's quite a lot of moving parts in here and we can visualize everything in this really nice Unreal Engine environment. And there's going to be some AI to detect lane markings. We will go into details a bit later. But first, Gernot, I think you should explain this a bit. What we need from a theoretical point of view to make all of this happen.

Well, let's start with the first part. I want to give an overview about linear and nonlinear MPC. Here, in this slide, you can see a general overview about model predictive controller and how this is connected with the plant. Set a model predictive controller can be seen here. We have got actual signals going to the real plant, and we receive outputs from the plant. Action signals and outputs are combined here, in the state estimator, which creates states that will be used within the model predictive controller. That is necessary to be able to predict the actual situation of the plant, and I'll show you just a little bit later how the prediction works.

Important is that the model predictive controller uses optimization techniques to predict the system behavior. So, therefore, we can have optimization based on the linear plant model, which is shown up here. Or non-linear, as a will show later. Here in the linear case, we will have a quadratic cost function. The cost function is defined, typically by the deviation of the plant output, which we square here together with a weight factor. And we might have some penalties concerning the action signals or the derivative of the action signals. A nice thing here is also that we can focus on constraints, which are linear constraints here. These constraints can be on the output signals as well as on the action signals or the derivative something. In case of nonlinear MPC, the prediction model is non-linear because the plant is non-linear. We can have nonlinear constraints. Also the cost function will be non-linear. So we use not the quadratic programming from the case before but non-linear programming techniques to solve this optimization problem.

Gernot, I have two small questions for you. So, I've seen Model Predictive Control you've mentioned. You've been needing a linear or a nonlinear model of our system. So, usually it's hard to get an accurate system. Will MPC also work if my model is not that accurate?

It will also work because it has a feedback loop. And that means that even if you have small deviations in the model for the prediction, deviations from the real plant will work because of the feedback. So, let's continue now. For the reasons why people use MPC. One is that MPC works perfectly with multiple input, multiple output systems. These systems can have coupled dynamics, and these would be systems that are very difficult to handle with traditional controls. Another nice feature is that MPC can handle constraints. Because we have got these constraints in the optimization problem. And that's quite normal for an optimizer to deal with constraints. That means we have balance, for example, in the action signals on the output side of the controller and they can be incorporated very easily. We can have multiple controller objectives. We have the preview capability, which fits quite well to certain kind of problems where you need a preview. For example, for lane detection. And MPCs used in different industries, is traditional coming from the process industry. But with increasing computing power, it finds its way-- also, the other industries like the automotive industry or robotics.

So how does MPC work now, in more detail? Let's have a short look to that. Well, you see here, 2 signals. 1 is the action signal on the top here. On the lower side, we have the measured output. And what you can see here is that the MPC controller outputs hear certain values at specific times. And that's done within the control horizon. Direction of the plant will be shown here on the lower side. And this we have to consider in the prediction horizon.

So now the goal of the MPC, and of solving the optimization problem is to come as close to the reference signal here. And to keep the system stable over a longer time. Coming close means having an optimization and minimization problem to solve. Now, time for 1 time step. Now the controller generates the real output, as you can see here. This deviates a little bit from the computed output because the real plant deviates from the model. But, no problem. If we go to the next step, we start the calculation with the actual output at this time. We start with a new control horizon, which has moved by one time step and the new prediction horizon moved by one time step. Now the same procedure continues again. We get an output signal here from the internal model. We try to come as close as possible to the reference by minimizing the output. So we keep them going all of the time. That's how MPC works, actually

So, Gernot, I have another question. You're showing here 2 horizons. So, you have the prediction horizon. You have to control horizon. It kind of tells me how many times steps the MPC will look into the future. How do I know what lengths I should pick and what impact does this have?

Actually, that's something that is done during the setup. And typically, the prediction horizon is longer than the control horizon. It has to do with how much preview you will need to be able to control the system in the right manner. Therefore, the prediction horizon is important. The control horizon, you might think, it should have the same length. But it has shown that shorter lengths are better to efficiently solve an MPC problem. Because every single time step within the control horizon means another design variable in the control problem. So let's try to keep this number as low as possible. But as I mentioned, prediction horizon has to have a certain length to be able to keep the system within a certain range. And to be able to control it.

Now let's have a general overview about the Model Predictive Control toolbox. We have certain key features here. We can handle several control problems with the MPC design process, linear and non-linear. We have an MPC designer app that helps us to do that interactively. And there are certain blocks for ADAS for the automotive industry, then I will give you a short overview about optimization solvers. And at last, we will keep on going with a deployment through automatic code generation.

Let's start with the first two points here. If we put the plant into the center of our consideration. And if we have a linear plant, then we just need a single operating point to consider. So we have linear constraints and the quadratic cost function, as seen before. In this case, we can use the implicit MPC block From the model predictive control toolbox. What does linear implicit empathy mean? We've got the plant model here, as shown on the right. We have certain signals coming from either the model predictive controller or from disturbances. The first signal here is the manipulated variables, which are the controller outputs. Then we have measured disturbances. These disturbances that we know. And unmeasured disturbances because we cannot measure them. In that case, we can use an input disturbance model that has to be set up together with the MPC.

We can have disturbances on the output side of the plant. These two models, you can see here. Both have to be set up together with the MPC. The plant model itself we can get by liberalization of the plant, or by definition in the control system toolbox. With specific objects there, like a transfer function object or a state space object. A third way is to use system identification toolbox to get the characteristics of a plant model. These three ways can be used to set up the Model Predictive Control.

Then we'll go to an interactive app. We can see here on the next slide. And we can specify the constraints here. We can specify weights for the optimization problem. And we have some sliders for setting up the performance or the robustness of the MPC problem. That gives us some interactivity as well here. The performance slider will have an influence to the weights. If those things are set up here, within the MPC app designer. We can then export the design to Simulink link and use it within the Simulink environment. But we can also continue working in MATLAB.

So Gernot, do we design the MPC in Simulink or in MATLAB? How does it work exactly?

We can start with the process in Simulink if they've got the plant model. And if we want to linearize that, the initial step can be in Simulink. Then the actual design process-- if one's got the linearized description of the MPCs then in-- done in MATLAB, or within the MPC toolbox. And then we can go back to Simulink. Or we can directly start, do everything in MATLAB. Because it's based on linear plant models, which can be expressed with control system toolbox commands.

That was the implicit MPC. Now, let's have a look-- if we have a non-linear plan, for example-- with non-linear plants, we can use multiple operating points. And say, well we consider the plant as linear for every specific operating point. In this case, we have a so-called adaptive MPC or linear time variant MPC. Then we can use multiple operating points that are fed to the MPC block via signals, for example. Important to understand here is that, in this case, we still have only one MPC controller. We do an update during the operation. For the prediction only, that specific plant model at this time is used.

What you can see here is that you get, for example, the blunt model information from a recursive polynomial model estimate. We come in here with inputs and outputs from the real plant. We estimate the plant parameters. We have to do some conversion here to change the format. Then we apply the plant model as A-B-C-D matrix and offsets for the inputs, the outputs, and the states to the adaptive MPC block. That's one possible way to apply plant model information to the adaptive MPC. Others are, for example, that you do a calculation based on symbolic math. Where you do symolic Jacobians. And you can apply the Jacobin information directly here into this model input. Or you can use so-called linear plant varying models. That is where you do these steps, these symbolic derivatives, for example, or the linearization in at once-- you got the complete nonlinear plant information within this linear parameter bearing model, which uses tables inside.

If you need multiple controllers, in this case with multiple operating points-- because maybe the characteristic of the plant changes completely. Then you can use gain schedule MPC. This is a more general approach, but you cannot adapt it in such a fine manner with adaptive MPC. So gains schedule MPC will typically work with a certain number of linearizations, but not with a steady flow of new plant linearization information.

Again, I have a question. When should I use adaptive and when should I use gains schedule MPC, then?

The adaptive MPC you can use if you have a single controller. For example, if the input and output signal of the plant do not change. Because if those change you might need another controller setup. In that case, you will need a gain schedule MPC with multiple controls. Does that answer your question?

So I could, with gain schedule-- I could do different configurations of my system, which has a different number of actuators.

Yes, that's right. Let's keep on going here. If you want to speed up the execution of the MPCs, we have the option of explicit MPC. This can be combined with the implicit-- so it's a simple case of MPC or with the gain schedule MPC. How does the explicit MPC work? In principle, you consider the optimization for every single section. And the sections or the borders of the sections come from the constraints you have. So, you might be in a section where you have no constraints, or you might be in a section where you have specific constraints active. And for every single section, you solve the optimization problem in at once. That means that you can access simpler equations that can be solved faster, compared to solving an optimization problem online. That's the big advantage of explicit MPC. It will not work for adaptive MPC because in that case, you change the plant model permanently. And it's too complex to handle that with explicit MPC.

Well the last version of MPC that I want to explain is the nonlinear MPC. This can be used for non-linear plants where you have multiple operating points. But in this case, you really want to do the prediction based on non-linear models compared to doing the prediction with a linear model for every specific point of time in the adaptive MPC. Nonlinear MPC, of course, is the most complex form here. It can also include nonlinear constraints and non quadratic cost functions.

So Christoph will show that in more detail. The only thing I want to mention here for, nonlinear MPCs, is that typically you define the nonlinear functions within MATLAB. And the fmincon algorithm is used for solving the optimization problem. This has been the main emphasis that I wanted to explain to you here. Now let's have a closer look to some specific application in automated driving.

The MPC toolbox also delivers some blocks here, which can be used for lane keeping assistant systems, for adaptive cruise control systems, and for path following control systems. These blocks have the big advantage that you have reference examples coming with the blocks, and you can go under the mask of the block and see how they work. It's a good starting point for developing your own lane keep assistance systems or adaptive cruise control systems or paths following control systems.

The next point here are the optimization solvers. In general, we can say that The MathWorks is delivering all the solvers you will need for those kind of MPC problems we have seen so far. They also support code generation. On the other side, we have custom or third party source. They typically have the big advantage that they can solve certain problems faster, especially if it's about embedded code generation. 1 that you will see later, is FORCES Pro solver by Embotech. Let's start with The MathWorks solvers. For all linear MPC problems-- that means problems that can be expressed with implicit MPC, adaptive, or time varying MPC, or gains schedule MPC-- we can use standard solvers, QP solvers like ActiveSet QP solver, InteriorPoint QP solver, and if we have discrete control sets, then we can use mixed integer QP solvers which come with the optimization toolbox. For nonlinear MPC, we can use fmincom from the optimization toolbox. We have an active set for a QP set problem. And fmincon, together with interior point algorithm, also coming from the optimization toolbox.

So Gernot, what is this grid control set MPC? We haven't talked about that.

That's right, that's not enough time to talk about everything. But-- just in a few words-- this is an MPC where the action signal going from the MPC to the real plant is, for example, a binary signal. In this case, you cannot define the problem with a continuous MPC with continuous signals, but you have to consider these discrete control set that means this binary outputs and also you have to use the mixed integer optimization. Does that answer your question, Christoph?

Yes, thanks.

There's a few more things I want to mention here. Conserving solving the optimization problem here and an MPC-- there are some methods that allow you to speed up such optimizations. 1 is, for example, that you just use a certain number of iterations in the optimization. That's an option we have for model predictive control. It's called a suboptimal solution and this is especially helpful if you do not have enough time to solve the optimization problem in real time.

This is very interesting. Deploying NBC , especially, that's where timing becomes a real constraint, right? It needs to be fast enough. Are there any other concepts, Gernot, which allow us to speed up MPC?

Yeah, one issue like that Embotech will show their concept. But there are also some steps we can do before. You can try to reduce the number of constraints. You can make the prediction of a control horizon smaller. Although, these two concepts will help to simplify the optimization problem and make it faster.

I see, that makes sense.

I think now it's time to hand over to Christoph, who will show this demo that he's shown at the beginning in more detail. Christoph, are you ready therefore?

I am ready, Gernot. Thanks. I'd like to show you a demo on how to design, simulate, and validate a nonlinear MPC controller for a vehicle lane following application. To visualize this a bit further-- assuming we have a car over here, but we want to control the longitudinal acceleration and the front steering angle. This is what the MPC controller will output.

And we want to keep the lateral deviation, which is E1 as well as the relative yaw angle, which is E2, we want to keep those small. So we want to stay nicely within the middle of our lane. We also want to keep the longitudinal velocity of the x. Going forward, we want to keep that close to a driver set velocity. The driver wants to drive at a certain speed and you want to be able to be as close as possible to that speed. And, of course, these goals might not be achievable simultaneously. Sometimes if the curve is too narrow, then we'll have to break. We want to balance these above goals when they cannot be met simultaneously. I guess you can see, this is pretty complicated control problem. But MPC is very well suited to tackle challenges like that. So without further ado, let's jump into MATLAB and see how we set this up.

Here we are. So, this is MATLAB. And I'd like to show you this demo, which is pretty comprehensive system of a lane following demo. We'll see exactly how the MPC has been set up. This live script will guide you through everthing, so I just want to start by defining some parameters and having a look at my model.

So this is my Simulink model. You see, there's three main parts. There is a simulation scenario, which we have over. There is a simulation scenario. There is the actual line following decision logic. There's the MPC controller in here. And finally, we have the vehicle dynamics on the right-hand side.

Just quickly diving into the simulation scenario, we set up our vehicle here. We set up how the vehicle behaves. We set up also a sensor configuration, so we will have a virtual camera which will take images from our virtual environment. And then, we have a detector for lane markers That's essentially the measurements we need to stay within our lane. We need some way to actually measure where the lane is. In here, we can try different algorithms. I think this one is based on image processing. We could also try a neural network in here to detect lanes in our camera image. The right hand side, we have the vehicle dynamics. Looking into this, we have here a certain type of car model. It's a pretty comprehensive model here, and a pretty realistic one as well. And see if there's a bunch of other blocks to handle different things, to handle the signals. The actual piece of interest today is the length Following Controller.

So we see, again, we have an estimator for the lane centers. We get lane detections, we want to estimate where the lane centers are. We also get our velocity and we use it to preview the curvature of our road, the lateral deviation of our car, and the relative yaw angle of our car. We feed all of these measurements into an extended Kalman filter, because our MPC controller will need the complete state information. So, we have a Kalman filter, we have a state estimator, which will take the measurements we have available and give us the complete state to use in our MPC controller. The MPC controller itself-- it calls this null object, which is our MPC object.

I'd now like to show you how we can create this object. Going back to MATLAB, let's follow this live script in order to construct our MPC controller. Here, we set some initial velocities and then we create our null object by calling this NL-MPC command. This command creates the MPC object and it takes a bunch of inputs. What I've shown here above-- this is actually the state space model, which defines, which describes, how our system behaves. If you look a bit more closely, we have 7 states, which is the first input to our NL-MPC command. We have 3 outputs, which we'll see a bit later. You have 4 inputs in total. We have 2 inputs, which come from the MPC controller, so this is what we will compute. We have 1 measured disturbance and we also have 1 unmeasured disturbance.

So the two inputs are the acceleration and the steering, that make sense we're driving a car so we can accelerate we can steer. We have a measured disturbance, which we define as the product of road curvature and longitudinal velocity. And we have one unmeasured disturbance, which we put in as white noise, which acts on our system. Once we have defined our null object, next we will need to define the state function.

Now, since we already have this nice description here, we can directly take that from here. So the states function is the state space model here. If we look into this a bit more closely, we see this is a standard MATLAB function. And here we've written down-- if this were a live function, we could copy/paste our image of the state space equations. And here, we define some parameters of our vehicle. And then here, you're write down the state equations. Looks a bit nasty, but it's really just implementing what we have seen over here.

The second thing that you can provide is the Jacobians. If we open it up, it's another MATLAB function. In here, we now define the Jacobians of this state function we've seen before. It's not strictly necessary to put down the Jacobians, but it's advisable to always do so when they are available. Otherwise, the MPC controller will have to evaluate them numerically, which is quite costly, especially for a larger problem like this. Always supply them if they are available.

Next, we specify the output function. It's a pretty simple one here. Our output is a vector, which has a longitudinal velocity, lateral deviation and some of the yaw angle and the yaw angle output disturbance. Again, we have a MATLAB script. It's going to be a very simple function because all of these are states, so the output is the third, the fifth, and the sum of the sixth and seventh state. And similarly, we define the Jacobian of the output function, that's also very straightforward here. Then, we define some more stuff. We define the controller sample time. We control a prediction horizon. It's 30, sample time is 0.1, so we have a 3 seconds prediction horizon. We predict 3 seconds into the future. And we take a control horizon of 2 as Gernot mentioned, taking a shorter control horizon should help us a lot in making our problem run much faster. We also set constraints.

As we mentioned, one of the key advantages of MPC is that we are able to set constraints. We have a minimum and a maximum acceleration. We cannot accelerate infinitely fast. We also have a minimum to maximum steering angle. We set scale factors. We should always keep in mind-- we need to solve an optimization problem to actually make a prediction.

So, optimization problems, they're quite sensitive to numerical issues. If you have 1 state which is at 1 to the -5 and other state is around 10 to the 6th, then you will run the 2 numerical problems, and it will not solve it well. We need to make sure all our states are scaled similarly between, usually around 0 and 1. We have some scale factors to get that right. Then, we need to define weights. So we have a standard MPC cost function, which government has shown us, this quadratic cost function. And we need to tell the MPC how to weigh this. We need to tell it what is more important, what is less important. This is not a hard rule. So you don't know in advance what exactly are good weights. This is a bit of a Tuning parameter.

So, to figure out how to weigh, this is always a bit of a trade off, as well. Usually, You cannot get everything perfectly. You cannot control every state perfectly. So you need a bit of a trade-off to make sure that the performance is good. And we can also penalize the manipulated variables here. We don't want it to switch too fast to get the chattering, so you can also penalize the changes and the inputs here.

And then we can validate, actually. And we can look, if everything works out. We can call this validate functions, and this tells us that all the dimensions work out, that all the functions take the right input arguments, and give back the right arguments, and that's it actually, Then we can-- we have an object, we have to find everything. And we can place it in our Simulink model, and you can run this whole thing. It will take a second to compile. Then we'll see it launches up my virtual environment. This comes up here and this is in the Unreal Engine, where it simulates my virtual car. You can also see here, on the left, you have the raw segmentation of our camera image and we have the lane marker detection. So we can visualize this, as well, in real time and make sure everything works out.

And we can have this other view, which shows us a dry review with the lane markings. And here, we see this car-- it manages to follow a road. It takes measurements from the environment. It doesn't know the ground truth, so it's a pretty realistic simulation. It takes camera measurements, it figures out where it is, and it gives the right steering commands to make sure we stay in the line while driving in this curve.

There's one point I would be interested in. How are these model-based functions-- cost function, constrained function-- how are they integrated into the nonlinear MPC block? Could you show that, please?

Essentially, the cost functions are part of this MPC object and the documentation that defines how exactly they're formulated. It's a kind of quadratic cost function, and this is predefined because we need to solve an optimization problem, which can take this certain formulation. You can see in the documentation how exactly the mathematical formulation works out. But it's all integrated in the object, we don't need to concern ourselves with implementing it ourselves

And the object that is integrated with the block, I guess, no?

Exactly.

OK, thanks.

Great. That was that. So we've seen how to successfully run an MPC controller, and in this complete Simulink ML simulation for lane following.

Let me just go back through the slides.

I'd just quickly like to close it out. I'm talking about deployment of MPC tuned by the targets for a few slides. And at Embotech we'll also talk about this in much more detail.

To deploy controllers from MATLAB and Simulink, there's various options. After designing controller and, ideally, testing it in simulation, you want to generate code which can be run on an embedded target. From MATLAB, for linear and nonlinear MPC, you can generate C or C++ code for a wide range of embedded targets. Or, for linear MPC, you can generate CUDA code for cheap use-- which allows a faster real-time execution.

If you have Simulink, then you can also take advantage of Simulink Coder and Embedded Coder, which offer further optimizations for specific embedded targets. Or, you can also use PLC Coder, it will target PLCs. And the ADAS blocks are also only supported in Simulink.

This is how you bring your MPC controller to the embedded device-- it's a very straightforward workflow. The main constraint will be that-- the main thing to figure out will be if it actually runs fast enough. So if you deploy an MPC controller, and it runs fast enough, it reaches your desired sample time, then everything is fine. If not, then you might have to look to more advanced solutions.

This is our cue to hand it over to Embotech, who will talk about their highly optimized embedded software for MPC optimization problems.

All right, let's start with the second part. So, Stefano and me will give you an overview on Embedded MPC. We will first talk about modified control for mechatronics systems, and where you actually have these embedded MPC applications. Then, we will have a look at Embotech's FORCES Pro solution-- and FORCES Pro is actually a numerical solver for Embedded MPC. Afterwards, we will dive into applications of MPC for automated driving, on the one side, and for industrial automation on the other side. At the end, we will show the combination of FORCES Pro and The MathWorks small patch control toolbox. So, Embotech and MathWorks have worked together, in the long collaboration, so that there is a workflow to use both software frameworks, that as a user, one can easily design and deploy embedded MPC algorithms.

Let's talk first about implications of Model Predictive Control. So, Model Predictive Control was originally used in the process industry. So, for example, in the chemical plant. And nowadays it goes more and more to the advanced mechatronics systems. If we have a look at them, we see that there are some parts that are common between these two. For example, both are characterized by very complex, nonlinear system dynamics. Complex for example, because you have different inputs and different outputs that you need to consider.

What's also similar is, you have constraints that you need to respect. For example, in terms of the safety, so all the processes need to run in a very safe manner. Then, you have constraints in terms of the performance. So, for example, you want to, in some applications, you want to avoid overshoots. And you also have physical properties that need to be considered. It might be on the actuator side that you have lower and upper bounds. To give you an example here, if you have a valve, you cannot open it more than 100%.

These properties are similar. What makes these advanced mechatronics systems much more challenging is the autonomy. In the chemical industry, or in the process plants, you actually have a human operator and he is surveying this process. And if something goes wrong, he can actually take over. Now, the mechatronics system, they are run entirely autonomous. So, there is a much higher demand on the reliability of the system. And because you do not have this operator anymore that takes over. The other point is that the control algorithms now run on embedded hardware. The embedded hardware is actually very resource-limited, so you only have a small memory available. And also the computation of power is very limited. And the process industry, because you have single plants, you still have a powerful PC where you can run your algorithms. Mechatronics systems, you typically have very high volumes. If you look, for example, into cars, there's a demand to have simpler embedded hardware.

Now that I've talked about these advanced mechatronics systems, let's look into some applications. Here we see 4 icons. The first one is automated driving. There, we have a lot of task-related to motion planning and motion control. All these properties that I mentioned-- they are very important in this application. The same thing with robotic systems-- there also goes more and more into this direction that's not operated in a quite static fashion, where you have the same movement over and over again, but it's going into the direction that it's very reactive to what's happening outside. The same for laser cutting machines, and in general production machines. We'll talk later about it more in detail.

As a last point, the guidance navigation controller algorithms in the aerospace industry. And these 4 pictures are not chosen randomly, but FORCES Pro is actually used in all 4 applications. And FORCES Pro is developed, having in mind, all the requirements that are arising for these mechatronics systems. The good thing is the model predictive control can give significant advantages for these applications. With the process solver-- actually there is a software solution available to run it in serial applications.

To give you one example-- this is trajectory planning for cars. This is done also MPC-based and with FORCES Pro as the numeric solver You see an emergency maneuver. In the last segment, the car sees that there is an obstacle and it needs to avoid this obstacle. And FORCES Pro is running with high frequency and looking for suitable trajectories. Because the optimization problem is solved in a very short amount of time, it's actually possible to do that. And you actually also see if the car would just slam the brakes-- it would not be able to avoid this maneuver. Stefano will talk later a little bit more in detail about this trajectory planning and what's exactly done there. After we have also seen a little bit of background from the topic of motion planning.

Let's look into FORCES Pro. What's the workflow of FORCES Pro? FORCES Pro takes the mathematical optimization problem that's arising from your model predictive control algorithm, and this might be depending on if you have a linear MPC, a non-linear MPC, or hybrid MPC. These can be different types of optimization problems. FORCES Pro takes into account most typically run quadratic programs, nonlinear programs, the mixed integer versions of it. Second, all of the cone programs, linear programs, and quadratically constrained quadratic programs.

Based on that, you as a user would write it down as you would do with pen and paper. Then it automatically generates a numerical solver for this optimization problem. And m tailor made so that you have the fastest available computation time for your specific problem. And it is very highly reliable. It's also tailored for you-- a better platform, so you can run it on a PC, microcontroller, microprocessor, or DSP. It gives you an algorithm that is tailored for all the requirements and possibilities that your embedded hardware does have. What comes out is a numerical solver that you can run on your desktop with C, but, that you can also deploy on your embedded platform.

What are the advantages of FORCES Pro? If you compare it to a very generic optimization solver, it takes into account all the specifics-- the model predictive control control algorithm has in terms of the numerical structure, for example, but also in terms of the embedded platform. For example, if it has paralyzation or not. This makes it the fastest available solver for these embedded MPC problems. Then, it was designed from the very beginning having in mind these embedded MPC applications. That's the reason why it's very small in the memory size-- in terms of the code, And, it also runs on any embedded hardware platform. For example, it uses only static memory allocation.

Because the applications that we go to-- most of them are very autonomous, so that's the reason why there is also high demands on the code quality. And, for example, in the automotive industry, MISRA C is very important. That's the reason why our code is compliant with the MISRA C standard.

At the same time, it is very user friendly, so there's different options that you have to set up your optimization problem and generate your numerical server. One of the ways is the matrix multiplication control toolbox, and we will see later on how this works in detail. And because we, Embotech as a company-- we are focused on model predictive control. That's the reason why FORCES Pro was developed by professional teams since more than 10 years, and new features are added continuously.

We are very happy that many customers trust us for serial applications. And, with all the requirements that we gather from the customers, we are actually able to include these new features that I was talking about. At the end, in many applications, there needs to be a certification process. And Embotech actually also assists with this whole process.

Now, let's look into automated driving applications and Stefano will dive into that and give you a little bit more details.

All right everyone. Thanks, Tiva, and we're going to focus now on a model predictive control applications and implementation for autonomous or automated driving. So first of all, we're going to be talking a little bit more on trajectory generation and tracking. MPC as a history in automotive and apart from automated driving, so classical problems like motion planning and control, path tracking and following. MPC has a place in an chassis control application like ADAS system, torque vectoring, and active suspension control. Actually, active suspension control was one of the first applications for MPC. And, of course, powertrain's in problems that you have control of variable transmissions and in energy management for hybrid vehicles or hybrid electric vehicles.

Optimization in automated driving, this is done in different way by different people. There is no consensus on what is the best strategy. Things are evolving but there is no standard between these interfaces. So the blocks I'm describing here are my own research of the literature and how I see the problem could be split into some problems. Once again, this is not necessarily the approach that everyone takes. It's not the approach that Embotech tales, as we'll see the future. This is kind of intuitive. The first part being the root planner. This is what your-- satellite navigation that's in the car-- basically decides which road to take from A - B.

Then, there is a path planner that actually decides the path for the vehicle to drive. I want to make a distinction here that a path and trajectory-- they're definitely not the same thing. they're 2 very different things. A path, and normally when I say path, I refer to some XY position. Maybe a Pose and maybe a velocity profile at the point. When I refer to trajectory, I mean, then, a full set of states. Which is time-dependent, so at each point in time, you have a full set of states for every vehicle

Third block could be some sort of behavior selector. This is probably fading away as a technique, but behavior selector is some logic that decides, for example, to stay in your lane do a lane change, or perform an overtake. Then, there is a motion planner which outputs the trajectories. So, given a specified path, now it calculates exactly how the vehicle should implement the path. Then, I put here a block called Emergency Manager. This is my technology, but often, there is another block that's a last minute change of trajectory in case something is happening. For example, if the vehicle detects a collision, for whatever reason, something has gone wrong in the calculation, you still have a final stage where this could be corrected.

The Emergency Manager in the simplest case-- and probably the most common-- simply stops the vehicles, or hits on the brake to avoid or mitigate a collision. At the end there is a controller, it's a low level controller that acts directly on the actuator and tries to follow the trajectory generated by the motion planner.

At a very high level, you could say that the first parts of the left-most-part is this strategic part of the decision making, autonomous driving. Then, there is the tactical part, as you can see, the path planner, here I've put it somewhere between strategic and tactical. Some people think it's more strategic, and some people think it's more tactical. Then there, is the operational part, which is actually the low level controllers.

In terms of timing, for the various blocks, as you can imagine, to the left. We're talking about prediction horizon of minutes to hour, if you are in time domain, or kilometers if you are discretizing in space. The blocks to the left normally have slow updates. They are very long look-ahead horizons. There is a low safety concern there. If there is something that's been miscalculated, it's unlikely to result in safety issues.

Normally these problems are complex from the optimization point of view, and they're solved by heuristics. Then, as we move more to the right of this chain of blocks, we then-- sampling time of horizon in the order of milliseconds. Or, if you look at this in terms of space and horizon of meters.

Here, we have very fast updates, and very short look-ahead horizons. If you use techniques like model predictive control, there are very high safety concerns. A miscalculated control input could be catastrophic. You have the preference, of course, to have simpler algorithms, that are more deterministic. So, you say, it's more predictable-- what the output is going to be.

So, for the decision-making part of automated driving-- the scope for a model predictive control, or a more linear model predictive control, is in these last 3 blocks. By the way, we're not talking at all about sensing a perception. We assume that sensing is performed somewhere else-- maybe some sort of state estimation. This is what i would call the decision making parts of deciding how to drive the vehicle.

Let's have a look at the scope for NBC. But before we do that-- I'll spend a little bit of time trying to classify and categorize typical problems in automated driving See what kind of control techniques are more commonly used. And again, this is my own summary. It's not necessarily that this control and techniques I used for this application. But I would say that, to my experience, this is normally the case. This is a typical overview.