Move some aspects of eq from Model to Data

[PeterMitrano]

I'm working on manipulation of deformable objects (rope) and I've found myself using m.eq_active and m.eq_data in ways that feel more like data than they do model. Generally speaking, things in model should not change during the simulation. However, using equality constraints to simulate simplified grasping is very handy, and means you probably want to change eq_data and eq_active during the simulation. Right now if I want to save/restore/copy the simulation state I have to also remember to do those fields from model in addition to the entire data object. Might it make sense to move them to the MjData structure instead?

[yuvaltassa]

Yup this is a good idea that we've discussed before. However, removing things from mjModel is a bad idea in multiple ways.

My proposal would be to add eq_active and eq_data to mjData, initialised to the values in mjModel, which have the semantic of overriding the values in mjModel. So we keep the values in mjModel, but their semantic becomes "the values that the corresponding variables in mjData get upon mj_resetData". Does that sound reasonable?

[saran-t]

I prefer <weld ... dynamic="true"/>, neqdyn in mjModel, and eq in mjData.

[yuvaltassa]

@saran-t, that's exactly what we'll want for the dynamic constraints I describe in the first bullet above. What the OP is asking for is different, not "dynamic" like mjData.act, but user-settable inputs, like mjData.ctrl.

I'm leaning towards <weld input="true">, mjModel.neq_input and mjData.eq_data_input.

We'll probably need a new enum for equalities that means fixed/stateful/settable.

[saran-t]

"controllable"? or is that confusable with the mathematical notion of controllability?

[yuvaltassa]

Ya control implies applying forces which is not what this is. Also the reason it has to be eq_data_input. You can't delete the _data since we're not touching the constraint forces, just parameters. _prm would have been better than _data but too late now I guess.

The more I roll with _input the more I like it. Override is more precise but long and clunky.

Another thought I'm having is that eq_active should be a float. 0 means the same thing, remove from efc, but in (0, 1] it weakens the constraint force proportionally. Maybe @emotodorov knows of a principled way of doing this.

[PeterMitrano]

This seems like a good way to achieve what I want! It makes sense as a user input to physics like ctrl. Should eq_active also be a user input? So both eq_data_user and eq_active_user?

Thanks for pointing me to that section of the docs, I just learned a few things about what components of data I actually need to be copying, which could say a tiny bit of time 🤔 . I can also try stripping textures and see how much time that saves!

If active is a float, I think that would conflict with solref? for example solref=0.02 1 vs solref=0.04 1 where the latter is softer?

[emotodorov]

I think we should add eq_enable to mjData, initialize it to mjModel.eq_enable in mj_reset(), and then use it at runtime to enable/disable constraints. Making it float does not work, since the constraint forces are computed by the solver and it is not a good idea to scale them afterwards. Incidentally, in the new soft bodies I am adding, it also makes sense to do this in mjData so as to cut/tear soft bodies. I will have to add a similar field for collision elements in mjData (something like elem_enable) so that both collisions and equality constrains can be disabled at runtime. In that case though, there is no corresponding field in mjModel.

…

-- Emo

On Fri, May 19, 2023 at 10:40 AM Yuval Tassa ***@***.***> wrote: Ya control implies applying forces which is not what this is. Also the reason it has to be eq_data_input. You can't delete the _data since we're not touching the constraint forces, just parameters. _param would have been better than _data but too late now I guess. The more I roll with _input the more I like it. Override is more precise but long and clunky. Another thought I'm having is that eq_active should be a float. 0 means the same thing, remove from efc, but in (0, 1] it weakens the constraint force proportionally. Maybe @emotodorov <https://github.com/emotodorov> knows of a principled way of doing this. — Reply to this email directly, view it on GitHub <#876 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB2V4L2Y6NGX6LSVD2SEI73XG6A45ANCNFSM6AAAAAAYGSBM5Y> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[yuvaltassa]

Fixed by ee78b8f