Version 2.2.2

[saran-t]

General

1. Added adhesion actuators mimicking vacuum grippers and adhesive biomechanical appendages.

2. Added related example model and video.

3. Added mj_jacSubtreeCom for computing the translational Jacobian of the center-of-mass of a subtree.

4. Added torquescale and anchor attributes to weld constraints. torquescale sets the torque-to-force ratio exerted by the constraint, anchor sets the point at which the weld wrench is applied. See weld for more details.

5. Increased mjNEQDATA, the row length of equality constraint parameters in mjModel.eq_data, from 7 to 11.

6. Added visualisation of anchor points for both connect and weld constraints (activated by the 'N' key in simulate).

7. Added weld.xml showing different uses of new weld attributes.

8. Cartesian 6D end-effector control is now possible by adding a reference site to actuators with site transmission. See description of new refsite attribute in the actuator documentation and refsite.xml example model. Video

9. Added autolimits compiler option. If true, joint and tendon limited attributes and actuator ctrllimited, forcelimited and actlimited attributes will automatically be set to true if the corresponding range is defined and false otherwise.

   If autolimits="false" (the default) models where a range attribute is specified without the limited attribute will fail to compile. A future release will change the default of autolimits to true, and this compilation error allows users to catch this future change of behavior.

   This is a breaking change. In models where a range was defined but limited was unspecified, explicitly set limited to false or remove the range to maintain the current behavior of your model.

10. Added moment of inertia computation for all well-formed meshes. This option is activated by setting the compiler flag exactmeshinertia to true (defaults to false). This default may change in the future.

11. Added parameter shellinertia to geom, for locating the inferred inertia on the boundary (shell). Currently only meshes are supported.

12. For meshes from which volumetric inertia is inferred, raise error if the orientation of mesh faces is not consistent. If this occurs, fix the mesh in e.g., MeshLab or Blender.

13. Added catenary visualisation for hanging tendons. The model seen in the video can be found here.

14. Added azimuth and elevation attributes to visual/global, defining the initial orientation of the free camera at model load time.

15. Added mjv_defaultFreeCamera which sets the default free camera, respecting the above attributes.

16. simulate now supports taking a screenshot via a button in the File section or via Ctrl-P.

17. Improvements to time synchronisation in simulate, in particular report actual real-time factor if different from requested factor (if e.g., the timestep is so small that simulation cannot keep up with real-time).

18. Added a disable flag for sensors.

19. mju_mulQuat and mju_mulQuatAxis support in place computation. For example mju_mulQuat(a, a, b); sets the quaternion a equal to the product of a and b.

20. Added sensor matrices to mjd_transitionFD (note this is an API change).

Deleted/deprecated features

21. Removed distance constraints.

Bug fixes

22. Fixed rendering of some transparent geoms in reflection.
23. Fixed intvelocity defaults parsing.

---

This discussion was created from the release 2.2.2.

[MyelinsheathXD]

Hey mujoco team!
Any plans to add these 2 features below in future?

1. Multi threaded optimization to run several interactive articulated bodies in real time
   2 Seperate integrators to every objects. e.g. articulated bodies runs in RK4 but simple non articulated bodies run in Euler integrator. This is for the sake of Quality and performance

[saran-t]

Can you provide an example XML (MJCF) of a scene that you're currently having trouble running in real-time?

[MyelinsheathXD]

For instance ,example of mujoco samples 22_humanoids.xml . With Euler integrator the scene runs fine in real time but any large extarnal forces like mouse grab pulling brokes its limit range. As a result mujoco engine resets the model file .
Hopefully , with RK4 integrator everything works fine except its frame rate . Also RK4 a bit expancive to run on a single thread to achive game environment ready .

In my view, for interactive video games, multi threaded and customizable RK4 integrator for articulated bodies is crucial.

[yuvaltassa]

Hi,

Regarding integrators, the implicit integrator will soon be much faster, and the Euler integrator more stable (at the same cost). Mixing integrators for different parts of the state (esp. multi-stage integrators like RK4) will be hard to implement but probably possible after we implement "sleeping", i.e. skipping some DoFs during the step. I think sleeping is the more valuable feature, but it is not super close on our roadmap.

Regarding multithreading of a single simulation: Not soon. The basic design of parallelism in MuJoCo is to run multiple non-interacting simulations, one on each thread, rather than breaking up a single simulation between threads. I completely agree with you that for a certain class of video games this is exactly what you want, but MuJoCo was made for Robotics and ML, not to drive video games. That said, this should also become possible after sleeping is implemented (imagine some dofs sleeping on one thread and others in another thread), but is not a high priority at the moment.

Does that make sense?

[stevenbrills]

Hey, I'm working with MuJoCo in python and was trying to access azimuth and elevation attributes but they seem to be unavailable. The package that I installed from PyPI is version 2.3.2 which according to the documentation should match the MuJoCo version 2.3.2 but I'm still not able to access these parameters.

Is there a way to check which version of MuJoCo it is linking to underneath the bindings?

Thank you!

[hyarion]

You can check the version using mujoco.__version__:

import mujoco
print(mujoco.__version__)

On mujoco 2.3.2 this should print 2.3.2.

[stevenbrills]

Thank you! So this does in fact print 2.3.2 but I still am not able to access the "azimuth" and "elevation" parameters from the "visual._global" object. I set them using the MJCF definition and the xml parses without any errors. However, when I try to access these attributes from the visual handle, it says that such attributes don't exist. All the other attributes that belong to global do exist like "fovy". I appreciate any insight on what might be going on here. My goal is to set the initial view of the camera to a default location when the viewer is launched. Is there another way to achieve this goal?

[yuvaltassa]

Hi, yes you're absolutely right.

This is due to some brittle code in the Python bindings (missing test for elements or mismatched sizes).
If you are able to build the bindings from source, all you need to do is add the missing elements here. Either way we will shortly fix this at head soon, and you'll have this fixed in the next release.

Thanks for reporting this bug!

[yuvaltassa]

Reported in #747