Hi

I am working on a NMPC model in ACADOS, via the MATLAB interface. I have created a model that runs smoothly in MATLAB. Now I want to export it to Simulink, but the performance there is very different. I created an S-function (ocp solver) from my MATLAB based model following the examples of `simulink_example_advanced.m`

in the getting started folder. I used repmat to duplicate my inputs enough to fit the S-function input size requirements (as they are they required for the full horizon).

The Simulink based model returns different results over the full timeline (which is not necessarily problematic as long as they are ‘good enough’ as well), but more importantly becomes infeasible at a certain point in my simulation. This comparison is shown in the graph below (both models were evaluated with the same stopping criterion, all default except: nlp_solver_tol_stat 5e-3):

If I were to make a guess at what is causing this, I would start with looking at the differences between the simulink based solver and the Matlab one. The only real difference between them is the fact that there is one option that I can not use in the Simulink model that I do have in my Matlab model. I use this option to progress my initial state in my next MPC evaluation, this is the option (it is placed within my for loop over my simulation time where I simulate my MPC use case):

`ocp.set('constr_x0', xtraj(:,2)); % set the initial state`

My solution to still have the same functionality in my simulink model was to than use the option `lb_x0`

and `ub_x0`

to constrain this initial state. I ran the MATLAB model with this change as well, and this model was still feasible at all solver calls. There was however a noteworthy difference in the chosen inputs that this model selected as opposed to that where I use the `constr_x0`

option. I believe this difference is because now that I set it as a constrain the state only needs to be that result within the constraint tolerances, (visible if I look at the x-trajectory, i.e. if I constrain a state as 0, it will result in a state being 1e-9). This difference is marginally and the states are generally very much alike, up until the approximately the point where in the Simulink solver the the solutions tend to start becoming infeasible. Hinting at that the root of the infeasibilities may lay at the difference in setting this option.

Do you perhaps know what the root is of the Simulink model resulting in all these infeasibilities?

Am I searching in the right direction with assuming it is caused by this absence of setting `constr_x0`

?

p.s.

The only other potential root of the issue that I can think of is the setting of the S-function input `lh_0`

and `uh_0`

. All constraints are defined as inputs for shooting nodes 0 to N-1 already in the other S-function inputs (lbx, ubx, lbu, ubu, lg,ug, lh, uh). So these feel like a duplicate input, or have I misunderstood how I should use these two S-function inputs.