Multi-Joint dynamics with Contact. A general purpose physics simulator.

Overview

MuJoCo Physics

MuJoCo stands for Multi-Joint dynamics with Contact. It is a general purpose physics engine that aims to facilitate research and development in robotics, biomechanics, graphics and animation, machine learning, and other areas which demand fast and accurate simulation of articulated structures interacting with their environment.

DeepMind has acquired MuJoCo, and we are currently making preparations to open source the codebase. In the meantime, MuJoCo is available for download as a free and unrestricted precompiled binary under the Apache 2.0 license from mujoco.org.

MuJoCo's source code will be released through this GitHub repository once it is ready. In the meantime, the repository hosts MuJoCo's documentation, C header files for its public API, and sample program code. If you wish to report bugs or make feature requests, please file them as GitHub Issues. You are also welcome to make pull requests for the documentation source files.

Overview

MuJoCo is a C/C++ library with a C API, intended for researchers and developers. The runtime simulation module is tuned to maximize performance and operates on low-level data structures which are preallocated by the built-in XML parser and compiler. The user defines models in the native MJCF scene description language -- an XML file format designed to be as human readable and editable as possible. URDF model files can also be loaded. The library includes interactive visualization with a native GUI, rendered in OpenGL. MuJoCo further exposes a large number of utility functions for computing physics-related quantities, not necessarily in a simulation loop. Features include

  • Simulation in generalized coordinates, avoiding joint violations.

  • Inverse dynamics that are well-defined even in the presence of contacts.

  • Unified continuous-time formulation of constraints via convex optimization.

  • Constraints include soft contacts, limits, dry friction, equality constraints.

  • Simulation of particle systems, cloth, rope and soft objects.

  • Actuators including motors, cylinders, muscles, tendons, slider-cranks.

  • Choice of Newton, Conjugate Gradient, or Projected Gauss-Seidel solvers.

  • Choice of pyramidal or elliptic friction cones, dense or sparse Jacobians.

  • Choice of Euler or Runge-Kutta numerical integrators.

  • Multi-threaded sampling and finite-difference approximations.

  • Intuitive XML model format (called MJCF) and built-in model compiler.

  • Cross-platform GUI with interactive 3D visualization in OpenGL.

  • Run-time module written in ANSI C and hand-tuned for performance.

Requirements

MuJoCo binaries are currently built for Linux, macOS (Intel), and Windows.

Documentation

MuJoco's current documentation is available at mujoco.org/book, which is serving Sphinx-based webpages derived from the ReStructuredText documentation source files.

Citation

If you use MuJoCo for published research, please cite:

@inproceedings{todorov2012mujoco,
  title={Mujoco: A physics engine for model-based control},
  author={Todorov, Emanuel and Erez, Tom and Tassa, Yuval},
  booktitle={2012 IEEE/RSJ International Conference on Intelligent Robots and Systems},
  pages={5026--5033},
  year={2012},
  organization={IEEE}
}

License and Disclaimer

Copyright 2021 DeepMind Technologies Limited

ReStructuredText documents, images, and videos in the doc directory are made available under the terms of the Creative Commons Attribution 4.0 (CC BY 4.0) license. You may obtain a copy of the License at https://creativecommons.org/licenses/by/4.0/legalcode.

Source code is licensed under the Apache License, Version 2.0. You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.

This is not an officially supported Google product.

Comments
  • Refactor simulate.cc in preparation for Python bindings

    Refactor simulate.cc in preparation for Python bindings

    Hi,

    I have refactored simulate.cc so that the ui is a standalone set of functions, that do not use global variables, and can be called from a C++ application and soon a Python application as discussed in #190.

    I will rebase soon, but I was hoping to get some feedback sooner rather than later. I'm willing to see this through so it gets released sooner rather than later. I am simultaneously working on the pybind11 bindings.

    It seems that ideally "simulateui.so" would be a member of the Mujoco standard library, but since that source is not available yet, I kept the relevant files in the sample directory for now.

    Ciao

    opened by aftersomemath 49
  • Python bindings for simulate

    Python bindings for simulate

    This PR is to get initial feedback about my Python bindings for simulate in order to determine if they are worth polishing until they are mergable. Right now they are at a "look it works" level of quality. I have been using the bindings for a few months on Linux, however some careful consideration of how glfw linkage should work is needed before they will work on Windows or Mac.

    Here are some questions:

    • Is the approach taken to write the bindings acceptable and do they fit into the future plans for MuJoCo/Simulate? They are most similar to the rollout example in the python package and so are only loosely integrated with the rest of the MuJoCo Python bindings.
    • If so, would it be good to add the examples for simulate shown below to this PR?

    If the answer to the first question is no, then we can close this and I will instead make a PR to add a CMake option that installs the mjsimulate library as discussed in #201. Then these bindings can be easily maintained in a fork.

    Here are two examples of what the bindings make easy:

    Double Pendulum Stabilization

    Double Pendulum Simulate Python

    Fixation using Visual Feedback

    Fixation Simulate Python

    opened by aftersomemath 25
  • Python bindings won't compile - complaints of #pragma

    Python bindings won't compile - complaints of #pragma

    Hi there

    I'm trying to use MuJoCo on a cluster (Compute Canada if it makes any difference). I am trying to compile the Python bindings for MuJoCo 2.2.0. Amazingly, they don't have the precompiled bindings on the server, but they do have the MuJoCo binaries.

    gcc is 11.3.0

    My workflow is as follows:

    $ module load StdEnv/2020 # note this just loads the compiler, etc
    $ module load mujoco/2.2.0
    $ export MUJOCO_PATH=/cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Core/mujoco/2.2.0
    $ wget https://github.com/deepmind/mujoco/archive/refs/tags/2.2.0.zip
    $ unzip 2.2.0.zip
    $ cd mujoco-2.2.0/python
    $ virtualenv tmp/env
    $ source tmp/env/bin/activate
    $ ./make_sdist.sh
    $ pip wheel mujoco-2.2.0.tar.gz
    

    I came across this issue, but it wasn't obvious how @berniekirby solved the issue. I've tried removing everything, etc. I'm just trying to get this working with dm_control. Any help would be appreciated.

    I end up getting a bunch of output like below:

    ``` < ... lots cut >
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
        298 | MJMODEL_SITE
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSiteViews::bodyid()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSiteViews::matid()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSiteViews::group()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<unsigned char> mujoco::python::MjModelSiteViews::sameframe()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelSiteViews::size()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelSiteViews::pos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelSiteViews::quat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelSiteViews::user()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<float> mujoco::python::MjModelSiteViews::rgba()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:298:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::matid()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
        302 | MJMODEL_SKIN
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<float> mujoco::python::MjModelSkinViews::rgba()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<float> mujoco::python::MjModelSkinViews::inflate()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::vertadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::vertnum()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::texcoordadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::faceadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::facenum()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::boneadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelSkinViews::bonenum()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:302:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTendonViews::_adr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
        306 | MJMODEL_TENDON
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTendonViews::_num()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTendonViews::_matid()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTendonViews::_group()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<unsigned char> mujoco::python::MjModelTendonViews::_limited()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_width()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_solref_lim()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_solimp_lim()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_solref_fri()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_solimp_fri()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_range()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_margin()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_stiffness()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_damping()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_frictionloss()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_lengthspring()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_length0()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_invweight0()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTendonViews::_user()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<float> mujoco::python::MjModelTendonViews::_rgba()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:306:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTextureViews::type()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:310:1: error: ‘#pragma’ is not allowed here
        310 | MJMODEL_TEXTURE
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTextureViews::height()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:310:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTextureViews::width()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:310:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTextureViews::adr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:310:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<unsigned char> mujoco::python::MjModelTextureViews::rgb()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:310:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTupleViews::adr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:314:1: error: ‘#pragma’ is not allowed here
        314 | MJMODEL_TUPLE
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTupleViews::size()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:314:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTupleViews::objtype()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:314:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjModelTupleViews::objid()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:314:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelTupleViews::objprm()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:314:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelKeyframeViews::time()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:318:1: error: ‘#pragma’ is not allowed here
        318 | MJMODEL_KEYFRAME
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelKeyframeViews::qpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:318:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelKeyframeViews::qvel()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:318:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelKeyframeViews::act()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:318:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelKeyframeViews::mpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:318:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjModelKeyframeViews::mquat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:318:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataActuatorViews::ctrl()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:333:1: error: ‘#pragma’ is not allowed here
        333 | MJDATA_ACTUATOR
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataActuatorViews::length()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:333:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataActuatorViews::moment()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:333:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataActuatorViews::velocity()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:333:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataActuatorViews::force()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:333:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::xfrc_applied()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
        337 | MJDATA_BODY
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::xpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::xquat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::xmat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::xipos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::ximat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::subtree_com()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::cinert()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::crb()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::cvel()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::subtree_linvel()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::subtree_angmom()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::cacc()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::cfrc_int()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataBodyViews::cfrc_ext()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:337:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataCameraViews::xpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:341:1: error: ‘#pragma’ is not allowed here
        341 | MJDATA_CAMERA
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataCameraViews::xmat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:341:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataGeomViews::xpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:345:1: error: ‘#pragma’ is not allowed here
        345 | MJDATA_GEOM
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataGeomViews::xmat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:345:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
        349 | MJDATA_JOINT
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qvel()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qacc_warmstart()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_applied()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qacc()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::xanchor()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::xaxis()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::cdof()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qLDiagInv()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qLDiagSqrtInv()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataJointViews::efc_JT_rownnz()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataJointViews::efc_JT_rowadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataJointViews::efc_JT_rowsuper()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataJointViews::efc_JT_colind()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::efc_JT()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::cdof_dot()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_bias()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_passive()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_actuator()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_smooth()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qacc_smooth()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_constraint()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataJointViews::qfrc_inverse()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:349:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataLightViews::xpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:353:1: error: ‘#pragma’ is not allowed here
        353 | MJDATA_LIGHT
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataLightViews::xdir()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:353:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataSensorViews::data()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:357:1: error: ‘#pragma’ is not allowed here
        357 | MJDATA_SENSOR
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataSiteViews::xpos()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:361:1: error: ‘#pragma’ is not allowed here
        361 | MJDATA_SITE
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataSiteViews::xmat()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:361:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataTendonViews::wrapadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
        365 | MJDATA_TENDON
            | ^~~
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataTendonViews::wrapnum()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataTendonViews::J_rownnz()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataTendonViews::J_rowadr()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<int> mujoco::python::MjDataTendonViews::J_colind()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataTendonViews::length()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataTendonViews::J()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc: In member function ‘pybind11::array_t<double> mujoco::python::MjDataTendonViews::velocity()’:
      /tmp/pip-req-build-y63uhm9z/mujoco/indexers.cc:365:1: error: ‘#pragma’ is not allowed here
      gmake[2]: *** [CMakeFiles/_structs.dir/build.make:66: CMakeFiles/_structs.dir/indexers.cc.o] Error 1
      gmake[2]: *** Waiting for unfinished jobs....
      [ 91%] Linking CXX shared module _rollout.cpython-39-x86_64-linux-gnu.so
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/cmake -E cmake_link_script CMakeFiles/_rollout.dir/link.txt --verbose=1
      /cvmfs/soft.computecanada.ca/easybuild/software/2020/Core/gcccore/9.3.0/bin/c++ -fPIC -O3 -DNDEBUG -fuse-ld=gold -Wl,--gc-sections -shared  -o _rollout.cpython-39-x86_64-linux-gnu.so CMakeFiles/_rollout.dir/rollout.cc.o  -Wl,-rpath,"\$ORIGIN" /cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Core/mujoco/2.2.0/lib/libmujoco.so _deps/abseil-cpp-build/absl/strings/libabsl_cord.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_info.a _deps/abseil-cpp-build/absl/strings/libabsl_cord_internal.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_functions.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_handle.a _deps/abseil-cpp-build/absl/hash/libabsl_hash.a _deps/abseil-cpp-build/absl/hash/libabsl_city.a _deps/abseil-cpp-build/absl/types/libabsl_bad_variant_access.a _deps/abseil-cpp-build/absl/hash/libabsl_low_level_hash.a _deps/abseil-cpp-build/absl/container/libabsl_raw_hash_set.a _deps/abseil-cpp-build/absl/types/libabsl_bad_optional_access.a _deps/abseil-cpp-build/absl/container/libabsl_hashtablez_sampler.a _deps/abseil-cpp-build/absl/profiling/libabsl_exponential_biased.a _deps/abseil-cpp-build/absl/synchronization/libabsl_synchronization.a _deps/abseil-cpp-build/absl/debugging/libabsl_stacktrace.a _deps/abseil-cpp-build/absl/synchronization/libabsl_graphcycles_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_symbolize.a _deps/abseil-cpp-build/absl/debugging/libabsl_debugging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_malloc_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_demangle_internal.a _deps/abseil-cpp-build/absl/time/libabsl_time.a _deps/abseil-cpp-build/absl/strings/libabsl_strings.a _deps/abseil-cpp-build/absl/strings/libabsl_strings_internal.a _deps/abseil-cpp-build/absl/base/libabsl_base.a _deps/abseil-cpp-build/absl/base/libabsl_spinlock_wait.a -lpthread -lrt _deps/abseil-cpp-build/absl/numeric/libabsl_int128.a _deps/abseil-cpp-build/absl/time/libabsl_civil_time.a _deps/abseil-cpp-build/absl/time/libabsl_time_zone.a _deps/abseil-cpp-build/absl/base/libabsl_throw_delegate.a _deps/abseil-cpp-build/absl/base/libabsl_raw_logging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_log_severity.a
      [ 91%] Linking CXX shared module _callbacks.cpython-39-x86_64-linux-gnu.so
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/cmake -E cmake_link_script CMakeFiles/_callbacks.dir/link.txt --verbose=1
      /cvmfs/soft.computecanada.ca/easybuild/software/2020/Core/gcccore/9.3.0/bin/c++ -fPIC -O3 -DNDEBUG -fuse-ld=gold -Wl,--gc-sections -shared  -o _callbacks.cpython-39-x86_64-linux-gnu.so CMakeFiles/_callbacks.dir/callbacks.cc.o  -Wl,-rpath,"\$ORIGIN" /cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Core/mujoco/2.2.0/lib/libmujoco.so _deps/abseil-cpp-build/absl/strings/libabsl_cord.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_info.a _deps/abseil-cpp-build/absl/strings/libabsl_cord_internal.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_functions.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_handle.a _deps/abseil-cpp-build/absl/hash/libabsl_hash.a _deps/abseil-cpp-build/absl/hash/libabsl_city.a _deps/abseil-cpp-build/absl/types/libabsl_bad_variant_access.a _deps/abseil-cpp-build/absl/hash/libabsl_low_level_hash.a _deps/abseil-cpp-build/absl/container/libabsl_raw_hash_set.a _deps/abseil-cpp-build/absl/types/libabsl_bad_optional_access.a _deps/abseil-cpp-build/absl/container/libabsl_hashtablez_sampler.a _deps/abseil-cpp-build/absl/profiling/libabsl_exponential_biased.a _deps/abseil-cpp-build/absl/synchronization/libabsl_synchronization.a _deps/abseil-cpp-build/absl/debugging/libabsl_stacktrace.a _deps/abseil-cpp-build/absl/synchronization/libabsl_graphcycles_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_symbolize.a _deps/abseil-cpp-build/absl/debugging/libabsl_debugging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_malloc_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_demangle_internal.a _deps/abseil-cpp-build/absl/time/libabsl_time.a _deps/abseil-cpp-build/absl/strings/libabsl_strings.a _deps/abseil-cpp-build/absl/strings/libabsl_strings_internal.a _deps/abseil-cpp-build/absl/base/libabsl_base.a _deps/abseil-cpp-build/absl/base/libabsl_spinlock_wait.a -lpthread -lrt _deps/abseil-cpp-build/absl/numeric/libabsl_int128.a _deps/abseil-cpp-build/absl/time/libabsl_civil_time.a _deps/abseil-cpp-build/absl/time/libabsl_time_zone.a _deps/abseil-cpp-build/absl/base/libabsl_throw_delegate.a _deps/abseil-cpp-build/absl/base/libabsl_raw_logging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_log_severity.a
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/strip /tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39/_rollout.cpython-39-x86_64-linux-gnu.so
      gmake[2]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      [ 91%] Built target _rollout
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/strip /tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39/_callbacks.cpython-39-x86_64-linux-gnu.so
      gmake[2]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      [ 91%] Built target _callbacks
      [ 91%] Linking CXX shared module _render.cpython-39-x86_64-linux-gnu.so
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/cmake -E cmake_link_script CMakeFiles/_render.dir/link.txt --verbose=1
      /cvmfs/soft.computecanada.ca/easybuild/software/2020/Core/gcccore/9.3.0/bin/c++ -fPIC -O3 -DNDEBUG -fuse-ld=gold -Wl,--gc-sections -shared  -o _render.cpython-39-x86_64-linux-gnu.so CMakeFiles/_render.dir/render.cc.o  -Wl,-rpath,"\$ORIGIN" _deps/abseil-cpp-build/absl/strings/libabsl_cord.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_info.a _deps/abseil-cpp-build/absl/strings/libabsl_cord_internal.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_functions.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_handle.a _deps/abseil-cpp-build/absl/hash/libabsl_hash.a _deps/abseil-cpp-build/absl/hash/libabsl_city.a _deps/abseil-cpp-build/absl/types/libabsl_bad_variant_access.a _deps/abseil-cpp-build/absl/hash/libabsl_low_level_hash.a _deps/abseil-cpp-build/absl/container/libabsl_raw_hash_set.a _deps/abseil-cpp-build/absl/types/libabsl_bad_optional_access.a _deps/abseil-cpp-build/absl/container/libabsl_hashtablez_sampler.a _deps/abseil-cpp-build/absl/profiling/libabsl_exponential_biased.a _deps/abseil-cpp-build/absl/synchronization/libabsl_synchronization.a _deps/abseil-cpp-build/absl/debugging/libabsl_stacktrace.a _deps/abseil-cpp-build/absl/synchronization/libabsl_graphcycles_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_symbolize.a _deps/abseil-cpp-build/absl/debugging/libabsl_debugging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_malloc_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_demangle_internal.a _deps/abseil-cpp-build/absl/time/libabsl_time.a _deps/abseil-cpp-build/absl/strings/libabsl_strings.a _deps/abseil-cpp-build/absl/strings/libabsl_strings_internal.a _deps/abseil-cpp-build/absl/base/libabsl_base.a _deps/abseil-cpp-build/absl/base/libabsl_spinlock_wait.a -lpthread -lrt _deps/abseil-cpp-build/absl/numeric/libabsl_int128.a _deps/abseil-cpp-build/absl/time/libabsl_civil_time.a _deps/abseil-cpp-build/absl/time/libabsl_time_zone.a _deps/abseil-cpp-build/absl/base/libabsl_throw_delegate.a _deps/abseil-cpp-build/absl/base/libabsl_raw_logging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_log_severity.a /cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Core/mujoco/2.2.0/lib/libmujoco.so
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/strip /tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39/_render.cpython-39-x86_64-linux-gnu.so
      gmake[2]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      [ 91%] Built target _render
      [100%] Linking CXX shared module _functions.cpython-39-x86_64-linux-gnu.so
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/cmake -E cmake_link_script CMakeFiles/_functions.dir/link.txt --verbose=1
      /cvmfs/soft.computecanada.ca/easybuild/software/2020/Core/gcccore/9.3.0/bin/c++ -fPIC -O3 -DNDEBUG -fuse-ld=gold -Wl,--gc-sections -shared  -o _functions.cpython-39-x86_64-linux-gnu.so CMakeFiles/_functions.dir/functions.cc.o  -Wl,-rpath,"\$ORIGIN" _deps/abseil-cpp-build/absl/strings/libabsl_cord.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_info.a _deps/abseil-cpp-build/absl/strings/libabsl_cord_internal.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_functions.a _deps/abseil-cpp-build/absl/strings/libabsl_cordz_handle.a _deps/abseil-cpp-build/absl/hash/libabsl_hash.a _deps/abseil-cpp-build/absl/hash/libabsl_city.a _deps/abseil-cpp-build/absl/types/libabsl_bad_variant_access.a _deps/abseil-cpp-build/absl/hash/libabsl_low_level_hash.a _deps/abseil-cpp-build/absl/container/libabsl_raw_hash_set.a _deps/abseil-cpp-build/absl/types/libabsl_bad_optional_access.a _deps/abseil-cpp-build/absl/container/libabsl_hashtablez_sampler.a _deps/abseil-cpp-build/absl/profiling/libabsl_exponential_biased.a _deps/abseil-cpp-build/absl/synchronization/libabsl_synchronization.a _deps/abseil-cpp-build/absl/debugging/libabsl_stacktrace.a _deps/abseil-cpp-build/absl/synchronization/libabsl_graphcycles_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_symbolize.a _deps/abseil-cpp-build/absl/debugging/libabsl_debugging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_malloc_internal.a _deps/abseil-cpp-build/absl/debugging/libabsl_demangle_internal.a _deps/abseil-cpp-build/absl/time/libabsl_time.a _deps/abseil-cpp-build/absl/strings/libabsl_strings.a _deps/abseil-cpp-build/absl/strings/libabsl_strings_internal.a _deps/abseil-cpp-build/absl/base/libabsl_base.a _deps/abseil-cpp-build/absl/base/libabsl_spinlock_wait.a -lpthread -lrt _deps/abseil-cpp-build/absl/numeric/libabsl_int128.a _deps/abseil-cpp-build/absl/time/libabsl_civil_time.a _deps/abseil-cpp-build/absl/time/libabsl_time_zone.a _deps/abseil-cpp-build/absl/base/libabsl_throw_delegate.a _deps/abseil-cpp-build/absl/base/libabsl_raw_logging_internal.a _deps/abseil-cpp-build/absl/base/libabsl_log_severity.a /cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Core/mujoco/2.2.0/lib/libmujoco.so
      cc1plus: all warnings being treated as errors
      gmake[2]: *** [CMakeFiles/_enums.dir/build.make:66: CMakeFiles/_enums.dir/enums.cc.o] Error 1
      gmake[2]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      gmake[1]: *** [CMakeFiles/Makefile2:1944: CMakeFiles/_enums.dir/all] Error 2
      gmake[1]: *** Waiting for unfinished jobs....
      /cvmfs/soft.computecanada.ca/gentoo/2020/usr/bin/strip /tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39/_functions.cpython-39-x86_64-linux-gnu.so
      gmake[2]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      [100%] Built target _functions
      gmake[2]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      gmake[1]: *** [CMakeFiles/Makefile2:1776: CMakeFiles/_structs.dir/all] Error 2
      gmake[1]: Leaving directory '/tmp/pip-req-build-y63uhm9z/build/temp.linux-x86_64-cpython-39'
      gmake: *** [Makefile:133: all] Error 2
      Traceback (most recent call last):
        File "<string>", line 2, in <module>
        File "<pip-setuptools-caller>", line 34, in <module>
        File "/tmp/pip-req-build-y63uhm9z/setup.py", line 265, in <module>
          setup(
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/__init__.py", line 87, in setup
          return distutils.core.setup(**attrs)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/core.py", line 177, in setup
          return run_commands(dist)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/core.py", line 193, in run_commands
          dist.run_commands()
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/dist.py", line 968, in run_commands
          self.run_command(cmd)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/dist.py", line 1217, in run_command
          super().run_command(command)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/dist.py", line 987, in run_command
          cmd_obj.run()
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/wheel/bdist_wheel.py", line 223, in run
          self.run_command('build')
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/cmd.py", line 317, in run_command
          self.distribution.run_command(command)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/dist.py", line 1217, in run_command
          super().run_command(command)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/dist.py", line 987, in run_command
          cmd_obj.run()
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/command/build.py", line 24, in run
          super().run()
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/command/build.py", line 131, in run
          self.run_command(cmd_name)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/cmd.py", line 317, in run_command
          self.distribution.run_command(command)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/dist.py", line 1217, in run_command
          super().run_command(command)
        File "/project/6029978/stone/Work/mujoco-2.2.0/python/tmp/env/lib/python3.9/site-packages/setuptools/_distutils/dist.py", line 987, in run_command
          cmd_obj.run()
        File "/tmp/pip-req-build-y63uhm9z/setup.py", line 144, in run
          self._configure_cmake()
        File "/tmp/pip-req-build-y63uhm9z/setup.py", line 243, in _configure_cmake
          subprocess.check_call(
        File "/cvmfs/soft.computecanada.ca/easybuild/software/2020/avx2/Core/python/3.9.6/lib/python3.9/subprocess.py", line 373, in check_call
          raise CalledProcessError(retcode, cmd)
      subprocess.CalledProcessError: Command '['cmake', '--build', '.', '-j64', '--config', 'Release']' returned non-zero exit status 2.
      [end of output]
    

    note: This error originates from a subprocess, and is likely not a problem with pip. ERROR: Failed building wheel for mujoco

    </details>
    python building 
    opened by scottastone 23
  • Looking for a simple example for python binding

    Looking for a simple example for python binding

    I'm trying to run a simple script to get started, and it would help if there was one available. Any chance to add an example script?

    At the moment I'm running this and all I'm getting is a black screen (maybe my camera is looking at the wrong place, or my model is empty?). Any help would be appreciated.

    import mujoco
    import glfw
    
    def init_window(max_width, max_height):
        glfw.init()
        # glfw.window_hint(glfw.VISIBLE, 0)
        window = glfw.create_window(width=max_width, height=max_height,
                                           title='Demo', monitor=None,
                                           share=None)
        glfw.make_context_current(window)
        return window
    
    window = init_window(1200, 900)
    
    model = mujoco.MjModel.from_xml_path('./xml_files/ball.xml')
    data = mujoco.MjData(model)
    context = mujoco.MjrContext(model, mujoco.mjtFontScale.mjFONTSCALE_100)
    mujoco.mjr_setBuffer(mujoco.mjtFramebuffer.mjFB_OFFSCREEN, context)
    
    scene = mujoco.MjvScene(model, 1000)
    camera = mujoco.MjvCamera()
    
    
    mujoco.mjv_updateScene(
        model, data, mujoco.MjvOption(), mujoco.MjvPerturb(),
        camera, mujoco.mjtCatBit.mjCAT_ALL, scene)
    
    
    
    
    while(not glfw.window_should_close(window)):
        while data.time < 1:
            mujoco.mj_step(model, data)
            print(data.geom_xpos)
    
        glfw.get_framebuffer_size(window)
    
        viewport = mujoco.MjrRect(0, 0, 0, 0)
    
    
        mujoco.mjv_updateScene(
            model, data, mujoco.MjvOption(), None,
            camera, mujoco.mjtCatBit.mjCAT_ALL, scene)
        mujoco.mjr_render(viewport, scene, context)
    
        glfw.swap_buffers(window)
    
        glfw.poll_events()
    
    
    glfw.terminate()
    

    Together with this xml file:

    <mujoco>
        <worldbody>
                <light diffuse=".5 .5 .5" pos="0 0 3" dir ="0 0 -1"/>
            <geom type="plane" size="1 1 0.1" rgba=".9 0 0 1" />
            <body pos="0 0 1">
                <joint type="free"/>
                <geom type="sphere" size=".1" rgba="0 .9 0 1"/>
            </body>
        </worldbody>
    </mujoco>
    
    question 
    opened by m-mandel 19
  • How the modifications in the UI are passed to the physics simulation ?

    How the modifications in the UI are passed to the physics simulation ?

    Hi,

    I'm having a hard time trying to understand how the modifications in the UI are passed to the physics simulation in the boilerplate simulate.cc. I want to add new buttons to the UI to make my robot follow hard coded plans using the joint position actuators.

    So far, I understand that the physics loop runs in a background thread and modify the state through the function Simulate::applyforceperturbations, which calls mjv_applyPerturbForce to modify the mjData object using an mjvPerturb object.

    I also understand that the render loop runs in the main thread and calls mjui_event and mjui_update when I modify joint positions.

    But I can't understand where the connection between the render loop and the physics loop happens. More specifically, what is the mechanism of the render loop that fills the mjvPerturb object so that the physics loop can modify the state of the simulation accordingly ?

    A detailed high level detailed explanation would be much appreciated.

    Thanks in advance

    question 
    opened by joaopfg 18
  • “pip install mujoco” get stuck

    “pip install mujoco” get stuck

    Hi,

    I'm a student and I'm trying to use MuJoCo for my research. And I'm looking for some help with the installation of mujoco.

    There are mujocos for C/CXX and for python. Hence, to distinguish, I denote them as Mujoco(C/CXX) and Mujoco(Python), respectively. Mujoco(C/CXX) can be installed by building from source or just download a precomplied version. Mujoco(Python) can be installed using pip or building from source.

    After installing Mujoco(C/CXX) (The server maintainer installed Mujoco2.2.0 from source and provided a module that I can load), I tried to run “pip install mujoco” to install Mujoco(Python). There were no bugs reported but just got stuck. I waited for about two hours but the installation process was still not finished. Could you please help me? I have also tried to build Mujoco(Python) from source, but the same problem occurred.

    """ (mujocotest) [zhc]$ pip install mujoco Collecting mujoco Using cached mujoco-2.2.0.tar.gz (138 kB) Preparing metadata (setup.py) ... done Requirement already satisfied: absl-py in /home/zch/.local/lib/python3.7/site-packages (from mujoco) (0.15.0) Requirement already satisfied: glfw in /home/zch/.local/lib/python3.7/site-packages (from mujoco) (2.5.3) Requirement already satisfied: numpy in /home/zch/.local/lib/python3.7/site-packages (from mujoco) (1.19.5) Requirement already satisfied: pyopengl in /home/zch/.local/lib/python3.7/site-packages (from mujoco) (3.1.6) Requirement already satisfied: six in /usr/local/python/3.7.7/lib/python3.7/site-packages (from absl-py->mujoco) (1.15.0) Building wheels for collected packages: mujoco Building wheel for mujoco (setup.py) ... /

    """

    building 
    opened by zhihaocheng 17
  • Try to simulate a suction-type gripper

    Try to simulate a suction-type gripper

    I want to try to simulate a suction-type gripper. When the suction-type gripper is close enough to the object, the object can be sucked. I would like to ask what characteristics I can use to achieve these functions?Thanks for any help!

    enhancement 
    opened by Lucky-hqj 17
  • What is the best way to import a Fusion360 model?

    What is the best way to import a Fusion360 model?

    My end goal is rendering and controlling a robot in Unity using mujoco physics. The robot was designed on Fusion360. My question is: What would be the best practice? Importing the model to mujoco first and importing the mujoco scene into unity? or importing the model directly to unity and adding the scripts from the unity engine? In case I have to import first to mujoco, is there an established pipeline to convert the model to a mujoco-friendly format?

    Thank you so much.

    question Unity 
    opened by DinoDany 16
  • Analytical Time Derivative of Site Jacobian

    Analytical Time Derivative of Site Jacobian

    Discussed in https://github.com/deepmind/mujoco/discussions/410

    Originally posted by dhruvthanki July 31, 2022 I'm trying to write an optimization-based controller for a humanoid robot in MuJoCo with equality constraints of the QP being the dynamics and contact constraint defined at the site as similar to #53. Obtaining the site jacobian was straightforward, but the time derivative of the jacobian is a little bit complicated. Until now I have been using finite difference but now I want to calculate the time derivative of the jacobian analytically.

    From Equation 28-33 in the document, it is easy to see that computing the product, dJdq using Equation 31 is more efficient than computing the time derivative of the jacobian alone. Computing the acceleration drift (dJdq) as shown in Eqn 31 requires spatial velocities, v_i of all the bodies. One way I can think of is to compute jacobian using mj_jac() with the point as 0 vector and the bodyID being the ID of the parent Body of the site and map the system velocities, qdot using the jacobian to obtain the body spatial velocities. I am not sure if this is the right way to do this. Any help is appreciated.

    opened by dhruvthanki 15
  • Windows Binary Build artifacts

    Windows Binary Build artifacts "System Error" when executed (double click, powershell, and Cygwin execution) v2.1.1 through v2.2.0

    1. Install Windows 10 fresh in VirtualBox
    2. Download the latest Windows x86_64 binary release of MuJoCo
    3. extract the zip on Windows 10 64 bit
    4. double click simulate.exe or testspeed.exe
    5. Get a series of 4 popups saying DLL's are missing

    speedtestfail

    This issue is also effecting linking against the binary release of the library for applications.

    bug 
    opened by madhephaestus 15
  • How to send cartesian target for the end effector ?

    How to send cartesian target for the end effector ?

    Hi, I am new to MuJoCo and I would like to use it to push an object with a robotic arm, checking how the object moved in the end.

    I loaded successfully the model and I have the callbacks for the mouse to move the camera.

    Now I have some questions: 1- How can I control the joints in order to remain still ? Now the arm is oscillating due to gravity I think. 2- How can I send a cartesian target to reach with the end-effector ? 3- How can I get the position of an object in the space to check the resulting pose of the object after a push ?

    Thank you for the help !

    opened by aled96 15
  • Gripping of Cable by Fin Gripper

    Gripping of Cable by Fin Gripper

    Hi,

    I'm a student and I'm trying to use MuJoCo for Master's research.

    I'm looking for some help with my model, Grasping Cables in Flexible Object Manipulation Tasks.

    Here is a model which explains my question:

    <mujoco model="panda scene">
    
      <include file="panda.xml"/>
    
      <statistic center="0.3 0 0.4" extent="1"/>
      <extension>
        <required plugin="mujoco.elasticity.cable"/>
      </extension>
    
      <visual>
        <headlight diffuse="0.6 0.6 0.6"  ambient="0.3 0.3 0.3" specular="0 0 0"/>
        <rgba haze="0.15 0.25 0.35 1"/>
        <global azimuth="120" elevation="-30"/>
      </visual>
      <size nconmax="500" njmax="1000"/>
    
      <asset>
        <texture type="skybox" builtin="gradient" rgb1="0.3 0.5 0.7" rgb2="0 0 0" width="512"
            height="3072"/>
        <texture type="2d" name="groundplane" builtin="checker" mark="edge" rgb1="0.2 0.3 0.4"
            rgb2="0.1 0.2 0.3" markrgb="0.8 0.8 0.8" width="300" height="300"/>
        <material name="groundplane" texture="groundplane" texuniform="true" texrepeat="5 5"
            reflectance="0.2"/>
      </asset>
    
      <worldbody>
        <light pos="0 0 1.5" dir="0 0 -1" directional="true"/>
        <geom name="floor" size="0 0 0.05" type="plane" material="groundplane"/>
        <composite type="cable" curve="s" count="51 1 1" size="2" offset="-1 0.3 .2"  initial="none">
          <plugin plugin="mujoco.elasticity.cable">
            <!--Units are in Pa (SI)-->
            <config key="twist" value="1e6"/>
            <config key="bend" value="1e5"/>
          </plugin>
          <joint kind="main" damping=".5"/>
          <geom type="capsule" size=".01" rgba=".8 .2 .1 1" friction="4" condim="1"/>
        </composite>
        <!--<body name="socket" pos="1 0.3 .1">
          <geom type="box" size="0.05 0.05 0.05" margin=".02" gap=".01" rgba=".1 .8 .2 1" contype="2" conaffinity="2"/>
        </body>-->
        <body name="box1" pos="0.1 0.3 .1" zaxis="0 0 1">
          <geom type="box" size="0.05 0.05 0.05"  group="1" condim="1"/>
        </body>
        <body name="box2" pos="0.5 0.3 .1" zaxis="0 0 1">
          <geom type="box" size="0.05 0.05 0.05"  group="1" condim="1"/>
        </body> 
      </worldbody>
    </mujoco>
    

    This xml file is intended for use with the robot arm "panda" to grasp a cable. However, when it grabs and lifts the cable, the cable slips off. <geom type="capsule" size=".005" rgba=".8 .2 .1 1" friction="2" condim="1"/> I have included the parameter :friction to indicate friction, but I am not sure if it is working.

    Here is a video of the implementation.

    Screencast from 2022年12月19日 16時53分27秒.webm

    question 
    opened by makitayugo 1
  • Is there any way to create a composite model from import obj/stl file?

    Is there any way to create a composite model from import obj/stl file?

    I would like to import an existing obj file as soft model. I have tried the composite model, but not work. I would like to know is there any way to create a composite model from import .obj/.stl file? Does current version of Mujoco support to import a existing obj file as soft model?

    question 
    opened by KunZHANG1994 2
  • Help modeling vehicular collisions

    Help modeling vehicular collisions

    Hi,

    I'm a student trying to use MuJoCo to model vehicular dynamics in an environment with static obstacles.

    I'm looking for some help with my model, particularly with detecting collisions.

    Here is a model which explains my question:

    <mujoco>
    	<option gravity="0 0 -9.81" integrator="RK4" timestep="0.005" />
    	<worldbody>
            <light diffuse=".5 .5 .5" pos="0 0 3" dir="0 0 -1"/>
    		<geom name="floor" type="plane" size="5 5 0.1" rgba=".9 .9 .9 1"/>
            <geom name="obstacle" type="box" size=".25 .25 .25" pos="1.0 0 0.1" rgba="0 0 1 1"/>
    		<body name = "chassis" pos="0 0 0.2" euler='0 90 0'>
    			<joint type="free"/>
    			<geom type="box" size=".05 .2 .5" rgba=".9 .9 0 1"/>
    			<site name="marker" pos = "0 0 0.1" size="0.1" />
    			<body name="left-tire" pos="0 0.3 -0.5" euler='90 0 0'>
    				<joint name = "left-wheel" type="hinge" axis="0 0 -1"/>
    				<geom type="cylinder" size=".2 0.05" rgba="0 .9 0 1"/>
    			</body>
    			<body name="right-tire" pos="0 -0.3 -0.5" euler='90 0 0'>
    				<joint name = "right-wheel" type="hinge" axis="0 0 -1"/>
    				<geom type="cylinder" size=".2 0.05" rgba="0 .9 0 1"/>
    			</body>
    		</body>
    	</worldbody>
    	<sensor>
    		<framepos objtype="site" objname="marker"/>
    	</sensor>
    	<actuator>
    		<velocity name="left-velocity-servo" joint="left-wheel" kv="100"/>
    		<velocity name="right-velocity-servo" joint="right-wheel" kv="100"/>
    	</actuator>
    </mujoco>
    

    When I run the following code:

    int ncon = d->ncon;
    if (ncon > 0)
    {
        for (int i = 0; i < ncon; i++)
        {
            auto s1 = mj_id2name(m, mjOBJ_BODY, m -> geom_bodyid[d->contact[i].geom1]);
            auto s2 = mj_id2name(m, mjOBJ_BODY, m -> geom_bodyid[d->contact[i].geom2]);
            std::cout << "Contact " << i << ": " << s1 << " " << s2 << std::endl;
        }
    
    }
    

    it prints out:

    Contact 0: world chassis
    Contact 1: world chassis
    Contact 2: world left-tire
    Contact 3: world left-tire
    Contact 4: world right-tire
    Contact 5: world right-tire
    

    Why are there multiple collisions between the same pair of bodies? Or since I'm defining the geoms for the floor and the obstacle inside the worldbody tag, collisions with them are registered as collisions with the worldbody?

    What is the best practice to model acceptable pairs of collisions (such as between the floor and the vehicular body)? The documentation on how to do this is not very clear on this.

    Thank you!

    question 
    opened by aravindsiv 1
  • Static Magnet for Connectors

    Static Magnet for Connectors

    First of all, thank you very much for all contributors to this MuJoCo project. This is an awesome repository.

    Is your feature request related to a problem? Please describe.

    I want to make a magnet to implement something like MagSafe 3 of Mac.

    Implementing magnetic forces might be useful for other functions too. For example, adhesion currently attracts all objects within margin - gap with the same force strength. However, if one needs a realistic suction gripper, its force strength needs to depend on the distance between the gripper and an object, in a way similar to magnetic forces. (Closer, stronger.)

    Describe the solution you'd like

    It would be nice if we can add to an object a sclar attribute (like "magnetism"), which determines the magnitude of the force, and another attribute that determines the orientation of the magnetism (S and N). It would be also nice if setting the orientation to some special value allows to instantiate something like metal-like objects (no repulsion, no attraction of other objects, only attraction to magnets) and gravitation (no repulsion, only attraction). That said, for the purpose I descibed above (i.e., MagSafe 3), ferromagnetism and magnetic forces caused by electric currents are unnesesary.

    Describe alternatives you've considered

    Currently, I have no other idea on how to implement magnets. Setting contype and conaffinity with adhesion actuators allows an ad-hoc method to implement something like magnets. However, it sometimes leads to no contacts between some objects.

    Additional context

    I opened an issue about this topic, and Yuval asked me to open a feature request. See this issue for the additional context: https://github.com/deepmind/mujoco/issues/615#issuecomment-1332673517

    enhancement 
    opened by tadashiK 0
  • Help installing MuJoCo on FPGA

    Help installing MuJoCo on FPGA

    Hi,

    I'm a student researcher and I'm looking for some help installing MuJoCo on an FPGA.

    Here is a screenshot of the error I'm getting when I run pip install mujoco:

    image

    Does anyone have any idea how to fix this? Thank you so much in advance! I'm pretty new to interacting with the GitHub community, I apologize if I posted this in the wrong place.

    question 
    opened by alvinli6 3
Releases(2.3.1)
  • 2.3.1(Dec 6, 2022)

    Python bindings

    1. The simulate GUI is now available through the mujoco Python package as mujoco.viewer. See documentation for details. (Contribution by Levi Burner.)
    2. The Renderer class from the MuJoCo tutorial Colab is now available directly in the native Python bindings.

    General

    1. The tendon springlength attribute can now take two values. Given two non-decreasing values, springlength specifies a deadband range for spring stiffness. If the tendon length is between the two values, the force is 0. If length is outside this range, the force behaves like a regular spring, with the spring resting length corresponding to the nearest springlength value. This can be used to create tendons whose limits are enforced by springs rather than constraints, which are cheaper and easier to analyse. See tendon_springlength.xml example model. This is a minor breaking API change. mjModel.tendon_lengthspring now has size ntendon x 2 rather than ntendon x 1.

    2. Removed the requirement that stateless actuators come before stateful actuators.

    3. Added mju_fill, mju_symmetrize and mju_eye utility functions.

    4. Added gravcomp attribute to body implementing gravity compensation and buoyancy. See balloons.xml example model.

    5. Renamed the cable plugin library to elasticity.

    6. Added actdim attribute to general actuators. Values greater than 1 are only allowed for user, as native activation dynamics are all scalar. Added example test implementing 2nd-order activation dynamics to engine_forward_test.cc.

    7. Improved particle composite type, which now permits a user-specified geometry and multiple joints. See the two new examples: particle_free.xml and particle_free2d.xml.

    8. Performance improvements for non-AVX configurations:

    9. Added new solid passive force plugin.

      • This is new force field compatible with the composite particles.
      • Generates a tetrahedral mesh having particles with mass concentrated at vertices.
      • Uses a piecewise-constant strain model equivalent to finite elements but expressed in a coordinate-free formulation. This implies that all quantities can be precomputed except edge elongation, as in a mass-spring model.
      • Only suitable for small strains (large displacements but small deformations). Tetrahedra may invert if subject to large loads.
    10. Added API functions mj_loadPluginLibrary and mj_loadAllPluginLibraries. The first function is identical to dlopen on a POSIX system, and to LoadLibraryA on Windows. The second function scans a specified directory for all dynamic libraries file and loads each library found. Dynamic libraries opened by these functions are assumed to register one or more MuJoCo plugins on load.

    11. Added an optional visualize callback to plugins, which is called during mjv_updateScene. This callback allows custom plugin visualizations. Enable stress visualization for the Cable plugin as an example.

    12. Sensors of type user no longer require objtype, objname and needstage. If unspecified, the objtype is now mjOBJ_UNKNOWN. user sensors datatype default is now real, needstage default is now acc.

    13. Added support for capsules in URDF import.

    14. On macOS, issue an informative error message when run under Rosetta 2 translation on an Apple Silicon machine. Pre-built MuJoCo binaries make use of AVX instructions on x86-64 machines, which is not supported by Rosetta 2. (Before this version, users only get a cryptic "Illegal instruction" message.)

    Bug fixes

    1. Fixed bug in mj_addFileVFS that was causing the file path to be ignored (introduced in 2.1.4).

    Simulate

    1. Renamed the directory in which the simulate application searches for plugins from plugin to mujoco_plugin.
    2. Mouse force perturbations are now applied at the selection point rather than the body center of mass.

    Python bindings 2.3.1.post1 (6 December 2022)

    • Fix type annotations in mujoco.viewer that were causing errors in Python 3.7 and 3.8.
    Source code(tar.gz)
    Source code(zip)
    mujoco-2.3.1-linux-aarch64.tar.gz(5.27 MB)
    mujoco-2.3.1-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.3.1-linux-x86_64.tar.gz(5.34 MB)
    mujoco-2.3.1-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.3.1-macos-universal2.dmg(7.79 MB)
    mujoco-2.3.1-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.3.1-windows-x86_64.zip(4.60 MB)
    mujoco-2.3.1-windows-x86_64.zip.sha256(100 bytes)
  • 2.3.0(Oct 18, 2022)

    General

    1. The contact array and arrays prefixed with efc_ in mjData were moved out of the buffer into a new arena memory space. These arrays are no longer allocated with fixed sizes when mjData is created. Instead, the exact memory requirement is determined during each call to mj_forward (specifically, in mj_collision and mj_makeConstraint) and the arrays are allocated from the arena space. The stack now also shares its available memory with arena. This change reduces the memory footprint of mjData in models that do not use the PGS solver, and will allow for significant memory reductions in the future. See the Memory allocation section for details.

    2. Added colab notebook tutorial showing how to balance the humanoid on one leg with a Linear Quadratic Regulator. The notebook uses MuJoCo's native Python bindings, and includes a draft Renderer class, for easy rendering in Python. Try it yourself: Open In Colab

    3. Updates to humanoid model:

      • Added two keyframes (stand-on-one-leg and squat).
      • Increased maximum hip flexion angle.
      • Added hamstring tendons which couple the hip and knee at high hip flexion angles.
      • General cosmetic improvements, including improved use of defaults and better naming scheme.
    4. Added mju_boxQP and allocation function mju_boxQPmalloc for solving the box-constrained Quadratic Program: $x^* = \text{argmin} ; \tfrac{1}{2} x^T H x + x^T g \quad \text{s.t.} \quad l \le x \le u$ The algorithm, introduced in Tassa et al. 2014, converges after 2-5 Cholesky factorisations, independent of problem size.

    5. Added mju_mulVecMatVec to multiply a square matrix $M$ with vectors $x$ and $y$ on both sides. The function returns $x^TMy$.

    6. Added new plugin API. Plugins allow developers to extend MuJoCo's capability without modifying core engine code. The plugin mechanism is intended to replace the existing callbacks, though these will remain for the time being as an option for simple use cases and backward compatibility. The new mechanism manages stateful plugins and supports multiple plugins from different sources, allowing MuJoCo extensions to be introduced in a modular fashion, rather than as global overrides. Note the new mechanism is currently undocumented except in code, as we test it internally. If you are interested in using the plugin mechanism, please get in touch first.

    7. Added assetdir compiler option, which sets the values of both meshdir and texturedir. Values in the latter attributes take precedence over assetdir.

    8. Added realtime option to visual for starting a simulation at a slower speed.

    9. Added new cable composite type:

      • Cable elements are connected with ball joints.
      • The initial parameter specifies the joint at the starting boundary: free, ball, or none.
      • The boundary bodies are exposed with the names B_left and B_right.
      • The vertex initial positions can be specified directly in the XML with the parameter vertex.
      • The orientation of the body frame is the orientation of the material frame of the curve.
    10. Added new cable passive force plugin:

      • Twist and bending stiffness can be set separately with the parameters twist and bend.
      • The stress-free configuration can be set to be the initial one or flat with the flag flat.
      • New cable.xml example showing the formation of plectoneme.
      • New coil.xml example showing a curved equilibrium configuration.
      • New belt.xml example showing interaction between twist and anisotropy.
      • Added test using cantilever exact solution.

    Python bindings

    1. Added id and name properties to named accessor objects. These provide more Pythonic API access to mj_name2id and mj_id2name respectively.

    2. The length of MjData.contact is now ncon rather than nconmax, allowing it to be straightforwardly used as an iterator without needing to check ncon.

    3. Fix a memory leak when a Python callable is installed as callback (#527).

    Source code(tar.gz)
    Source code(zip)
    mujoco-2.3.0-linux-aarch64.tar.gz(5.19 MB)
    mujoco-2.3.0-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.3.0-linux-x86_64.tar.gz(5.30 MB)
    mujoco-2.3.0-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.3.0-macos-universal2.dmg(7.74 MB)
    mujoco-2.3.0-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.3.0-windows-x86_64.zip(4.55 MB)
    mujoco-2.3.0-windows-x86_64.zip.sha256(100 bytes)
  • 2.2.2(Sep 7, 2022)

    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

    1. Removed distance constraints.

    Bug fixes

    1. Fixed rendering of some transparent geoms in reflection.
    2. Fixed intvelocity defaults parsing.
    Source code(tar.gz)
    Source code(zip)
    mujoco-2.2.2-linux-aarch64.tar.gz(4.51 MB)
    mujoco-2.2.2-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.2.2-linux-x86_64.tar.gz(4.62 MB)
    mujoco-2.2.2-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.2.2-macos-universal2.dmg(7.18 MB)
    mujoco-2.2.2-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.2.2-windows-x86_64.zip(3.98 MB)
    mujoco-2.2.2-windows-x86_64.zip.sha256(100 bytes)
  • 2.2.1(Jul 17, 2022)

    General

    1. Added mjd_transitionFD to compute efficient finite difference approximations of the state-transition and control-transition matrices, see here for more details.
    2. Added derivatives for the ellipsoid fluid model.
    3. Added ctrl attribute to keyframes.
    4. Added clock sensor which measures time.
    5. Added visualisation groups to skins.
    6. Added actuator visualisation for free and ball joints and for actuators with site transmission.
    7. Added visualisation for actuator activations.
    8. Added <intvelocity> actuator shortcut for "integrated velocity" actuators, documented here.
    9. Added <damper> actuator shortcut for active-damping actuators, documented here.
    10. mju_rotVecMat and mju_rotVecMatT now support in-place multiplication.
    11. mjData.ctrl values are no longer clamped in-place, remain untouched by the engine.
    12. Arrays in mjData's buffer now align to 64-byte boundaries rather than 8-byte.
    13. Add memory poisoning when building with Address Sanitizer (ASAN) and Memory Sanitizer (MSAN). This allows ASAN to detect reads and writes to regions in mjModel.buffer and mjData.buffer that do not lie within an array, and for MSAN to detect reads from uninitialised fields in mjData following mj_resetData.
    14. Add a slider-crank example to model/.

    Bug fixes

    1. Activation clamping was not being applied in the implicit integrator.
    2. Stricter parsing of orientation specifiers. Before this change, a specification that included both quat and an alternative specifier e.g., <geom ... quat=".1 .2 .3 .4" euler="10 20 30">, would lead to the quat being ignored and only euler being used. After this change a parse error will be thrown.
    3. Stricter parsing of XML attributes. Before this change an erroneous XML snippet like <geom size="1/2 3 4"> would have been parsed as size="1 0 0" and no error would have been thrown. Now throws an error.
    4. Trying to load a NaN via XML like <geom size="1 NaN 4">, while allowed for debugging purposes, will now print a warning.
    5. Fixed null pointer dereference in mj_loadModel.
    6. Fixed memory leaks when loading an invalid model from MJB.
    7. Integer overflows are now avoided when computing mjModel buffer sizes.
    8. Added missing warning string for mjWARN_BADCTRL.

    Packaging

    1. Changed MacOS packaging so that the copy of mujoco.framework embedded in MuJoCo.app can be used to build applications externally.
    Source code(tar.gz)
    Source code(zip)
    mujoco-2.2.1-linux-aarch64.tar.gz(4.36 MB)
    mujoco-2.2.1-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.2.1-linux-x86_64.tar.gz(4.46 MB)
    mujoco-2.2.1-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.2.1-macos-universal2.dmg(6.97 MB)
    mujoco-2.2.1-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.2.1-windows-x86_64.zip(3.89 MB)
    mujoco-2.2.1-windows-x86_64.zip.sha256(100 bytes)
  • 2.2.0(May 23, 2022)

    Open Sourcing

    1. MuJoCo is now fully open-source software. Newly available top level directories are:

      1. src/: All source files. Subdirectories correspond to the modules described in the Programming chapter introduction:
        • src/engine/: Core engine.
        • src/xml/: XML parser.
        • src/user/: Model compiler.
        • src/visualize/: Abstract visualizer.
        • src/ui/: UI framework.
      2. test/: Tests and corresponding asset files.
      3. dist/: Files related to packaging and binary distribution.
    2. Added contributor's guide and style guide.

    General

    1. Added analytic derivatives of smooth (unconstrained) dynamics forces, with respect to velocities:

      • Centripetal and Coriolis forces computed by the Recursive Newton-Euler algorithm.
      • Damping and fluid-drag passive forces.
      • Actuation forces.
    2. Added implicit integrator. Using the analytic derivatives above, a new implicit-in-velocity integrator was added. This integrator lies between the Euler and Runge Kutta integrators in terms of both stability and computational cost. It is most useful for models which use fluid drag (e.g. for flying or swimming) and for models which use velocity actuators. For more details, see the Numerical Integration section.

    3. Added actlimited and actrange attributes to general actuators, for clamping actuator internal states (activations). This clamping is useful for integrated-velocity actuators, see the Activation clamping section for details.

    4. mjData fields qfrc_unc (unconstrained forces) and qacc_unc (unconstrained accelerations) were renamed qfrc_smooth and qacc_smooth, respectively. While "unconstrained" is precise, "smooth" is more intelligible than "unc".

    5. Public headers have been moved from /include to /include/mujoco/, in line with the directory layout common in other open source projects. Developers are encouraged to include MuJoCo public headers in their own codebase via #include <mujoco/filename.h>.

    6. The default shadow resolution specified by the shadowsize attribute was increased from 1024 to 4096.

    7. Saved XMLs now use 2-space indents.

    Bug fixes

    1. Antialiasing was disabled for segmentation rendering. Before this change, if the offsamples attribute was greater than 0 (the default value is 4), pixels that overlapped with multiple geoms would receive averaged segmentation IDs, leading to incorrect or non-existent IDs. After this change offsamples is ignored during segmentation rendering.

    2. The value of the enable flag for the experimental multiCCD feature was made sequential with other enable flags. Sequentiality is assumed in the simulate UI and elsewhere.

    3. Fix issue of duplicated meshes when saving models with OBJ meshes using mj_saveLastXML.


    Update 1 (27 May 2022): Replaced Linux tarball to fix RPATH on the sample binaries. No change in functionality.

    Source code(tar.gz)
    Source code(zip)
    mujoco-2.2.0-linux-aarch64.tar.gz(4.33 MB)
    mujoco-2.2.0-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.2.0-linux-x86_64.tar.gz(4.41 MB)
    mujoco-2.2.0-linux-x86_64.tar.gz.sha256(99 bytes)
    mujoco-2.2.0-macos-universal2.dmg(6.79 MB)
    mujoco-2.2.0-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.2.0-windows-x86_64.zip(3.84 MB)
    mujoco-2.2.0-windows-x86_64.zip.sha256(100 bytes)
  • 2.1.5(Apr 13, 2022)

    General

    1. Added an experimental feature: multi-contact convex collision detection, activated by an enable flag. See full description here.

    Bug fixes

    1. GLAD initialization logic on Linux now calls dlopen to load a GL platform dynamic library if a *GetProcAddress function is not already present in the process' global symbol table. In particular, processes that use GLFW to set up a rendering context that are not explicitly linked against libGLX.so (this applies to the Python interpreter, for example) will now work correctly rather than fail with a gladLoadGL error when mjr_makeContext is called. Fixes https://github.com/deepmind/dm_control/issues/283.

    2. In the Python bindings, named indexers for scalar fields (e.g. the ctrl field for actuators) now return a NumPy array of shape (1,) rather than (). This allows values to be assigned to these fields more straightforwardly. Fixes https://github.com/deepmind/mujoco/issues/238.

    Source code(tar.gz)
    Source code(zip)
    mujoco-2.1.5-linux-aarch64.tar.gz(4.21 MB)
    mujoco-2.1.5-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.1.5-linux-x86_64.tar.gz(4.29 MB)
    mujoco-2.1.5-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.1.5-macos-universal2.dmg(7.58 MB)
    mujoco-2.1.5-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.1.5-windows-x86_64.zip(3.81 MB)
    mujoco-2.1.5-windows-x86_64.zip.sha256(100 bytes)
  • 2.1.4(Apr 4, 2022)

    General

    1. MuJoCo now uses GLAD to manage OpenGL API access instead of GLEW. On Linux, there is no longer a need to link against different GL wrangling libraries depending on whether GLX, EGL, or OSMesa is being used. Instead, users can simply use GLX, EGL, or OSMesa to create a GL context and mjr_makeContext will detect which one is being used.

    2. Add visualisation for contact frames. This is useful when writing or modifying collision functions, when the actual direction of the x and y axes of a contact can be important.

    Binary build

    1. The _nogl dynamic library is no longer provided on Linux and Windows. The switch to GLAD allows us to resolve OpenGL symbols when mjr_makeContext is called rather than when the library is loaded. As a result, the MuJoCo library no longer has an explicit dynamic dependency on OpenGL, and can be used on system where OpenGL is not present.

    Simulate

    1. Fix a bug in simulate where pressing '[' or ']' when a model is not loaded causes a crash.

    2. Contact frame visualisation is added to the Simulate GUI.

    3. Rename "set key", "reset to key" to "save key" and "load key", respectively.

    4. Change bindings of F6 and F7 from the not very useful "vertical sync" and "busy wait" to the more useful cycling of frames and labels.

    Bug fixes

    1. mj_resetData now zeroes out the solver_nnz field.

    2. Remove a special branch in mju_quat2mat for unit quaternions. Previously, mju_quat2mat skipped all computation if the real part of the quaternion equals 1.0. For very small angles (e.g. when finite differencing), the cosine can evaluate to exactly 1.0 at double precision while the sine is still nonzero.

    Source code(tar.gz)
    Source code(zip)
    mujoco-2.1.4-linux-aarch64.tar.gz(4.20 MB)
    mujoco-2.1.4-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.1.4-linux-x86_64.tar.gz(4.28 MB)
    mujoco-2.1.4-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.1.4-macos-universal2.dmg(6.70 MB)
    mujoco-2.1.4-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.1.4-windows-x86_64.zip(3.81 MB)
    mujoco-2.1.4-windows-x86_64.zip.sha256(100 bytes)
  • 2.1.3(Mar 23, 2022)

    This is a minor release, handling issues discovered after the launch of 2.1.2.

    General

    1. simulate now support cycling through cameras (with [ and ] keys).
    2. mjVIS_STATIC toggles all static bodies, not just direct children of the world.

    Python bindings

    1. Added a free() method to MjrContext, rather than relying on the object destructor.
    2. Enums now support arithmetic and bitwise operations with numbers.

    Bug fixes

    1. Fixed a rendering bug for planes, introduced in 2.1.2. This broke maze environments in dm_control.
    Source code(tar.gz)
    Source code(zip)
    mujoco-2.1.3-linux-aarch64.tar.gz(6.32 MB)
    mujoco-2.1.3-linux-aarch64.tar.gz.sha256(102 bytes)
    mujoco-2.1.3-linux-x86_64.tar.gz(6.38 MB)
    mujoco-2.1.3-linux-x86_64.tar.gz.sha256(101 bytes)
    mujoco-2.1.3-macos-universal2.dmg(7.09 MB)
    mujoco-2.1.3-macos-universal2.dmg.sha256(102 bytes)
    mujoco-2.1.3-windows-x86_64.zip(4.65 MB)
    mujoco-2.1.3-windows-x86_64.zip.sha256(100 bytes)
  • 2.1.2(Mar 15, 2022)

    New modules

    1. Added new Python bindings, which can be installed via pip install mujoco, and imported as import mujoco.
    2. Added new Unity plug-in.
    3. Added a new introspect module, which provides reflection-like capability for MuJoCo's public API, currently describing functions and enums. While implemented in Python, this module is expected to be generally useful for automatic code generation targeting multiple languages. (This is not shipped as part of the mujoco Python bindings package.)

    API changes

    1. Moved definition of mjtNum floating point type into a new header mjtnum.h.
    2. Renamed header mujoco_export.h to mjexport.h.
    3. Added mj_printFormattedData, which accepts a format string for floating point numbers, for example to increase precision.

    General

    1. MuJoCo can load OBJ mesh files.
      • Meshes containing polygons with more than 4 vertices are not supported.
      • In OBJ files containing multiple object groups, any groups after the first one will be ignored.
    2. Added optional frame-of-reference specification to: framepos, framequat, framexaxis, frameyaxis, framezaxis, framelinvel, and frameangvel sensors. The frame-of-reference is specified by new reftype and refname attributes.
    3. Sizes of user parameters are now automatically inferred.
      • Declarations of user parameters in the top-level size clause (e.g. nuser_body, nuser_jnt, etc.) now accept a value of -1, which is the default. This will automatically set the value to the length of the maximum associated user attribute defined in the model.
      • Setting a value smaller than -1 will lead to a compiler error (previously a segfault).
      • Setting a value to a length smaller than some user attribute defined in the model will lead to an error (previously additional values were ignored).
    4. Increased the maximum number of lights in an mjvScene from 8 to 100.
    5. Saved XML files only contain explicit inertial elements if the original XML included them. Inertias that were automatically inferred by the compiler's inertiafromgeom mechanism remain unspecified.
    6. User-selected geoms are always rendered as opaque. This is useful in interactive visualizers.
    7. Static geoms now respect their geom group for visualisation. Until this change rendering of static geoms could only be toggled using the mjVIS_STATIC visualisation flag . After this change, both the geom group and the visualisation flag need to be enabled for the geom to be rendered.
    8. Pointer parameters in function declarations in mujoco.h that are supposed to represent fixed-length arrays are now spelled as arrays with extents, e.g. mjtNum quat[4] rather than mjtNum* quat. From the perspective of C and C++, this is a non-change since array types in function signatures decay to pointer types. However, it allows autogenerated code to be aware of expected input shapes.
    9. Experimental stateless fluid interaction model. As described here, fluid forces use sizes computed from body inertia. While sometimes convenient, this is very rarely a good approximation. In the new model forces act on geoms, rather than bodies, and have a several user-settable parameters. The model is activated by setting a new attribute: <geom fluidshape="ellipsoid"/>. The parameters are described succinctly here, but we leave a full description or the model and its parameters to when this feature leaves experimental status.

    Bug Fixes

    1. mj_loadXML and mj_saveLastXML are now locale-independent. The Unity plugin should now work correctly for users whose system locales use commas as decimal separators.
    2. XML assets in VFS no longer need to end in a null character. Instead, the file size is determined by the size parameter of the corresponding VFS entry.
    3. Fix a vertex buffer object memory leak in mjrContext when skins are used.
    4. Camera quaternions are now normalized during XML compilation.

    Binary build

    1. Windows binaries are now built with Clang.

    Python bindings 2.1.2.post1 (16 March 2022)

    • Removed a stray print statement in __init__.py.
    • Bundled libglewegl.so for Linux now has a DT_NEEDED entry on libOpenGL.so.0. (The download packages for Linux below have also been updated with this.)
    • The sdist can now be built with GCC.
    Source code(tar.gz)
    Source code(zip)
    mujoco-2.1.2-linux-aarch64.tar.gz(6.32 MB)
    mujoco-2.1.2-linux-aarch64.tar.gz.sha256(100 bytes)
    mujoco-2.1.2-linux-x86_64.tar.gz(6.38 MB)
    mujoco-2.1.2-linux-x86_64.tar.gz.sha256(99 bytes)
    mujoco-2.1.2-macos-universal2.dmg(6.59 MB)
    mujoco-2.1.2-macos-universal2.dmg.sha256(100 bytes)
    mujoco-2.1.2-windows-x86_64.zip(4.12 MB)
    mujoco-2.1.2-windows-x86_64.zip.sha256(98 bytes)
  • 2.1.1(Dec 16, 2021)

    API changes

    1. Added mj_printFormattedModel, which accepts a format string for floating point numbers, for example to increase precision.

    2. Added mj_versionString, which returns human-readable string that represents the version of the MuJoCo binary.

    3. Converted leading underscores to trailing underscores in private instances of API struct definitions, to conform to reserved identifier directive, see C standard: Section 7.1.3.

      This is a minor breaking change. Code which references private instances will break. To fix, replace leading underscores with trailing underscores, e.g. struct _mjModel becomes struct mjModel_.

    General

    1. Safer string handling: replaced strcat, strcpy, and sprintf with strncat, strncpy, and snprintf respectively.
    2. Changed indentation from 4 spaces to 2 spaces everywhere.

    Bug Fixes

    1. Fixed reading from uninitialized memory in PGS solver.

    2. Computed capsule inertias are now exact. Until this change, capsule masses and inertias computed by the compiler's inertiafromgeom mechanism were approximated by a cylinder, formed by the capsule's cylindrical middle section, extended on both ends by half the capsule radius. Capsule inertias are now computed with the Parallel Axis theorem, applied to the two hemispherical end-caps.

      This is a minor breaking change. Simulation of a model with automatically-computed capsule inertias will be numerically different, leading to, for example, breakage of golden-value tests.

    3. Fixed bug related to force and torque sensors. Until this change, forces torques reported by F/T sensors ignored out-of-tree constraint wrenches except those produced by contacts. Force and and torque sensors now correctly take into account the effects of connect and weld constraints.

      Forces generated by spatial tendons which are outside the kinematic tree (i.e. between bodies which have no ancestral relationship) are still not taken into account by force and torque sensors. This remains a future work item.

    Code samples

    1. testspeed: Added injection of pseudo-random control noise, turned on by default. This is to avoid settling into some fixed contact configuration and providing an unrealistic timing measure.

    2. simulate:

      • Added slower-than-real-time functionality, which is controlled via the '+' and '-' keys.
      • Added sliders for injecting Brownian noise into the controls.
      • Added "Print Camera" button to print an MJCF clause with the pose of the current camera.
      • The camera pose is not reset when reloading the same model file.

    Updated dependencies

    1. TinyXML was replaced with TinyXML2 6.2.0.
    2. qhull was upgraded to version 8.0.2.
    3. libCCD was upgraded to version 1.4.
    4. On Linux, libstdc++ was replaced with libc++.

    Binary build

    1. MacOS packaging. We now ship Universal binaries that natively support both Apple Silicon and Intel CPUs.

      • MuJoCo library is now packaged as a Framework Bundle, allowing it to be incorporated more easily into Xcode projects (including Swift projects). Developers are encouraged to compile and link against MuJoCo using the -framework mujoco flag, however all header files and the ``libmujoco.2.1.1.dylib` library can still be directly accessed inside the framework.
      • Sample applications are now packaged into an Application Bundle called MuJoCo.app. When launched via GUI, the bundle launches the simulate executable. Other precompiled sample programs are shipped inside that bundle (in MuJoCo.app/Contents/MacOS) and can be launched via command line.
      • Binaries are now signed and the disk image is notarized.
    2. Windows binaries and libraries are now signed.

    3. Link-time optimization is enabled on Linux and macOS, leading to an average of ~20% speedup when benchmarked on three test models (cloth.xml, humanoid.xml, and humanoid100.xml).

    4. Linux binaries are now built with LLVM/Clang instead of GCC.

    5. An AArch64 (aka ARM64) Linux build is also provided.

    6. Private symbols are no longer stripped from shared libraries on Linux and MacOS.

    Sample models

    1. Clean-up of the model/ directory.

      • Rearranged into subdirectories which include all dependencies.
      • Added descriptions in XML comments, cleaned up XMLs.
      • Deleted some composite models: grid1, grid1pin, grid2, softcylinder, softellipsoid.
    2. Added descriptive animations in docs/images/models/


    EDIT (30/12/2021 21:45 UTC): Added import libraries mujoco.lib and mujoco_nogl.lib to the Windows release package.

    EDIT (16/12/2021 21:10 UTC): We've updated the download packages to reflect minor changes in https://github.com/deepmind/mujoco/commit/ee39340ae783f6944f74168d852d7ac1664268c0. These changes only affect the bundled code and asset files. The libraries and binaries behave identically to the original packages released earlier today.

    Source code(tar.gz)
    Source code(zip)
    mujoco-2.1.1-linux-aarch64.tar.gz(5.69 MB)
    mujoco-2.1.1-linux-aarch64.tar.gz.sha256(100 bytes)
    mujoco-2.1.1-linux-ppc64le.tar.gz(6.22 MB)
    mujoco-2.1.1-linux-ppc64le.tar.gz.sha256(100 bytes)
    mujoco-2.1.1-linux-x86_64.tar.gz(5.73 MB)
    mujoco-2.1.1-linux-x86_64.tar.gz.sha256(99 bytes)
    mujoco-2.1.1-macos-universal2.dmg(6.43 MB)
    mujoco-2.1.1-macos-universal2.dmg.sha256(100 bytes)
    mujoco-2.1.1-windows-x86_64.zip(4.50 MB)
    mujoco-2.1.1-windows-x86_64.zip.sha256(98 bytes)
  • 2.1.0(Oct 18, 2021)

    New features

    1. Keyframes now have mocap_pos and mocap_quat fields (mpos and quat attributes in the XML) allowing mocap poses to be stored in keyframes.
    2. New utility functions: mju_insertionSortInt (integer insertion sort) and mju_sigmoid (constructing a sigmoid from two half-quadratics).

    General

    1. The pre-allocated sizes in the virtual file system (VFS) increased to 2000 and 1000, to allow for larger projects.
    2. The C structs in the mjuiItem union are now named, for compatibility.
    3. Fixed: mjcb_contactfilter type is mjfConFilt (was mjfGeneric).
    4. Fixed: The array of sensors in mjCModel was not cleared.
    5. Cleaned up cross-platform code (internal changes, not visible via the API).
    6. Fixed a bug in parsing of XML texcoord data (related to number of vertices).
    7. Fixed a bug in simulate.cc related to nkey (the number of keyframes).
    8. Accelerated collision detection in the presence of large numbers of non-colliding geoms (with contype==0 and conaffinity==0).

    UI

    1. Figure selection type changed from int to float.
    2. Figures now show data coordinates, when selection and highlight are enabled.
    3. Changed mjMAXUIMULTI to 35, mjMAXUITEXT to 300, mjMAXUIRECT to 25.
    4. Added collapsable sub-sections, implemented as separators with state: mjSEPCLOSED collapsed, mjSEPCLOSED+1 expanded.
    5. Added mjITEM_RADIOLINE item type.
    6. Added function mjui_addToSection to simplify UI section construction.
    7. Added subplot titles to mjvFigure.

    Rendering

    1. render_gl2 guards against non-finite floating point data in the axis range computation.
    2. render_gl2 draws lines from back to front for better visibility.
    3. Added function mjr_label (for text labels).
    4. mjr_render exits immediately if ngeom==0, to avoid errors from uninitialized scenes (e.g. frustrum==0).
    5. Added scissor box in mjr_render, so we don't clear the entire window at every frame.

    License manager

    1. Removed the entire license manager. The functions mj_activate and mj_deactivate are still there for backward compabitibily, but now they do nothing and it is no longer necessary to call them.
    2. Removed the remote license certificate functions mj_certXXX.
    Source code(tar.gz)
    Source code(zip)
    mujoco210-linux-x86_64.tar.gz(4.18 MB)
    mujoco210-macos-x86_64.tar.gz(3.73 MB)
    mujoco210-windows-x86_64.zip(4.55 MB)
Official PyTorch implementation of "Physics-aware Difference Graph Networks for Sparsely-Observed Dynamics".

Physics-aware Difference Graph Networks for Sparsely-Observed Dynamics This repository is the official PyTorch implementation of "Physics-aware Differ

USC-Melady 46 Nov 20, 2022
A python implementation of Physics-informed Spline Learning for nonlinear dynamics discovery

PiSL A python implementation of Physics-informed Spline Learning for nonlinear dynamics discovery. Sun, F., Liu, Y. and Sun, H., 2021. Physics-informe

Fangzheng (Andy) Sun 8 Jul 13, 2022
ImVoxelNet: Image to Voxels Projection for Monocular and Multi-View General-Purpose 3D Object Detection

ImVoxelNet: Image to Voxels Projection for Monocular and Multi-View General-Purpose 3D Object Detection This repository contains implementation of the

Visual Understanding Lab @ Samsung AI Center Moscow 190 Dec 30, 2022
Implementation of self-attention mechanisms for general purpose. Focused on computer vision modules. Ongoing repository.

Self-attention building blocks for computer vision applications in PyTorch Implementation of self attention mechanisms for computer vision in PyTorch

AI Summer 962 Dec 23, 2022
a general-purpose Transformer based vision backbone

Swin Transformer By Ze Liu*, Yutong Lin*, Yue Cao*, Han Hu*, Yixuan Wei, Zheng Zhang, Stephen Lin and Baining Guo. This repo is the official implement

