DMControlEnv (walker/quadruped) has zero gravity in default context
Closed this issue · 4 comments
Hi, I am trying to use the DMControlEnvs walker/quadruped with the default context value. But the gravity is zero even when the context has the correct value. Here are the packages I have installed in my python 3.9 environment
absl-py==2.0.0
antlr4-python3-runtime==4.9.3
appdirs==1.4.4
asttokens==2.4.1
astunparse==1.6.3
beautifulsoup4==4.12.2
blinker==1.7.0
brax==0.9.3
bs4==0.0.1
cachetools==5.3.2
carl-bench @ git+https://github.com/automl/CARL.git@b96661be3a2d10bf77969f2bdca6d05b84d54673
certifi==2023.11.17
chardet==5.2.0
charset-normalizer==3.3.2
chex==0.1.85
click==8.1.7
cloudpickle==3.0.0
comm==0.2.0
ConfigArgParse==1.7
ConfigSpace==0.7.1
contextlib2==21.6.0
contourpy==1.2.0
crafter==1.8.2
cycler==0.12.1
dataclasses==0.6
DataProperty==1.0.1
debugpy==1.8.0
decorator==4.4.2
dm-control==1.0.15
dm-env==1.6
dm-tree==0.1.8
docker-pycreds==0.4.0
etils==1.5.2
exceptiongroup==1.2.0
executing==2.0.1
Farama-Notifications==0.0.4
Flask==3.0.0
Flask-Cors==4.0.0
flatbuffers==1.12
flax==0.7.5
fonttools==4.45.1
fsspec==2023.10.0
gast==0.4.0
gitdb==4.0.11
GitPython==3.1.40
glfw==2.6.3
google-auth==2.23.4
google-auth-oauthlib==0.4.6
google-pasta==0.2.0
grpcio==1.59.3
gym==0.26.2
gym-notices==0.0.8
gymnasium==0.29.1
h5py==3.10.0
idna==3.6
imageio==2.33.0
imageio-ffmpeg==0.4.9
importlib-metadata==6.8.0
importlib-resources==6.1.1
ipykernel==6.27.1
ipython==8.18.1
itsdangerous==2.1.2
jax==0.4.20
jaxlib==0.4.20+cuda11.cudnn86
jaxopt==0.8.2
jedi==0.19.1
Jinja2==3.1.2
jupyter_client==8.6.0
jupyter_core==5.5.0
keras==2.9.0
Keras-Preprocessing==1.1.2
kiwisolver==1.4.5
labmaze==1.0.6
libclang==16.0.6
lxml==4.9.3
Markdown==3.5.1
markdown-it-py==3.0.0
MarkupSafe==2.1.3
matplotlib==3.8.2
matplotlib-inline==0.1.6
mbstrdecoder==1.1.3
mdurl==0.1.2
ml-collections==0.1.1
ml-dtypes==0.3.1
more-itertools==10.1.0
moviepy==1.0.3
msgpack==1.0.7
mujoco==3.0.1
nest-asyncio==1.5.8
numpy==1.26.2
numpyencoder==0.3.0
nvidia-cublas-cu11==11.11.3.6
nvidia-cuda-cupti-cu11==11.8.87
nvidia-cuda-nvcc-cu11==11.8.89
nvidia-cuda-nvrtc-cu11==11.8.89
nvidia-cuda-runtime-cu11==11.8.89
nvidia-cudnn-cu11==8.9.6.50
nvidia-cufft-cu11==10.9.0.58
nvidia-cusolver-cu11==11.4.1.48
nvidia-cusparse-cu11==11.7.5.86
nvidia-nccl-cu11==2.19.3
oauthlib==3.2.2
omegaconf==2.3.0
opensimplex==0.4.5
opt-einsum==3.3.0
optax==0.1.7
orbax-checkpoint==0.4.3
packaging==23.2
pandas==2.1.3
parso==0.8.3
pathvalidate==3.2.0
pexpect==4.9.0
Pillow==10.1.0
platformdirs==4.0.0
proglog==0.1.10
prompt-toolkit==3.0.41
protobuf==3.20.0
psutil==5.9.6
ptyprocess==0.7.0
pure-eval==0.2.2
pyasn1==0.5.1
pyasn1-modules==0.3.0
pygame==2.5.2
pyglet==2.0.10
Pygments==2.17.2
PyOpenGL==3.1.7
pyparsing==3.1.1
pytablewriter==1.2.0
python-dateutil==2.8.2
pytinyrenderer==0.0.14
pytz==2023.3.post1
PyYAML==6.0.1
pyzmq==25.1.1
requests==2.31.0
requests-oauthlib==1.3.1
rich==13.7.0
rsa==4.9
ruamel.yaml==0.17.32
ruamel.yaml.clib==0.2.8
scipy==1.11.4
sentry-sdk==1.38.0
setproctitle==1.3.3
six==1.16.0
smmap==5.0.1
soupsieve==2.5
stack-data==0.6.3
tabledata==1.3.3
tabulate==0.9.0
tcolorpy==0.1.4
tensorboard==2.9.0
tensorboard-data-server==0.6.1
tensorboard-plugin-wit==1.8.1
tensorboardX==2.6.2.2
tensorflow-cpu==2.9.0
tensorflow-estimator==2.9.0
tensorflow-io-gcs-filesystem==0.34.0
tensorflow-probability==0.23.0
tensorstore==0.1.50
termcolor==2.3.0
toolz==0.12.0
tornado==6.4
tqdm==4.66.1
traitlets==5.14.0
trimesh==4.0.5
typepy==1.3.2
typing_extensions==4.8.0
tzdata==2023.3
urllib3==2.1.0
wandb==0.16.0
wcwidth==0.2.12
Werkzeug==3.0.1
wrapt==1.16.0
xvfbwrapper==0.2.9
zipp==3.17.0
Thanks for the issue - I suspect a version upgrade in DM we don't cover yet, will investigate!
We'll definitely need more information here @sai-prasanna , since we haven't been able to reproduce this issue with your or an older dm_control version:
- what is the exact gravity value and how do you get it? I'd assume you use 'env.env.env.physics.model.opt' to inspect the physics of the environment?
- which environments did you try this with specifically? Did you reset them before checking (since instance changing happens in reset)?
- since you installed carl at a specific commit that doesn't seem to be the latest one: is there a specific reason for that? Does it work on the current main branch?
- does you environment instantiate at all? MuJoCo gravity is usually an array with x,y and z gravity where we only change z gravity, a single zero value should cause issues here
Sorry for the late reply got tied up with some work and then vacations.
I am using the v1.0.0 tag just to have it in the release version. Here is my sample code.
from carl.envs.dmc.carl_dm_walker import CARLDmcWalkerEnv
import numpy as np
import matplotlib.pyplot as plt
import imageio
from carl.context.selection import StaticSelector
from carl.envs.dmc import CARLDmcWalkerEnv
contexts = None
frames = []
env = CARLDmcWalkerEnv(contexts={0: CARLDmcWalkerEnv.get_default_context()})
env.reset()
for i in range(1000):
action = env.action_space.sample()
state, reward, terminated, truncated, info = env.step(action=action)
frames.append(env.render())
imageio.mimsave('video.mp4', frames, fps=30)
This answers some of your questions (1, 2, 3). The environment does instantiate (4).
With random actions, I would assume the walker would writhe on the ground unable to walk, but inspecting the video, it's floating. Am I wrong in assuming this?
video.mp4
env.env.env.physics.model.opt has the following value
<MjOption
apirate: 100.0
cone: 0
density: 0.0
disableactuator: 0
disableflags: 0
enableflags: 0
gravity: array([0. , 0. , 9.81])
impratio: 1.0
integrator: 0
iterations: 100
jacobian: 2
ls_iterations: 50
ls_tolerance: 0.01
magnetic: array([ 0. , -0.5, 0. ])
mpr_iterations: 50
mpr_tolerance: 1e-06
noslip_iterations: 0
noslip_tolerance: 1e-06
o_friction: array([1.e+00, 1.e+00, 5.e-03, 1.e-04, 1.e-04])
o_margin: 0.0
o_solimp: array([9.0e-01, 9.5e-01, 1.0e-03, 5.0e-01, 2.0e+00])
o_solref: array([0.02, 1. ])
sdf_initpoints: 40
sdf_iterations: 10
solver: 2
timestep: 0.0025
tolerance: 1e-08
viscosity: 0.0
wind: array([0., 0., 0.])
>
Now I tried directly loading vanilla dm control environment (used this wrapper to convert it to gymnasium). It works properly. So I think the bug is isolated to CARL rather than my dmcontrol setup being wacky.
video.mp4
Found the issue! We refactored these recently and added the sins of the bounds in the wrong order. I pushed a fix on development, locally your example now gives me the video below. Let me know if it works for you!