jrvanwhy / traj_opt Goto Github PK

The nonlinear optimizers may work better if they are correctly fed linear constraints. Some mechanism for adding or recognizing linear constraints should be added.

Using Taylor series, an implicit integration formula of arbitrary order may be derived:

Let dy = f(y, u, t), where u is an affine function of time (over one integration interval)

Suppose t2 = t1 + dt

Expanding the Taylor series for y about y(1) at y(t2), we get:
y(t2) = y(t1) + dt_dy(t1) + dt^2_ddy(t1)/2 + dt^3*dddy(t1)/6 + ...

Expanding the Taylor series for y about y(t2) at y(t1), we get:
y(t1) = y(t2) - dt_dy(t2) + dt^2_ddy(t2)/2 - dt^3*dddy(t2)/6 + ...

Subtracting the last equation from the previous equation we get:
y(t2) - y(t1) = y(t1) - y(t2) + dt_(dy(t1) + dy(t2)) + dt^2_(ddy(t1)-ddy(t2))/2 + dt^3*(dddy(t1) + dddy(t2))/6 + ...

Adding y(t2) - y(t1) to each side gives:
2_(y(t2) - y(t1)) = dt_(dy(t2) + dy(t2)) + dt^2_(ddy(t1) - ddy(t2))/2 + dt^3_(dddy(t1) + dddy(t2))/6 + ...

Note that if we only carry this out to one term, it is simply the trapezoidal integration rule. If you carry out more, you can exactly solve affine systems.

The configuration parameter for order could specify a range; it will create a solver of at least the minimum order, but if it can do so and produce a linear constraint, it should increase the order up to the maximum (maximizing accuracy w/out sacrificing linearity of that would make it nonlinear).

If a parameter is constrained to equal a constant, then it should be removed from the optimization. This will improve numerical performance with both fmincon and a custom symbolically-generated optimizer, and therefore will be a good idea for MPC.

Some of the functions generated in opt_fmincon, such as gceq and gc, are quite large. Perhaps the matrices can, in symbolic form, be broken down via [m,i,j] = find(A) and encoder in a flat format, then re-encoder via sparse() during the numerical optimization.

This may reduce overall problem solve time by trading numerical solve time for setup time.

The benchmark should do 3 phases of 2 types and create a "combined time" equivalent to that needed to do 1 setup and 10 numerical optimizations.

fmincon should be run in a loop. This loop should detect successes and failures.

Currently, the user has to change the maxiter and maxfuneval options to prevent fmincon from aborting early.

A trapezoidal ODE solver should be implemented; this may be easier to work with as the states, inputs, and custom functions will all line up.

After seeing how fast sparse and/or custom solvers can be, a symbolic "solver generator" should be written that can generate an efficient solver for any given problem.

This is a good way to try for MPC and may tell us how feasible full nonlinear MPC is.

Currently, only states, derivatives of states, and inputs are timestamped. All custom functions should have a timestamp.

Currently, there's no way to generate large vector variables where most of the entries are optimization variables and the rest are parameters and/or fixed. Some mechanism for doing this should be added.

addObj could remember how many variables were defined when the last objective was added. This could be used to decrease the size of the (dense) symbolic objective gradient, decreasing problem build time.

Currently, only time-invariant systems are supported. Support for a time parameter in intervals should be added.

Doing this should allow for a cleanup of the function timestamp code too -- these could be specified by the sub-interval generated, rather than being added after the fact during cloning.

There should be a way to parameterize the optimization problems so that multiple problems with the same format can be solved rapidly.

Currently, the same functions are processed repeatedly. Instead, they should be processed once, and arrays of input and output values should be kept. This should significantly reduce problem setup time.

A benchmarking tool should be written in order to make performance improvement evaluation possible (to aid in improving the framework's performance).

I image it should take a time as a parameter; it will iterate through interval counts until reaching that time in execution time. It will then go back, identify times that are unusually large (higher than both its neighboring times), and re-run those tests to reduce noise in the output.

Times for interval setup, scenario setup, and numerical optimization should be evaluated separately, so they may be compared.

traj_analyze_feasibility() has not been implemented. It should select the constraint with the highest violation, and plot it at the latest solution with respect to each of its variables (in fact, it's probably preferable to do a contour plot with respect to each pair of its variables).

It would be nice to be able to do x '<=' y '<=' z or other chained constraints (with more than one equality or inequality).

String manipulation could be used to identify what variables are present in a symbolic expression. This could be done initially by name with later refinement (in a second pass) by variable index.

Perhaps the sparsity structure of a constraint (or objective's) Jacobian could be discovered before any symbolic differentiation is done. This could allow for optimization of the calls to jacobian, giving a large potential speed boost to derivative calculations.

Alternatively, perhaps complex step differentiation could be done on the anonymous constraint and objective functions (though I think this would be slow).