Setting control bounds in slacked linear least squares provokes solver error

Possible Bug Report Fixed
,
1

Hey,

I am solving a linear LS problem in acados, via python and with help of casadi using slack variables on the path constraints.
There are bounds on the state but without slacks.
Accordingly I have specified only the matrices related to the slacks on the path constraints. (e.g. I set Jsh but didn’t set Jsbx or Jsbu)

The solver works well on the slacked problem without any errors until adding the following lines of code:

ocp.constraints.lbu = np.array([-1e15, -1e15])
ocp.constraints.ubu = np.array([1e15, 1e15])
ocp.constraints.idxbu = np.array([0, 1])

Then the solver consistently produces status 4 (I tried partial condensing hpipm and full condensing qpoases. I also tried lower constraints like 1000 which are already far higher than the controls the solver would produce without constraints)

When running exactly the same problem but without slacks it would work as expected, e.g. the constraints have no effect as they are so high.

Thanks in advance for your support!

For more details, all the variables of the slacked formulation that I did specify in my code:

ocp.constraints.Jsh
ocp.constraints.Jsh_e
ocp.cost.Zl
ocp.cost.Zl_e
ocp.cost.zl
ocp.cost.zl_e
ocp.cost.Zu
ocp.cost.Zu_e
ocp.cost.zu
ocp.cost.zu_e

Z matrices, z vectors are shaped according to number of path constraints h.

2

Hi,

It is indeed better to set those bounds to numbers in the same magnitude.
So, it is not unexpected to me that control bounds of 1e15 can lead to numerical issues.

However, you said that the issue was the same if you use 1e3 instead. Right?
In which value range are your controls?
And which of the control bounds do you actually want in your problem?
It seems like you set all of them to values that cannot get violated in practice anyway.

3

Thanks for your reply!

Right I also tried 1e3.
The maximum value for the unconstrained controls where at most 12 in one of the problems I tried.
I would like to set the constraints to about 10. (which I also tried)
I only set them so high in the beginning to make sure the solver errors are not the result of constraining the problem too much.

4

So, the issue is the same with 1e3?
What about 1e2?

5

I tried for 1e1, 1e2, 1e3, 1e4, 1e5. It all resulted in the same error.
However I could get it running now by removing slack cost on the terminal state (e.g. not setting Jsh_e, Zl_e, zl_e, Zu_e, zu_e).
I could reproduce a similar behavior in the minimal_example_ocp.py. (the one with the pendulum)
Setting both, bounds on the control and setting slack on terminal states will result in solver errors right at the first iteration, even when setting bounds on control so high they won’t get activated.
When setting only one of them the solver will either converge or at least iterate until maximum iterations.

EDIT:
I realized that I didn’t set the path constraints con_h_expr_e, lh_e, uh_e separately. I only set con_h_expr, lh, uh.
However I am still wondering why this wasn’t resulting in a problem earlier, when setting the slacks on the terminal state and without bounds on u. :thinking:

6

It sounds indeed weird.

If you can share this example, I will have a look and try to see if there is a bug!

7

Thanks for sharing an example privately.

I think the error should be fully addressed with this PR: