Hi everyone,
Is it possible to use different prediction and control horizon for MPC using GRAMPC? For example, set user.param.Thor = 1. while the control horizon is only 0.5s, which means the control variable u remains constant in the remaining 0.5s.
The current access for prediction horizon is user.param.Thor and user.param.dt. I would like to know if there is a way to set different control and prediction horizon.
Thank you!
Best,
Jingqiang Zha
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
due to the numerical solution method, GRAMPC does not distinguish between control and prediction horizon. It is possible to keep the control constant by setting dfdu=0 for t > t0+tControl and dldu=0 for t > tControl, where tControl is the desired control horizon. However, this only means that grampc.rws.u is not updated, and not that the last value u(tControl) is used for the remaining horizon. Probably, one could implement a complex solution by storing pointers to grampc.rws.u in the userparam structure, but I cannot see any benefit.
For some other MPC methods, the computational complexity heavily increases with the number of prediction steps. This has motivated to combine a long prediction horizon for stability with a short control horizon for real-time feasibility. However, in GRAMPC the computational demand primarily depends on the number of discretization steps Nhor and not on the value of Thor. There is only an indirect relationship in so far as longer prediction horizons typically require more discretization steps for an accurate integration of the canonical equations.
Can you give some more details on your usecase and the motivation for a separate control horizon?
Best regards,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Andreas,
Thank you for your reply. The reason I would like to use different control and prediction horizon is that I am using MicroAutoBox to implement the NMPC which has limited memory. By using a relative long prediction horizon (Np not Thor ) and small control horizon(Nc), I could implement it in real time environment.
Anyway, I have reduced both prediction and control horizon, instead using a larger sampling time. (dt)
Another question is about the Integration step Nhor. Does it mean how many steps the system model is discretized？For example, if Thor=2, dt=0.1, Nhor=10, does it mean during the every 2 prediction steps use the same discretized model?
due to the numerical solution method, GRAMPC does not distinguish between control and prediction horizon. It is possible to keep the control constant by setting dfdu=0 for t > t0+tControl and dldu=0 for t > tControl, where tControl is the desired control horizon. However, this only means that grampc.rws.u is not updated, and not that the last value u(tControl) is used for the remaining horizon. Probably, one could implement a complex solution by storing pointers to grampc.rws.u in the userparam structure, but I cannot see any benefit.
For some other MPC methods, the computational complexity heavily increases with the number of prediction steps. This has motivated to combine a long prediction horizon for stability with a short control horizon for real-time feasibility. However, in GRAMPC the computational demand primarily depends on the number of discretization steps Nhor and not on the value of Thor. There is only an indirect relationship in so far as longer prediction horizons typically require more discretization steps for an accurate integration of the canonical equations.
Can you give some more details on your usecase and the motivation for a separate control horizon?
again, GRAMPC neither has a prediction horizon Np nor a control horizon Nc. The computation time per MPC step is mainly influenced by the number of discretization steps Nhor, the number of gradient iterations MaxGradIter and the number of multiplier iterations MaxMultIter. For real-time feasibility, it is often a good choice to use "heun" as integration method and "explicit2" as line search strategy (both are the default settings).
Furthermore, the value of dt is not used by GRAMPC for the numerical solution itself and GRAMPC does not assume that dt corresponds to Thor / Nhor or something similar. GRAMPC internally uses Nhor equally spaced discretization points to represent the trajectories x(t), u(t), ... over the time horizon [0, Thor]. You can use a time horizon Thor=2s, Nhor=10 discretization steps and still run the MPC with a sampling time of dt = 0.01s.
The value of dt is used to compute grampc->sol->xnext by interpolating the trajectory x(t) for t = dt and to shift the control trajectory u(t) after each sampling step so that the new u(t) is warmstarted with the old u(t+dt).
Maybe I did not fully understand your questions. In this case, please ask further. Did you read through the chapter "Optimization algorithm and options" in the GRAMPC manual and the corresponding section in the paper in Optimization and Engineering? Most aspects of the numerical solution method are described there.
Regards,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Andreas,
Thank you for your detailed explanation. I totally understand that GRAMPC has neither prediction horizon nor control horizon.
The reason why I have doubt on Thor, Nhor and dt when I tuned MPC, I changed dt accidentally, which caused large effect on the performance of the NMPC. My initial setting is Thor=2s, Nhor=10, dt =0.2. (previously I thought it was better to have Thor/Nhor=dt, which is not necessary actually). I tuned NMPC weighting and did not find the desired performance. Then I accidentally changed dt=0.1 and I got the desired performance. By the way, my system/dSPACE(Simulink model) sampling time is 0.01s. Then I got confused why this happens because dt is basically used for warmstart for NMPC. If dt<Thor/Nhor, what value of u(t+dt) it will use? is it still u(t) because we only have u(t),u(t+0.2),u(t+0.4),…, we don’t have u(t+0.1)?
I have read the material you refer and I will go deeper into it.
Thank you very much! I really appreciate your help!
Previously, I attempted to use ACADO for dSAPCE real time implementation. I finally gave up due to its bad documentation.
again, GRAMPC neither has a prediction horizon Np nor a control horizon Nc. The computation time per MPC step is mainly influenced by the number of discretization steps Nhor, the number of gradient iterations MaxGradIter and the number of multiplier iterations MaxMultIter. For real-time feasibility, it is often a good choice to use "heun" as integration method and "explicit2" as line search strategy (both are the default settings).
Furthermore, the value of dt is not used by GRAMPC for the numerical solution itself and GRAMPC does not assume that dt corresponds to Thor / Nhor or something similar. GRAMPC internally uses Nhor equally spaced discretization points to represent the trajectories x(t), u(t), ... over the time horizon [0, Thor]. You can use a time horizon Thor=2s, Nhor=10 discretization steps and still run the MPC with a sampling time of dt = 0.01s.
The value of dt is used to compute grampc->sol->xnext by interpolating the trajectory x(t) for t = dt and to shift the control trajectory u(t) after each sampling step so that the new u(t) is warmstarted with the old u(t+dt).
Maybe I did not fully understand your questions. In this case, please ask further. Did you read through the chapter "Optimization algorithm and options" in the GRAMPC manual and the corresponding section in the paper in Optimization and Engineering? Most aspects of the numerical solution method are described there.
I changed dt accidentally, which caused large effect on the performance of the NMPC
Of course the sampling time has a huge impact, half the sampling time implies doubling the number of iterations if all other options are kept fixed.
my system/dSPACE(Simulink model) sampling time is 0.01s
In this case, I would use dt=0.01 for GRAMPC. Often it is possible to reduce the number of iterations so far that real-time feasibility can be achieved.
If dt<Thor/Nhor, what value of u(t+dt) it will use?,
The value unext that is applied to the system is usually u(0). If you need values between u(t[0]) and u(t[1]), e.g. u(dt), you have to use linear interpolation.
How many states and controls do you have? Do you need variable stepsize integration for your ODEs? What values are you currently using for the options?
Regards,
Andreas
Last edit: Andreas Völz 2020-01-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Andreas,
I used the default integration method ‘Heun’. (fixed size) For integration settings, they are all default values. There are five states in my system and 1 control variables.
By the way, is there a status flag table for GRAMPC in Simulink environment I can refer? Currently, I could not understand the exact meaning of the status flag. (it is sometimes 35, 32 or 288…) There is a 4.8 status flag section in the manual. I guess they represent 2 bits of every status flag.
I changed dt accidentally, which caused large effect on the performance of the NMPC
Of course the sampling time has a huge impact, half the sampling time implies doubling the number of iterations if all other options are kept fixed.
my system/dSPACE(Simulink model) sampling time is 0.01s
In this case, I would use dt=0.01 for GRAMPC. Often it is possible to reduce the number of iterations so far that real-time feasibility can be achieved.
If dt<Thor/Nhor, what value of u(t+dt) it will use?
The value unext that is applied to the system is usually u(0). If you need values between u(t[0]) and u(t[1]), e.g. u(dt), you have to use linear interpolation.
How many states and controls do you have? Do you need variable stepsize integration for your ODEs? What values are you currently using for the options?
There are five states in my system and 1 control variables
So Nx=5, Nu=1, Np=0. Do you have constraints? Furthermore, you have Thor=2s and Nhor=10. How many iterations per step are you using? From my experience, real-time feasibility for dt=0.01s should be possible in this case.
is there a status flag table for GRAMPC in Simulink environment I can refer?
Use the function grampc_printstatus or grampc_printstatus_Cmex in Matlab to get an info message that explains the status flag.
Regards,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Andreas,
There is no real-time implementation issue right now since I have changed Nhor from 20 to 10.
Now I understand why the performance is improved by reducing dt.
Thank you!
There are five states in my system and 1 control variables
So Nx=5, Nu=1, Np=0. Do you have constraints? Furthermore, you have Thor=2s and Nhor=10. How many iterations per step are you using? From my experience, real-time feasibility for dt=0.01s should be possible in this case.
is there a status flag table for GRAMPC in Simulink environment I can refer?
Use the function grampc_printstatus or grampc_printstatus_Cmex in Matlab to get an info message that explains the status flag.
I would like to ask you a similar question with zhazha (2020-01-09). It has to do with the grampc->sol->status (status flag). As zhazha mentions, sometimes the grampc->sol->status takes some strange values (35, 32 or 288). In some cases, I obtain exactly the same values. I have checked the declaration of the Status Flags and there are no cases with these values: 35, 32 or 288. Do you have any idea what are those values?
Additionally, could you please tell me what does it mean that the grampc->sol->status is equal to 0? In the daclaration it is set as none when the status is equal to 0. Is the solution in that case feasible?
Kind regards,
Konstantinos Spanos
Last edit: Konstantinos Spanos 2020-02-26
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the status field is essentially a bit set. Each of the status flags corresponds to exactly one bit that is either set to 0 or 1 (2^0 = 1, 2^1 = 2, 2^2 = 4, 2^3 = 8, ....). If you get as status e.g. 35 this is 32 + 2 + 1 = 2^5 + 2^1 + 2^0, i.e. the states 0, 1 and 5 are active. You can check if certain flags are set using bit operators or use the functions grampc_printstatus or grampc_printstatus_Cmex in Matlab to obtain a readable text. For further information about the status flags, please consult the documentation, it explains the meanings in Section 4.8 (page 25 following). If the status field is equal to 0, it simply means that no flag has been set. However, to see if everything works as you have expected, you should have a detailed look at the resulting trajectories (do they look as expected) and at the statistics plot. In particular, you should look at the evolution of the cost function. If the cost is monotonically decreasing, this is a good sign that the MPC is working fine.
Regards,
Andreas
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi everyone,
Is it possible to use different prediction and control horizon for MPC using GRAMPC? For example, set user.param.Thor = 1. while the control horizon is only 0.5s, which means the control variable u remains constant in the remaining 0.5s.
The current access for prediction horizon is user.param.Thor and user.param.dt. I would like to know if there is a way to set different control and prediction horizon.
Thank you!
Best,
Jingqiang Zha
Dear Jingqiang Zha,
due to the numerical solution method, GRAMPC does not distinguish between control and prediction horizon. It is possible to keep the control constant by setting dfdu=0 for t > t0+tControl and dldu=0 for t > tControl, where tControl is the desired control horizon. However, this only means that grampc.rws.u is not updated, and not that the last value u(tControl) is used for the remaining horizon. Probably, one could implement a complex solution by storing pointers to grampc.rws.u in the userparam structure, but I cannot see any benefit.
For some other MPC methods, the computational complexity heavily increases with the number of prediction steps. This has motivated to combine a long prediction horizon for stability with a short control horizon for real-time feasibility. However, in GRAMPC the computational demand primarily depends on the number of discretization steps Nhor and not on the value of Thor. There is only an indirect relationship in so far as longer prediction horizons typically require more discretization steps for an accurate integration of the canonical equations.
Can you give some more details on your usecase and the motivation for a separate control horizon?
Best regards,
Andreas
Hi Andreas,
Thank you for your reply. The reason I would like to use different control and prediction horizon is that I am using MicroAutoBox to implement the NMPC which has limited memory. By using a relative long prediction horizon (Np not Thor ) and small control horizon(Nc), I could implement it in real time environment.
Anyway, I have reduced both prediction and control horizon, instead using a larger sampling time. (dt)
Another question is about the Integration step Nhor. Does it mean how many steps the system model is discretized？For example, if Thor=2, dt=0.1, Nhor=10, does it mean during the every 2 prediction steps use the same discretized model?
Thank you very much!
Best,
Jingqiang Zha
Dear Jingqiang Zha,
again, GRAMPC neither has a prediction horizon Np nor a control horizon Nc. The computation time per MPC step is mainly influenced by the number of discretization steps Nhor, the number of gradient iterations MaxGradIter and the number of multiplier iterations MaxMultIter. For real-time feasibility, it is often a good choice to use "heun" as integration method and "explicit2" as line search strategy (both are the default settings).
Furthermore, the value of dt is not used by GRAMPC for the numerical solution itself and GRAMPC does not assume that dt corresponds to Thor / Nhor or something similar. GRAMPC internally uses Nhor equally spaced discretization points to represent the trajectories x(t), u(t), ... over the time horizon [0, Thor]. You can use a time horizon Thor=2s, Nhor=10 discretization steps and still run the MPC with a sampling time of dt = 0.01s.
The value of dt is used to compute grampc->sol->xnext by interpolating the trajectory x(t) for t = dt and to shift the control trajectory u(t) after each sampling step so that the new u(t) is warmstarted with the old u(t+dt).
Maybe I did not fully understand your questions. In this case, please ask further. Did you read through the chapter "Optimization algorithm and options" in the GRAMPC manual and the corresponding section in the paper in Optimization and Engineering? Most aspects of the numerical solution method are described there.
Regards,
Andreas
Andreas,
Thank you for your detailed explanation. I totally understand that GRAMPC has neither prediction horizon nor control horizon.
The reason why I have doubt on Thor, Nhor and dt when I tuned MPC, I changed dt accidentally, which caused large effect on the performance of the NMPC. My initial setting is Thor=2s, Nhor=10, dt =0.2. (previously I thought it was better to have Thor/Nhor=dt, which is not necessary actually). I tuned NMPC weighting and did not find the desired performance. Then I accidentally changed dt=0.1 and I got the desired performance. By the way, my system/dSPACE(Simulink model) sampling time is 0.01s. Then I got confused why this happens because dt is basically used for warmstart for NMPC. If dt<Thor/Nhor, what value of u(t+dt) it will use? is it still u(t) because we only have u(t),u(t+0.2),u(t+0.4),…, we don’t have u(t+0.1)?
I have read the material you refer and I will go deeper into it.
Thank you very much! I really appreciate your help!
Previously, I attempted to use ACADO for dSAPCE real time implementation. I finally gave up due to its bad documentation.
Best,
Jingqiang Zha
Dear Jingqiang Zha,
Of course the sampling time has a huge impact, half the sampling time implies doubling the number of iterations if all other options are kept fixed.
In this case, I would use dt=0.01 for GRAMPC. Often it is possible to reduce the number of iterations so far that real-time feasibility can be achieved.
The value unext that is applied to the system is usually u(0). If you need values between u(t[0]) and u(t[1]), e.g. u(dt), you have to use linear interpolation.
How many states and controls do you have? Do you need variable stepsize integration for your ODEs? What values are you currently using for the options?
Regards,
Andreas
Last edit: Andreas Völz 2020-01-09
Andreas,
I used the default integration method ‘Heun’. (fixed size) For integration settings, they are all default values. There are five states in my system and 1 control variables.
By the way, is there a status flag table for GRAMPC in Simulink environment I can refer? Currently, I could not understand the exact meaning of the status flag. (it is sometimes 35, 32 or 288…) There is a 4.8 status flag section in the manual. I guess they represent 2 bits of every status flag.
Best,
Jingqiang Zha
Dear Jingqiang Zha,
So Nx=5, Nu=1, Np=0. Do you have constraints? Furthermore, you have Thor=2s and Nhor=10. How many iterations per step are you using? From my experience, real-time feasibility for dt=0.01s should be possible in this case.
Use the function grampc_printstatus or grampc_printstatus_Cmex in Matlab to get an info message that explains the status flag.
Regards,
Andreas
Andreas,
There is no real-time implementation issue right now since I have changed Nhor from 20 to 10.
Now I understand why the performance is improved by reducing dt.
Thank you!
Best,
Jingqiang Zha
Hello Andreas,
I would like to ask you a similar question with zhazha (2020-01-09). It has to do with the grampc->sol->status (status flag). As zhazha mentions, sometimes the grampc->sol->status takes some strange values (35, 32 or 288). In some cases, I obtain exactly the same values. I have checked the declaration of the Status Flags and there are no cases with these values: 35, 32 or 288. Do you have any idea what are those values?
Additionally, could you please tell me what does it mean that the grampc->sol->status is equal to 0? In the daclaration it is set as none when the status is equal to 0. Is the solution in that case feasible?
Kind regards,
Konstantinos Spanos
Last edit: Konstantinos Spanos 2020-02-26
Dear Konstantinos,
the status field is essentially a bit set. Each of the status flags corresponds to exactly one bit that is either set to 0 or 1 (2^0 = 1, 2^1 = 2, 2^2 = 4, 2^3 = 8, ....). If you get as status e.g. 35 this is 32 + 2 + 1 = 2^5 + 2^1 + 2^0, i.e. the states 0, 1 and 5 are active. You can check if certain flags are set using bit operators or use the functions grampc_printstatus or grampc_printstatus_Cmex in Matlab to obtain a readable text. For further information about the status flags, please consult the documentation, it explains the meanings in Section 4.8 (page 25 following). If the status field is equal to 0, it simply means that no flag has been set. However, to see if everything works as you have expected, you should have a detailed look at the resulting trajectories (do they look as expected) and at the statistics plot. In particular, you should look at the evolution of the cost function. If the cost is monotonically decreasing, this is a good sign that the MPC is working fine.
Regards,
Andreas
Dear Andreas,
Thank you for the immediate response. My questions were clearly answered.
Kind regards,
Konstantinos