6.2 Receding Horizon Controller
6.2.5 Class IOdeManager
The purpose of the class IOdeManager is to cover three implementations for calculating the values of the cost function, the constraints and their derivatives required by a class MinProg object. The derivatives need to be computed with respect to every component of the optimization variable (5.7). This allows for a simple definition and approximation of the derivative of some function f(·) with respect to all components ofxvia the difference quotient
Dvf(x) = lim
t→0
f(x+t·v)−f(x)
t ≈ f(x+t·v)−f(x)
t (6.2)
where v ∈RN m+s, kvk= 1 and t ∈R. Remark 6.19
In the receding horizon control context, we think of f(·) being either the cost functional or one of the restriction functions. Moreover, the steplength t should be chosen depending on the used computer, i.e. its floating point ability. Note that given an optimal control problem, the computation of the difference quotient (6.2) may be sensitive if different discretizations are used to compute f(x+t·v) andf(x). To circumvent this problem, we additionally implemented a synchronized computation, see Section 6.2.5.3 below.
Within the context of optimizing a discretized optimal control problem, the function values to be computed are depending on the state of the system and the control. Since the state of the system is not contained in the optimization variable (5.7), neither the cost function and the restrictions nor their derivatives can be evaluated.
Now, we use the additional information on the initial state of the system x0. This infor-mation is provided by the user to the class MPC object by calling the calc method. By this method, the information is passed over to the class Discretization object defining the abstract optimization problem and hence the class MinProg object. Within the class IOdeManager object called by the minimization routine of class MinProg, this allows us to call a differential equation solver of class OdeSolveto solve the dynamic of the system using this initial value x0 and the optimization variable x.
Hence, a class IOdemanager object provides a link between the classes MinProg and OdeSolve to solve an optimal control problem.
Using the predescribed methodology, we can evaluate all required functions f(·) and, using the difference quotient (6.2), all derivatives.
For the implementation of such a differential equation manager derived from the class IOdeManager, we have to keep the following in mind:
(1) Memory requirements: A naive implementation is to compute and store all necessary values, i.e. the trajectories for nominal and varied parameter sets. Such a strategy,
6.2 Receding Horizon Controller 159 however, requires a rather large storage capacity even for small systems. Considering large differential equation systems like a discretization of a PDE, this may exceed hardware limitations.
(2) Speed: Every evaluation of a functionf(·) possibly triggers a call of the differential equation solver. Hence, if the number of function evaluations is not reduced on implementation, many calculations have to be performed which makes this part computationally expensive.
(3) Correctness: The Lagrangian part of the cost function has to be evaluated along the trajectory. To this end, an identical discretization has to be used for the evaluation of this integral and the dynamic of the problem, see also [104] for a detailed analysis.
The same holds for the derivative of a function f(·), that is for the two required evaluations of f(·) the same discretization grid should be considered.
Remark 6.20
The Lagrangian part of the cost function is appended to the dynamic of the system within the class Discretization object. Since this new dynamic is handed over to the class IOdeManager, the first part of the correctness requirement is fulfilled for all deduced classes of class IOdeManager. Appending the cost function is convenient since in the minimiza-tion routines of class MinProg, every evaluation of the cost function at the current iterate is accompanied by an evaluation of the restriction functions.
Moreover, the class Discretization object combines the optimization variable according to (5.7).
Within the receding horizon control setting, the Jacobian of the constraints has the fol-lowing general structure:
Optimization variables
Control vectors Shooting nodes
Constraints ConstraintsShootingnodes
s×N·m s×s
N·r×N·m N·r×s
Figure 6.10: Structure of the Jacobian of the constraints
The number of function evaluations is growing quadratically in the horizon length N. Moreover, a recomputation of these values has to be performed within a large number
of the iteration steps of the minimization routine. Hence, an efficient implementation is required for the receding horizon controller. For computing time comparisons of the different IOdeManager subclasses see Section 8.2.
Remark 6.21
Note that the dimension of the constraintsrmay also depend on the optimization procedure since not all methods treat box constraints as nonlinear constraints.
6.2.5.1 Class SimpleOdeManager
The classSimpleOdeManageris a straight forward implementation of a interface described in the previous Section 6.2.5 which calculates all function values by solving the differential equation on the whole optimization horizon for the given optimization variable. To utilize an object of this type within the receding horizon controller, it can be constructed/de-structed by calling
I O d e M a n a g e r * o b j e c t _ o d e m a n a g e r = new S i m p l e O d e M a n a g e r ; delete o b j e c t _ o d e m a n a g e r ;
Listing 6.25: Constructing/destructing call of a class SimpleOdeManager object For memory purposes, this method is effective since no intermediate results are stored.
However, it is not computationally efficient since many identical calculation steps are re-peated, see also Table 6.7. Moreover, the correctness aspect concerning the discretization used to compute the derivatives is not satisfied.
Method Description
comdgl Attaches the Lagrangian part of the cost func-tion to the differential equafunc-tion system
calcObjectiveFunction Calculates the value of the cost function for a fixed set of optimization variables considering the appended differential equation of the dy-namic, the summation term and the terminal cost term, see Section 6.2.4
calcObjectiveFunctionGrad Computes the gradient of the cost function with respect to all optimization variables
calcRestrFunction Calculates the values of all restrictions for all sampling instances and a fixed set of optimiza-tion variables
calcRestrFunctionGrad Computes the Jacobian update
Table 6.7: Calculation methods within class SimpleOdeManager Remark 6.22
Since all derivatives are computed within the Jacobian of the constraints, the QP iteration of the optimization routine is actually a Newton method with complete BFGS–update.
6.2.5.2 Class CacheOdeManager
To utilize the advantages of the quasi–Newton approach based on a reduced Hessian approximation in the QP iterations, a class CacheOdeManager object calculates only the required function values. An object of this class is constructed/destructed via
6.2 Receding Horizon Controller 161
I O d e M a n a g e r * o b j e c t _ o d e m a n a g e r = new C a c h e O d e M a n a g e r ; delete o b j e c t _ o d e m a n a g e r ;
Listing 6.26: Constructing/destructing call of a class CacheOdeManager object In particular, it considers two aspects:
(1) The array needc of the optimization method is used to identify the columns in the Jacobian of the constraints which have to be recomputed.
(2) Repeated function evaluations for identical optimization variables are avoided.
The implementation of the second aspect is a simple but very effective reordering of calculations. Considering the control vectors and the multiple shooting nodes separately, we note that changing thej-th value in this part of the optimization vector does not affect the state trajectory values x(i) for i∈[0, . . . , j]. Therefore, we first compute the nominal trajectory and store it. Then, the gradient of the cost functional and the required columns of the Jacobian of the constraints are calculated starting from the end of the vectors of control vectors. This is repeated for the vector of shooting nodes. In Figure 6.11, we indicated the proposed method by thick black arrows.
Using the illustration of Figure 6.10, the algorithm computes the Jacobian update by solving the dynamic of the control system in the top to bottom order of the arrows within Figure 6.11. Here, the aspect (1) is integrated, i.e. only the required updates within the Jacobian are actually computed. Within Figure 6.11, these are indicated in blue.
Since we have stored the nominal trajectory, one solution of the differential equation is sufficient to compute one column of the Jacobian which yields the implementation to be computationally efficient.
Optimization variables
Control vectors Shooting nodes
Constraints ConstraintsShootingnodes
Figure 6.11: Sequence of calculations within a class CacheOdeManager object
The methodology of the CacheOdeManager is split up in several methods:
Method Description
comdgl Attaches the Lagrangian part of the cost func-tion to the differential equafunc-tion system
compareCache Compares actual set of time set, initial values and control values to previous calls of the class OdeSolveobject
calcCache Calculates the value of the cost function when-ever a combination of time set, initial values and control values has not been handled yet
calcCacheDerived Calculates the value of the cost function when-ever a combination of time set, initial values and optimization variables has not been handled yet calcObjectiveFunction Utilizes the compareCache and calcCache methods to compute the value of the cost func-tion
calcObjectiveFunctionGrad Utilizes the compareCache, calcCache and calcCacheDerived methods to compute the gradient of the cost function with respect to all optimization variables
calcRestrFunction Utilizes the compareCache and calcCache methods to compute the value of the restriction function at one sampling instant
calcRestrFunctionGrad Computes the Jacobian update for columns in-dicated by the array needc of the optimiza-tion routine using the methods compareCache, calcCache and calcCacheDerived
Table 6.8: Calculation methods within classCacheOdeManager
Remark 6.23
Class CacheOdeManager objects are not as robust as class SimpleOdeManager objects regarding the correctness issue. We experienced problems with this class if the derivatives of the Jacobian are small and changes in the optimization parameter sets result in changes of the function value which are lower than the tolerance level of the differential equation solver.
6.2.5.3 Class SyncOdeManager
Within the classSimpleOdeManagerand the classCacheOdeManager, derivatives are com-puted by separately solving two differential equations based on the nominal and an ap-propriately changed set of parameters. This may lead to two different discretization grids.
Moreover, if the change between the resulting two trajectories is smaller than the tolerance of the step–size controller, then the approximation of the derivative might be useless.
The class SyncOdeManager is designed to cope with this problem. The fundamental principle is to combine several (one plus the number of optimization variables) copies of the differential equation system and solve it by one call of the class OdeSolve object.
The resulting discretization grid is identical by definition such that the correctness issue is satisfied. Similar to the class SimpleOdeManager and CacheOdeManager objects, the calls
6.2 Receding Horizon Controller 163
I O d e M a n a g e r * o b j e c t _ o d e m a n a g e r = new S y n c O d e M a n a g e r ; delete o b j e c t _ o d e m a n a g e r ;
Listing 6.27: Constructing/destructing call of a class SimpleOdeManager object construct and destruct such a manager.
Within this class, the cacheing principle of class CacheOdeManager is applied to avoid repeated calls of the differential equation solver for identical optimization parameter sets.
However, since the differential equation system is enlarged, the computational advantage is reduced.
Method Description
comdgl Combines differential equation systems and the Lagrangian part of the cost function to compute the gradient of the cost function
diffcomdgl Combines differential equation systems and the Lagrangian part of the cost function to compute the Jacobian of the constraints
compareCache Compares actual set of time set, initial values and control values to previous calls of the class OdeSolveobject
calcCache Calculates the value of the cost function when-ever a combination of time set, initial values and control values has not been handled yet
calcCacheDerived Calculates the value of the cost function when-ever a combination of time set, initial values and optimization variables has not been handled yet calcObjectiveFunction Utilizes the compareCache and calcCache methods to compute the value of the cost func-tion
calcObjectiveFunctionGrad Utilizes the compareCache and calcCacheDerived methods to compute the gradient of the cost function with respect to all optimization variables
calcRestrFunction Utilizes the compareCache and calcCache methods to compute the value of the restriction function at one sampling instant
calcRestrFunctionGrad Computes the Jacobian update for columns in-dicated by the array needc of the optimization routine using the methods compareCache and calcCacheDerived
Table 6.9: Calculation methods within class SyncOdeManager
Concluding, the usage of the different implementations depends on the considered exam-ple:
• A classSimpleOdeManager object is efficient in terms of the internal usage of mem-ory. However, due to unnecessary differential equation solver calls, it is computa-tionally costy and may exhibit correctness problems.
• A class SyncOdeManager object is designed to treat the correctness aspect. The internal combination of the differential equation systems and the resulting effort to compute the update of the Jacobian are treated efficiently but the inherent repeated calculation of the nominal trajectory cannot be avoided. Moreover, combining the dynamics results in longer solution times of the differential equation, hence it is in general slower than a class SimpleOdeManager object.
• Implemented for speed, a class CacheOdeManager object outruns the other imple-mentations concerning the calls of the differential equation solver and shows only small memory allocations. However, robustness problems may occur and have to be kept in mind.