英文:
Python Scipt Killed by OOM during FiniteHorizonLinearQuadraticRegulator. Is this normal/expected behaviour?
问题
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.
我正在尝试使用FiniteHorizonLinearQuadraticRegulator生成一个针对自由浮动基座和7自由度机械臂的时间变化LQR控制器：状态空间中包含14个位置和13个速度。我尝试用TVLQR来稳定的轨迹包含50个节点。Q和R矩阵都是简单的对角矩阵。
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.
我从轨迹中使用自定义线性化方法创建了一个时间变化的线性系统，以处理四元数。因此，时间变化的线性系统在状态空间中包含13个位置和13个速度。然后，这用于FiniteHorizonLinearQuadraticRegulator。之前，我可以轻松地使用浮动基座和3自由度机械臂完成这个过程，但对于7自由度机械臂来说，相同的过程占用了太多内存。
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.
然而，当我尝试运行FiniteHorizonLinearQuadraticRegulator来创建TVLQR的K矩阵时，Python进程被我的操作系统（Ubuntu 22.04）的OOM killer终止。我有16GB的RAM和8GB的交换空间，两者在运行脚本期间都被完全占用，之后进程被终止。
Is this expected/normal behavior?
这是预期/正常行为吗？
英文:
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?
答案1
得分: 1
感谢您提供的复制（在上述评论中）。 我在finite_horizon_linear_quadratic_regulator.cc中的RiccatiSystem的DoCalcTimeDerivatives方法中添加了一个打印输出，并确认您的系统正在使数值积分变得僵硬（积分器在时间-4.765秒左右采取任意小的时间步长）。正确的解决方法是理解并解决系统/轨迹对中的这种僵硬性。
一个合理的功能请求是在FiniteHorizonLinearQuadraticRegulator中提供更多的积分器选项支持。 在内部，它正在使用Drake积分器的"dense integration"功能; 但是这些积分器还有许多其他可设置的选项，例如控制最小步长（以牺牲有限的数值精度为代价）。这些选项可能有助于您调试此处的问题。
实际的API可能是支持将对现有积分器的引用传递给FiniteHorizonLinearQuadraticRegulatorOptions。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论