为何要为控制器单独实例化一个独立的Plant？
我正在学习MIT机器人操控笔记中的操控仿真内容，对代码里的一个特定设计感到困惑：作者坚持为控制器单独实例化一个Plant。例如，使用manipulation仓库的辅助函数时：
- 主Plant在
MakeHardwareStation中创建 - 之后处理配置驱动指令时，会实例化第二个
controller_plant
后续这个控制器Plant仅调用plant.SetPositions(...)来匹配主Plant的配置（见代码中TorqueController.CalcTorqueOutput的定义）。我记得在drake或manipulation中见过该模式，自己实验时复用主Plant也能实现控制策略，想了解Drake中这种设计的原因，猜测可能和维度有关？
这种双Plant的设计在Drake生态里是很实用的工程实践，核心原因主要有这几点：
轻量化与计算隔离
主Plant包含了完整的仿真环境逻辑，比如碰撞检测、传感器模拟、外部约束等，这些模块会带来额外的计算负载。而控制器只需要机器人的核心动力学模型来计算指令，单独实例化的controller_plant只保留机器人关节的动力学参数，能让控制器的计算更高效，避免主Plant的复杂状态干扰控制器的核心逻辑。状态安全与逻辑隔离
主Plant的状态是由仿真器驱动更新的，如果控制器直接操作主Plant，很容易不小心修改到仿真的核心状态（比如误改关节速度、添加额外约束），导致仿真逻辑混乱。独立的controller_plant完全属于控制器模块，只用来计算逆动力学、雅各比矩阵这类控制器需要的量，不会对主仿真的运行产生任何影响。贴合真实硬件的部署逻辑
在真实机器人系统中，实时控制器的运行环境无法直接访问完整的物理仿真模型，只能基于简化的动力学模型计算控制指令。这种双Plant的设计其实是在模拟真实场景：主Plant对应真实机器人的本体+外部环境，controller_plant对应控制器中运行的简化动力学模型，这样代码可以更平滑地从仿真迁移到真实硬件，减少适配成本。维度与模型一致性保障
虽然复用主Plant能实现功能，但主Plant可能包含额外的自由度（比如环境中的其他物体、传感器的冗余关节），会导致状态向量维度冗余，控制器计算时需要额外过滤无关维度。单独的controller_plant只保留机器人的关节自由度，能确保状态向量维度完全匹配控制器需求，避免维度不匹配的潜在bug，同时也能保证模型参数的纯粹性（只加载机器人的动力学参数，不混入环境参数）。
内容的提问来源于stack exchange，提问作者Dmitri K
