Adhesion actuator dyntype

[vaxenburg]

The feature, motivation and pitch

Is there a good reason the dyntype of adhesion actuators can only be none? Can't we expose dyntype (along with dynprm) as another custom attribute of the adhesion actuators, like e.g. gain? For example, having a filter dynamics for adhesion could be quite useful (and realistic in some cases).

Alternatives

No response

Additional context

No response

[yuvaltassa]

This is a reasonable ask, however this should be possible now by saving an adhesion actuator as and then adding a dyntype. Yes, this is not as elegant as , but should just work.

So unless you're saying that you tried this and it failed, this request is basically about nicer MJCF cosmetics.

If you tried it and it failed then that's a bug 🙂

[vaxenburg]

For now, I do something like this, but it's not very nice:

adhesion_actuator.dclass.general.dyntype = 'filter'
adhesion_actuator.dclass.general.dynprm = (0.01,)

Yeah, this is not a bug report, just an enhancement request

[vaxenburg]

@yuvaltassa is it me or is your comment missing a bit or two? What do you mean by "saving an adhesion actuator as"?

[yuvaltassa]

I mean that if you have an XML with <adhesion> and you save the XML then you get a <general>.

But the trick you're using with default classes is even better, if you have procedural code.

That said, your enhancement request is valid and would not be hard to add. There are two options really:

1. Expose dyntype
2. If we think only filters are useful, expose timeconst, like in <position>.

WDYT?

[vaxenburg]

Thanks Yuval, that sounds good. For all I know, for the <adhesion> shortcut we don't need more than filterexact, so that'd be my vote probably -- that is, expose only timeconst. And if you want more, you do it with <general>. How about that?