README.md

metadata

license: apache-2.0
tags:
  - robotics
  - vla
  - openpi
  - pi0
  - lerobot
  - manipulation
  - bimanual
library_name: openpi
pipeline_tag: robotics

openpi_lab — real-robot π₀ checkpoints + the datasets they were trained on

Two robots, each with its trained π₀ weights and the exact LeRobot dataset behind them.

G2 is the main release — trained, validated on hardware in four stages, and it completes its task closed-loop from live camera observations. Piper is a reference example: a second robot with a different arm count, action space and control rate, provided so the pipeline can be followed on a contrasting setup. It ships the checkpoints and data only; no evaluation results are claimed for it.

g2/model/        π₀, 30k steps            g2/dataset/     58 ep / 48,332 frames / 10 Hz
piper/model/pi0/     π₀,  30k steps       piper/dataset/  125 ep / 71,702 frames / 30 Hz
piper/model/pi05/    π₀.₅, 30k steps

	G2	Piper
Robot	AgiBot G2, dual 7-DOF arm	AgileX Piper, single 6-DOF arm
Action / state	16-D [L_j1..7, L_grip, R_j1..7, R_grip]	7-D [j1..j6, gripper]
Action space	absolute joint rad + boolean gripper	joint delta from episode start + absolute gripper (m)
Cameras	head + hand_left + hand_right	head + hand
Control rate	10 Hz	30 Hz
Chunk	50	16
Tasks	1 (Make a yogurt bowl with cereal and fruit.)	4 (pen→cup, carrot→bowl, blocks→drawer, stack bowls)

Download

hf download siyuhsu/openpi_lab --include "g2/model/*"       --local-dir ./g2_ckpt
hf download siyuhsu/openpi_lab --include "piper/model/pi0/*" --local-dir ./piper_pi0
hf download siyuhsu/openpi_lab --include "g2/dataset/*"     --local-dir ./g2_data

Serving

# G2
python examples/g2_dualarm/g2_serve_openpi.py --config pi0_g2_dualarm \
    --ckpt-dir ./g2_ckpt/g2/model --port 8000
# Piper
python examples/piper/code/piper_serve_openpi.py --config pi0_piper_4task \
    --ckpt-dir ./piper_pi0/piper/model/pi0 --port 8000

Each server publishes its deployment contract in the connect-time metadata (action_chunk_size, action_rate_hz, robot_servo_hz, action_space, reset_pose).

⚠️ Advance the action chunk at the DATASET rate, not the servo rate. G2 is 10 Hz, Piper is 30 Hz. Actions are absolute (G2) or delta-from-start (Piper) joint targets; stepping G2's chunk at 30 Hz would execute it 3× too fast.

Things that will bite you

• G2 gripper polarity is inverted between dataset and wire. In the dataset 1.0 = OPEN, 0.0 = CLOSED — the raw field is called gripper_closed and the name is backwards relative to the physical behaviour. Verified from physical semantics: in episode 27 the right gripper dim flips 1.0 → 0.0 at step 54, exactly as the arm reaches its deepest point (the grasp). On that robot's DDS tool wire the convention is the opposite again. Confirm your own wire convention before driving hardware.
• G2's right gripper position sensor is dead (constant 0.2173 in all 60 episodes), so both gripper dims come from the command boolean, not a sensor.
• G2 _rs10 = resampled to a uniform 10 Hz grid. Raw recordings are badly jittered — but the cause is the on-robot disk writer, not the cameras or the control loop (control runs at a steady 29.5–29.9 Hz; 60–65% of frames never reach disk). Naive contiguous re-indexing distorts episode duration by −18%…+35%; resampling is +0.06%.
• Do not JPEG-compress observations to save bandwidth. Measured on the G2 checkpoint, q92/q85 flips the gripper decision outright (|Δ| = 1.007 on a boolean dim, 3 of 6 trials) while joint dims move only ~2°. Mean error hides this completely.
• These policies are stochastic (flow matching): identical input gives joint outputs differing by ~1.2°. Repeated inference is not a determinism check.
• Piper's action is the recorded teleop target and leads the state by ~3 frames; G2's satisfies action[t] == state[t+1] exactly. Do not assume one convention for both.

Scope

Single scene per task, 58 (G2) / 125 (Piper) demonstrations. Expect brittleness outside the recorded prop layout.

Code

examples/g2_dualarm/ and examples/piper/ in the accompanying openpi fork, including the real-robot clients, the staged validation tooling and the hardware-verification scripts.