mani_skill.envs.tasks.quadruped.quadruped_reach =============================================== .. py:module:: mani_skill.envs.tasks.quadruped.quadruped_reach Classes ------- .. autoapisummary:: mani_skill.envs.tasks.quadruped.quadruped_reach.AnymalCReachEnv mani_skill.envs.tasks.quadruped.quadruped_reach.QuadrupedReachEnv mani_skill.envs.tasks.quadruped.quadruped_reach.UnitreeGo2ReachEnv Module Contents --------------- .. py:class:: AnymalCReachEnv(*args, robot_uids='anymal_c', **kwargs) Bases: :py:obj:`QuadrupedReachEnv` **Task Description:** Control the AnymalC robot to reach a target location in front of it. Note the current reward function works but more needs to be added to constrain the learned quadruped gait looks more natural **Randomizations:** - Robot is initialized in a stable rest/standing position - The goal for the robot to reach is initialized 2.5 +/- 0.5 meters in front, and +/- 1 meters to either side **Success Conditions:** - If the robot position is within 0.35 meters of the goal **Fail Conditions:** - If the robot has fallen over, which is considered True when the main body (the center part) hits the ground **Goal Specification:** - The 2D goal position in the XY-plane .. py:attribute:: _UNDESIRED_CONTACT_LINK_NAMES :value: ['LF_KFE', 'RF_KFE', 'LH_KFE', 'RH_KFE'] .. py:attribute:: _sample_video_link :value: 'https://github.com/haosulab/ManiSkill/raw/main/figures/environment_demos/AnymalC-Reach-v1_rt.mp4' a link to a sample video of the task. This is mostly used for automatic documentation generation .. py:attribute:: default_qpos .. py:class:: QuadrupedReachEnv(*args, robot_uids='anymal-c', **kwargs) Bases: :py:obj:`mani_skill.envs.sapien_env.BaseEnv` Superclass for ManiSkill environments. :param num_envs: number of parallel environments to run. By default this is 1, which means a CPU simulation is used. If greater than 1, then we initialize the GPU simulation setup. Note that not all environments are faster when simulated on the GPU due to limitations of GPU simulations. For example, environments with many moving objects are better simulated by parallelizing across CPUs. :param obs_mode: observation mode to be used. Must be one of ("state", "state_dict", "none", "sensor_data", "rgb", "depth", "segmentation", "rgbd", "rgb+depth", "rgb+depth+segmentation", "rgb+segmentation", "depth+segmentation", "pointcloud") The obs_mode is mostly for convenience to automatically optimize/setup all sensors/cameras for the given observation mode to render the correct data and try to ignore unnecessary rendering. For the most advanced use cases (e.g. you have 1 RGB only camera and 1 depth only camera) :param reward_mode: reward mode to use. Must be one of ("normalized_dense", "dense", "sparse", "none"). With "none" the reward returned is always 0 :param control_mode: control mode of the agent. "*" represents all registered controllers, and the action space will be a dict. :param render_mode: render mode registered in @SUPPORTED_RENDER_MODES. :param shader_dir: shader directory. Defaults to None. Setting this will override the shader used for all cameras in the environment. This is legacy behavior kept for backwards compatibility. The proper way to change the shaders used for cameras is to either change the environment code or pass in sensor_configs/human_render_camera_configs with the desired shaders. Previously the options are "default", "rt", "rt-fast". "rt" means ray-tracing which results in more photorealistic renders but is slow, "rt-fast" is a lower quality but faster version of "rt". :type shader_dir: Optional[str] :param enable_shadow: whether to enable shadow for lights. Defaults to False. :type enable_shadow: bool :param sensor_configs: configurations of sensors to override any environment defaults. If the key is one of sensor names (e.g. a camera), the config value will be applied to the corresponding sensor. Otherwise, the value will be applied to all sensors (but overridden by sensor-specific values). For possible configurations see the documentation see :doc:`the sensors documentation `. :type sensor_configs: dict :param human_render_camera_configs: configurations of human rendering cameras to override any environment defaults. Similar usage as @sensor_configs. :type human_render_camera_configs: dict :param viewer_camera_configs: configurations of the viewer camera in the GUI to override any environment defaults. Similar usage as @sensor_configs. :type viewer_camera_configs: dict :param robot_uids: list of robots to instantiate and control in the environment. :type robot_uids: Union[str, BaseAgent, list[Union[str, BaseAgent]]] :param sim_config: Configurations for simulation if used that override the environment defaults. If given a dictionary, it can just override specific attributes e.g. ``sim_config=dict(scene_config=dict(solver_iterations=25))``. If passing in a SimConfig object, while typed, will override every attribute including the task defaults. Some environments define their own recommended default sim configurations via the ``self._default_sim_config`` attribute that generally should not be completely overriden. :type sim_config: Union[SimConfig, dict] :param reconfiguration_freq: How frequently to call reconfigure when environment is reset via `self.reset(...)` Generally for most users who are not building tasks this does not need to be changed. The default is 0, which means the environment reconfigures upon creation, and never again. :type reconfiguration_freq: int :param sim_backend: By default this is "auto". If sim_backend is "auto", then if ``num_envs == 1``, we use the PhysX CPU sim backend, otherwise we use the PhysX GPU sim backend and automatically pick a GPU to use. Can also be "physx_cpu" or "physx_cuda" to force usage of a particular sim backend. To select a particular GPU to run the simulation on, you can pass "physx_cuda:n" where n is the ID of the GPU, similar to the way PyTorch selects GPUs. Note that if this is "physx_cpu", num_envs can only be equal to 1. :type sim_backend: str :param render_backend: By default this is "gpu". If render_backend is "gpu" or it's alias "sapien_cuda", then we auto select a GPU to render with. It can be "sapien_cuda:n" where n is the ID of the GPU to render with. If this is "cpu" or "sapien_cpu", then we try to render on the CPU. If this is "none" or None, then we disable rendering. Note that some environments may require rendering functionalities to work. Moreover it is sometimes difficult to determine before running an environment if your machine can render or not. If you encounter some issue with rendering you can first try to double check your NVIDIA drivers / Vulkan drivers are setup correctly. If you don't need to do rendering you can simply disable it by setting render_backend to "none" or None. :type render_backend: str :param parallel_in_single_scene: By default this is False. If True, rendered images and the GUI will show all objects in one view. This is only really useful for generating cool videos showing all environments at once but it is not recommended otherwise as it slows down simulation and rendering. :type parallel_in_single_scene: bool :param enhanced_determinism: By default this is False and env resets will reset the episode RNG only when a seed / seed list is given. If True, the environment will reset the episode RNG upon each reset regardless of whether a seed is provided. Generally enhanced_determinisim is not needed and users are recommended to pass seeds into the env reset function instead. :type enhanced_determinism: bool .. py:method:: _compute_undesired_contacts(threshold=1.0) .. py:method:: _get_obs_extra(info) Get task-relevant extra observations. Usually defined on a task by task basis .. py:method:: _initialize_episode(env_idx, options) Initialize the episode, e.g., poses of actors and articulations, as well as task relevant data like randomizing goal positions .. py:method:: _load_agent(options) loads the agent/controllable articulations into the environment. The default function provides a convenient way to setup the agent/robot by a robot_uid (stored in self.robot_uids) without requiring the user to have to write the robot building and controller code themselves. For more advanced use-cases you can override this function to have more control over the agent/robot building process. :param options: The options for the environment. :type options: dict :param initial_agent_poses: The initial poses of the agent/robot. Providing these poses and ensuring they are picked such that they do not collide with objects if spawned there is highly recommended to ensure more stable simulation (the agent pose can be changed later during episode initialization). :type initial_agent_poses: Optional[Union[sapien.Pose, Pose]] :param build_separate: Whether to build the agent/robot separately. If True, the agent/robot will be built separately for each parallel environment and then merged together to be accessible under one view/object. This is useful for randomizing physical and visual properties of the agent/robot which is only permitted for articulations built separately in each environment. :type build_separate: bool .. py:method:: _load_scene(options) Loads all objects like actors and articulations into the scene. Called by `self._reconfigure`. Given options argument is the same options dictionary passed to the self.reset function .. py:method:: compute_dense_reward(obs, action, info) Compute the dense reward. :param obs: The observation data. By default the observation data will be in its most raw form, a dictionary (no flattening, wrappers etc.) :type obs: Any :param action: The most recent action. :type action: torch.Tensor :param info: The info dictionary. :type info: dict .. py:method:: compute_normalized_dense_reward(obs, action, info) Compute the normalized dense reward. :param obs: The observation data. By default the observation data will be in its most raw form, a dictionary (no flattening, wrappers etc.) :type obs: Any :param action: The most recent action. :type action: torch.Tensor :param info: The info dictionary. :type info: dict .. py:method:: evaluate() Evaluate whether the environment is currently in a success state by returning a dictionary with a "success" key or a failure state via a "fail" key This function may also return additional data that has been computed (e.g. is the robot grasping some object) that may be reused when generating observations and rewards. By default if not overriden this function returns an empty dictionary .. py:attribute:: SUPPORTED_ROBOTS :value: ['anymal_c', 'unitree_go2_simplified_locomotion'] Override this to enforce which robots or tuples of robots together are supported in the task. During env creation, setting robot_uids auto loads all desired robots into the scene, but not all tasks are designed to support some robot setups .. py:attribute:: _UNDESIRED_CONTACT_LINK_NAMES :type: list[str] :value: None .. py:property:: _default_human_render_camera_configs Add default cameras for rendering when using render_mode='rgb_array'. These can be overriden by the user at env creation time .. py:property:: _default_sensor_configs Add default (non-agent) sensors to the environment by returning sensor configurations. These can be overriden by the user at env creation time .. py:property:: _default_sim_config .. py:attribute:: agent :type: mani_skill.agents.robots.anymal.anymal_c.ANYmalC .. py:attribute:: default_qpos :type: torch.Tensor .. py:class:: UnitreeGo2ReachEnv(*args, robot_uids='unitree_go2_simplified_locomotion', **kwargs) Bases: :py:obj:`QuadrupedReachEnv` Superclass for ManiSkill environments. :param num_envs: number of parallel environments to run. By default this is 1, which means a CPU simulation is used. If greater than 1, then we initialize the GPU simulation setup. Note that not all environments are faster when simulated on the GPU due to limitations of GPU simulations. For example, environments with many moving objects are better simulated by parallelizing across CPUs. :param obs_mode: observation mode to be used. Must be one of ("state", "state_dict", "none", "sensor_data", "rgb", "depth", "segmentation", "rgbd", "rgb+depth", "rgb+depth+segmentation", "rgb+segmentation", "depth+segmentation", "pointcloud") The obs_mode is mostly for convenience to automatically optimize/setup all sensors/cameras for the given observation mode to render the correct data and try to ignore unnecessary rendering. For the most advanced use cases (e.g. you have 1 RGB only camera and 1 depth only camera) :param reward_mode: reward mode to use. Must be one of ("normalized_dense", "dense", "sparse", "none"). With "none" the reward returned is always 0 :param control_mode: control mode of the agent. "*" represents all registered controllers, and the action space will be a dict. :param render_mode: render mode registered in @SUPPORTED_RENDER_MODES. :param shader_dir: shader directory. Defaults to None. Setting this will override the shader used for all cameras in the environment. This is legacy behavior kept for backwards compatibility. The proper way to change the shaders used for cameras is to either change the environment code or pass in sensor_configs/human_render_camera_configs with the desired shaders. Previously the options are "default", "rt", "rt-fast". "rt" means ray-tracing which results in more photorealistic renders but is slow, "rt-fast" is a lower quality but faster version of "rt". :type shader_dir: Optional[str] :param enable_shadow: whether to enable shadow for lights. Defaults to False. :type enable_shadow: bool :param sensor_configs: configurations of sensors to override any environment defaults. If the key is one of sensor names (e.g. a camera), the config value will be applied to the corresponding sensor. Otherwise, the value will be applied to all sensors (but overridden by sensor-specific values). For possible configurations see the documentation see :doc:`the sensors documentation `. :type sensor_configs: dict :param human_render_camera_configs: configurations of human rendering cameras to override any environment defaults. Similar usage as @sensor_configs. :type human_render_camera_configs: dict :param viewer_camera_configs: configurations of the viewer camera in the GUI to override any environment defaults. Similar usage as @sensor_configs. :type viewer_camera_configs: dict :param robot_uids: list of robots to instantiate and control in the environment. :type robot_uids: Union[str, BaseAgent, list[Union[str, BaseAgent]]] :param sim_config: Configurations for simulation if used that override the environment defaults. If given a dictionary, it can just override specific attributes e.g. ``sim_config=dict(scene_config=dict(solver_iterations=25))``. If passing in a SimConfig object, while typed, will override every attribute including the task defaults. Some environments define their own recommended default sim configurations via the ``self._default_sim_config`` attribute that generally should not be completely overriden. :type sim_config: Union[SimConfig, dict] :param reconfiguration_freq: How frequently to call reconfigure when environment is reset via `self.reset(...)` Generally for most users who are not building tasks this does not need to be changed. The default is 0, which means the environment reconfigures upon creation, and never again. :type reconfiguration_freq: int :param sim_backend: By default this is "auto". If sim_backend is "auto", then if ``num_envs == 1``, we use the PhysX CPU sim backend, otherwise we use the PhysX GPU sim backend and automatically pick a GPU to use. Can also be "physx_cpu" or "physx_cuda" to force usage of a particular sim backend. To select a particular GPU to run the simulation on, you can pass "physx_cuda:n" where n is the ID of the GPU, similar to the way PyTorch selects GPUs. Note that if this is "physx_cpu", num_envs can only be equal to 1. :type sim_backend: str :param render_backend: By default this is "gpu". If render_backend is "gpu" or it's alias "sapien_cuda", then we auto select a GPU to render with. It can be "sapien_cuda:n" where n is the ID of the GPU to render with. If this is "cpu" or "sapien_cpu", then we try to render on the CPU. If this is "none" or None, then we disable rendering. Note that some environments may require rendering functionalities to work. Moreover it is sometimes difficult to determine before running an environment if your machine can render or not. If you encounter some issue with rendering you can first try to double check your NVIDIA drivers / Vulkan drivers are setup correctly. If you don't need to do rendering you can simply disable it by setting render_backend to "none" or None. :type render_backend: str :param parallel_in_single_scene: By default this is False. If True, rendered images and the GUI will show all objects in one view. This is only really useful for generating cool videos showing all environments at once but it is not recommended otherwise as it slows down simulation and rendering. :type parallel_in_single_scene: bool :param enhanced_determinism: By default this is False and env resets will reset the episode RNG only when a seed / seed list is given. If True, the environment will reset the episode RNG upon each reset regardless of whether a seed is provided. Generally enhanced_determinisim is not needed and users are recommended to pass seeds into the env reset function instead. :type enhanced_determinism: bool .. py:attribute:: _UNDESIRED_CONTACT_LINK_NAMES :value: ['FR_thigh', 'RR_thigh', 'FL_thigh', 'RL_thigh'] .. py:attribute:: default_qpos