I have started to use GRAMPC for a project in order to validate it and understand if it is suitable for my implementation. Until now everything is OK except one thing.
I have put some inequality constraints for my states. Specifically, for one state in order to arrange the bounds for that. However, I need my constraints to vary during the Prediction Horizon. For example, if I have a prediction horizon with 5 steps, I need to have a constraint for my state like: state_constraint = [1, 2, 3, 4, 5]. I would like, if it is possible, you to explain me how it can be done, as currently I just put a constraint like: out[0] = param[0] - x[0] where param is the bound of my state, but it is the same during the whole horizon.
Thank you in advance,
Konstantinos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank your for your interest in GRAMPC. If I understand you correctly, you have a time-varying inequality constraint that depends on the time t \in [0, T]. For example, x(t) < 1 + t, which would result in x(0s) < 1, x(1s) < 2, x(2s) < 3, ... x(Thor) < 1 + Thor. Such constraints can be easily implemented, since the prediction time t is already passed to the constraint functions as second argument.
Regards,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your response. I don't have the constraints given as explicit formulas, containing time values. But I have exactly the lower and upper bound as values, directly, comming from a different component. For example: at a certain time sample, I have a vector of low_bound = [l(t), l(t+1), l(t+2),...,l(t+h)] and a vector of upper_bound= [u(t), u(t+1), u(t+2),..., u(t+h)], both with the length of the prediction horizon. And the lower and upper bounds vectors are not constant.
Kind regards,
Konstantinos Spanos
Last edit: Konstantinos Spanos 2019-12-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the vectors of lower and upper bounds can be updated in each time step using the user parameters. If you use an integrator with fixed step-size (euler, modeuler, heun), you can determine the index for the vectors of upper and lower bounds. Something like t * (Nhor - 1) / Thor, such that t = 0 gives index 0 and t = Thor gives index Nhor-1. The required values of Nhor and Thor can be passed in via userparam, too. A similar approach is used in the example Reactor_CSTR for the measured values in the MHE cost function, see probfct_REACTOR_CSTR_MHE.c, initDataMHE.m and startMHE.m. The strange number in the expression
comes from precomputing Thor / (Nhor - 1). If you use an integrator with variable step-size (ruku45, rodas), the time t can be inbetween two of the disrete steps and one could use linear interpolation to approximate the constraint bounds.
Regards,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have already tried to update the constraints by using userparam and it works. I will also try the rest of your suggestions. Thank you again for the support.
Best regards,
Konstantinos Spanos
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I have started to use GRAMPC for a project in order to validate it and understand if it is suitable for my implementation. Until now everything is OK except one thing.
I have put some inequality constraints for my states. Specifically, for one state in order to arrange the bounds for that. However, I need my constraints to vary during the Prediction Horizon. For example, if I have a prediction horizon with 5 steps, I need to have a constraint for my state like: state_constraint = [1, 2, 3, 4, 5]. I would like, if it is possible, you to explain me how it can be done, as currently I just put a constraint like: out[0] = param[0] - x[0] where param is the bound of my state, but it is the same during the whole horizon.
Thank you in advance,
Konstantinos
Dear Konstantinos,
thank your for your interest in GRAMPC. If I understand you correctly, you have a time-varying inequality constraint that depends on the time t \in [0, T]. For example, x(t) < 1 + t, which would result in x(0s) < 1, x(1s) < 2, x(2s) < 3, ... x(Thor) < 1 + Thor. Such constraints can be easily implemented, since the prediction time t is already passed to the constraint functions as second argument.
Regards,
Andreas
Dear Andreas,
Thank you for your response. I don't have the constraints given as explicit formulas, containing time values. But I have exactly the lower and upper bound as values, directly, comming from a different component. For example: at a certain time sample, I have a vector of low_bound = [l(t), l(t+1), l(t+2),...,l(t+h)] and a vector of upper_bound= [u(t), u(t+1), u(t+2),..., u(t+h)], both with the length of the prediction horizon. And the lower and upper bounds vectors are not constant.
Kind regards,
Konstantinos Spanos
Last edit: Konstantinos Spanos 2019-12-02
Dear Konstantinos,
the vectors of lower and upper bounds can be updated in each time step using the user parameters. If you use an integrator with fixed step-size (euler, modeuler, heun), you can determine the index for the vectors of upper and lower bounds. Something like t * (Nhor - 1) / Thor, such that t = 0 gives index 0 and t = Thor gives index Nhor-1. The required values of Nhor and Thor can be passed in via userparam, too. A similar approach is used in the example Reactor_CSTR for the measured values in the MHE cost function, see probfct_REACTOR_CSTR_MHE.c, initDataMHE.m and startMHE.m. The strange number in the expression
comes from precomputing Thor / (Nhor - 1). If you use an integrator with variable step-size (ruku45, rodas), the time t can be inbetween two of the disrete steps and one could use linear interpolation to approximate the constraint bounds.
Regards,
Andreas
Dear Andreas,
I have already tried to update the constraints by using userparam and it works. I will also try the rest of your suggestions. Thank you again for the support.
Best regards,
Konstantinos Spanos