We are facing an issue with the Acados sometimes returning status code 4. We have located this to have a correlation with times where we have been running on a constraint for a while and we think this has to do with the init_x and init_u initial guesses. Since we use the previous solution to initialize the next solver call, it seems that if we have variables in the previous solution that are right on their constraint limits, they can cause the solver to be infeasible at the initial point. Maybe due to numerical rounding? This is very disturbing for our application as we do not have a way to safe guard against it.
Would it be possible to implement an improvement to Acados such that it does not require the initial guess to be feasible? Can the first SQP iteration be made “soft” by default or is there a better way to handle this? We simply need to find a way to robustify the solver against this situation.
We are looking very much forward to hear your thoughts on this!
Thanks a lot for all your great work!
as you suggested I would recommend to slack some/all of your constraints if you are running into infeasible problems. This is not possible for a single SQP iteration though.
Yes, I agree that this can be a solution. But having it as a built-in functionality in Acados, to ensure that the initial guess does not cause infeasibility, would make it way less complicated to handle for the user. The initial guess is only a guess, so requiring that it is also a feasible solution to the problem (before you know the solution) is an issue, I think.
You do not need to initialize with a feasible guess! But depending on your constraints you might run into infeasible subproblems within the SQP iterations.
We have talked about this, and even though we might be drawing some wrong conclusions, it seems that there is a strong correlation between some of our variables being right at their limits in one solve, and then getting a solver code = 4 in the following solve (where the previous solution is used as x_init and u_init). This, at least makes us think, that numerical rounding could cause a solution right on the constraint to be interpreted as an infeasible initial point in the next solve.
You mention that the initial guess does not need to be feasible but that the subproblems in the SQP iterations could be infeasible:
Is there some general way to avoid this? Make the code recursively feasible also in the subproblems?
Does HPIPM need an initial point which is feasible for the subproblem?
Adding slacks to all constraints seems like a lot of extra decision variables only to avoid this particular issue. If we use the built-in formulation for soft constraints, is this more efficient than simply adding an extra decision variable in the u vector that is used as slack in a soft constraint. Could you elaborate on the difference between extending the u vector to manually add slack variables and using the built-in options for soft constraints?
