OpenPI: Run a Robot Model and Keep Experiment Notes
Run the documented OpenPI example without a robot, understand what it tests, and keep the model, environment and observations needed to repeat it.
Updated 5 min read
OpenPI is Physical Intelligence’s public repository of robot models and supporting code. Its Simple Client example (opens in a new tab) lets you test model inference, meaning generating actions from observations, without connecting a robot. Start with that small example and record exactly what ran. Tools like fenbs can keep your own experiment notes so a later session starts with the same evidence.
The useful first result is modest: you understand how the documented client and policy server work together in your environment. This guide follows the published commands; it does not report an experiment performed here or claim that a successful example makes a physical robot safe to operate.
What should you check before starting?
Begin with Installation and Model Checkpoints in the official OpenPI README (opens in a new tab). The repository is tested on Ubuntu 22.04, and the maintainers say other operating systems are not currently supported. Check its hardware guidance for your intended workload before downloading models.
Inference and fine-tuning have different resource requirements. Inference runs a saved model; fine-tuning changes a model using training data. A machine suitable for the first job is not automatically suitable for the second. Use the README’s current memory table instead of treating a GPU model name as a complete compatibility check.
- Choose the no-robot Simple Client example as the first test. Leave physical hardware out of this initial check.
- Check the supported operating system, NVIDIA hardware and available GPU memory against the README.
- Prepare the documented Linux environment and uv, the Python dependency tool used by the repository.
- Record the repository revision, operating system and GPU before you make changes, so the starting point is clear.
How do you install the documented environment?
The Installation section gives the following clone command. Run it in the supported Linux environment, then open the downloaded openpi directory before running the two dependency commands. Preserve the command text in your notes alongside any error you encounter.
git clone --recurse-submodules git@github.com:Physical-Intelligence/openpi.git
GIT_LFS_SKIP_SMUDGE=1 uv sync GIT_LFS_SKIP_SMUDGE=1 uv pip install -e .
Finish the installation before changing model settings or trying other examples. If dependency setup fails, that is an installation result, not evidence that the model cannot perform a task. Separating those stages gives you a much smaller problem to investigate and a clearer account of what you have actually tested.
How do you run the Simple Client example?
The Simple Client README documents a policy server and a separate client with matching DROID settings. Use two terminals in the prepared environment. Keep both outputs available: the client alone cannot explain a server that failed to load its policy.
uv run scripts/serve_policy.py --env DROID
uv run examples/simple_client/main.py --env DROID
For the client’s documented options, run the help command below. Keep the first attempt at the documented settings. If you change several options together, a different outcome will be difficult to attribute to any one change.
uv run examples/simple_client/main.py --help
Write down whether installation completed, the server started, the client connected and inference returned output. Those are separate observations. Do not replace them with “works” when the next reader needs to know which stage succeeded. A failed attempt is still useful if it identifies the last successful stage and preserves the relevant error.
What does a successful run actually prove?
A no-robot inference check does not demonstrate successful real-world manipulation. The main README distinguishes base checkpoints from robot-specific expert checkpoints and warns that adaptation may not work for a particular robot. Keep those boundaries attached to any result you share.
| What you observed | What you can reasonably record | What remains untested |
|---|---|---|
| Dependencies installed | The documented setup completed on the recorded machine. | Model inference and robot behavior. |
| Client received model output | The selected client and policy ran together in this example. | Physical task success or transfer to another robot. |
| A changed setting produced different output | The two recorded runs differed under the listed conditions. | Whether that change improves a real task. |
For a broader model-testing method, see AI model evaluation. The companion guide to Physical Intelligence’s pi0 owns the model explanation. This first run is about learning the example and making your observations repeatable.
What should you save, and what commonly goes wrong?
The README places downloaded checkpoints in ~/.cache/openpi by default and documents OPENPI_DATA_HOME for another location. A checkpoint cache preserves model files; it does not tell the story of an experiment. Record the identifier actually used and where your output lives separately.
- Environment: repository revision, operating system, GPU and relevant dependency setup.
- Model: checkpoint identifier, policy configuration and any settings changed from the example.
- Inputs: the selected example, its environment setting and the conditions you supplied.
- Observation: what completed, what failed, output locations and the exact error where useful.
- Next attempt: one change to try and the question that change is meant to answer.
Check mismatched example settings, unsupported environments and workload requirements before drawing conclusions about model quality. If you move into fine-tuning later, preserve earlier runs rather than casually adding an overwrite option. You need a comparison you can inspect, including disappointing results.
Keep that short explanation with your own research in fenbs. The wider AI model guides cover other model choices; self-hosted language models and AI API services answer different deployment questions.
Never lose the work you did in an AI session
After a useful AI session, save it in fenbs: the key observations, findings, research and context. Then carry on from exactly where you left off, on any device and in any other AI. The next AI you connect reads it at the start of the session, so you never have to explain the same problem again.
Create a free accountFree for up to 5 people and 50 open tasks · No credit card · Works with Claude, ChatGPT, Cursor and more
How to keep your experiment notes with fenbs
Keep enough to carry on from exactly where you left off, on any device and with another AI. The record is your account of the experiment; OpenPI does not document a native fenbs connection or an automatic prose notebook.
- Create a free account. Give your experiment a name you will recognize later.
- Save the public instructions you followed, the model identifier, the machine details and the example settings.
- Write what you saw and where the output is stored. Mark anything you did not test, especially physical robot behavior.
- Before you stop, write the next small check. When you return, ask your connected assistant to read those notes before helping with the next attempt.
fenbs is useful for your research and experiment notes. It does not run OpenPI, host model checkpoints or replace a robotics test environment. Keep the large files and execution tools where they belong, and save the explanation that makes the next session useful.