User Activity

  • Posted a comment on discussion General Discussion on GRAMPC

    Hi Sophie, I don't see anything wrong with your approach. If I modify the grampc_run_Sfct.c ((typeRNum*) grampc->rws->u)[0] = -1.0; /* run mpc */ grampc_run(grampc); this works fine for me. Could you maybe provide the message shown by Simulink on crashing? You can also check, that you don't change any values in u and p that are out of bounds. I can produce a crash with your code by using an expample without parameters, i.e. dim(p)=0. If you then try to change some parameter value ((typeRNum*) grampc->rws->p)[0]...

  • Posted a comment on discussion General Discussion on GRAMPC

    With regard to your first question. You have to change the file probfct.c, which contains the dynamics, cost functions, constraints and the corresponding derivatives. Please refer to section 3 of the manual. Regards, Felix

  • Posted a comment on discussion General Discussion on GRAMPC

    Hi Pierre, sorry for the late answer.... Yes, you need the previous values of the control signal. I guess your way will work. Another approach would be to directly manipulate the field which holds the control values in the grampc struct (see line 171 of startMHE.m in the CSTR example). Your states will be calculated via integration (See section 2.3 in https://link.springer.com/article/10.1007/s11081-018-9417-2?wt_mc=Internal.Event.1.SEM.ArticleAuthorOnlineFirst&utm_source=ArticleAuthorContributingOnlineFirst&utm_medium=email&utm_content=AA_en_06082018&ArticleAuthorContributingOnlineFirst_20190121)...

  • Posted a comment on discussion General Discussion on GRAMPC

    Hi Pierre, your approach sounds fine. You need to supply your MHE-block/probfct with your measurements. This is best done with the userparam (see the CSTR example). To be able to do change the userparam with the S-function in simulink, see https://sourceforge.net/p/grampc/discussion/general/thread/c6123760c1/ where this problem was already discussed. If you have any further questions, feel free to ask. Regards, Felix

  • Posted a comment on discussion General Discussion on GRAMPC

    Hi Daniel, we use an augmented Lagrangian formulation to handle equality and inequality constraints. The underlying minimization is done with a projected gradient method (see Section 3.3 in https://link.springer.com/content/pdf/10.1007%2Fs11081-018-9417-2.pdf for more details). In each iteration, the dynamics (and adjoint dynamics) are integrated over your horizon Thor with the integration scheme you chose, where the step size for Euler / Heun is equal to (Thor / (Nhor -1)). It seems your step size...

  • Posted a comment on discussion General Discussion on GRAMPC

    If you do it like this, your system dynamic will not be continuous. This might lead to numerical problems in the integration of your adjoint states. You didn’t write so explicitly, but I assume you also added this change to every function in your probfct-file? In addition, your predicted states 4-6 can very well be negative, since out[3] = U0; out[4] = U1; out[5] = U2; Like I wrote earlier, after changing the option LineSearchMax, I didn’t have any problems running your example (no NaNs appearing),...

  • Modified a comment on discussion General Discussion on GRAMPC

    Hi, it should definitely be possible, but you are not supposed to change the value of the state x from within the probfct.c. This is why all arguments besides out and userparam are constant... What you have to do, is to change the values in out[0], if x[0] is close or equal to zero. I believe your state x[3] is some kind of in/outflow for you first state, i.e. if x[0] == 0, then x[3] < 0 is not possible and the respective part in out[0] = ... should be removed? if ( (x[0] < 1e-16) && (x[3] < 0.0)...

  • Posted a comment on discussion General Discussion on GRAMPC

    Hi, it should definitely be possible, but you are not supposed to change the value of the state x from within the probfct.c. This is why all arguments besides out and userparam are constant... What you have to do, is to change the values in out[0], if x[0] is close or equal to zero. I believe your state x[3] is some kind of in/outflow for you first state, i.e. if x[0] == 0, then x[3] < 0 is not possible and the respective part in out[0] = ... should be removed? if ( (x[0] < 1e-16) && (x[3] < 0.0)...

View All

Personal Data

Username:
mesmer
Joined:
2018-07-03 07:05:54

Projects

This is a list of open source software projects that Felix Mesmer is associated with:

  • GRAMPC A gradient-based augmented Lagrangian framework for embedded NMPC Last Updated:

Personal Tools