tron2_openpi

What this repository provides

TRON2 OpenPI is described in its README as a TRON2 deployment focused derivative of the OpenPI project. It keeps the OpenPI policy serving and the pi0 and pi0.5 model stack, then adds TRON2 specific policy transforms, deployment configuration templates, and real robot client examples. The repository is meant to work together with a sibling runtime package called tron2_env, and the README is clear that this is an integration and deployment example, not a complete release of private checkpoints, datasets, low level robot SDKs, or local deployment profiles. Concretely, the code offers pi0.5 policy serving through a serve_policy script, TRON2 input and output transforms in a policies file, training and deployment config registrations, and TRON2 robot clients in an examples folder. There are public deployment templates, YAML driven task training, an optional bridge observation mode for images and state from TRON2 Bridge, an optional legacy RealSense observation mode, and an RTC deployment client with warmup, observation timeout recovery, queue diagnostics and optional action smoothing. An OpenPI client package sits under packages. The layout keeps tron2_openpi and tron2_env side by side, and the client adds the sibling source path at startup so it can import the runtime package without extra configuration. The project is positioned as an integration example, so it shows the wiring rather than shipping the private assets a production deployment would need.

What is intentionally excluded

The README lists what the repository does not ship, which is just as important for setting expectations. Model weights and checkpoint directories are not included, nor are training datasets, evaluation datasets, logs or benchmark results. Private local deployment files, credentials, real camera serial numbers, customer data and private local deployment profiles are excluded. The undeveloped low level robot transport is not part of the release, and neither is a safety certification for unattended robot operation. Because weights are absent, the README instructs users to download them from a linked model repository and then set the checkpoint path in the task server profile before running a robot. Example task resources are listed in a table with user guides, model weight links and public deploy profiles for tasks named Candy, Cloth and Sort, with weights hosted on Hugging Face and ModelScope. The separation keeps the public repo focused on deployment plumbing while the heavy assets stay in external model repositories that the user must fetch separately. This boundary is stated up front so no one mistakes the repository for a turnkey robot product. By stating up front what is missing, the README sets correct expectations and steers users to the external model repositories for the heavy files.

Deployment and configuration

Deployment uses two profiles per task: a server profile that names the model checkpoint, prompt, policy overrides and server port, and a client profile that names the policy server address, robot endpoint, observation source, camera or bridge settings, execution loop and RTC settings. The README provides minimal server and client examples and explains fields such as policy config, repo id, checkpoint dir, default prompt, observation source, state dim, fps, publish rate, max steps and robot IP. The client can run in non RTC mode with a basic client script or in RTC mode with a dedicated RTC client that warms up the model, seeds the action queue, retries short observation timeouts, records queue diagnostics, and can apply optional client side action smoothing. Running the policy server starts from a profile such as candy_server, and the RTC client reads timing values like execution horizon and delay from the YAML. The README warns that the robot should be in its initial state before the client starts, and that the workspace in front should be kept clear. It also notes that some runtime links may lack authentication or TLS, so the policy server and robot control must stay on a controlled local network.

Training, safety and licensing

Training a new TRON2 task starts from a YAML entry point that points LeRobot at a dataset root, computes normalization statistics, then launches training, with an optional one command portable script for cloud or local paths. Real task YAML files are ignored by gitignore so only the example template stays public. The README sets a network deployment boundary: the policy server, robot control and bridge observation paths must run only on a controlled robot LAN reachable by authorized systems, never exposed to the internet or an untrusted shared network. It adds safety notes that real robot clients need a trained operator present with emergency stop access, and that verification of joints, endpoints and camera ordering should happen before executing policy actions. The source follows its file level licenses, and unless noted otherwise project source is provided under the Apache License 2.0, while third party source stays under the licenses recorded in the notices file. A SECURITY.md file covers vulnerability reporting and the full deployment boundary. The repository is published under the Apache License 2.0 and its most recent commit was on 2026-08-26. The safety and network sections make clear that running policies on a robot is a controlled activity, not something to expose on a public network.

Editorial conclusion

TRON2 OpenPI is a deployment focused derivative of the OpenPI project for the LimX TRON2 robot, and it is published under the Apache License 2.0 with the source snapshot dated to its most recent commit on 2026-08-26.