pi05-droid: pi 0.5 DROID, the DROID-tuned pi 0.5 checkpoint from Physical Intelligence, documented as a metered action lane

pi05-droid is this platform's name for a metered lane serving the DROID tune of pi 0.5, the open-weights vision-language-action model from Physical Intelligence shipped in September 2025. The tune is real, public, and downloadable today. Its row sits in the platform's model data, behind the public list, rate set, nothing answering. The family head, the pi05 page, carries what pi 0.5 is and how it differs from pi 0. This page owns the DROID side: the rig, the menu, the cameras, the latency band.

Last verified: 2026-10-05

What it is

The pi05_droid checkpoint is an expert tune of pi 0.5: the publisher fine-tuned the base model on the DROID dataset, a large public collection of recorded arm work. The checkpoint table in the openpi repository describes the row as fast inference and good language-following, built with knowledge insulation. The action expert's learning signal stays out of the vision-language backbone, so the backbone keeps its scene and language knowledge. What matters here: the repository calls this one its strongest generalist DROID policy, based on the public RoboArena benchmark.

The name map: pi0.5 DROID, pi05_droid, and F-Droid

The collision earns its row: autocomplete for pi0.5 droid collapses into Android-store questions.

What DROID is: a rig, not a robot brand

DROID stands for Distributed Robot Interaction Dataset. The DROID paper (2024) describes the collection: 76,000 recorded runs, 350 hours, 564 scenes, 84 tasks, 50 collectors, 12 months, three continents. Every recording came off one standardized rig, and the rig shopping list is public. The rig: a Franka arm (Emika Panda or Research 3), a Robotiq 2F-85 gripper, two ZED 2 stereo cameras outside, a ZED Mini on the wrist, a small industrial computer, and a control laptop. Parts run roughly 20,000 to 46,000, per that list, updated around September 2025.

One line in that shopping list matters more than the prices: a strong GPU in the laptop is only needed if you skip remote inference. The publisher's instructions take that option. The model runs as a policy server on a second machine; the control laptop queries it. That brain-leaves-the-robot split is the publisher's own, and the exact shape of a hosted lane. The SO-101 cloud brain guide walks the pattern on a low cost arm.

Posture once more: not on the public list. The models index is the live catalog, and the VLA category page covers the family.

Use cases

Zero-shot tabletop pick and place. Two camera views and a sentence in, joint commands out, for simple tabletop work. The instructions claim wide tolerance across environments, camera positions, and lighting, with no careful control of camera angle or placement needed. In the publisher's words, "the policy is fairly robust in our experience".

Language-followed rerouting. Good language-following is the checkpoint table's pitch for this tune: the task sentence is read, not matched. The same table notes the older pi0-DROID baseline as weaker at language, the practical reason this tune exists.

A starting point for your own DROID data. Record on your rig, then fine-tune from this checkpoint. The publisher's training notes give two paths: a small custom dataset of tens of demonstrations converts to the LeRobot format and trains with a ready config. Full DROID training is another matter: about 1.8 TB on disk, and roughly two days on eight H100 GPUs per pass. The same notes say plain that low-rank adapter training underperformed on this path.

Where it is the wrong tool: fast reactive work and complex manipulation. In the instructions' words, the policy is far from perfect and will fail on more complex tasks, though it usually makes a decent effort.

The camera and state contract

Two views drive the model: one external camera, chosen left or right, plus the wrist camera. The rig carries two outside ZED 2 cameras, so you pick the better side. ZED Explorer, the setup tool, lists camera IDs and shows the live picture. Check that the outside view sees every object the task touches.

The state is the arm's joint state, sent with every call. Actions come back as a chunk of future joint commands. One detail matters to driver authors. The released tune was trained on joint velocity actions. The publisher's open training recipe switched to joint positions, which fit simulation evaluation. Know which space your driver consumes. Norm stats translate output into your robot's units; wrong stats produce wrong motion. The lane returns the stats it applied with every answer.

The checkpoint menu

The DROID tune sits in a family, and the menu lives in one repository table:

The repository frames the choice honestly: expert checkpoints are meant to run directly on the target robot, and may or may not work on yours. Its counterweight: the publisher found some, especially the DROID checkpoint, to generalize quite broadly in practice. The rule: close to a Franka rig with two cameras, run the DROID tune. With your own demos, start from the base. The LIBERO sibling has its own page; the family page carries the map.

Latency to expect

The publisher's troubleshooting table gives the band: 0.5 to 1 second per action chunk is normal; a cabled connection for the control laptop reduces latency. Read any latency claim against two units. A chunk is the batch one call returns. A step is one command inside it. Pages mix them. The family page carries the timing breakdown. The lane's contract follows the same shape: one call, one chunk, the robot runs it while the next computes.

API usage

The lane's contract speaks the platform's action route: POST /v1/action, a Bearer key from the console, multipart form data in, JSON out. The model id is pi05-droid.

One served request returns three things. actions is the action chunk, a list of joint commands in the checkpoint's own shape. normalization is the norm stats the lane applied, untouched; your driver converts back to your units. usage is ours: the call count and cost. Metering is per call. One served request is one billed call. A refused request bills nothing. The prepaid wallet is the spending stop. Every field, error code, and limit lives in the run-action reference.

Metering, as designed:

