|
| 1 | +# Sim-to-Real Transfer |
| 2 | +This page covers the randomization techniques to narrow the reality gap of our robotics simulation. These techniques, which concerns about [visual observations](#visuals), [system dynamics](#dynamics), and [sensors](#sensors), are employed to improve the efficacy of transferring our simulation-trained models to the real world. |
| 3 | + |
| 4 | + |
| 5 | +## Visuals |
| 6 | + |
| 7 | +It is well shown that randomizing the visuals in simulation can play an important role in sim2real applications. **robosuite** provides various `Modder` classes to control different aspects of the visual environment. This includes: |
| 8 | + |
| 9 | +- `CameraModder`: Modder for controlling camera parameters, including FOV and pose |
| 10 | +- `TextureModder`: Modder for controlling visual objects' appearances, including texture and material properties |
| 11 | +- `LightingModder`: Modder for controlling lighting parameters, including light source properties and pose |
| 12 | + |
| 13 | +Each of these Modders can be used by the user to directly override default simulation settings, or to randomize their respective properties mid-sim. We provide [demo_domain_randomization.py](../demos.html#domain-randomization) to showcase all of these modders being applied to randomize an environment during every sim step. |
| 14 | + |
| 15 | + |
| 16 | +## Dynamics |
| 17 | + |
| 18 | +In order to achieve reasonable runtime speeds, many physics simulation platforms often must simplify the underlying physics model. Mujoco is no different, and as a result, many parameters such as friction, damping, and contact constraints do not fully capture real-world dynamics. |
| 19 | + |
| 20 | +To better compensate for this, **robosuite** provides the `DynamicsModder` class, which can control individual dynamics parameters for each model within an environment. Theses parameters are sorted by element group, and briefly described below (for more information, please see [Mujoco XML Reference](http://www.mujoco.org/book/XMLreference.html)): |
| 21 | + |
| 22 | +#### Opt (Global) Parameters |
| 23 | +- `density`: Density of the medium (i.e.: air) |
| 24 | +- `viscosity`: Viscosity of the medium (i.e.: air) |
| 25 | + |
| 26 | +#### Body Parameters |
| 27 | +- `position`: (x, y, z) Position of the body relative to its parent body |
| 28 | +- `quaternion`: (qw, qx, qy, qz) Quaternion of the body relative to its parent body |
| 29 | +- `inertia`: (ixx, iyy, izz) diagonal components of the inertia matrix associated with this body |
| 30 | +- `mass`: mass of the body |
| 31 | + |
| 32 | +#### Geom Parameters |
| 33 | +- `friction`: (sliding, torsional, rolling) friction values for this geom |
| 34 | +- `solref`: (timeconst, dampratio) contact solver values for this geom |
| 35 | +- `solimp`: (dmin, dmax, width, midpoint, power) contact solver impedance values for this geom |
| 36 | + |
| 37 | +#### Joint parameters |
| 38 | +- `stiffness`: Stiffness for this joint |
| 39 | +- `frictionloss`: Friction loss associated with this joint |
| 40 | +- `damping`: Damping value for this joint |
| 41 | +- `armature`: Gear inertia for this joint |
| 42 | + |
| 43 | +This `DynamicsModder` follows the same basic API as the other `Modder` classes, and allows per-parameter and per-group randomization enabling. Apart from randomization, this modder can also be instantiated to selectively modify values at runtime. A brief example is given below: |
| 44 | + |
| 45 | +```python |
| 46 | +import robosuite as suite |
| 47 | +from robosuite.utils.mjmod import DynamicsModder |
| 48 | +import numpy as np |
| 49 | + |
| 50 | +# Create environment and modder |
| 51 | +env = suite.make("Lift", robots="Panda") |
| 52 | +modder = DynamicsModder(sim=env.sim, random_state=np.random.RandomState(5)) |
| 53 | + |
| 54 | +# Define function for easy printing |
| 55 | +cube_body_id = env.sim.model.body_name2id(env.cube.root_body) |
| 56 | +cube_geom_ids = [env.sim.model.geom_name2id(geom) for geom in env.cube.contact_geoms] |
| 57 | + |
| 58 | +def print_params(): |
| 59 | + print(f"cube mass: {env.sim.model.body_mass[cube_body_id]}") |
| 60 | + print(f"cube frictions: {env.sim.model.geom_friction[cube_geom_ids]}") |
| 61 | + print() |
| 62 | + |
| 63 | +# Print out initial parameter values |
| 64 | +print("INITIAL VALUES") |
| 65 | +print_params() |
| 66 | + |
| 67 | +# Modify the cube's properties |
| 68 | +modder.mod(env.cube.root_body, "mass", 5.0) # make the cube really heavy |
| 69 | +for geom_name in env.cube.contact_geoms: |
| 70 | + modder.mod(geom_name, "friction", [2.0, 0.2, 0.04]) # greatly increase the friction |
| 71 | +modder.update() # make sure the changes propagate in sim |
| 72 | + |
| 73 | +# Print out modified parameter values |
| 74 | +print("MODIFIED VALUES") |
| 75 | +print_params() |
| 76 | + |
| 77 | +# We can also restore defaults (original values) at any time |
| 78 | +modder.restore_defaults() |
| 79 | + |
| 80 | +# Print out restored initial parameter values |
| 81 | +print("RESTORED VALUES") |
| 82 | +print_params() |
| 83 | +``` |
| 84 | + |
| 85 | +Running [demo_domain_randomization.py](../demos.html#domain-randomization) is another method for demo'ing (albeit an extreme example of) this functionality. |
| 86 | + |
| 87 | +Note that the modder already has some sanity checks in place to prevent presumably undesired / non-sensical behavior, such as adding damping / frictionloss to a free joint or setting a non-zero stiffness value to a joint that is normally non-stiff to begin with. |
| 88 | + |
| 89 | + |
| 90 | +## Sensors |
| 91 | + |
| 92 | +By default, Mujoco sensors are deterministic and delay-free, which is often an unrealistic assumption to make in the real world. To better close this domain gap, **robosuite** provides a realistic, customizable interface via the [Observable](../source/robosuite.utils.html#module-robosuite.utils.observables) class API. Observables model realistic sensor sampling, in which ground truth data is sampled (`sensor`), passed through a corrupting function (`corrupter`), and then finally passed through a filtering function (`filter`). Moreover, each observable has its own `sampling_rate` and `delayer` function which simulates sensor delay. While default values are used to instantiate each observable during environment creation, each of these components can be modified by the user at runtime using `env.modify_observable(...)` . Moreover, each observable is assigned a modality, and are grouped together in the returned observation dictionary during the `env.step()` call. For example, if an environment consists of camera observations and a single robot's proprioceptive observations, the observation dict structure might look as follows: |
| 93 | + |
| 94 | +```python |
| 95 | +{ |
| 96 | + "frontview_image": np.array(...), # this has modality "image" |
| 97 | + "frontview_depth": np.array(...), # this has modality "image" |
| 98 | + "robot0_joint_pos": np.array(...), # this has modality "robot0_proprio" |
| 99 | + "robot0_gripper_pos": np.array(...), # this has modality "robot0_proprio" |
| 100 | + "image-state": np.array(...), # this is a concatenation of all image observations |
| 101 | + "robot0_proprio-state": np.array(...), # this is a concatenation of all robot0_proprio observations |
| 102 | +} |
| 103 | +``` |
| 104 | + |
| 105 | +Note that for memory efficiency the `image-state` is not returned by default (this can be toggled in `robosuite/utils/macros.py`). |
| 106 | + |
| 107 | +We showcase how the `Observable` functionality can be used to model sensor corruption and delay via [demo_sensor_corruption.py](../demos.html#sensor-realism). We also highlight that each of the `sensor`, `corrupter`, and `filter` functions can be arbitrarily specified to suit the end-user's usage. For example, a common use case for these observables is to keep track of sampled values from a sensor operating at a higher frequency than the environment step (control) frequency. In this case, the `filter` function can be leveraged to keep track of the real-time sensor values as they're being sampled. We provide a minimal script showcasing this ability below: |
| 108 | + |
| 109 | +```python |
| 110 | +import robosuite as suite |
| 111 | +import numpy as np |
| 112 | +from robosuite.utils.buffers import RingBuffer |
| 113 | + |
| 114 | +# Create env instance |
| 115 | +control_freq = 10 |
| 116 | +env = suite.make("Lift", robots="Panda", has_offscreen_renderer=False, use_camera_obs=False, control_freq=control_freq) |
| 117 | + |
| 118 | +# Define a ringbuffer to store joint position values |
| 119 | +buffer = RingBuffer(dim=env.robots[0].robot_model.dof, length=10) |
| 120 | + |
| 121 | +# Create a function that we'll use as the "filter" for the joint position Observable |
| 122 | +# This is a pass-through operation, but we record the value every time it gets called |
| 123 | +# As per the Observables API, this should take in an arbitrary numeric and return the same type / shape |
| 124 | +def filter_fcn(corrupted_value): |
| 125 | + # Record the inputted value |
| 126 | + buffer.push(corrupted_value) |
| 127 | + # Return this value (no-op performed) |
| 128 | + return corrupted_value |
| 129 | + |
| 130 | +# Now, let's enable the joint position Observable with this filter function |
| 131 | +env.modify_observable( |
| 132 | + observable_name="robot0_joint_pos", |
| 133 | + attribute="filter", |
| 134 | + modifier=filter_fcn, |
| 135 | +) |
| 136 | + |
| 137 | +# Let's also increase the sampling rate to showcase the Observable's ability to update multiple times per env step |
| 138 | +obs_sampling_freq = control_freq * 4 |
| 139 | +env.modify_observable( |
| 140 | + observable_name="robot0_joint_pos", |
| 141 | + attribute="sampling_rate", |
| 142 | + modifier=obs_sampling_freq, |
| 143 | +) |
| 144 | + |
| 145 | +# Take a single environment step with positive joint velocity actions |
| 146 | +arm_action = np.ones(env.robots[0].robot_model.dof) * 1.0 |
| 147 | +gripper_action = [1] |
| 148 | +action = np.concatenate([arm_action, gripper_action]) |
| 149 | +env.step(action) |
| 150 | + |
| 151 | +# Now we can analyze what values were recorded |
| 152 | +np.set_printoptions(precision=2) |
| 153 | +print(f"\nPolicy Frequency: {control_freq}, Observable Sampling Frequency: {obs_sampling_freq}") |
| 154 | +print(f"Number of recorded samples after 1 policy step: {buffer._size}\n") |
| 155 | +for i in range(buffer._size): |
| 156 | + print(f"Recorded value {i}: {buffer.buf[i]}") |
| 157 | +``` |
0 commit comments