Training a policy (library)

Training uses physicalai.train.Trainer with a Policy and a DataModule. Both entry points work from an installed physicalai-train package; the Studio repository contains example configs and implementation code for reference:

• CLI — physicalai fit (and validate, test, predict): jsonargparse YAML in your project (examples live under Studio's library/configs/), overrides on the command line; checkpoints under experiments/{name}/version_N/ by default. See the CLI guide.
• Python API — construct Policy, LeRobotDataModule (or another datamodule), and Trainer, then trainer.fit(model=policy, datamodule=datamodule) (and validate / test / predict with a checkpoint as needed). See the quickstart.

The CLI subcommands and the Python API share the same objects; YAML class_path / init_args should match what you would wire in code.

The four CLI subcommands share the same --model / --data / --trainer.* shape; checkpoint arguments are namespaced by subcommand (--fit.ckpt_path to resume, --validate.ckpt_path, --test.ckpt_path, --predict.ckpt_path to evaluate). Prefer the Python API when the user needs a script, and the CLI for a repeatable YAML-driven run.

Anatomy of a config

A config wires three pieces via class_path / init_args:

• model — a Policy subclass (e.g. physicalai.policies.ACT).
• data — a DataModule, usually physicalai.data.lerobot.LeRobotDataModule with a repo_id (e.g. lerobot/pusht).
• trainer — Lightning args (max_epochs, accelerator, devices, callbacks…).