Microsoft 9.9k Jan 8, 2023
BYOL for Audio: Self-Supervised Learning for General-Purpose Audio Representation

BYOL for Audio: Self-Supervised Learning for General-Purpose Audio Representation This is a demo implementation of BYOL for Audio (BYOL-A), a self-sup

NTT Communication Science Laboratories 160 Jan 4, 2023
A task-agnostic vision-language architecture as a step towards General Purpose Vision

Towards General Purpose Vision Systems By Tanmay Gupta, Amita Kamath, Aniruddha Kembhavi, and Derek Hoiem Overview Welcome to the official code base f

AI2 79 Dec 23, 2022
ZSL-KG is a general-purpose zero-shot learning framework with a novel transformer graph convolutional network (TrGCN) to learn class representation from common sense knowledge graphs.

ZSL-KG is a general-purpose zero-shot learning framework with a novel transformer graph convolutional network (TrGCN) to learn class representa

Bats Research 94 Nov 21, 2022
Unofficial PyTorch implementation of MobileViT based on paper "MobileViT: Light-weight, General-purpose, and Mobile-friendly Vision Transformer".

MobileViT RegNet Unofficial PyTorch implementation of MobileViT based on paper MOBILEVIT: LIGHT-WEIGHT, GENERAL-PURPOSE, AND MOBILE-FRIENDLY VISION TR

Hong-Jia Chen 91 Dec 2, 2022
General purpose GPU compute framework for cross vendor graphics cards (AMD, Qualcomm, NVIDIA & friends)

General purpose GPU compute framework for cross vendor graphics cards (AMD, Qualcomm, NVIDIA & friends). Blazing fast, mobile-enabled, asynchronous and optimized for advanced GPU data processing usecases. Backed by the Linux Foundation.

The Kompute Project 1k Jan 6, 2023
A general-purpose programming language, focused on simplicity, safety and stability.

The Rivet programming language A general-purpose programming language, focused on simplicity, safety and stability. Rivet's goal is to be a very power

The Rivet programming language 17 Dec 29, 2022
Real-Time Multi-Contact Model Predictive Control via ADMM

Here, you can find the code for the paper 'Real-Time Multi-Contact Model Predictive Control via ADMM'. Code is currently being cleared up and optimize

null 17 Dec 28, 2022
A Python framework for developing parallelized Computational Fluid Dynamics software to solve the hyperbolic 2D Euler equations on distributed, multi-block structured grids.

pyHype: Computational Fluid Dynamics in Python pyHype is a Python framework for developing parallelized Computational Fluid Dynamics software to solve

Mohamed Khalil 21 Nov 22, 2022
Official PyTorch implementation of Joint Object Detection and Multi-Object Tracking with Graph Neural Networks