The dash is deliberate: the rate publishes with the row, not before. It is set in the platform's model data, this page's search listing carries it, and the pricing page renders rate cards for the rows it lists.

Calls to this alias answer a plain 404 today, and a client written against this shape is testable now. A busy lane answers with a named 429 and a retry hint, never a silent failure, unbilled.

curl

curl -X POST "https://api.ironstratum.com/v1/action" \
  -H "Authorization: Bearer $KEY" \
  -F "model=pi05-droid" \
  -F "instruction=pick up the apple and put it on the plate" \
  -F 'state=[0.0, 0.12, -0.4, 0.0, 0.5, 0.1, 0.0]' \
  -F "image=@outside.jpg" \
  -F "image=@wrist.jpg"

python

import os
import requests

state = [0.0, 0.12, -0.4, 0.0, 0.5, 0.1, 0.0]  # your arm's joint state

resp = requests.post(
    "https://api.ironstratum.com/v1/action",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    data={
        "model": "pi05-droid",
        "instruction": "pick up the apple and put it on the plate",
        "state": "[" + ", ".join(str(s) for s in state) + "]",
    },
    files=[
        ("image", ("outside.jpg", open("outside.jpg", "rb"), "image/jpeg")),
        ("image", ("wrist.jpg", open("wrist.jpg", "rb"), "image/jpeg")),
    ],
    timeout=30,
)
resp.raise_for_status()

answer = resp.json()
chunk = answer["actions"]         # the action chunk: future joint commands
stats = answer["normalization"]   # the norm stats this lane applied
print("commands in this chunk:", len(chunk))
print("cost of this call:", answer["usage"]["cost"])

lerobot

A rig already recording in the LeRobot format speaks this checkpoint's vocabulary. The port maps the two views and the joint state onto observation keys, so a recorded dataset carries the same fields the route takes. Per the LeRobot pi 0.5 docs, the port trains with quantile statistics, so datasets ship q01 and q99 fields; at serving, the normalization block carries the applied stats.

import os
import requests

session = requests.Session()
session.headers["Authorization"] = "Bearer " + os.environ["KEY"]

instruction = "pick up the apple and put it on the plate"
state = [0.0, 0.12, -0.4, 0.0, 0.5, 0.1, 0.0]  # same order on every call

running = True
while running:
    outside = read_camera("outside")  # your camera source, one frame
    wrist = read_camera("wrist")
    resp = session.post(
        "https://api.ironstratum.com/v1/action",
        data={
            "model": "pi05-droid",
            "instruction": instruction,
            "state": "[" + ", ".join(str(s) for s in state) + "]",
        },
        files=[
            ("image", ("outside.jpg", outside, "image/jpeg")),
            ("image", ("wrist.jpg", wrist, "image/jpeg")),
        ],
        timeout=30,
    )
    resp.raise_for_status()

    chunk = resp.json()["actions"]
    for deltas in chunk:
        state, running = arm_step(state, deltas)  # your arm driver goes here
        if not running:
            break

The loop is the whole pattern: send two frames, the sentence, and the joint state. Receive a chunk. Run it at your control rate. Send the new state with the next call. The contract is the form fields, not a client library.

Benchmarks

Every number below carries its owner and its date. None is this platform's own run: nothing serves under this alias today. Our numbers publish only after they are measured, with the method named. That refresh is later work, not a promise here.

The publisher's positioning, quoted. The openpi DROID instructions, read 2026-10-05, call this checkpoint "currently our strongest generalist DROID policy", based on the public RoboArena benchmark, a community arena that scores policies through real-world paired comparisons. The same instructions set the ceiling: tabletop pick-and-place widely, failure on more complex tasks.

A third-party real-robot table, where this tune loses. The MolmoAct2 paper from Ai2 (arXiv 2605.02881, Table 6, read 2026-10-05) ran zero-shot evaluation on a DROID setup, with novel objects and varied camera views, 15 trials per task:

Read that honestly: on this out-of-distribution suite the DROID tune averaged 45.2 percent and the newer model 87.1. The paper's authors built the suite and won it; that bias is worth naming, and the numbers remain the cleanest published real-robot set for this tune. A checkpoint averaging 45 percent on hard novel scenes is still a working tool for the simple tabletop tasks it was tuned for. Both facts sit on this page because both are true.

What is deliberately absent. The family page carries a dated community leaderboard read for the pi 0.5 family. This page does not repeat it. The one DROID-specific production figure circulating in community notes is conflicted between two dated readings, and the leaderboard itself was unreachable at draft time, so no number from it is quoted here.

Getting started

1. Read the primary sources. The openpi repository, its DROID instructions, and the DROID paper are all public. Every identity fact on this page traces to one of them.
2. Match the rig before the model. Two camera views, one outside and one on the wrist; a joint state you can send every control tick; a driver that knows whether it consumes joint velocities or joint positions. Those three lines decide whether this tune can run on your robot at all.
3. Write your client against the contract now. The tabs above are the shape the lane ships under; the run-action reference documents every field and error. The models index is the live catalog.
4. Watch the index, not this page. The models index is the live catalog. The VLA page introduces the rest of the action model set.
5. Open the console when you build. The signup flow opens the prepaid wallet, the keys, and the billing history. The loaded balance is the spend bound, and each key revokes alone.