Modifiers¶
Modifiers post-process a term's input or output. Action modifiers sit between an action term and the actuator
and model its imperfections (delay, friction, effort clipping, motor strength, backlash, deadband); chain several
with Compose. On the observation side, noise models corrupt a term's output during training only, and the
observation modifiers in a term's modifiers=[...] list (a moving average, a delay) run in every mode. The
actions guide and observations guide show them in
context.
from eden.managers.modifiers.actions.actuators import ActionDelay, Compose
from eden.managers.modifiers.observations.noise import UniformNoise
Base classes and registries¶
Base classes and registries for manager term modifiers.
Attributes¶
NOISE_MODEL_REGISTRY
module-attribute
¶
NOISE_MODEL_REGISTRY = TermRegistry('NOISE_MODEL', NoiseModel, populated_by=('eden.managers.modifiers.observations',))
ACTION_MODIFIER_REGISTRY
module-attribute
¶
ACTION_MODIFIER_REGISTRY = TermRegistry('ACTION_MODIFIER', ActionModifier, populated_by=('eden.managers.modifiers.actions',))
OBSERVATION_MODIFIER_REGISTRY
module-attribute
¶
OBSERVATION_MODIFIER_REGISTRY = TermRegistry('OBSERVATION_MODIFIER', ObservationModifier, populated_by=('eden.managers.modifiers.observations',))
Classes¶
NoiseModel
¶
NoiseModel(env: EnvBase, options: _TermOptionsT)
Bases: ConfigurableTermBase[NoiseOptions]
Base class for noise models applied to observation terms.
Source code in eden/managers/base.py
Attributes¶
ActionModifier
¶
ActionModifier(env: EnvBase, options: _TermOptionsT)
Bases: ConfigurableTermBase[ActionModifierOptions]
Base class for composable action modifiers.
Action modifiers intercept and transform processed actions (target
positions/velocities) and/or control torques. They are designed to be
composed together using :class:~eden.managers.modifiers.actions.actuators.Compose.
Subclasses override any of three hooks, which run at two different rates:
modify_processed_action: once per control step, from the controller'scompute(). Its output isprocessed_action— the command a deployment sends.modify_applied_target: once per physics step (sim_dt), from the controller'sapply_actions(), on the command the actuator acts on (e.g. a delay).modify_ctrl_torque: once per physics step, on the torque an explicit controller computed.
Source code in eden/managers/base.py
Methods:¶
build
¶
build(num_envs: int, device: str, entity: 'Entity' | None = None, dofs_idx_local: Tensor | None = None) -> None
Initialize internal buffers, called by the owning action term after the entity is resolved.
| PARAMETER | DESCRIPTION |
|---|---|
num_envs
|
Number of parallel environments.
TYPE:
|
device
|
Torch device string.
TYPE:
|
entity
|
The entity being controlled. Needed by state-dependent modifiers.
TYPE:
|
dofs_idx_local
|
Local DOF indices being controlled.
TYPE:
|
Source code in eden/managers/modifiers/base.py
compute
¶
modify_processed_action
¶
Transform target positions/velocities before PD control. Default is identity.
Runs once per control step, from the controller's compute(); what it returns becomes
processed_action.
Source code in eden/managers/modifiers/base.py
modify_applied_target
¶
Transform the command the actuator acts on during this physics step. Default is identity.
Runs once per physics step (sim_dt) — decimation times per control step — from the
controller's apply_actions(), on the controller's whole command (processed_action,
both halves of a position+velocity one), after every modify_processed_action and before
the control law. A stateful override may count on exactly one call per physics step.
processed_action itself is left alone, and a deployment sends that and never calls
apply_actions(), so what this hook does stays in simulation — the right place for a
model of the robot's own latency, which the hardware already has.
Source code in eden/managers/modifiers/base.py
modify_ctrl_torque
¶
Transform computed torques after PD control. Default is identity.
pos_err (target - current joint position) is supplied by PD-position
controllers for modifiers that need it (e.g. position deadbands); it is
None for velocity-only controllers.
Source code in eden/managers/modifiers/base.py
get
¶
get(cls: type) -> ActionModifier | None
Return self if it is an instance of cls, else None.
:class:~eden.managers.modifiers.actions.actuators.Compose overrides this
to search its children. Callers that require the modifier to exist should
check for None and raise their own actionable error.
Source code in eden/managers/modifiers/base.py
ObservationModifier
¶
ObservationModifier(env: EnvBase, options: _TermOptionsT)
Bases: ConfigurableTermBase[ObservationModifierOptions]
Base class for a transform the observation manager applies to one term's output, frame by frame.
Listed on an observation term as modifiers=[...]. Each frame of the term goes through its
modifiers in list order, then noise, clip and scale, then the group's nan_policy, and last the
history window. Unlike noise, a modifier runs in every mode (training, eval, deployment). Each term
instance owns its modifier instances, so the same modifier on a policy and a critic copy of
a term keeps two independent states.
compute(frame) is a read, the same rule as for an observation term. The manager calls it
every time the observation is computed, which can be several times per control step: from
EnvBase.reset(), at phase 19, at phase 12 for the final-observation snapshot, from
get_observations(), and once at build to check the output. It returns the output for
frame given the modifier's current state and changes nothing.
advance(frame) is the commit. A stateful modifier (a filter, a delay) folds frame into
its state here. The manager calls it right after compute(frame), with the same frame, on the
pass that also pushes the history windows (compute(update_history=True)). That pass runs once
per control step (phase 19 of RLEnvBase.step, EnvBase.step, each deploy tick) and once per
EnvBase.reset(). A partial env.reset(envs_idx) therefore advances every env, the same way
it pushes every env's history window. So a modifier's state moves together with the history window,
and a delay of k is k pushes. A read that comes after the push and before the next step
(get_observations() between steps) applies the current frame once more, as the history
window's read does. With backfill, right after a reset, that gives the same value; otherwise it
runs one push ahead. A stateless modifier leaves advance as the no-op it is here.
Two rules keep reads and commits apart:
computereturns a tensor it does not write afterwards. The manager uses the output after callingadvance, so a view of state thatadvanceupdates in place would change under it. Return a fresh tensor, or.clone()the state.- Neither method writes into
frame, andadvancecopies what it keeps (self._last.copy_(frame), notself._last = frame).framemay be the raw output that another group's copy of the term also reads (the manager's cross-group cache), the term's own buffer, or a view of simulator state.
The other hooks: build(frame) allocates the state from a sample frame, before the env steps
(allocate here, then write in place: see "Term state lifecycle" in docs/guides/terms.md).
reset(envs_idx) restarts the rows of the envs whose episode restarts. It is called with the
same indices as the term's history window: None for every env, otherwise an index or
boolean-mask tensor to index with.
A modifier returns a frame of the shape, dtype and device it received. The manager checks this at
build, because scale, history and concatenation are all sized from the term's raw output.
Source code in eden/managers/base.py
Methods:¶
build
¶
Allocate per-env state sized like frame. No-op by default.
| PARAMETER | DESCRIPTION |
|---|---|
frame
|
A sample of the frames this modifier will receive,
TYPE:
|
Source code in eden/managers/modifiers/base.py
reset
¶
compute
¶
Return this frame's output given the current state, without changing the state or frame.
advance
¶
Fold frame into the state: called once per control step, right after compute(frame).
No-op by default, which is right for a stateless modifier.
Action modifiers¶
Composable action modifiers for action terms.
Action modifiers sit between action terms and the physics engine. They intercept and transform processed actions (target positions/velocities) and/or control torques via composable operations like clipping, delay, friction, and motor strength scaling.
Modifiers are designed to be composed together using :class:Compose,
similar to torchvision.transforms.Compose::
modifiers = Compose.configure(
modifiers=[
ActionDelay.configure(delay_range_steps=(1, 3)),
FrictionModel.configure(),
EffortClip.configure(),
]
)
Each modifier implements up to three hooks:
modify_processed_action: transforms the target positions/velocities once per control step, before PD control (e.g., envelope clip, backlash).modify_applied_target: transforms the command the actuator acts on, once per physics step (e.g., delay).modify_ctrl_torque: transforms the computed torques after PD control (e.g., friction, effort clipping, motor strength scaling).
Modifiers that need motor spec parameters (friction, T-N curve limits) read
them automatically from the entity's actuator spec (dofs_spec) at build
time. Explicit overrides can still be passed to use custom values.
Attributes¶
Classes¶
Compose
¶
Compose(env: EnvBase, options: ActionModifierOptions)
Bases: ActionModifier
Chains multiple action modifiers in sequence.
Each hook calls the children in list order, but the three hooks run at different points of a
step (see :class:~eden.managers.modifiers.ActionModifier): every modify_processed_action
once per control step in compute(), then every modify_applied_target once per physics
step in apply_actions(), then every modify_ctrl_torque after the control law. A
physics-step modifier such as :class:ActionDelay therefore acts after every control-step one
such as :class:EnvelopeClip, wherever each is listed. Listing it first logs a warning, since
the list would then read in a different order from the one that runs.
| PARAMETER | DESCRIPTION |
|---|---|
modifiers
|
Ordered sequence of modifier configurations.
TYPE:
|
Example
::
Compose.configure(
modifiers=[
ActionDelay.configure(delay_range_steps=(1, 3)),
FrictionModel.configure(),
EffortClip.configure(),
]
)
Source code in eden/managers/modifiers/actions/actuators.py
Attributes¶
modifiers
class-attribute
instance-attribute
¶
modifiers: tuple[ActionModifierOptions, ...] | list[ActionModifierOptions] = ()
Methods:¶
build
¶
modify_processed_action
¶
modify_applied_target
¶
modify_ctrl_torque
¶
Source code in eden/managers/modifiers/actions/actuators.py
get
¶
get(cls: type) -> ActionModifier | None
Return the first child modifier that is an instance of cls, or None.
Recurses into nested Compose chains via each child's get.
Source code in eden/managers/modifiers/actions/actuators.py
ActionDelay
¶
ActionDelay(env: EnvBase, options: ActionModifierOptions)
Bases: ActionModifier
Delays the command the actuator acts on by a random number of physics steps, drawn per episode.
The delay is applied at the actuator, once per physics step (sim_dt), not once per control
step: every apply_actions() pushes the controller's command into a history and drives the
actuator with the entry d physics steps old. So a latency shorter than a control step can be
expressed — at sim_dt=0.005, decimation=4, d=2 keeps the first two physics steps of
every control step on the previous command. This matches the physics-step unit of Isaac Lab's
DelayedPDActuatorCfg and mjlab's actuator delay_* fields.
Each env draws d uniformly from the inclusive range when it resets and keeps it until its
next reset. The range is given either in physics steps (delay_range_steps) or in seconds
(delay_range_s), but not both; with neither, commands pass through. After a reset the
history is backfilled with the first new command, so the actuator never acts on a command from
before the reset.
processed_action stays undelayed. It is the command the policy issued, and what a deployment
sends. The delay acts only inside apply_actions(), after every modify_processed_action
modifier wherever it sits in a :class:Compose chain (which warns when it is listed before one).
It models the simulated actuator's latency, and no deployment applies it: eden deploy never
calls apply_actions(), so a real robot has only its own latency, and the MuJoCo sim-to-sim
robot has none. A policy trained against a delay therefore runs there with less latency
than it trained with. With both ends of the range equal, the lag was fixed, so it expects that
lag on every step, and a MuJoCo sim-to-sim run does not reproduce it.
| PARAMETER | DESCRIPTION |
|---|---|
delay_range_steps
|
The inclusive delay range |
delay_range_s
|
The inclusive delay range in seconds instead. Converted to physics steps at build, so each
end must be a whole multiple of |
Source code in eden/managers/modifiers/actions/actuators.py
Attributes¶
delay_range_steps
class-attribute
instance-attribute
¶
resolved_range_steps
property
¶
The inclusive delay range in physics steps, resolved at build from whichever field was set.
delay_steps
property
¶
Each env's current delay in physics steps, shape (num_envs,); None when the range is (0, 0).
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
modify_applied_target
¶
FrictionModel
¶
FrictionModel(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Applies tanh-based static + viscous dynamic friction to torques.
By default, friction parameters are read from the entity's actuator
spec (dofs_spec). Explicit values override the entity defaults.
| PARAMETER | DESCRIPTION |
|---|---|
static_friction
|
Static friction coefficient per DOF, or a scalar broadcast. None → read from entity spec.
TYPE:
|
dynamic_friction
|
Dynamic (viscous) friction coefficient. None → read from entity spec.
TYPE:
|
friction_activation_vel
|
Velocity at which static friction is fully activated [rad/s]. None → read from entity spec.
TYPE:
|
friction_offset
|
Constant friction offset torque per DOF (or scalar broadcast).
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
friction_activation_vel
class-attribute
instance-attribute
¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
modify_ctrl_torque
¶
Source code in eden/managers/modifiers/actions/actuators.py
EffortClip
¶
EffortClip(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Clips torques to motor torque-speed (T-N) curve limits.
By default, T-N curve parameters are read from the entity's actuator
spec (dofs_spec). Explicit values override the entity defaults.
| PARAMETER | DESCRIPTION |
|---|---|
driving_torque_limit
|
Maximum torque when torque and velocity are in the same direction. None → read from entity spec.
TYPE:
|
braking_torque_limit
|
Maximum torque when torque and velocity are in opposite directions. None → read from entity spec.
TYPE:
|
full_torque_speed
|
Speed below which full torque is available [rad/s]. None → read from entity spec.
TYPE:
|
no_load_speed
|
Speed at which available torque drops to zero [rad/s]. None → read from entity spec.
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
driving_torque_limit
class-attribute
instance-attribute
¶
braking_torque_limit
class-attribute
instance-attribute
¶
full_torque_speed
class-attribute
instance-attribute
¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
modify_ctrl_torque
¶
Source code in eden/managers/modifiers/actions/actuators.py
MotorStrength
¶
MotorStrength(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Scales control torques by a motor strength multiplier.
| PARAMETER | DESCRIPTION |
|---|---|
motor_strength
|
Per-DOF multiplier, or a scalar broadcast to every controlled DOF.
TYPE:
|
Note
This modifier provides a deterministic motor strength multiplier. To randomize it, use the
:class:~eden.managers.terms.events.domain_rand.RandomizeMotorStrength event term instead.
Source code in eden/managers/base.py
Attributes¶
motor_strength_realized
property
¶
The realized per-env torque-scale buffer, shape (num_envs, n_dof).
Named *_realized rather than motor_strength to avoid shadowing the
motor_strength configuration field (the nominal value, exposed as
:attr:motor_strength_baseline).
motor_strength_baseline
property
¶
The configured nominal torque-scale row, shape (n_dof,) — the value reset restores.
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
modify_ctrl_torque
¶
TorqueOffset
¶
TorqueOffset(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Adds a constant offset to the control torques.
| PARAMETER | DESCRIPTION |
|---|---|
torque_offset
|
Per-DOF offset, or a scalar broadcast to every controlled DOF.
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
modify_ctrl_torque
¶
ConstantTorqueKick
¶
ConstantTorqueKick(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Adds a flat directional torque on top of computed control torque.
This acts like a minimum drive effort: when the joint has a nonzero position
error, the modifier adds torque_kick in the direction of that error. It
is useful for matching actuators that move sharply through small errors or
have firmware/static-friction compensation that a pure proportional term
cannot reproduce.
| PARAMETER | DESCRIPTION |
|---|---|
torque_kick
|
Nonnegative torque magnitude per DOF, or a scalar broadcast.
TYPE:
|
activation_epsilon
|
Position-error magnitude (rad) below which no torque kick is added.
This only applies when
TYPE:
|
direction_source
|
Direction signal for the torque kick.
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
reset
¶
reset(envs_idx: slice | Tensor | None = None) -> None
Source code in eden/managers/modifiers/actions/actuators.py
modify_ctrl_torque
¶
Source code in eden/managers/modifiers/actions/actuators.py
Deadband
¶
Deadband(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Zeroes PD control torque inside a position-error deadband.
No torque is applied when the instantaneous position error |pos_err|
is smaller than deadband_epsilon. Only applicable to PD-position controllers that pass
pos_err into :meth:modify_ctrl_torque — velocity-only controllers do
not and the modifier is a no-op there.
The threshold is stored as a per-env per-DOF tensor so it can be
domain-randomized (see :class:~eden.managers.terms.events.domain_rand.RandomizeDeadbandEpsilon).
| PARAMETER | DESCRIPTION |
|---|---|
deadband_epsilon
|
Position-error magnitude (rad) below which torque is zeroed. Per
:class:
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
modify_ctrl_torque
¶
Source code in eden/managers/modifiers/actions/actuators.py
GearBacklash
¶
GearBacklash(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Adds direction-dependent gear slop to position targets before PD control.
This models lost motion in the drivetrain, where the load settles on the
side of the gear gap selected by the latest commanded motion. After a
positive target move the effective motor-side target becomes
target + backlash; after a negative move it becomes
target - backlash. Small target changes below reversal_threshold do
not change the selected side, which prevents command noise from flipping the
gap state.
| PARAMETER | DESCRIPTION |
|---|---|
backlash
|
One-sided position offset in radians. A scalar broadcasts to all
controlled DOFs; an iterable must match
TYPE:
|
reversal_threshold
|
Minimum target-position change in radians required to select a new backlash side.
TYPE:
|
takeup_rate
|
Fraction of the remaining gap state to take up on each action update.
TYPE:
|
initial_side
|
Initial gap side on reset.
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
reset
¶
reset(envs_idx: slice | Tensor | None = None) -> None
Source code in eden/managers/modifiers/actions/actuators.py
modify_processed_action
¶
Source code in eden/managers/modifiers/actions/actuators.py
EnvelopeClip
¶
EnvelopeClip(env: EnvBase, options: _TermOptionsT)
Bases: ActionModifier
Clips target positions so PD torques stay within the motor torque-speed envelope.
Back-solves the motor torque-speed curve to find the range of target positions that yield feasible torques, then clips targets into that range. This ensures the PD controller never commands torques outside the motor's physical capability.
The torque-speed envelope is defined by four parameters::
Torque, N·m
^
Y2──────|
|──────────────Y1
| │\\
| │ \\
| │ \\
| | \\
--------+--------------|------> velocity, rad/s
X1 X2
Given current joint state (q, dq) and PD gains (kp, kd), the modifier computes the maximum and minimum feasible torques from the T-N curve, then back-solves for the corresponding target position bounds::
target_low = (tau_low + kd * dq) / kp + q
target_high = (tau_high + kd * dq) / kp + q
By default, T-N curve parameters are read from the entity's actuator
spec (dofs_spec). Explicit values override the entity defaults.
| PARAMETER | DESCRIPTION |
|---|---|
driving_torque_limit
|
(Y1) Maximum torque when torque and velocity are in the same direction. None → read from entity spec.
TYPE:
|
braking_torque_limit
|
(Y2) Maximum torque when torque and velocity are in opposite directions. None → read from entity spec.
TYPE:
|
full_torque_speed
|
(X1) Speed below which full torque is available [rad/s]. None → read from entity spec.
TYPE:
|
no_load_speed
|
(X2) Speed at which available torque drops to zero [rad/s]. None → read from entity spec.
TYPE:
|
Source code in eden/managers/base.py
Attributes¶
driving_torque_limit
class-attribute
instance-attribute
¶
braking_torque_limit
class-attribute
instance-attribute
¶
full_torque_speed
class-attribute
instance-attribute
¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/actions/actuators.py
reset
¶
reset(envs_idx: slice | Tensor | None = None) -> None
Source code in eden/managers/modifiers/actions/actuators.py
modify_processed_action
¶
Source code in eden/managers/modifiers/actions/actuators.py
Functions:¶
Observation noise¶
Observation noise modifiers (constant, uniform, Gaussian).
Attributes¶
Classes¶
ConstantNoise
¶
ConstantNoise(env: EnvBase, options: NoiseOptions)
Bases: NoiseModel
Source code in eden/managers/modifiers/observations/noise.py
UniformNoise
¶
UniformNoise(env: EnvBase, options: NoiseOptions)
Bases: NoiseModel
Source code in eden/managers/modifiers/observations/noise.py
Attributes¶
n_min
class-attribute
instance-attribute
¶
n_min: Tensor | float = ensure_tensor_on_device(self.n_min, device=self.device)
n_max
class-attribute
instance-attribute
¶
n_max: Tensor | float = ensure_tensor_on_device(self.n_max, device=self.device)
Methods:¶
compute
¶
Source code in eden/managers/modifiers/observations/noise.py
GaussianNoise
¶
GaussianNoise(env: EnvBase, options: NoiseOptions)
Bases: NoiseModel
Source code in eden/managers/modifiers/observations/noise.py
Attributes¶
mean
class-attribute
instance-attribute
¶
mean: Tensor | float = ensure_tensor_on_device(self.mean, device=self.device)
std
class-attribute
instance-attribute
¶
std: Tensor | float = ensure_tensor_on_device(self.std, device=self.device)
Methods:¶
compute
¶
Source code in eden/managers/modifiers/observations/noise.py
Functions:¶
ensure_tensor_on_device
¶
Ensure tensor is on the correct device, leave scalars unchanged.
Source code in eden/managers/modifiers/observations/noise.py
Temporal observation modifiers¶
Stateful observation modifiers that act across control steps: an exponential moving average and a delay.
Attributes¶
Classes¶
ExponentialMovingAverage
¶
ExponentialMovingAverage(env: EnvBase, options: ObservationModifierOptions)
Bases: ObservationModifier
Exponential moving average, updated once per control step.
y(t) = alpha * x(t) + (1 - alpha) * y(t - 1).
alpha is the weight of the newest frame, as in pandas' ewm(alpha=...). Some filter
libraries write the complement, so check that before porting a value. The term's frame must be
floating-point — the weights are held in its dtype, so an integer one would truncate them to zero;
:class:ObservationDelay is the modifier that carries any dtype.
A non-finite frame keeps its kind: an infinity entering the average stays an infinity, so a
clip on the term still bounds it — a raycast's +inf for "no hit" reaches the policy as the
clip's far end, not as a NaN that no clip bounds — and a NaN stays a NaN. Either one stays in the
average until the env resets. The group's nan_policy checks the term's output after its
modifiers, so it replaces what the policy receives but cannot clean the average itself. The one
frame that still averages to NaN is a component that sees both +inf and -inf, their
weighted sum being genuinely undefined.
| PARAMETER | DESCRIPTION |
|---|---|
alpha
|
Weight of the newest frame, in
TYPE:
|
backfill
|
What the average starts from after a reset (default True).
TYPE:
|
Source code in eden/managers/modifiers/observations/temporal.py
Attributes¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/observations/temporal.py
reset
¶
Source code in eden/managers/modifiers/observations/temporal.py
compute
¶
Source code in eden/managers/modifiers/observations/temporal.py
advance
¶
Source code in eden/managers/modifiers/observations/temporal.py
ObservationDelay
¶
ObservationDelay(env: EnvBase, options: ObservationModifierOptions)
Bases: ObservationModifier
Delivers the frame the term produced control_steps control steps earlier.
The delay is counted in pushes of the observation window (see
:class:~eden.managers.modifiers.base.ObservationModifier), which happen once per control step.
That is the same clock as history_length, so a delayed term with a history window holds the
delayed frames.
| PARAMETER | DESCRIPTION |
|---|---|
control_steps
|
How many control steps to delay by,
TYPE:
|
backfill
|
What is delivered while fewer than
TYPE:
|
Source code in eden/managers/modifiers/observations/temporal.py
Attributes¶
Methods:¶
build
¶
Source code in eden/managers/modifiers/observations/temporal.py
reset
¶
compute
¶
Functions:¶
See also¶
- Modifier options
- Domain-randomization events, several of which drive an action modifier