Hello!
Is there any way to use wrappers? There are None values (for ‘goal_mask’ and ‘goal_positions’ keys) in observation dict in R1-environment. It can be solved with adding zero values for this keys to 93 line in real_robots/env.py:
or with use of wrappers.
Also it can be useful if observation_space also was provided to controller (for nn model defining and etc.). In my code I got information about observation_space from Kuka class, but it is not the most elegant way)
Also environments ‘object_positions’ spaces shape differs from corresponding shape in observation: (7,) vs (3,). I guess problem is in get_position() method calling (returns only coordinates) instead of get_pose() (returns coordinates and orientation).
Is there any way to use wrappers? There are None values (for ‘goal_mask’ and ‘goal_positions’ keys) in observation dict in R1-environment. It can be solved with adding zero values for this keys to 93 line in real_robots/env.py:
mmm I am not sure if I understand what do you mean by using wrappers.
As you have noticed, during the intrinsic phase, the goal is an all zeros image, while the additional observations goal_mask and goal_positions are set to None.
Your controller can be made aware of when the intrinsic phase starts or ends since it should extend the real_robots.BasePolicy class:
this means that you can implement the following methods:
def start_intrinsic_phase(self):
def end_intrinsic_phase(self, observation, reward, done):
and they will be automatically called when the intrinsic phase starts and ends.
If necessary, when your controller receives the observation through its step method, you can change the None values of goal_mask and goal_positions to anything you like (e.g. all zeros like the goal for example).
Also it can be useful if observation_space also was provided to controller (for nn model defining and etc.). In my code I got information about observation_space from Kuka class, but it is not the most elegant way)
Yes, correct, it would be better to pass the observation space too, since you shouldn’t access the environment directly.
We will change that.
Also environments ‘object_positions’ spaces shape differs from corresponding shape in observation: (7,) vs (3,). I guess problem is in get_position() method calling (returns only coordinates) instead of get_pose() (returns coordinates and orientation)
Do you mean ‘object_positions’ vs ‘goal_positions’ observations?
Yes, they are different - it is actually the goal_positions that returns more than we intended.
About wrappers: It was just a suggestion, no problems
About observation space: Thank you)
About ‘object_position’: I mean ‘object_position’ space.shape vs ‘object_position’ observation.shape.
Environment observation space is taken from ‘robot’ attribute - Kuka class. Kukas observation space is Dict space. There is key ‘object_position’ and it corresponds to Dict space with keys [‘tomato’, …]. This spaces (‘tomato’-space and etc.) are Box spaces with shape (7,) (real_robots/envs/robot.py, line 75). But environments [‘step’, ‘reset’] methods returns observation where observation[‘object_position’][‘tomato’].shape is (3,), because get_position() is called instead of get_pose() (real_robots/envs/env.py, line 234).
About ‘object_position’: I mean ‘object_position’ space.shape vs ‘object_position’ observation.shape.
Environment observation space is taken from ‘robot’ attribute - Kuka class. Kukas observation space is Dict space. There is key ‘object_position’ and it corresponds to Dict space with keys [‘tomato’, …]. This spaces (‘tomato’-space and etc.) are Box spaces with shape (7,) (real_robots/envs/robot.py, line 75). But environments [‘step’, ‘reset’] methods returns observation where observation[‘object_position’][‘tomato’].shape is (3,), because get_position() is called instead of get_pose() (real_robots/envs/env.py, line 234).
You are right @ermekaitygulov , the observation space definition should be amended too to reflect what step and reset currently return!
Thanks for pointing it out
