Time optimal formulation

HI,

If I am not mistaken, there is no time optimal formulation in acados (optimize time as a parameter). There was one in ACADO I think. Do you plan on adding this in the future?

Cheers,
CT

Hi @ctoumieh,

Sorry for the loose response, I guess we all missed your post :stuck_out_tongue: At the moment it is not possible to use the prediction horizon T as an optimization variable. You can however, try to use a reformulation with time-scaled dynamics, but it might not be possible to do so from the high-level interfaces at the moment (you would need to keep one of the components of x_0 free). This would be instead relatively easy from the C interface and we should make this feature available from MATLAB/Python asap.

Cheers,
Andrea

2 Likes

Is there any update on this? I’m also trying to solve a time optimal problem, and this feature would be really useful to have in the Matlab interface.

Hi @aknight0, welcome to the forum!

There is indeed an update:
The interfaces now allow for a more flexibel way of setting bounds on the initial state vector x0.
Instead of setting the property constr_x0, you can now set the following properties.

  • constr_Jbx_0, the matrix that specifies which components of x0 are bounded
  • constr_lbx_0, constr_ubx_0 the lower and upper bounds on x0

I did not play around with that a lot in Matlab, so please let me know if there is an issue

Best,
Jonathan

Great, thank you! I’ll try it out and let you know if I run into any issues.

This is working well, and I’ve been able to solve my time optimal control problem in Matlab. However, I noticed that it is not possible to update the initial constraint after the model is compiled, as you can for constr_x0. Is that a possibility to add? For that matter, is it possible to change the terminal state constraints after compiling? I’d like to run the same problem repeatedly for different starting and ending constraint values.

Hi @aknight0,

I am glad that is working for you!

It is already be possible to update the values for the bounds on x at an arbitrary stage, i.e. shooting node.

Assuming you created an acados ocp solver in Matlab called ocp, this works as follows:

% rough API of the setter: ocp.set('field', value, optional: stage_index)

% Set lower bounds on x for initial stage:
ocp.set('constr_lbx', ones(nx,1), 0)
% Set lower bounds on x for terminal stage:
ocp.set('constr_lbx', ones(nx,1), N)

% For upper bounds it is the same: use field = 'constr_ubx'

Best,
Jonathan

Has there been a change to how this works? I had code working with constr_lbx_0 and constr_ubx_0, but after recent updates, it is no longer giving the correct answers. I see a new parameter constr_idxbxe_0 in the interface code that is set when using constr_x0, but not for the bounds version. What is that?

I also get different answers when using constr_x0, and when setting constr_lbx_0 and constr_ubx_0 to the same value. It almost seems like the bound on the first state is being set correctly, but the remainder are not. For example, this image shows the expected behavior from an MPC problem using constr_x0.
debugx0_2
And this image shows the result I’m getting using the same x0 values in constr_lbx_0 and constr_ubx_0 with i.e. ocp.set(‘constr_lbx’,x0,0). It’s like the starting y values are offset by 1.
debugx0_1

Hi @aknight0,

indeed the field constr_idxbxe_0 has been introduced recently.
idxbxe are the indices of bounds on x that are always equality constraints.
_0 means they belong to the first shooting node.

It is set internally, when setting constr_x0.

I think that things go wrong, right now, because the dimension nbxe_0 is set to nbx_0 even though idxbxe_0 is not provided.

I think that it is fixed in my PR:
https://github.com/acados/acados/pull/585, more specifially in this commit: https://github.com/acados/acados/pull/585/commits/a5bdd1e80c8eb0537fbd9b81ec3f5128d84107bc.

Can you try and let me know if there is still an issue?

Best,
Jonathan

Thank you Jonathan, changing those lines fixed the problem, and things are working as they were before. One small note, the code in your commit is missing an end after the if statement.

Oops, thanks for spotting!
I guess I am becoming a Python guy :sweat_smile: