DMControlEnv (walker/quadruped) has zero gravity in default context about carl HOT 4 CLOSED

Thanks for the issue - I suspect a version upgrade in DM we don't cover yet, will investigate!

from carl.

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

from carl.

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?

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.

from carl.

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!

from carl.