Implementing rate constraints and rate costs


I am working on transferring an OCP from Casadi to Acados using the Python interface and was wondering if its in any way possible to implement rate constraints and rate costs. My this i mean e.g. having constraint on my input rate or adding x_dot to my objective. A trivial way to do this in Casadi would be to add a constraint/objective term with the difference between two consequative inputs or state variables e.g. u_{k+1} - u{k}. Is there a way to add such a cost/constraint in Acados? It seems to me like each stage cost is completely separate from each other, making this impossible, is this indeed the case?

I know this could be achieved by augmenting the dynamics or adding the dynamics function as x_dot in the cost function / path constraints, but that would increase the number of variables or complicate the NLP a lot, so it would not be ideal.

Any help greatly appreciated, cheers!

1 Like

Hi Martin,

Reformulating your system to have u as a state and \dot{u} as the new control would probably be the way to go.
In typical optimal control problem formulations, there is no coupling of the control inputs.
Since acados is tailored to exploit the typical optimal control problem structure, this is not supported.

Yes, the stages are only coupled trough the model dynamics.
Sorry, if this is not ideal for you.
But I hope you can still get good enough performance in acados using this reformulation.


Hi Jonathan,

I see, thanks for the quick and detailed reply. I was hoping there was a way around it but i will try adding u as a state to get u_dot and using the dynamics function to get x_dot then.

Thanks for developing this awesome framework!


1 Like

Hi @martiabr,

I am trying the same right now, only creating weird output rates and thus failing.
Would love to hear if you made it!

greets, Alex

Hi @AlexWin,

I have managed to add a cost term on x_dot using my dynamics function and it works great. I have not yet tried to add input rate constraints, but I dont see why it should not work. Just have to augment the dynamics, update the constraints properly and make sure the new state u is initialized.
I will get back to you once I try it!


Hi again @AlexWin,

Just tested it on my system and it seems to work ok. With the way I did it you need to pull out the u state variable at stage 1, and apply it at the next time step. This introduces a delay so I dont think this is a good solution. But taking u at stage 1 and applying it at the current step (0) seems a bit hacky. Would be interested to hear your approach.

Cheers, Martin

Hi @martiabr,

As stated above, I extended my state vector by the control quantity, added constraints to the derivative and penalized it in the cost function. I take the “real” control variable from the state vector output of the solver and pass it to the simulink model. Unfortunately the results are nonsensical. I tried both ways, using u_0 or u_1.

For example, the absolute value of the control variable is directly dependent on the maximum rate of change of the control variable. As if the solver would always set x0 to zero. Short example: At Ts = 0.1 s and du_max = 500 Nm / s, u0 = 50 Nm, u1 = 100 Nm, u2 = 150 Nm.
Do you know these errors? Can you think of a solution or something I should check?

Greets, thanks for your help,

@tom since I read your recently published paper “NMPC for Racing Using a Singularity-Free Path-Parametric Model with Obstacle Avoidance”, maybe you can help?

Hi @AlexWin,
I am not the same Tommaso from the article, sorry.
I’ve been using acados for some time for my thesis but I would not know how to help you.

it was worth a try. :wink: thx for the answer anyway. all the best

Hi @AlexWin,

Are you sure you initialize the variables correctly? If you let u0 be 0 (which is the case for my application) it would make sense that u is “maxing out” the du constraint at every time step in the beginning. That behaviour you describe is exactly what I get for my system and is something I expected. What happens if you relax du_max? Do you get the normal behaviour without input rate constraint if you let du_max be very large?

Cheers, Martin

Hey @martiabr,

thx for your help, indeed I initialized the problem wrong. Turning on the warm start option improved the results a lot as well. It is working! Appreciate the help.

Greets, Alex

1 Like