A few questions and comments

[peterkrull]

Hey TinyMPC team,

I am doing a project where I am expanding on my own tinympc-rs implementation, and have spent some more time looking into your derivations and implementation. So I have come up with some questions and comments.

• I noticed there appear to be two distinct implementations: the main TinyMPC repository and the one used for the Crazyflie firmware. Could you elaborate on the relationship between these two? Would code generation for the Crazyflie not be the best demonstration of the main TinyMPC code base?

• Is the memory usage described in the original paper from the code-gen implementation or the Crazyflie one? Since it bottoms out at ~380 kB of memory, which already exceeds the STM32F405, I would guess the former. Also is it static memory usage, or combined with dynamic stack usage? If there is a large different in memory consumption, what about compute between the two implementations?

• Your termination check only includes the box-constraint slack variables, which presumably would result in premature termination when they are inactive, even when other constraints may be active and have large residuals. Could this have affected the results in your latest paper? In my implementation I have made an interface for constraints and their projection function, which allows for easily computing the residual for all constraints, but also give more flexibility to end users. Slack and dual variables are owned by each constraint, meaning their variables are not even allocated if not needed.

• In your initial paper you mention using penalty scaling with multiple cached sets of matrices, but unless I am missing something, this was never published to the main branch? If you ever tested it out, how does it compare to the first-order approach from the latest paper? I have done some testing with the multiple-cache approach but find that the performance improvement for well-conditioned problems is not that great, and the result can be a bit jumpy. I have also considered doing a combined approach, where I use the value and derivative of the matrices for multiple values of rho, and then do cubic hermite spline interpolation between them.

• I believe update_linear_cost should be the first operation in the solver loop, otherwise a changed reference is not accounted for during the first iteration. It is also what sets the terminal condition in preparation for the Riccati backward pass. Having it last means the first forward pass is done using an outdated reference. It should just be considered part of the primal update, since it would be required in the unconstrained finite-horizon LQR case, and does not inherently have any connection to ADMM. Presumably, having it last might result in premature termination on a sub optimal solution. Is there a reason for this ordering that I might be missing?

• For my own implementation I have concluded that shifting the slack and dual variables (see discussion 10) is indeed preferable. Specifically when the related constraints are active, and especially when the cost matrices have a high conditioning number. See the recording below, made using rerun (which also has C++ bindings)

tinympc-shifted.mp4

The clip shows off two "recordings", the first without shifting the dual and slack variables, and the second with shifting. Notice how in the first non-shifted recording, the residuals remain high throughout, and the control signal (pink signal on left figure) does not flatten out at its constraints. In the second recording where shifting is enabled, the residuals reduce on successive solves, and the constraints are eventually respected.

Thank for your time and the work you are doing.

Regards, Peter

[ishaanamahajan]

Hey @peterkrull , thanks for comments and suggestions! They are really helpful!

1. The main TinyMPC repository contains the core solver implementation that is intended for general use and code generation, while the Crazyflie firmware repository contains an implementation specifically integrated into the Crazyflie 2.1 quadrotor firmware. The code generation was developed after and hence they are separate, but yes you are right, the code generation for the Crazyflie is the best demonstration of the infrastructure - something we haven't really had the time to unify yet.

2. Yes the memory usage described is from the codegen capabilities. TinyMPC does not make use of any dynamic memory at runtime. The original paper reports RAM usage on a Teensy 4.1.

3. In our latest paper we only made use of box constraints, and not SOCs or other linear ones. If you spotted a spot in the code path that only aggregates the bound-block residuals when others are active, that’s a bug. We’ll happily take a PR or a snippet for a fix.

4. Yes, we never published that code to main, and although we never published our comparisons between the new adaptive rho approach with the multiple caching ones, during testing we observed that our new adaptive rho mechanism (FOAC) did end up close to the value manually picked. FOAC in a way supersedes it with smaller flash/RAM footprint for similar benefits.

5. Good catch, I agree update_linear_cost should be the first step! I just pushed a fix for that, thanks for that!

6. Again, thanks for testing that! As mentioned in Should stuff be time-shifted on tiny_solve entry? #10 is there a quantitative advantage you see, compared to the current approach? If the impact is significant we would appreciate a PR and then maybe could add an additional flag that users could choose based on their preference.