Should stuff be time-shifted on tiny_solve entry?

[peterkrull]

With tiny_solve being called at every time step $k \leftarrow k + 1$, and the contents of the workspace struct being carried over, shouldn't some of this content be shifted in time?

I am specifically looking at the first forward pass, where the column vectors of the d-matrix are unique for every time step, and carry the previously optimized information. In my mind, it should be shifted prior to doing any iterations to get the best starting point for optimizing further. Likewise for the vectors in y and g which are reused before they are overwritten. I am thinking of something like

for (int i = 0; i < NHORIZON - 1; i++)
{
    solver->work->d.col(i) = solver->work->d.col(i+1);
    solver->work->y.col(i) = solver->work->y.col(i+1);
    solver->work->g.col(i) = solver->work->g.col(i+1);
}

at the start of tiny_solve.

In my quick testing this can give some more 'gradual' or 'incremental' convergence, allowing for a lower number of max iterations. I am curious if there are any downsides to this approach that I am missing.

[xkhainguyen]

Hello,

In our current implementation, we warm-start with the original solution from the previous MPC step. While theoretically shifting it one step ahead seems promising, in our specific cases, we didn't observe significant computational gains. Notice that the control rate is often fixed, which may depend on the worst-case scenario. In some cases (e.g., problem data changes rapidly, the previous solution is suboptimal), we even need to reset the multiplier/dual variables to avoid cumulative errors instead of warm-starting them.

If possible, could you provide us with your quantitative testing results, preferably conducted on microcontrollers?

We are open to considering the addition of this feature if it demonstrates a substantial impact.

Thank you.

[peterkrull]

Hello, thanks for the reply.

I will try to put together a minimum viable example. I do not have a good MC to test with, but I do not believe that matters much for this. Perhaps just counting iterations and accumulated tracking error will give a good enough idea of performance differences? Maybe calculating the actual cost for the predicted $x$ and $u$. Any specific type of plant dynamics, non-linear simulation, disturbance or other things that you think could highlight issues in this approach?

One of the things I like to look at, which arguably is not very qualitative, is how the series of predicted $x$ and $u$ converge on a time-series plot. I have found that when operating close to/on the constraints, warm-starting with the shifted previous best-guess can result in a lower total number of iterations, and it is sometimes possible to get away with a lower max number of iterations. In simulations the total number of iterations required can be anywhere between negligible (sometimes slightly worse) all the way to half the number of iterations. Though I have also observed some weird behavior when settings the max iterations very low, e.g. like below 10.

What do you mean with 'problem data changes rapidly'? As in the reference matrix changes quickly, or that there are discrepancies between real dynamics and the linear model? I am only working with simulations so far, and I have not seen much benefit to resetting the dual variables.