I am having an interesting issue with generated code for a very simple problem:
H = eye(2);
G = eye(2);
g = [0;0];
u = [2;2];
l = [1;1];
When I solve in MATLAB via emosqp calling generated code, the correct answer [1 1] is returned.
However, if I take that same generated code and solve in a Simulink block using a call to coder.ceval(‘osqp_harness’), where osqp_harness is a little C function whose only line (other than #includes) is
then when I interrogate the solution I see it has diverged. All elements of x and y are returned as identical values on the order of 2e9, solver iterations are 100, and solution status is -7 (nonconvex).
This happens with OSQP 0.6.0–but with OSQP 0.3.1 the Simulink process described above returns the correct solution [1 1]. I suspect this behavior actually appeared starting in 0.4.0, but need to go back and verify.
Some slight complexities should be noted with the generated code:
- I manually added #DLONG to glob_opts
- I manually changed all instances of “util” to “osqp_util” (including in filenames)
I made these same modifications for both OSQP versions (0.3.1 or 0.6.0).
I can try to put together a standalone minimum working example, but in the meantime I am wondering whether this issue rings a bell for anyone?