MPC is a predictive controller. Which means that MPC will analyse the best input values $u$ to get the shortest way from setpoint to reference point in trajectories $x$.

MPC is very well used in the industry. But my question is:

As I heard, LQR with saturation limits on $u$ is equal to MPC. Because LQR do the same math as MPC. The difference is that MPC have some limits in the input signal. I'm talking about the very basic MPC now.

That make me wonder what will be the difference between implementation of a controller with saturation and a controller with no saturation.

Image that we have a car and the car starting from 0 and the goal is 100. The controller's mission is to speed up the car so the car can recive 100 at a few seconds, without over shoot.

So, let's assume that we are implementing a LQR controller inside the car and start the controller. The LQR gives full signal into the fuel injection module inside the car, but in reality, the LQR is implemented inside a computer and the computer's signal output is limited. Which results that the fuel injection model cannot give full power to the engine inside the car.


Due to the limits inside the car and the computer. The LQR controller will act like it has saturation in the input, and the results will be that LQR in reality will act like MPC in a simulation?

And this expand to a following question: If I want to simulate a process inside my computer, a MPC is better preferred that LQR, due to the built in saturation/constraint limits in the MPC controller?


No, an LQR controller (or trivially saturated LQR controller) will not give the same control signal as an MPC controller. You can (and typically want to) tune he MPC controller though such that it coincides with the LQR feedback once the system enters the state where the LQR feedback is and remains unsaturated.

If LQR gave the same control as MPC we would never use MPC, as MPC is several orders of magnitudes more computationally expensive.

| cite | improve this answer | |
  • $\begingroup$ But LQR is still a predictive controller? $\endgroup$ – Daniel Mårtensson Feb 12 '18 at 19:50
  • $\begingroup$ It would be very interesting to know how good an MPC is compared to a LQR, and to what price. $\endgroup$ – Daniel Mårtensson Feb 12 '18 at 19:54
  • $\begingroup$ Depends on what you put in the word predictive controller. Any controller which uses a model is in a sense a predictive controller (what is the model for otherwise?). But you can also say a completely model free PD controller is predictive, as the whole purpose of the D-part is to predict. However, many people reserve the word predictive to the machinery typically involved in MPC (model, optimization, prediction horizon, constraints, possible preview) $\endgroup$ – Johan Löfberg Feb 13 '18 at 7:01
  • 1
    $\begingroup$ If you don't have constraints, there is no reason to use MPC unless you absolutely want to use some strange objective. You can formulate the standard quadratic MPC problem if you wish, but you can solve it analytically and the result is a linear state-feedback (+linear feedforward of references, forecast disturbances ) $\endgroup$ – Johan Löfberg May 24 '19 at 16:10
  • 1
    $\begingroup$ Terminal cost is the penalty on the final state, $x_{k+N}^TPx_{k+N}$, hence you select $P$ to be the cost-to-go Riccati solution from LQ $\endgroup$ – Johan Löfberg May 24 '19 at 16:11

LQR is designed via an offline optimization.

MPC is equipped with an online optimization. At every sample time, MPC optimizez the input to the plant. In addition, MPC is talent to handle the constraints. It predicts possible future infringements and avoid them. While LQR reach the limits and then thinks how to get out of the trouble.

Handling the input constraints are very trivial. The concern is mostly related to handle the output constraints.

| cite | improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.