# `Monty.Frameworks.Models.SensorModules.DefaultMessageNoise`
[🔗](https://github.com/d-led/ex.tbp.monty/blob/v0.1.0/packages/ex_tbp_monty_core/lib/monty/frameworks/models/sensor_modules/default_message_noise.ex#L1)

The noise layer a config asks for with `noise_params`.

Mirrors `tbp/monty/frameworks/models/sensor_modules.py::DefaultMessageNoise`.
The parameters say how much to move each thing:

    noise_params:
      features:
        principal_curvatures_log: [0.1, 0.1]
        pose_vectors: 2.0        # degrees
      location: 0.001            # metres

A real-valued feature gets Gaussian noise of that standard deviation added to
it; a boolean flips with that *probability*; a hue is clipped back into
`[0, 1]` after the noise because there is no colour outside it. A
`pose_vectors` is not nudged component by component — that would stop the three
directions being a frame — but turned by a small sampled rotation.

Features are only noised when the percept carries features at all: a step that
is a location and nothing else is not worth learning from, and Monty does not
pretend otherwise.

The draws are NumPy's and come from the episode's one stream, because in Monty
they do: `ctx.rng` is a single `RandomState` that every module shares, so a
noised percept moves the numbers the motor system draws next. Drawing them from
a stream of the sensor's own would leave the episode's stream where it was, and
every later draw of the step would then belong to a different experiment.

# `t`

```elixir
@type t() :: %Monty.Frameworks.Models.SensorModules.DefaultMessageNoise{
  noise_params: map()
}
```

# `new`

```elixir
@spec new(map()) :: t()
```

---

*Consult [api-reference.md](api-reference.md) for complete listing*