phyzical: browser teleoperation episodes for elizaOS robot training

The supply problem phyzical targets inside elizaOS

The README frames elizaOS's robotics stack as complete except for one input: human demonstration data. According to the repository, that stack already ships MuJoCo and MJX simulation, continual-RL and text-conditioned policy trainers, a unified SQLite trajectory_db with tables for trajectories, steps, control_frames and embodied_contexts, profile-driven robots such as Hiwonder AiNex and ASIMOV-1, and WebSocket bridges for mock, mujoco, ros and isaac backends. What it lacks, in the README's own framing, is "large-scale human demonstration data" collected against those same morphologies.

phyzical positions itself as that supply side. The pitch is that anyone with a browser can teleoperate a simulated arm by dragging the end-effector while inverse kinematics solves the joints, and each session produces a 30 to 60Hz demonstration trajectory containing joint positions, end-effector pose, object poses and actions. The intended consumers are imitation-learning and VLA training pipelines, and the intended contributors are people with no robot hardware and no robotics background.

The audience question is narrower than the marketing suggests. If you already run an elizaOS robot stack, the converter and the mapping document are the parts you would actually use. If you are outside elizaOS, the episode schema is still readable JSON, but the value proposition of dropping into trajectory_db disappears.

From browser session to trajectory_db rows

The pipeline has three stages in the README's diagram. A Unity WebGL client records mouse-drag inverse-kinematics teleoperation at 30 to 60Hz. The phyzical backend applies quality checks, stores the episode, and anchors provenance consisting of a Data ID, a content hash and a contributor. Downstream, elizaOS consumes the episode through trajectory_db, the robot's SQLite store, for imitation or reinforcement learning.

The repository itself contains only the open pieces of that pipeline: schema/episode.schema.json (the v1 JSON Schema, including controller and fly fields), schema/MAPPING.md (a field-by-field mapping from phyzical episode to trajectory_db), converters/eliza_robot/import_phyzical.py (the working converter), controllers/flycns/ (the Fly controller), and two example episodes. The backend, the quality checks and the on-chain anchoring are described but not shipped here.

That split matters when you evaluate it. The conversion path is inspectable and runnable from the repository. The collection path, which is where data quality and contributor incentives live, is not.

Installing the converter and converting your first episode

The README states the converter requires Python 3.10 or later and has no dependencies beyond the standard library. There is no package to install: you clone the repository and run the script in place. The quickstart command takes an episode JSON and writes a SQLite database.

python3 converters/eliza_robot/import_phyzical.py \
    examples/episode_block_sorting.json \
    --db trajectories.db

The example episode is a 90-frame block-sorting demonstration recorded at 30Hz, so the output database should contain four tables populated as follows: trajectories holds one row for the episode with source='phyzical' and is_training_data=1, trajectory_steps holds one row for the human teleoperation macro-step, control_frames holds 90 rows of joint, end-effector and action frames, and embodied_contexts holds one row with object poses and the task description. Those counts come from the README's description of the quickstart output, not from a run.

The second example exercises the Fly controller instead of a human:

python3 converters/eliza_robot/import_phyzical.py \
    examples/episode_fly_keep_centered.json \
    --db fly_trajectories.db

That episode is 360 frames at 30Hz with controller=flycns_v1 and PPL101 plus PAM teach events. The README does not document a --help flag, a dry-run mode, or what the script does when an episode fails schema validation, so treat the two example invocations as the documented surface and read the script before pointing it at your own data.

The Fly controller: fixed wiring instead of a trained policy

The most unusual part of the repository is controllers/flycns/, which the README describes as a working Fly controller. It wires a visual crop of the MaleCNS connectome to the scene camera. MaleCNS v1.0 was released in 2025 by Google Research and HHMI Janelia under CC BY, and the README describes it as the first complete central nervous system map of an adult male fruit fly, with roughly 166,000+ neurons across brain and ventral nerve cord, including 3,335 R1 to R6 photoreceptors and 811 R7/R8 photoreceptors.

The mechanism, as documented, is a 64x64 crop from the scene camera sampled into ommatidia channels corresponding to R1 to R6 and R8, passed through fixed wiring with habituation and no training and no gradients, then read out through descending neurons into turn, lift, drive and grip signals that become ee_delta. PPL101 aversive and PAM reward events fire on collision or success, in a dopamine-style teaching role. The output travels over the same WebSocket and the same episode schema as human teleoperation.

