Control horizon

How can I choose the control horizon from the matlab interface?
What is the value of that control horizon as default?
Thanks in advance

Hi Antonio,

if you look at this example: https://github.com/acados/acados/blob/master/examples/acados_matlab_octave/getting_started/minimal_example_ocp.m

There are the fields T and param_scheme_N, which are the control horizon time and the number of shooting intervals respectively.

Cheers,
Jonathan

I thought that the fields T and param_scheme_N defined the prediction horizon, not the control horizon.
From what you are saying, I suspect that the prediction and control horizon are the same as default. I am right?
Thanks in advance!!

Right, I was not really familiar with the term control horizon.
acados only supports problems where the prediction and control horizon are equal.

The case where they are not equal is just to have a long constant control in the end of the horizon as far as I understand.

This can be implemented in acados by using a nonuniform grid and setting the time between the last 2 shooting nodes larger compared to the previous ones.
In order to achieve the same integration accuracy, you could use more steps in the last integrator.

Would that work for you?

Yes, I think it will help to solve the OCP faster.

Could you show me an example of how to do that in the Matlab interface? It would be very helpful.

If I understood correctly, we have a time grid [t0,t1,t2,…tN] in which we discretize the
controls to obtain piecewise constant controls, and we use the integrator to solve the ODE in the interval [tk, tk+1] of the same grid. For that reason control horizon and prediction horizon are always the same. Isn’t it?

I suposse you refer the option sim_method_num_steps in the matlab interface. Could you explain what that option means?
I think it means that, if you have a time grid [t0,t1,t2,…tN] in which we discretize the
controls, and for example if the number of steps of the integrator is 3, in the interval [t1,t2], we have a constant piecewise control, but we solve 3 ODEs in [t1, (t1+t2)/2, t2]
Is it correct?

Thanks in advance, sorry for the inconveniences and for writing such a long question.

Sure, here e.g. https://github.com/acados/acados/blob/90d75386cad9f2b16115cce04685e90934c0f7d8/examples/acados_matlab_octave/test/test_ocp_linear_mass_spring.m#L208

sim_method_num_steps, exists on each shooting interval [tk, tk+1].
The shooting interval is divided uniformly and the integration method (e.g. RK4) is applied to each of these subintervals.
IVPs are solved, not ODEs.

Note, from Matlab it is not possible yet to use different number of sim_method_num_steps for the shooting intervals. But there is a PR that adds this possibility for python: https://github.com/acados/acados/pull/698/commits/9b8e306b5ce337ac62202810c0a2cf173534ee9e

For that reason control horizon and prediction horizon are always the same. Isn’t it?

As I stated above, different control and prediction horizon can be formulated equivalently by using a longer last shooting interval in my opinion.

Cheers,
Jonathan

2 Likes

Hey,

sorry to dig out this four year old threat but i recently tried to implement an ocp with a smaller control than prediction horizon and came across the following questions:

  1. Is it possible to access the intermediate integrator values between the last two shooting nodes?
  2. In my understanding, setting the time between the last two shooting nodes larger will have as a consequence that we evaluate y (as example for LINEAR_LS) just once at the first shooting node instead of throughout the whole prediction horizon. I think that setting a control horizon different to the prediction horizon is more comparable to adjusting Vu at the n-th shooting node for all consequently following shooting nodes to all zeros (with n being the control horizon length). I would assume, however, that this will not have the same positive effect on computation time. Because all the u’s will still be instantiated for all the shooting nodes I would assume? Maybe we would need for this to work multiple “terminal” shooting nodes, which do not involve u at all.

Thanks,
Alex

Edit: Sorry, setting Vu to zero doesn’t make sense as then the control input would just go through the roof. What I intended is to keep the control input out of the equation like the terminal shooting node does.

Hi Alex,

I think the question is how to treat the part of the horizon that is not in the control horizon but in the prediction horizon, let’s call it the uncontrolled horizon.
I think in systems with steady state x=0, u=0, the the uncontrolled horizon, just uses u=0 to predict the behavior of the system on this part of the horizon. Does this align with your understanding?

In this case, I think my previous answer was indeed not correct, as one wants a fixed control on this uncontrolled horizon.
I think this is a special case of closed-loop costing, and can be modeled well with a multi-phase problem in acados, see our publication: Multi-Phase Optimal Control Problems for Efficient Nonlinear Model Predictive Control with acados
In this case you can also use multiple shooting on the uncontrolled horizon and retrieve the states there and have a corresponding cost discretization.

Indeed, the cost is by default just evaluated at the nodes in the OCP. However, you can use a finer cost discretization with the option cost_discretization for nonlinear least-squares and convex-over-nonlinear cost functions together with a Gauss-Newton Hessian, as described in Gauss–Newton Runge–Kutta integration for efficient discretization of optimal control problems with long horizons and least-squares costs.

Is it possible to access the intermediate integrator values between the last two shooting nodes?

This is not interfaced right now.
But I think the approach outlined above is the correct way to do it.

Let me know what you think!

Best,
Jonathan

Hey Jonathan,

yes exactly, the derivative of the control should be zero in the “uncontrolled” horizon while all the constraints and remaining costs e.g. of the reference should be further evaluated. Ironically, that would correspond to setting the cost of u_dot to inf for the uncontrolled horizon (opposing to what I previously mentioned).
I will take a look at your paper on multi-phase OCPs and the implementation in acados, thanks. Using cost_discretization doesn’t work out for me if it can only be used with IRK because of computational performance considerations.

Thank you for the quick response.

Kind regards
Alex

1 Like

Right, cost integration is only done in IRK for now. We might implement it in ERK at some point.