I'm trying to generate a Time-Varying LQR using FiniteHorizonLinearQuadraticRegulator for a system with a free-floating base + 7DoF arm: 14 positions + 13 velocities in state space. The trajectory which I'm trying to stabilize with TVLQR has 50-knot points. The Q and R matrices are simple diagonal matrices.
I create a time-varying linear system from the trajectory with custom linearization to handle the quaternions. So the time-varying linear system has 13 positions + 13 velocities in the state space. This is then used for the FiniteHorizonLinearQuadraticRegulator. Previously, I was able to do so easily with floating base and 3 DoF arm but the same process uses too much memory for a 7 DoF arm.
However, when I try to run FiniteHorizonLinearQuadraticRegulator to create the K matrices for the TVLQR, the Python process is killed by my OS (Ubuntu 22.04) by the OOM killer. I have 16GB of RAM and 8GB of swap both of which are completely filled during running the script after which the process is killed.
Is this expected/normal behavior?
Thanks for the reproduction (in the comments above). I added a printout to the DoCalcTimeDerivatives method of the RiccatiSystem in finite_horizon_linear_quadratic_regulator.cc, and confirmed that your system is making the numerical integration stiff (the integrator is taking arbitrarily small time-steps around time -4.765 seconds). The right solution is to understand and resolve that stiffness in your system/trajectory pair.
A reasonable feature request would be to have more support for integrator options in FiniteHorizonLinearQuadraticRegulator. Internally, it is using the "dense integration" feature of the Drake integrators; but those integrators have many other settable options to e.g. control the minimum step size (at the expense of limited numerical accuracy). Those might conceivably help you debug the issue here.
Probably the actual API would be to support passing a reference to an existing integrator into the FiniteHorizonLinearQuadraticRegulatorOptions.