Best practice for multirate simulations

[Simone G]

Hello everyone,

First of all, I wanted to thank the entire team for developing and releasing such a great tool. I have been using GRAMPC for months and I'm very happy with how it works. It's incredible how fast it works even with embedded systems. Great job!

After familiarizing with the toolbox and running several simulations using a slightly modified version of your template, I decided to combine the MPC with an already existing low-level control architecture. With the new code, the low-level control system is executed at 0.5 seconds, whereas the MPC runs every 12 minutes.

Unfortunately, since I have started dealing with a multirate simulation, I'm not obtaining the same results as before. Even if I feed the same data of previous simulations with the original template, the system function integrates the dynamics correctly, but the MPC doesn't provide the same output. (The output similar to what obtained previously, but not exactly the same.)

Before further explaining my problem, I would like to know:

(1) What are your recommended best practices for running multirate simulations in which the two rates are particularly different?
(2) As the GRAMPC S-Function sets the MPC's time step from the Simulink, is it possible to provide this information as an input of the function instead? I have read in another discussion that it should be possible to modify the C code, but I would like to know whether it's the only alternative.
(3) In a multirate framework, the simulation step may be very different than the MPC's one. Are you aware of any issue using function calls/triggered systems for reducing the computational burden of the simulation?

I thought to frame my questions to be as general as possible for helping the community also. I'll be more specific if they are too vague and won't let you formulate the best answer.

Thank you so much for your precious help!
Simone

[Andreas Völz]

Dear Simone,

short answer first, longer answer will follow. GRAMPC internally uses a piecewise linear control trajectory, i.e. the control u(t) is interpolated linearly between the Nhor discretization points. However, the MATLAB template handles the control trajectory as piecewise constant, i.e. the control u(t) is held constant during the sampling interval dt. This difference has negligible effect if the sampling time dt is short compared to the prediction horizon Thor, which is the case for most of the examples that come with GRAMPC. In your case, the sampling time of the MPC is quite long, so this might be the source of the differences that you observe now. The solution would be to interpolate the control trajectory during the sampling interval instead of simply using grampc.sol.unext (which is constant). Could you check this?

Regards,
Andreas Völz

[Simone G]

Dear Andreas,

Thank you for your prompt response. I've tried interpolating, but the improvement seems minor.

Is there anything else you would like me to try, or any additional information you need, to avoid the long answer?

Thank you!
Simone

[Simone G]

Hi Andreas,

Is there anything else I could try?

Thanks,
Simone

[Andreas Völz]

(1) What are your recommended best practices for running multirate simulations in which the two rates are particularly different?

Actually, we do not have much experience using GRAMPC in multirate simulations. As I already said in my first short answer, one should interpolate the control trajectory if the sampling time is relatively long. Beyond that, one should validate that the MPC is well-tuned, e.g. smooth decrease of the cost function, reasonable state and control trajectories, state constraints satisfied, line search not always using LineSearchMin or LineSearchMax, multipliers and penalties far from their maximum values, ... Performing the same simulations with a higher number of gradient and multiplier iterations can also be of help to see if some of the problems are due to the sub-optimality of the real-time strategy.

(2) As the GRAMPC S-Function sets the MPC's time step from the Simulink, is it possible to provide this information as an input of the function instead? I have read in another discussion that it should be possible to modify the C code, but I would like to know whether it's the only alternative.

One could add another input to the S-function, which requires a small modification of the C-Code. However, I do not understand why this is necessary, because the sampling time is not changed during the simulation, right? Therefore, updating parameters, initializing and restarting the simulation should also change the sampling time without recompilation of the S-function.

(3) In a multirate framework, the simulation step may be very different than the MPC's one. Are you aware of any issue using function calls/triggered systems for reducing the computational burden of the simulation?

Do you refer to the computation time of GRAMPC or of the simulation in Simulink? In the latter case, it would be better to ask in the Matlab / Simulink discussion boards.

Unfortunately, since I have started dealing with a multirate simulation, I'm not obtaining the same results as before. Even if I feed the same data of previous simulations with the original template, the system function integrates the dynamics correctly, but the MPC doesn't provide the same output. (The output similar to what obtained previously, but not exactly the same.)

To answer that question, I need more information about your problem. Which settings (parameters / options) of GRAMPC did you use with and without the multirate simulation? In particular, horizon Thor, sampling time dt, discretization Nhor, integrator, maximum number of iterations MaxGradIter, MaxMultIter. Do you have state constraints? If yes, I would do tests without state constraints, since this simplifies the debugging.

[Simone G]

Hi Andreas,

Thank you for your answers.
Simone

[Andreas Völz]

Hi Simone,

don't know why you have edited your last message, but I could still read the original one, since I receive them additionally as emails. If I have understood you correctly, the differences occured when you changed the sampling time of the Simulink model and used triggered function calls to keep the original sampling rate for the MPC.

Now, I'm not an expert on the Simulink issues and the S-function has been programmed by one of my colleagues. However, as I have skimmed through the code of grampc_run_Sfct.c, I discovered the following function

static void mdlInitializeSampleTimes(SimStruct *S)
{
    /* Attention: Read dt */
    ssSetSampleTime(S, 0, -1);
    ssSetOffsetTime(S, 0, 0.0);
}

I did not read the whole documentation https://de.mathworks.com/help/simulink/sfg/sample-times-cpp.html but I suspect that the settings could not be appropriate for a multi rate simulation. In particular

If your function has no intrinsic sample time, you must indicate that it is inherited according to the following guidelines:
A function that changes as its input changes, even during minor integration steps, should register the [INHERITED_SAMPLE_TIME, 0.0] sample time.
A function that changes as its input changes, but doesn't change during minor integration steps (meaning, is held during minor steps), should register the [INHERITED_SAMPLE_TIME, FIXED_IN_MINOR_STEP_OFFSET] sample time.

could imply that you need

ssSetOffsetTime(S, 0, FIXED_IN_MINOR_STEP_OFFSET)

Regards,
Andreas