PyLabRobot
Use PyLabRobot's hardware-agnostic frontends, resource tree, trackers, and
device-specific backends to develop laboratory automation. Default to local
manifest validation, bookkeeping, and the software-only chatterbox backend.
Verified snapshot
- PyPI stable:
PyLabRobot==0.2.1, released 2026-03-23.
- Upstream requirement: Python >=3.9. This skill uses Python 3.11 for its
reproducible smoke tests.
/stable/ documentation identifies itself as 0.2.1. /dev/ and repository
main describe unreleased work and must not be assumed available in 0.2.1.
- Stable liquid-handler backends include
STARBackend, VantageBackend,
EVOBackend, OpentronsOT2Backend, and the offline
LiquidHandlerChatterboxBackend.
- PyLabRobot's GitHub Releases page has no 0.2.x software release entry; use
the PyPI history,
v0.2.1 tag, and changelog as release evidence.
Non-negotiable hardware boundary
Never connect to, initialize, home, move, heat, shake, spin, pump, open/close,
or otherwise command physical equipment automatically. Do not turn a simulation
plan into a live backend merely by changing an environment variable, config
value, or import.
Before any separately authorized live run, require a trained human to:
- Explicitly confirm the exact backend, device identity, firmware, transport,
deck, and protocol revision.
- Reconcile the physical deck against the resource tree, including carriers,
adapters, lids, plates, tip racks, waste, labware orientation, barcodes, and
every occupied coordinate.
- Verify calibration, teaching, motion envelopes, collision risks, gripper or
channel clearances, and all aspiration/dispense coordinates.
- Review source identity and actual fill volume, dead volume, destination
capacity, tip type/capacity/filter compatibility, channel mapping, units,
heights, rates, liquid class, blowout/mixing, and contamination boundaries.
- Confirm guards, doors, waste capacity, containment, emergency stop readiness,
PPE, biosafety/chemical controls, and a safe abort/recovery procedure.
- Approve a slow dry run or nonhazardous commissioning run when anything is
new or changed.
Tracker state is bookkeeping, not sensing. It cannot prove that liquid or a
tip is physically present. The Visualizer renders resource/tracker events; it
does not model physics. Chatterbox prints planned operations; it does not prove
calibration, reachability, collision freedom, liquid behavior, or device state.
Required intake
Do not guess any of these:
- Exact device model, installed options, firmware, computer/OS, and transport.
- Stable PyLabRobot version and required extras.
- Deck/deck origin, carriers, adapters, resource definitions, dimensions,
coordinates, orientations, and motion clearances.
- Plate/tube/reservoir capacities and dead volumes; initial physical volumes.
- Tip model, filter, fitting, capacity, rack state, channel count, and channel
mapping.
- Transfer units (
uL, mm, uL/s, s), heights, rates, mixing, air gaps,
blowout, liquid properties, and validated vendor liquid class.
- Contamination policy, controls, waste handling, operator interventions,
acceptance criteria, and recovery procedure.
If information is missing, produce an assumptions/blockers list and an offline
draft only.
Reproducible install
For offline API inspection and chatterbox simulation:
uv venv --python 3.11 .venv-pylabrobot
uv pip install --python .venv-pylabrobot/bin/python "PyLabRobot==0.2.1"
On Windows, use .venv-pylabrobot\Scripts\python.exe. Do not install hardware
extras until the user names the device and explicitly approves its transport
dependencies. Then inspect the matching stable device page before considering a
pin such as "PyLabRobot[serial]==0.2.1" or "PyLabRobot[usb]==0.2.1".
Offline-first workflow
Run from the repository root. Every bundled CLI uses strict, bounded UTF-8
JSON/CSV, local non-symlink paths, fixed allowlists, and JSON output. None can
select a live backend.
python3 skills/pylabrobot/scripts/validate_manifest.py \
--input tests/pylabrobot/fixtures/protocol_manifest.json
python3 skills/pylabrobot/scripts/check_deck_geometry.py \
--input tests/pylabrobot/fixtures/protocol_manifest.json
python3 skills/pylabrobot/scripts/plan_transfers.py \
--manifest tests/pylabrobot/fixtures/protocol_manifest.json \
--transfers tests/pylabrobot/fixtures/transfers.csv
python3 skills/pylabrobot/scripts/generate_simulation_plan.py \
--manifest tests/pylabrobot/fixtures/protocol_manifest.json \
--transfers tests/pylabrobot/fixtures/transfers.csv
python3 skills/pylabrobot/scripts/inspect_backends.py \
--expected-version 0.2.1 --strict
The geometry checker uses conservative static axis-aligned boxes; it is not a
motion planner. The transfer planner requires one new tip per row and checks
source/dead/destination volumes, tip capacity, wells, channels, heights, rates,
units, and allowlists. Review
assets/protocol-manifest.schema.json and the synthetic fixtures before making
a project-specific manifest.
Verified software-only example
The exact backend below is software-only. Do not substitute a hardware backend.
from pylabrobot.liquid_handling import LiquidHandler
from pylabrobot.liquid_handling.backends import LiquidHandlerChatterboxBackend
from pylabrobot.resources import (
Cor_96_wellplate_360ul_Fb,
PLT_CAR_L5AC_A00,
TIP_CAR_480_A00,
hamilton_96_tiprack_1000uL_filter,
set_tip_tracking,
set_volume_tracking,
)
from pylabrobot.resources.hamilton import STARLetDeck
set_tip_tracking(True)
set_volume_tracking(True)
deck = STARLetDeck()
tip_carrier = TIP_CAR_480_A00(name="tip_carrier")
tips = hamilton_96_tiprack_1000uL_filter(name="tips")
tip_carrier[0] = tips
plate_carrier = PLT_CAR_L5AC_A00(name="plate_carrier")
source = Cor_96_wellplate_360ul_Fb(name="source")
destination = Cor_96_wellplate_360ul_Fb(name="destination")
plate_carrier[0] = source
plate_carrier[1] = destination
deck.assign_child_resource(tip_carrier, rails=3)
deck.assign_child_resource(plate_carrier, rails=15)
source.get_well("A1").tracker.set_volume(100.0) # planned state, not sensing
lh = LiquidHandler(backend=LiquidHandlerChatterboxBackend(), deck=deck)
await lh.setup() # safe here only because the backend above is software-only
try:
await lh.pick_up_tips(tips["A1"])
await lh.aspirate(source["A1"], vols=[10.0])
await lh.dispense(destination["A1"], vols=[10.0])
await lh.return_tips()
finally:
await lh.stop()
API rules that prevent stale code
- Current names are
STARBackend, VantageBackend, EVOBackend, and
OpentronsOT2Backend; do not use stale STAR, TecanBackend,
OpentronsBackend, or ChatterboxBackend imports.
- Use
LiquidHandlerChatterboxBackend for generic offline liquid-handler
testing. ChatterBoxBackend is a separate legacy-named export; do not
conflate the two.
Visualizer(resource=...) is valid, followed by await vis.setup() and
await vis.stop(); it starts localhost HTTP/WebSocket servers and may open a
browser.
- There is no generic
from pylabrobot.liquid_handling import LiquidClass in
0.2.1. Stable liquid classes are vendor-specific, for example
pylabrobot.liquid_handling.liquid_classes.hamilton.HamiltonLiquidClass.
- Most frontend methods are async. Backend kwargs and capabilities are
vendor/model specific; a shared frontend does not imply identical behavior.
References
- Liquid handling — operations, tips, tracking,
liquid classes, units, and validation.
- Resources — decks, coordinates, plates, tip racks,
collisions, state, and serialization.
- Hardware backends — verified names,
support levels, capabilities, and live-run gate.
- Analytical equipment — plate readers
and scales.
- Material handling — pumps, heaters,
shakers, temperature control, storage, and centrifuges.
- Visualization — chatterbox, Visualizer,
localhost services, and simulation limits.
Dated upstream sources
Checked 2026-07-23:
Source: K-Dense-AI/scientific-agent-skills → skills/pylabrobot/SKILL.md
1---2name: pylabrobot3description: Develop and review PyLabRobot lab-automation resources, liquid-handling plans, offline simulations, and supported-device integrations. Use for PyLabRobot protocols or API questions; keep physical execution behind an explicit operator safety gate.4---5
6
7# PyLabRobot
8
9Use PyLabRobot's hardware-agnostic frontends, resource tree, trackers, and
10device-specific backends to develop laboratory automation. Default to local
11manifest validation, bookkeeping, and the software-only chatterbox backend.
12
13## Verified snapshot
14
15- PyPI stable: **`PyLabRobot==0.2.1`**, released **2026-03-23**.
16- Upstream requirement: **Python >=3.9**. This skill uses Python 3.11 for its
17 reproducible smoke tests.
18- `/stable/` documentation identifies itself as 0.2.1. `/dev/` and repository
19 `main` describe unreleased work and must not be assumed available in 0.2.1.
20- Stable liquid-handler backends include `STARBackend`, `VantageBackend`,
21 `EVOBackend`, `OpentronsOT2Backend`, and the offline
22 `LiquidHandlerChatterboxBackend`.
23- PyLabRobot's GitHub Releases page has no 0.2.x software release entry; use
24 the PyPI history, `v0.2.1` tag, and changelog as release evidence.
25
26## Non-negotiable hardware boundary
27
28Never connect to, initialize, home, move, heat, shake, spin, pump, open/close,
29or otherwise command physical equipment automatically. Do not turn a simulation
30plan into a live backend merely by changing an environment variable, config
31value, or import.
32
33Before any separately authorized live run, require a trained human to:
34
351. Explicitly confirm the exact backend, device identity, firmware, transport,
36 deck, and protocol revision.
372. Reconcile the physical deck against the resource tree, including carriers,
38 adapters, lids, plates, tip racks, waste, labware orientation, barcodes, and
39 every occupied coordinate.
403. Verify calibration, teaching, motion envelopes, collision risks, gripper or
41 channel clearances, and all aspiration/dispense coordinates.
424. Review source identity and actual fill volume, dead volume, destination
43 capacity, tip type/capacity/filter compatibility, channel mapping, units,
44 heights, rates, liquid class, blowout/mixing, and contamination boundaries.
455. Confirm guards, doors, waste capacity, containment, emergency stop readiness,
46 PPE, biosafety/chemical controls, and a safe abort/recovery procedure.
476. Approve a slow dry run or nonhazardous commissioning run when anything is
48 new or changed.
49
50Tracker state is **bookkeeping**, not sensing. It cannot prove that liquid or a
51tip is physically present. The Visualizer renders resource/tracker events; it
52does not model physics. Chatterbox prints planned operations; it does not prove
53calibration, reachability, collision freedom, liquid behavior, or device state.
54
55## Required intake
56
57Do not guess any of these:
58
59- Exact device model, installed options, firmware, computer/OS, and transport.
60- Stable PyLabRobot version and required extras.
61- Deck/deck origin, carriers, adapters, resource definitions, dimensions,
62 coordinates, orientations, and motion clearances.
63- Plate/tube/reservoir capacities and dead volumes; initial physical volumes.
64- Tip model, filter, fitting, capacity, rack state, channel count, and channel
65 mapping.
66- Transfer units (`uL`, `mm`, `uL/s`, `s`), heights, rates, mixing, air gaps,
67 blowout, liquid properties, and validated vendor liquid class.
68- Contamination policy, controls, waste handling, operator interventions,
69 acceptance criteria, and recovery procedure.
70
71If information is missing, produce an assumptions/blockers list and an offline
72draft only.
73
74## Reproducible install
75
76For offline API inspection and chatterbox simulation:
77
78```bash
79uv venv --python 3.11 .venv-pylabrobot
80uv pip install --python .venv-pylabrobot/bin/python "PyLabRobot==0.2.1"
81```
82
83On Windows, use `.venv-pylabrobot\Scripts\python.exe`. Do not install hardware
84extras until the user names the device and explicitly approves its transport
85dependencies. Then inspect the matching stable device page before considering a
86pin such as `"PyLabRobot[serial]==0.2.1"` or `"PyLabRobot[usb]==0.2.1"`.
87
88## Offline-first workflow
89
90Run from the repository root. Every bundled CLI uses strict, bounded UTF-8
91JSON/CSV, local non-symlink paths, fixed allowlists, and JSON output. None can
92select a live backend.
93
94```bash
95python3 skills/pylabrobot/scripts/validate_manifest.py \
96 --input tests/pylabrobot/fixtures/protocol_manifest.json
97
98python3 skills/pylabrobot/scripts/check_deck_geometry.py \
99 --input tests/pylabrobot/fixtures/protocol_manifest.json
100
101python3 skills/pylabrobot/scripts/plan_transfers.py \
102 --manifest tests/pylabrobot/fixtures/protocol_manifest.json \
103 --transfers tests/pylabrobot/fixtures/transfers.csv
104
105python3 skills/pylabrobot/scripts/generate_simulation_plan.py \
106 --manifest tests/pylabrobot/fixtures/protocol_manifest.json \
107 --transfers tests/pylabrobot/fixtures/transfers.csv
108
109python3 skills/pylabrobot/scripts/inspect_backends.py \
110 --expected-version 0.2.1 --strict
111```
112
113The geometry checker uses conservative static axis-aligned boxes; it is not a
114motion planner. The transfer planner requires one new tip per row and checks
115source/dead/destination volumes, tip capacity, wells, channels, heights, rates,
116units, and allowlists. Review
117`assets/protocol-manifest.schema.json` and the synthetic fixtures before making
118a project-specific manifest.
119
120## Verified software-only example
121
122The exact backend below is software-only. Do not substitute a hardware backend.
123
124```python
125from pylabrobot.liquid_handling import LiquidHandler
126from pylabrobot.liquid_handling.backends import LiquidHandlerChatterboxBackend
127from pylabrobot.resources import (
128 Cor_96_wellplate_360ul_Fb,
129 PLT_CAR_L5AC_A00,
130 TIP_CAR_480_A00,
131 hamilton_96_tiprack_1000uL_filter,
132 set_tip_tracking,
133 set_volume_tracking,
134)
135from pylabrobot.resources.hamilton import STARLetDeck
136
137set_tip_tracking(True)
138set_volume_tracking(True)
139
140deck = STARLetDeck()
141tip_carrier = TIP_CAR_480_A00(name="tip_carrier")
142tips = hamilton_96_tiprack_1000uL_filter(name="tips")
143tip_carrier[0] = tips
144plate_carrier = PLT_CAR_L5AC_A00(name="plate_carrier")
145source = Cor_96_wellplate_360ul_Fb(name="source")
146destination = Cor_96_wellplate_360ul_Fb(name="destination")
147plate_carrier[0] = source
148plate_carrier[1] = destination
149deck.assign_child_resource(tip_carrier, rails=3)
150deck.assign_child_resource(plate_carrier, rails=15)
151source.get_well("A1").tracker.set_volume(100.0) # planned state, not sensing
152
153lh = LiquidHandler(backend=LiquidHandlerChatterboxBackend(), deck=deck)
154await lh.setup() # safe here only because the backend above is software-only
155try:
156 await lh.pick_up_tips(tips["A1"])
157 await lh.aspirate(source["A1"], vols=[10.0])
158 await lh.dispense(destination["A1"], vols=[10.0])
159 await lh.return_tips()
160finally:
161 await lh.stop()
162```
163
164## API rules that prevent stale code
165
166- Current names are `STARBackend`, `VantageBackend`, `EVOBackend`, and
167 `OpentronsOT2Backend`; do not use stale `STAR`, `TecanBackend`,
168 `OpentronsBackend`, or `ChatterboxBackend` imports.
169- Use `LiquidHandlerChatterboxBackend` for generic offline liquid-handler
170 testing. `ChatterBoxBackend` is a separate legacy-named export; do not
171 conflate the two.
172- `Visualizer(resource=...)` is valid, followed by `await vis.setup()` and
173 `await vis.stop()`; it starts localhost HTTP/WebSocket servers and may open a
174 browser.
175- There is no generic `from pylabrobot.liquid_handling import LiquidClass` in
176 0.2.1. Stable liquid classes are vendor-specific, for example
177 `pylabrobot.liquid_handling.liquid_classes.hamilton.HamiltonLiquidClass`.
178- Most frontend methods are async. Backend kwargs and capabilities are
179 vendor/model specific; a shared frontend does not imply identical behavior.
180
181## References
182
183- [Liquid handling](references/liquid-handling.md) — operations, tips, tracking,
184 liquid classes, units, and validation.
185- [Resources](references/resources.md) — decks, coordinates, plates, tip racks,
186 collisions, state, and serialization.
187- [Hardware backends](references/hardware-backends.md) — verified names,
188 support levels, capabilities, and live-run gate.
189- [Analytical equipment](references/analytical-equipment.md) — plate readers
190 and scales.
191- [Material handling](references/material-handling.md) — pumps, heaters,
192 shakers, temperature control, storage, and centrifuges.
193- [Visualization](references/visualization.md) — chatterbox, Visualizer,
194 localhost services, and simulation limits.
195
196## Dated upstream sources
197
198Checked **2026-07-23**:
199
200- [PyPI 0.2.1](https://pypi.org/project/PyLabRobot/) — released 2026-03-23;
201 Python >=3.9; extras and artifacts.
202- [Stable installation guide](https://docs.pylabrobot.org/stable/user_guide/_getting-started/installation.html)
203 — stable versus source/dev install and optional transport groups.
204- [Stable API](https://docs.pylabrobot.org/stable/api/pylabrobot.html) and
205 [supported machines](https://docs.pylabrobot.org/stable/user_guide/machines.html)
206 — 0.2.1 API and model-specific support labels.
207- [`v0.2.1` source tag](https://github.com/PyLabRobot/pylabrobot/tree/v0.2.1)
208 and [changelog](https://github.com/PyLabRobot/pylabrobot/blob/main/CHANGELOG.md)
209 — tag dated 2026-03-23; `Unreleased` is development-only.
210
211---
212
213**Source:** [`K-Dense-AI/scientific-agent-skills`](https://github.com/K-Dense-AI/scientific-agent-skills) → `skills/pylabrobot/SKILL.md`