trainnr

The Python package of trainnr, the physical AI platform for robot learning, run from your coding agent. It identifies a robot's dynamics from its telemetry, generates datasets, trains policies, evaluates them with exact confidence intervals, exports and gates them for deployment in simulation, and checks new telemetry for drift. Every step is an MCP tool and every result is a hash-stamped record the next step cites. What runs today, and where, is in the repository's README.

The premise: the robot is an artifact, not an import. A robot enters as a bundle name@hash (canonical MJCF or a USD asset read by Newton, measured dynamics with intervals, provenance), and every stage codes against that bundle, never against an embodiment.

The architecture and its decisions: docs/22-pipeline-architecture.md; the loop this package serves: docs/76-the-loop.md.

Layout

Subpackages under trainnr/trainnr/, lowest layer first.

The layer rule, pinned by tests/test_layers.py inside the package and by tools/check-layers.py across packages: stats ← bundles, protocol ← evaluate ← physics, tasks, collect, robot ← envs ← tools. This package never imports trainnr_mjlab or the Studio.

Tasks

Registered task families (list_task_families lists them):

The SO-101 reach, lift, block-stack and tool-insert scenes and the ALOHA 2 transfer-cube scene are task builders in the same registry.

The command and the plugin doors

trainnr mcp        # serve the tools over stdio (what an agent's config runs)
trainnr studio     # launch the Studio on the current project
trainnr version    # the installed version

Six entry-point groups let a third party extend the platform from its own package, without a fork:

A seventh, trainnr.mcp_tools, lets another package add tools to the MCP server (register_plugin_tools).

Develop

Everything runs through uv, which provisions the interpreter too.

cd trainnr
uv run python -m unittest discover -s tests   # the suite; heavy parts skip without their extra
uvx ruff format --check . && uvx ruff check . # the same gate pre-commit runs

The base install is light on purpose: onnx and ONNX Runtime, which the deployment tools (export, gate, pre-flight) need with nothing else installed, and no more. The statistics and bundle layers are standard library only, so they are recomputable anywhere a report is audited. The stages that need more are extras (pyproject.toml, [project.optional-dependencies]):

Two more sets are dependency groups, not extras: their sources are a git URL or not on PyPI, so they are not published with the package and are installed from a checkout only ([dependency-groups]):

mjx and usd conflict (Newton's release and our engine pin disagree on mujoco-warp); a USD import happens once, at onboarding, and the bundle it writes runs on every extra. LeRobot wants Python 3.12 while sim is measured on 3.11, so training commonly lives in a second environment (.venv-train) beside the sim one.

On WSL2 the GPU routing and headless rendering variables live in one file, wsl.env (uv run --env-file wsl.env … or ../tools/wsl-run.sh); its header says what each line does. Harmless on native Linux, unnecessary on macOS and Windows.