i’m using the Matlab interface.
Currently, I’m using a constraint that includes parameters.
However, these are multiplicative with my states and inputs [x,u].
This leads to detect_constr() correctly detecting them as linear constraints.
The problem is that in the jacobian, there are now constant matrices with parameters that are not evaluated (resulting in free parameters and an error). I guess linear constraints with parameters are not permitted…

Is this intended behavior?
I guess the additive case would be fine, as the jacobian is constant and contains no parameters.
To reproduce this error define constraints of the form sym_x*sym_p, e.g., sym_x(1)*sym_p(1).

A dirty fix was to add || any(c.which_depends(model.sym_p)) to the check in detect_constr() (line101) and treat every parametric constraint as nonlinear (which is not optimal for the additive case, however).

I’m very new to acados maybe you are not supposed to be using parameters in that way
However, with my dirty fix everything seems to work as it should…

thanks for reporting this.
The detect_constr() function is a Matlab feature that I wrote a few years ago.

Indeed I think that this is the correct fix.
In general, it is possible to formulate such constraints using the general linear constraints g.
However, the coefficients of those constraints are not changed with the parameters, the have to be changed separately changing the matrices C, D in the acados problem formulation.

I guess there is some room for improvement, as parametric constraints can be both linear and linear with constant values of C and D, but it certainly works.

Thanks for the hint using matrices C and D…
Is it also possible to set those at each shooting node? That would be all I need.

Another question I had was whether there is a command that does something like
ocp_model.set(‘constr_lh’, -Inf);
I guess the SQP solver does not like non-finite values here

Infinity values are not supported, you need to find some value such that the constraint is never active but too large values can lead to numerical issues.

yes, you can change them on each shooting nodes with the fields “constr_C” and “constr_D”.

Maybe printing something that they are actually linear but such an automatic reformulation not being supported would be better.