Closed qgallouedec closed 5 months ago
I take what should be the simplest, support for rendering first ... and I should finally learning to use got properly ^^"
https://github.com/perezjln/gym-lowcostrobot/commit/416c8e67bc50f3104372e73e202f21404cb29c14 https://github.com/perezjln/gym-lowcostrobot/commit/c3ab416896274f4218ee342100b177976fab32cd
Find the correct fps : it seems it can be set, not sure need to recheck on documentation. https://github.com/perezjln/gym-lowcostrobot/commit/c3ab416896274f4218ee342100b177976fab32cd
Regarding determinism of the environment, maybe @qgallouedec you have an example to share ?
One point I'm wondering is how to retrieve poses from mujoco, it seems two ways are somehow possible:
or
Add and test actuator ranges retrieval in base env. https://github.com/perezjln/gym-lowcostrobot/commit/fbcafd90f06745b4122ec67fa2904745cd08c619
Not sure how to estimate ranges for the object part of the observation space, one idea @qgallouedec ?
Find the correct fps : it seems it can be set, not sure need to recheck on documentation. c3ab416
For the moment, I'd opt for a fixed fps, which the user can't set. It has to be part of the environment's metadata.
Regarding determinism of the environment, maybe @qgallouedec you have an example to share ?
import gymnasium as gym
import gym_lowcostrobot
env = gym.make('LiftCube-v0')
observation1, info = env.reset(seed=123)
observation2, info = env.reset(seed=123)
assert (observation1 == observation2).all()
that why the CI fails.
One point I'm wondering is how to retrieve poses from mujoco, it seems two ways are somehow possible:
or
We should draw inspiration from gym_aloha, I'm not familiar with MuJoCo.
Add and test actuator ranges retrieval in base env. fbcafd9
The goal of having this range is to specify the action_space right?
Not sure how to estimate ranges for the object part of the observation space, one idea @qgallouedec ?
It doesn't have to be precise, but it would have to be at least one of the finite bounds for the observation space.
Add and test actuator ranges retrieval in base env. fbcafd9
The goal of having this range is to specify the action_space right?
The goal of defining the ranges is rather for the observation space actually. The observation is composed with the joints pose/velocity/accel associated with each actuator + same info for each object in the scene. Having the range will allow to normalize as we know.
The action space are rather displacement than absolute pose in both cases (joint and Cartesian), so they can be defined a priori.
Not sure how to estimate ranges for the object part of the observation space, one idea @qgallouedec ?
It doesn't have to be precise, but it would have to be at least one of the finite bounds for the observation space.
Not obvious to me in the case of the objects to manipulate , maybe I should check how you did in panda-gym.
Regarding determinism of the environment, maybe @qgallouedec you have an example to share ?
import gymnasium as gym import gym_lowcostrobot env = gym.make('LiftCube-v0') observation1, info = env.reset(seed=123) observation2, info = env.reset(seed=123) assert (observation1 == observation2).all()
that why the CI fails.
Thanks, I will check this…. Interesting
One point I'm wondering is how to retrieve poses from mujoco, it seems two ways are somehow possible: https://github.com/perezjln/gym-lowcostrobot/blob/c3ab416896274f4218ee342100b177976fab32cd/gym_lowcostrobot/envs/lift_cube_env.py#L61
We should draw inspiration from gym_aloha, I'm not familiar with MuJoCo.
Good idea, I just check, they use the qpos from the mujoco.data: https://github.com/huggingface/gym-aloha/blob/7f19312f453f45fbe8ca8883d6250626dfa36373/gym_aloha/tasks/sim.py#L61
It makes sense as it seems to work in the invk script of our examples module.
The goal of defining the ranges is rather for the observation space actually. The observation is composed with the joints pose/velocity/accel associated with each actuator + same info for each object in the scene. Having the range will allow to normalize as we know.
Makes sense!
Not obvious to me in the case of the objects to manipulate , maybe I should check how you did in panda-gym.
I will check, I can't remember tbh.
The goal of defining the ranges is rather for the observation space actually. The observation is composed with the joints pose/velocity/accel associated with each actuator + same info for each object in the scene. Having the range will allow to normalize as we know.
Makes sense!
Not obvious to me in the case of the objects to manipulate , maybe I should check how you did in panda-gym.
I will check, I can't remember tbh.
It seems like the position ranges for the object is pre-defined: https://github.com/qgallouedec/panda-gym/blob/51fb901db6968cb8a78ebb11070d313566700d38/panda_gym/envs/tasks/push.py#L24
I just implemented it the same way: https://github.com/perezjln/gym-lowcostrobot/commit/8e29cbb470c1e8d0f7d9cc1da304236dc381501b
render_mode
instead ofdo_render
) (https://github.com/perezjln/gym-lowcostrobot/commit/416c8e67bc50f3104372e73e202f21404cb29c14 https://github.com/perezjln/gym-lowcostrobot/commit/c3ab416896274f4218ee342100b177976fab32cd)