MATLAB crashing on difficult non-linear dynamics

Possible Bug Report Fixed
1

Hi :wave:

I have a dynamical system which as dynamics which look a bit like dot(x) = sqrt(x).
If I run the ocp solver starting from x = 0, MATLAB completely crashes, apparently in the ocp_create mex-file. (Windows, 64 bit, compiled with MinGW, and all defaults btw).

It is quite understandable that the mathematical problem might be unsolvable for such a case where the derivative is infinite, but it would be nice to get an exception in MATLAB i.s.o. MATLAB completely crashing and needing a restart.
I haven’t included a minimal code example nor the MATLAB crash log yet, as my guess was that the ‘problem’ formulated above would already be sufficiently specific. If you need either or both, I can make the effort.

Is any change in internal exception handling scheduled for future releases?

Kind regards,
Lense

2

Hi,

I would look into it later if you provide the code and crash log.
It definitely shouldn’t crash Matlab in the creation process.

Best,
Jonathan

3

Hi Jonathan,

I have put a zip-file with a .m file, log file and .mat file (loaded by the m-file) here: WeTransfer link

Apologies for the mat-file, but this was the fastest way for me to get to a minimalistic example.

The key thing is: if you replace the sqrt_fun with e.g. @(x) x; is does not crash.

Cheers,
Lense

4

Hi Lense,

I just tried to reproduce this.

Unfortunately, the mat-file is a problem because CasADi objects cannot be easily dumped into it.
I get
Warning: Serializing SWIG objects not supported.
Thus the solver can not be created it seems.

Cheers,
Jonathan

5

Well, the remainder of the code in the script is exactly to restore what cannot be saved into a mat file, namely the casadi variables and the dynamics defined using those variables.
I think that warning can be ignored and has nothing to do with the actual problem. If it also crashes with you now, it makes sense to check that it doesn’t when you replace the square root in the dynamics with an identity (by uncommenting the proper piece in the script).

6

Sorry, yes the error I had was due to me using a later version, but I fixed it.

There is another error with the mat file though:
ocp_traj is some VexarTrajectory looking at the mat file.
But if I load it, I get:

>> load('system.mat', 'ocp_traj')
>> ocp_traj

ocp_traj =

  6×1 uint32 column vector

   3707764736
            2
            1
            1
            4
            5

>> ocp_traj.x_traj_init
Dot indexing is not supported for variables of this type.
7

Ok, that was not intended. I’ll figure it out and get back.

8

Hi Jonathan,

The mat-file contained a custom class of which the definition was in my path (but not yours). I have converted it into a standard MATLAB struct and have made a new upload: Wetransfer update

I think this should run (and crash :stuck_out_tongue:) now.

Cheers,
Lense

9

Hi Lense,

thanks for the updated files!
I could reproduce the crash.
It seems to be an issue in the regularization.

For now, you can avoid the crash by not using the project regularization, you can for example set
ocp_opts.opts_struct.regularize_method = 'convexify';
before creating the solver with
ocp = acados_ocp(ocp_model, ocp_opts);

I will need some more time to find the actual bug and fix issue.
I will update this topic then.

Cheers,
Jonathan

10

So, I found the bug and this should be the proper fix:

For your problem, the solver returns error status 4 since the QP solver is returning error status 3.
Thus, the first QP seems infeasible.
Probably, you can solve it with a better initialization.

1 Like
11

Hi Jonathan,

Good to hear you found multiple ways to relieve the problem :slight_smile:!

Regarding infeasibility, knowing the system dynamics that shouldn’t happen. The only (inequality) constraints we have are some bounds on the controls (actually we also introduced 2 helper states to be able to implement rate constraints as well). The control u = 0 should be feasible (though on the lower bound), but of course have a poor tracking error. There is something problematic in there which is due to a square root in the dynamics such that getting the state away from the initial state might be very difficult as some gradient/jacobian becomes infinite on this square root. It must be numerical problems that look like infeasibility?

I did try to make a minimal example with dot(x) = sqrt(x) + u, but that did not give the same error though.

Cheers,
Lense

12

Good to hear you found multiple ways to relieve the problem :slight_smile:!

You’re welcome! :slight_smile:

Hm, I just tried your example with what was supposed to be working, i.e. this line:

sqrt_fun = @(x) x; % This does not crash

and I also got status 4, so I think the problem is infeasible because of something unrelated to the sqrt function.
Did you check this?