This is the official PyTorch implementation of our paper: "Joint Object Detection and Multi-Object Tracking with Graph Neural Networks". Our project website and video demos are here.

Richard Wang 443 Dec 6, 2022
CoReNet is a technique for joint multi-object 3D reconstruction from a single RGB image.

CoReNet CoReNet is a technique for joint multi-object 3D reconstruction from a single RGB image. It produces coherent reconstructions, where all objec

Google Research 80 Dec 25, 2022
Drone-based Joint Density Map Estimation, Localization and Tracking with Space-Time Multi-Scale Attention Network

DroneCrowd Paper Detection, Tracking, and Counting Meets Drones in Crowds: A Benchmark. Introduction This paper proposes a space-time multi-scale atte

VisDrone 98 Nov 16, 2022
CPF: Learning a Contact Potential Field to Model the Hand-object Interaction

Contact Potential Field This repo contains model, demo, and test codes of our paper: CPF: Learning a Contact Potential Field to Model the Hand-object

Lixin YANG 99 Dec 26, 2022
[WACV 2020] Reducing Footskate in Human Motion Reconstruction with Ground Contact Constraints

Reducing Footskate in Human Motion Reconstruction with Ground Contact Constraints Official implementation for Reducing Footskate in Human Motion Recon

Virginia Tech Vision and Learning Lab 38 Nov 1, 2022
CVPR 2021 - Official code repository for the paper: On Self-Contact and Human Pose.

selfcontact This repo is part of our project: On Self-Contact and Human Pose. [Project Page] [Paper] [MPI Project Page] It includes the main function

Lea Müller 68 Dec 6, 2022