This is a research artifact more than a production controller. Fixed wiring means no adaptation to a new arm morphology beyond whatever the mapping already encodes, and the README does not report task success rates for the Fly episodes. It is worth reading docs/flycns.md before assuming the fly demonstrations are interchangeable with human ones in a training set.

Where phyzical is the wrong choice

The repository is explicit that the browser client is Unity WebGL and that the backend performs quality checks, but only the converter, schema, controller and examples are present here. If you need a hosted data collection service with an SLA, this repository does not provide one; phyzical.org is listed as the homepage, and the README does not document an API, authentication scheme or data export endpoint.

Licensing is the second gap. The repository's LICENSE file is present but the license is reported as NOASSERTION, meaning no standard license identifier could be determined. The README does attribute the trajectory_db DDL to eliza_robot/trajectory_db/schema.py under MIT, and notes that MaleCNS is CC BY. Those are attributions for reused components, not a statement about the licence covering phyzical's own converter and schema. If you plan to redistribute converted datasets, that ambiguity is a reason to read LICENSE directly rather than infer terms from the README.

The third limitation is scope of provenance. On-chain anchoring of Data ID, content hash and contributor is described as part of the pipeline, but the repository contains no anchoring code and the README does not document how a hash is computed, which chain is used, or what happens if anchoring fails. For a regulated training pipeline that needs reproducible data lineage, that is an unverified dependency rather than a feature.

How it differs from LeRobot and other demonstration datasets

The natural comparison is Hugging Face's LeRobot, which also targets imitation learning and ships dataset tooling plus a Python stack for recording and training. The difference in approach is the ingestion format and the collection front end. LeRobot's datasets are organized around its own dataset conventions and typically assume you have hardware or a simulator you control locally; phyzical's output is shaped specifically for elizaOS's trajectory_db tables (trajectories, trajectory_steps, control_frames, embodied_contexts) and its collection front end is a browser tab rather than a local recording rig.

That makes phyzical narrower and, within its niche, more direct. If your training loop already reads trajectory_db, the converter is a single stdlib script with no dependency graph to reconcile. If your loop reads LeRobot datasets, phyzical gives you no bridge, and you would be writing the field mapping yourself from schema/MAPPING.md. A third option is collecting your own demonstrations in simulation with whatever teleoperation tool your simulator provides; that gives you control over morphology and task distribution but requires hardware or a configured simulator, which is exactly the barrier phyzical's browser client is designed to remove.

Maintenance, upgrade cost and licence status

The repository is not archived, and the last push was on 2026-09-14. There are no retrieved releases, so versioning appears to be tracked through the schema's v1 designation rather than tagged releases. The schema file is named episode.schema.json and described as v1, which implies a versioned contract, but the README does not describe a migration path from v1 to a future v2 or how the converter would handle an episode written against a newer schema.

Upgrade cost is low in one respect: the converter has no third-party dependencies, so there is no requirements file to drift. It is higher in another: the converter mirrors the DDL of eliza_robot/trajectory_db/schema.py, so if elizaOS changes that schema, import_phyzical.py needs a matching change, and the README does not state whether the converter validates against the upstream schema at runtime or simply writes the tables it expects.

On licensing, the honest position is that the repository's own terms are unclear from the metadata. The README attributes the DDL to elizaOS under MIT and cites MaleCNS as CC BY, which tells you the provenance of reused parts but not the terms you accept by using phyzical's converter and schema. Check LICENSE before shipping converted data to anyone else.

Editorial conclusion

Adopt phyzical if you are building an elizaOS robot stack and need demonstration frames in trajectory_db format, or if you want to study how a fixed-wiring controller maps visual input to end-effector deltas. Do not adopt it as a general robotics data platform: the repository ships a converter, a schema and one controller, and the README does not document a hosted API, a dataset licence, or rollback for the on-chain provenance step. Before wiring it into a training run, run the converter against examples/episode_block_sorting.json and inspect the four tables it writes, then read schema/MAPPING.md to confirm each phyzical field lands where your policy expects it.

Frequently asked questions

Official sources

1. Issues
2. Phyzicalorg/Phyzical_org on GitHub
3. Project website
4. README