Feature/979 mujoco stateful sysmodel

[juan-g-bonilla]

• Tickets addressed: Closes Add stateful SysModel for mujoco Dynamics #979
• Review: By commit
• Merge strategy: Merge (no squash)

Description

Currently, the MJScene dynamic object cannot have continuous states, other than the states of the multi-body. A continuous state is a state whose evolution is given by its time derivative, and thus must be integrated forward in time. spacecraft objects use stateEffector to declare such states (for example, a fuel tank is modeled as a stateEffector whose mass in a continuous state). A similar capability is required for MJScene.

To address this, a new class, StatefulSysModel, has been added, which inherits from SysModel but has an additional virtual method registerStates. MJScene has an internal "dynamics" task, which contains SysModel objects that compute the forces/torques applied on the multi-body system. With StatefulSysModel, we make it so that the SysModel objects in the "dynamics" task can also declare their own continuous-time states and then compute their derivative on their UpdateState method.

StatefulSysModel have a new method, registerStates, which is called on the initializeDynamics function in MJScene (the same method where the mujoco multi-body declares its states or stateEffector registered their states in spacecraft). The main difference with stateEffector is that StatefulSysModel get a DynParamRegisterer objects, instead of a DynParamManager. DynParamRegisterer wraps an instance of DynParamManager, but allows only one function to be called on it: registerState. Moreover, it prepends some model-unique string to the state name before registering it on the manager, which prevents state name collision between models (multiple models can register the same state name).

DynParamRegisterer purposefully grants access to only one method registerState, because I consider other methods in the manager to be transparent data sharing, which can be harmful to understanding the flow of data in the simulation. Shared state objects and properties allow models to talk to each other and influence each other through a parallel information passing scheme to messages. The message system provides clear model interfaces, functional encapsulation, and ease of testing and logging. Data sharing through states and properties goes against this. If a model wants to share its state information, I believe it should do so through a message. If a model needs to know a "property" of the multi-body (such as its center of mass or gravity acceleration), then a model should compute and properly publish this information as a message. With this new pattern, state objects are managed by a single model, and properties are deprecated.

Moreover, Python StatefulSysModel are supported. With this feature, we are able to effectively replicate the dynamicEffector and stateEffector functionality purely on the Python side, which will enable rapid prototyping.

Verification

A new test src/simulation/mujocoDynamics/_GeneralModuleFiles/_UnitTest/test_stateful_sys_model.py has been written. Moreover, a scenario examples/mujoco/scenarioDeployPanels.py has been updated to show the use of StatefulSysModel (in Python).

Documentation

No documentation has been added, other than the showcase in scenarioDeployPanels.py. Release notes have not been updated, since the previous MuJoCo entry covers this content.

[schaubh]

Did a quick skim across this change. Would like to Zoom with you to discuss in more detail to follow the motivation here. In the PR description, I would prefer not to call other work "evil". If this new approach has benefits, then let's be clear about the benefits of this approach and not insult prior efforts.

Also, the PR text gives a clear description on what is happening, but it is unclear to the reviewer why this change is being made. I would prefer to start such a discussion with a brief paragraph talking about the motivation for this work. I'm assuming this is going to enable you to integrate other stateEffectors in the future where the force/torque info is pulled from the output messages? You outlined to me last December your concept of doing the RK4, etc. integration only using messages and not having these specific function calls on the effectors?

[juan-g-bonilla]

Did a quick skim across this change. Would like to Zoom with you to discuss in more detail to follow the motivation here. In the PR description, I would prefer not to call other work "evil". If this new approach has benefits, then let's be clear about the benefits of this approach and not insult prior efforts.

Also, the PR text gives a clear description on what is happening, but it is unclear to the reviewer why this change is being made. I would prefer to start such a discussion with a brief paragraph talking about the motivation for this work. I'm assuming this is going to enable you to integrate other stateEffectors in the future where the force/torque info is pulled from the output messages? You outlined to me last December your concept of doing the RK4, etc. integration only using messages and not having these specific function calls on the effectors?

Really didn't mean to be insulting to other work, I used "evil" in the exaggerated trying-to-be-funny way programmers talk about things they don't agree with.

There's a bit more context/explanation for this feature on the associated issue, I'll put that explanation here too. I'll also put 30 mins on the calendar to chat about this!

[schaubh]

add release notes discussing the MuJoCo scenario having been changed.