Monty. Frameworks. Models. MotorPolicies. MotorPolicy behaviour
(ExTbpMonty.Core v0.1.0)
Copy Markdown
View Source
The scaffold every motor policy is built on.
Mirrors tbp/monty/frameworks/models/motor_policies.py::MotorPolicy, which is
abstract and says only what a policy has to be able to do: act on a step,
start an episode over, and say what it knows.
Monty's load_state_dict is absent: loading a memento is how a checkpoint
restores a run, and this port's checkpoints are the studio's own records.
fixme_provide_motor_system is absent for the reason given in
...MotorPolicySelectors.MotorPolicySelector — the flag travels in the result.
Summary
Callbacks
The actions to take, whether learning modules should sit this step out, and the policy as it now stands.
What to do once a jump has landed with the object in view.
Starts the next episode: whatever the policy learned about this one goes.
What the policy recorded, for a run that wants to be read afterwards.
Types
@type t() :: struct()
Callbacks
@callback call( t(), ctx :: Monty.Context.t(), observations :: map() | nil, state :: Monty.Frameworks.Models.MotorSystemState.t(), percept :: Monty.Cmp.Message.t() | nil, goal :: Monty.Cmp.Goal.t() | nil ) :: {Monty.Frameworks.Models.MotorPolicies.MotorPolicyResult.t(), t()}
The actions to take, whether learning modules should sit this step out, and the policy as it now stands.
What to do once a jump has landed with the object in view.
Monty's _handle_successful_jump, which SurfacePolicy overrides; a policy
that does not care answers itself unchanged. The policy's own module is asked
for it (docs/monty-differences.md §2.9).
Starts the next episode: whatever the policy learned about this one goes.
What the policy recorded, for a run that wants to be read afterwards.