Monty.Frameworks.Models.MotorPolicySelectors.MotorPolicySelector behaviour (ExTbpMonty.Core v0.1.0)

Copy Markdown View Source

The motor system's question to a selector: given this step, what should move?

Mirrors tbp/monty/frameworks/models/motor_policy_selectors.py::MotorPolicySelector, which joins Monty's runtime interface and its experiment interface into one. A selector decides which policy acts — one policy always, or one of several depending on the goals that arrived — and answers the same MotorPolicyResult whatever it chose.

Two differences from Monty, both forced by values rather than pointers:

  • the selector is handed back along with the result, because choosing is also recording — Monty appends the chosen goal to itself — and a struct cannot be changed in place;
  • there is no fixme_provide_motor_system. Monty hands the selector the motor system only so the chosen policy can set motor_only_step on it; here that flag travels in the result, so the call and its name both go.

Summary

Callbacks

The actions to take this step, whether learning modules should sit it out, and the selector as it now stands.

Forgets everything the selector knows about the episode so far.

What the selector recorded, for a run that wants to be read afterwards.

Types

t()

@type t() :: struct()

Callbacks

call(t, ctx, observations, state, percept, goals)

@callback call(
  t(),
  ctx :: Monty.Context.t(),
  observations :: map() | nil,
  state :: Monty.Frameworks.Models.MotorSystemState.t(),
  percept :: Monty.Cmp.Message.t() | nil,
  goals :: [Monty.Cmp.Goal.t()]
) :: {Monty.Frameworks.Models.MotorPolicies.MotorPolicyResult.t(), t()}

The actions to take this step, whether learning modules should sit it out, and the selector as it now stands.

reset(t)

@callback reset(t()) :: t()

Forgets everything the selector knows about the episode so far.

state_dict(t)

@callback state_dict(t()) :: map()

What the selector recorded, for a run that wants to be read afterwards.