I have a problem with my weights and constraints that I am defining in userparam. I have very weird errors when initializing the OCP in Matlab. Sometimes x0 has wrong dimension, then PenaltyMin has an invalid value, although I have quadruple-checked these values and they are 100% correct. By comparing my current code to the code from earlier stages, I saw that the only difference is in the definition of userparam.
In the newer version, I defined more values in userparam than in the older one. After removing some values the error did not occur anymore. Did you at anytime encounter something similar, or can you explain this behaviour? It especially occured in the estim_penmin function, and what I also discovered is that at some point PenaltyMin and potentially other parameters are overwritten by parameters in userparam.
Thank you very much in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
can you share the code or at least the relevant parts of it? Note that the estim_penmin function internally calls grampc_run which then calls your problem functions so it is important that the userparameters are correctly initialized before the call of estim_penmin. Maybe you extend the userparam vector after estim_penmin? In this case it could happen that your problem function reads from an invalid memory location.
Best regards,
Andreas Völz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sorry for not answering, I have not worked on GRAMPC in the last weeks. The problem came up because I tried to give sth back to my Matlab code from the probfct definition by assigning it to userparam, what messed up the parameter structure.
I still have some general questions about GRAMPC though. Despite reading every discussion on this page and reading the manual there are still some points I did not understand.
In my understanding grampc.sol.xnext is the same as the first x in grampc.rws.x. This seems to be wrong, as it is dependent from Nhor at whch position rws.x and sol.xnext are the same. Why is that? If I set Nhor to 401, rws.x at position 101 corresponds to sol.xnext
If I want to feed discrete measurements to the solver as a reference to follow I can do this by inserting them in each MPC step into a suitable position of userparam. If I do so, it works initially well, but shows a delayed behavior when following the reference. When trying some combinations of Thor, Nhor and dt, it turns out that for large dt (dt = 0.1, 0.2, 0.3) this behavior is better then for small dt (dt = 0.01).
In one of the discussions you also mentioned "The control is updated at time k \times dt" , what does not fit to this behavior. In general the definition of Thor, Nhor and dt as well as the time management of GRAMPC caused a lot of confusion for me.
Best Regards,
Genc Yavuz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my understanding grampc.sol.xnext is the same as the first x in grampc.rws.x. This seems to be wrong, as it is dependent from Nhor at whch position rws.x and sol.xnext are the same. Why is that? If I set Nhor to 401, rws.x at position 101 corresponds to sol.xnext
The first element in the workspace grampc.rws.x is always equal to grampc.param.x0, that is, the initial state from which the integration starts. The value of grampc.sol.xnext is an estimate of the predicted trajectory x(dt) that is computed by linear interpolation of grampc.rws.x at time grampc.param.dt. Therefore, depending on your setttings of Nhor, Thor and dt, the value grampc.sol.xnext may or may not be equal to one of the elements of grampcs.rws.x.
If I want to feed discrete measurements to the solver as a reference to follow I can do this by inserting them in each MPC step into a suitable position of userparam. If I do so, it works initially well, but shows a delayed behavior when following the reference. When trying some combinations of Thor, Nhor and dt, it turns out that for large dt (dt = 0.1, 0.2, 0.3) this behavior is better then for small dt (dt = 0.01).
The basic approach is correct, but the implementation is always a bit difficult so that each step along the prediction horizon uses the desired future reference value. For example, the different roles of global time (going from 0 to Tsim) and local time (going from 0 to Thor) often cause confusion and are source of many errors. I am sorry that I cannot explain why you get better behaviour with larger sampling times, but I simply have not enough information available.
In general the definition of Thor, Nhor and dt as well as the time management of GRAMPC caused a lot of confusion for me.
Thor is the duration of the prediction horizon, that is, how long the MPC looks into the future. In theory, longer prediction horizons are better, but the numerical solution also becomes more difficult. Therefore, in practice one has to choose the horizon as a trade-off between theoretical properties and numerical performance.
Nhor is the number of sampling points used to represent the continuous trajectories in a discretized manner. The required number depends on the system itself, the horizon and the integrator. In general, a simple integration scheme like euler requires more sampling points to get an accurate and stable integration, while less sampling points are necessary for integration with ruku45.
dt is the sampling time of the MPC and is independent of both Thor and Nhor. This sampling time determines how often a new control input is computed or in other words how far the horizon is shifted each time. Note that the spacing of the sampling points along the horizon is not determined by dt but by Thor / (Nhor-1), which may be but need not be equal to the setting of dt. However, there are some cases where implementations become a lot easier if both are set equal.
The global time runs from 0 to Tsim and can be set via grampc.param.t0. In contrast, the local time always runs from 0 to Thor and can be considered as the time along the prediction horizon. The global time can be computed from the local time inside the MPC by t0+t so that it runs from t0 to t0+Thor. However, a common source of error is that GRAMPC already passes t0+t to the system dynamics (ffct and its derivatives) while it passes only t to the other functions (e.g. lfct, hfct, and their derivatives).
Best regards,
Andreas Völz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, thank you for the detailed explanation, they are very helpful and help understanding the time dependencies more.
Now, if I want to incorporate an output y = f(x, u) into my cost function in order to follow an output reference ydes, in my understanding I can define ydes with userparam. Is it possible to define the output inside the function lfct, depending on x and u?
Is there anything special, besides the "normal" structure of GRAMPC I need to be aware of?
Also, in the future I would like to use the GRAMPC with a reference ydes, that is time-varying over the prediction horizon. Is this possible? I already have read the discussions where you mention that for these usecases the time t0 has to be given as a parameter into userparam and then one can use for example sin(t+t0).
For examples with prerecorded discrete points ydes that I want to follow, I then have to give my cost function all of the points along the prediction horizon, which leads to the length of userparam depending on my prediction horizon.
This yields to the question, whether there is a limitation on the number of parameters I can give to userparam?
I would like to know your opinion on this topic, before starting an implementation that is not even feasible with GRAMPC.
Best regards,
Genc Yavuz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now, if I want to incorporate an output y = f(x, u) into my cost function in order to follow an output reference ydes, in my understanding I can define ydes with userparam. Is it possible to define the output inside the function lfct, depending on x and u?
Is there anything special, besides the "normal" structure of GRAMPC I need to be aware of?
The cost functions can be arbitrary nonlinear functions depending on t, x, u and p so there is nothing special to consider when using some transformed output y instead of directly the states. Just check that you implement all partial derivatives correctly.
Also, in the future I would like to use the GRAMPC with a reference ydes, that is time-varying over the prediction horizon. Is this possible? I already have read the discussions where you mention that for these usecases the time t0 has to be given as a parameter into userparam and then one can use for example sin(t+t0).
If you compute your reference values inside the cost function depending on t0+t, then GRAMPC considers this time-varying reference in the prediction and thereby can exploit the look-ahead capability of predictive control.
For examples with prerecorded discrete points ydes that I want to follow, I then have to give my cost function all of the points along the prediction horizon, which leads to the length of userparam depending on my prediction horizon.
This yields to the question, whether there is a limitation on the number of parameters I can give to userparam?
Yes, you have to pass all discrete points to the problem functions via userparam. However, this is not a costly operation, since it is just a pointer to a memory block that is passed around. The size of this memory block may be limited by the operating system but I am pretty sure that you do not reach this limit with desired values for the prediction horizon. From my experience even several thousand elements in userparam cause no problem.
Best regards,
Andreas Völz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have discovered that the lfct function is called often, depending on the parameters Nhor, T and dt. Also I have varying x values at every lfct call.
How exactly does this work? Is lfct called at every step dt and thereby the cost function over the horizon T is evaluated stepwise? Is this the internal discretization that is done in the algorithm?
This would mean that I would only have to incorporate the discrete reference points at the current timestep t+dt and not all the values along the prediction horizon, right?
Best regards,
Genc Yavuz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
it is out of scope to explain the whole algorithm behind GRAMPC. We have done this in the journal paper in Optimization and Engineering and also in the documentation that comes along with the code.
* First, all trajectories are stored in discretized manner.
* Each gradient iteration performs a forward integration of the system dynamics,
* then a backward integration of the adjoint dynamics (involves partial derivatives of cost and system dynamics with respect to the states x),
* then an update of the inputs in the direction of the negative gradient (involves partial derivatives of cost and system dynamics with respect to the inputs u).
The cost function itself is only evaluated after the last gradient iteration unless you use the adaptive line search strategy.
For the start you can always use a constant setpoint over the horizon. This also works if you have a slowly time-varying reference, maybe with a bit of time lag between reference and output. Once this works, you can incorporate the time-varying reference into the prediction.
Best regards,
Andreas Völz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have a problem with my weights and constraints that I am defining in userparam. I have very weird errors when initializing the OCP in Matlab. Sometimes x0 has wrong dimension, then PenaltyMin has an invalid value, although I have quadruple-checked these values and they are 100% correct. By comparing my current code to the code from earlier stages, I saw that the only difference is in the definition of userparam.
In the newer version, I defined more values in userparam than in the older one. After removing some values the error did not occur anymore. Did you at anytime encounter something similar, or can you explain this behaviour? It especially occured in the estim_penmin function, and what I also discovered is that at some point PenaltyMin and potentially other parameters are overwritten by parameters in userparam.
Thank you very much in advance!
Dear Genc Yavuz,
can you share the code or at least the relevant parts of it? Note that the estim_penmin function internally calls grampc_run which then calls your problem functions so it is important that the userparameters are correctly initialized before the call of estim_penmin. Maybe you extend the userparam vector after estim_penmin? In this case it could happen that your problem function reads from an invalid memory location.
Best regards,
Andreas Völz
Hello,
I am sorry for not answering, I have not worked on GRAMPC in the last weeks. The problem came up because I tried to give sth back to my Matlab code from the probfct definition by assigning it to userparam, what messed up the parameter structure.
I still have some general questions about GRAMPC though. Despite reading every discussion on this page and reading the manual there are still some points I did not understand.
In my understanding grampc.sol.xnext is the same as the first x in grampc.rws.x. This seems to be wrong, as it is dependent from Nhor at whch position rws.x and sol.xnext are the same. Why is that? If I set Nhor to 401, rws.x at position 101 corresponds to sol.xnext
If I want to feed discrete measurements to the solver as a reference to follow I can do this by inserting them in each MPC step into a suitable position of userparam. If I do so, it works initially well, but shows a delayed behavior when following the reference. When trying some combinations of Thor, Nhor and dt, it turns out that for large dt (dt = 0.1, 0.2, 0.3) this behavior is better then for small dt (dt = 0.01).
In one of the discussions you also mentioned "The control is updated at time k \times dt" , what does not fit to this behavior. In general the definition of Thor, Nhor and dt as well as the time management of GRAMPC caused a lot of confusion for me.
Best Regards,
Genc Yavuz
Dear Genc,
The first element in the workspace grampc.rws.x is always equal to grampc.param.x0, that is, the initial state from which the integration starts. The value of grampc.sol.xnext is an estimate of the predicted trajectory x(dt) that is computed by linear interpolation of grampc.rws.x at time grampc.param.dt. Therefore, depending on your setttings of Nhor, Thor and dt, the value grampc.sol.xnext may or may not be equal to one of the elements of grampcs.rws.x.
The basic approach is correct, but the implementation is always a bit difficult so that each step along the prediction horizon uses the desired future reference value. For example, the different roles of global time (going from 0 to Tsim) and local time (going from 0 to Thor) often cause confusion and are source of many errors. I am sorry that I cannot explain why you get better behaviour with larger sampling times, but I simply have not enough information available.
Thor is the duration of the prediction horizon, that is, how long the MPC looks into the future. In theory, longer prediction horizons are better, but the numerical solution also becomes more difficult. Therefore, in practice one has to choose the horizon as a trade-off between theoretical properties and numerical performance.
Nhor is the number of sampling points used to represent the continuous trajectories in a discretized manner. The required number depends on the system itself, the horizon and the integrator. In general, a simple integration scheme like euler requires more sampling points to get an accurate and stable integration, while less sampling points are necessary for integration with ruku45.
dt is the sampling time of the MPC and is independent of both Thor and Nhor. This sampling time determines how often a new control input is computed or in other words how far the horizon is shifted each time. Note that the spacing of the sampling points along the horizon is not determined by dt but by Thor / (Nhor-1), which may be but need not be equal to the setting of dt. However, there are some cases where implementations become a lot easier if both are set equal.
The global time runs from 0 to Tsim and can be set via grampc.param.t0. In contrast, the local time always runs from 0 to Thor and can be considered as the time along the prediction horizon. The global time can be computed from the local time inside the MPC by t0+t so that it runs from t0 to t0+Thor. However, a common source of error is that GRAMPC already passes t0+t to the system dynamics (ffct and its derivatives) while it passes only t to the other functions (e.g. lfct, hfct, and their derivatives).
Best regards,
Andreas Völz
Dear Andreas Völz,
First of all, thank you for the detailed explanation, they are very helpful and help understanding the time dependencies more.
Now, if I want to incorporate an output y = f(x, u) into my cost function in order to follow an output reference ydes, in my understanding I can define ydes with userparam. Is it possible to define the output inside the function lfct, depending on x and u?
Is there anything special, besides the "normal" structure of GRAMPC I need to be aware of?
Also, in the future I would like to use the GRAMPC with a reference ydes, that is time-varying over the prediction horizon. Is this possible? I already have read the discussions where you mention that for these usecases the time t0 has to be given as a parameter into userparam and then one can use for example sin(t+t0).
For examples with prerecorded discrete points ydes that I want to follow, I then have to give my cost function all of the points along the prediction horizon, which leads to the length of userparam depending on my prediction horizon.
This yields to the question, whether there is a limitation on the number of parameters I can give to userparam?
I would like to know your opinion on this topic, before starting an implementation that is not even feasible with GRAMPC.
Best regards,
Genc Yavuz
Dear Genc,
The cost functions can be arbitrary nonlinear functions depending on t, x, u and p so there is nothing special to consider when using some transformed output y instead of directly the states. Just check that you implement all partial derivatives correctly.
If you compute your reference values inside the cost function depending on t0+t, then GRAMPC considers this time-varying reference in the prediction and thereby can exploit the look-ahead capability of predictive control.
Yes, you have to pass all discrete points to the problem functions via userparam. However, this is not a costly operation, since it is just a pointer to a memory block that is passed around. The size of this memory block may be limited by the operating system but I am pretty sure that you do not reach this limit with desired values for the prediction horizon. From my experience even several thousand elements in userparam cause no problem.
Best regards,
Andreas Völz
Dear Andreas,
I have discovered that the lfct function is called often, depending on the parameters Nhor, T and dt. Also I have varying x values at every lfct call.
How exactly does this work? Is lfct called at every step dt and thereby the cost function over the horizon T is evaluated stepwise? Is this the internal discretization that is done in the algorithm?
This would mean that I would only have to incorporate the discrete reference points at the current timestep t+dt and not all the values along the prediction horizon, right?
Best regards,
Genc Yavuz
Dear Genc,
it is out of scope to explain the whole algorithm behind GRAMPC. We have done this in the journal paper in Optimization and Engineering and also in the documentation that comes along with the code.
* First, all trajectories are stored in discretized manner.
* Each gradient iteration performs a forward integration of the system dynamics,
* then a backward integration of the adjoint dynamics (involves partial derivatives of cost and system dynamics with respect to the states x),
* then an update of the inputs in the direction of the negative gradient (involves partial derivatives of cost and system dynamics with respect to the inputs u).
The cost function itself is only evaluated after the last gradient iteration unless you use the adaptive line search strategy.
For the start you can always use a constant setpoint over the horizon. This also works if you have a slowly time-varying reference, maybe with a bit of time lag between reference and output. Once this works, you can incorporate the time-varying reference into the prediction.
Best regards,
Andreas Völz