Training a policy (library)

Training uses physicalai.train.Trainer (library/src/physicalai/train/trainer.py, a lightning.Trainer subclass) with a Policy and a DataModule. The library deliberately supports two equal entry points:

• CLI — physicalai fit (and validate, test, predict): jsonargparse YAML under library/configs/, overrides on the command line; checkpoints under experiments/{name}/version_N/ by default. See library/docs/how-to/training/cli.md.
• 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 library/docs/getting-started/quickstart.md and library/docs/explanation/trainer/README.md.

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 (see cli/_dispatch.py); validate/test/predict additionally take --ckpt_path. When a task is about library behavior rather than shell usage, prefer the Python API path first and then verify CLI parity if the change is user-facing.

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…).