Phyzical turns a browser drag into four rows of elizaOS training data

A mouse drag becomes a 30 to 60Hz demonstration trajectory

Everything starts with a cursor gesture, and that is the project's entire argument in one movement. A Unity WebGL scene puts a simulated robot arm in front of you, you drag the end effector roughly the way you would move a selection box, and inverse kinematics works out the joint angles behind it. Every session is recorded as a demonstration trajectory at 30 to 60Hz, and the payload is specific rather than vague: joint positions, end-effector pose, object poses and the action stream. That is the shape a Vision-Language-Action model or an imitation-learning trainer wants, which is why the project describes itself as the fuel station for agent robot stacks. The constraint it advertises hardest is that there is no robot hardware and no expertise, just a browser tab. Whether that lowers the floor on trajectory quality is the question the repository cannot answer, and it names no way to grade a contributor's session beyond the quality checks sitting in its backend. The stated pipeline is browser teleoperation into that backend, which does quality checks, keeps an episode store and handles onchain provenance, then out to an elizaOS robot stack.

The converter writes four tables and shows exactly one flag

The conversion path is the part of this repository that reads as finished rather than aspirational. It requires Python 3.10 or newer with no dependencies, standard library only, which is a rare enough claim that you can verify it by reading the imports. The converter writes a SQLite file using the same DDL as the elizaOS trajectory_db schema module, attributed under MIT, so the output drops into the elizaOS robot training pipeline without a translation layer. A block-sorting episode produces four populated tables: one trajectory row carrying source='phyzical' and is_training_data=1, one trajectory_steps row for the human macro-step, ninety control_frames rows holding the 30Hz joint, end-effector and action frames, and one embodied_contexts row carrying object poses plus the task description. The reasoning is that this mirrors how elizaOS already ingests an external episode source, in the shape of its own trajectory_db/import_hyperscape.py, with phyzical simply becoming the next value in the source column.

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

One command, one flag, and it is the only flag the documentation shows.

Three action sources share one WebSocket and one episode schema

The detail that makes mixed training runs possible is that all three action sources arrive over the same WebSocket and land in the same episode schema. Human is mouse-drag plus inverse kinematics, and the project calls it the pre-training core, which is an honest label for the only source a person actually intends. Auto is a scripted patrol, there for coverage and baselines rather than for demonstration. Fly is the outlier, a mapped fruit-fly nervous system instead of anything human-shaped. Keeping all three on one transport and one schema is the right decision if you intend to mix them, because otherwise you are comparing trajectories whose timestamps and units came out of different code paths and discovering the mismatch during training. It also forces the schema to carry a discriminator, and it does: the episode format is version 1 JSON Schema and explicitly includes controller and fly fields, so a downstream loader can tell which source produced an episode instead of inferring it from frame content. schema/MAPPING.md then spells out the field-by-field route from a phyzical episode into the elizaOS tables, which is the document to read before you assume field names will line up.

The Fly controller is a wiring diagram, not a policy that learned

The Fly controller is where the arguments will happen, so it is worth stating exactly what it claims. The underlying science is MaleCNS v1.0, released in 2025 by Google Research and HHMI Janelia under CC BY, described as the first complete central nervous system map of an adult male fruit fly: roughly 166,000 neurons or more across brain and ventral nerve cord, including 3,335 R1 to R6 and 811 R7/R8 photoreceptors. What the controller does with that map is not learning. It takes a 64 by 64 crop of the scene camera, samples it as hex-packed ommatidia on the R1 to R6 and R8 channels, applies fixed wiring with no training and no gradients, adds habituation, and reads descending-neuron activity into three gauges for turn, lift and drive or grip, which it emits as ee_delta over the same WebSocket and the same schema as a human episode. Reinforcement arrives the way it does in an insect: PPL101 with an aversive flag on collision, PAM with a reward flag on success. The documentation is clear that this is a mapping, which is the correct framing, since a fixed wiring diagram cannot honestly be called a result the way a trained policy could.

# generate a fly episode (T-F01 "Keep Target Centered", deterministic)
python3 controllers/flycns/demo.py --out examples/episode_fly_keep_centered.json

# import it into the same trajectory_db as human episodes
python3 converters/eliza_robot/import_phyzical.py \
    examples/episode_fly_keep_centered.json --db trajectories.db

The two shipped episodes are three seconds and twelve seconds long

Measure the bundled samples before you plan a training run, because they are short. The block-sorting episode is 90 frames at 30Hz, which is three seconds of arm movement for one teleoperation. The fly episode is 360 frames at 30Hz, twelve seconds, recorded with controller=flycns_v1 and carrying PPL101 and PAM teach events inline. The fly demo is labelled task T-F01, Keep Target Centered, and is deterministic, so re-running it reproduces the file rather than producing a new sample. None of that is wrong, but three seconds is a demo rather than a dataset, and the distance between a platform that emits one episode per browser session and a corpus that covers a manipulation task end to end is the whole distance between a supply idea and a trained policy. Two pieces in the repository speak to closing it. docs/integration-elizaos.md sets out the data supply, the DAgger loop and the agent roles. On the consuming side, elizaOS already ships MuJoCo and MJX simulation, Alberta continual reinforcement learning with text-conditioned policy trainers, and WebSocket bridge backends for mock, mujoco, ros and isaac, with profile-driven robots keyed by identifiers such as Hiwonder AiNex and ASIMOV-1 that need demos collected against those same morphologies.

Provenance is anchored on-chain, and no code here touches a chain

On-chain provenance is the one headline claim the open repository cannot demonstrate, and naming that gap matters more than repeating it. The pitch is that episode provenance, meaning a data identifier, a content hash and the contributor, is anchored on-chain. Every other moving part runs on the host with Python 3.10 and the standard library alone, and the converter's entire output is four SQLite tables. Nothing in the code reads a chain, signs a transaction or names an RPC endpoint, so either the anchoring happens in the hosted backend behind phyzical.org or it is a design the open pieces do not reach, and the documentation does not say which. Two smaller facts belong in the same paragraph. The repository has no GitHub releases, so there is no version to pin, and its metadata reports no recognised licence even though a LICENSE file sits at the root, which is awkward for a project whose stated purpose is to be the open supply side of somebody else's training pipeline. The last push was 2026-09-14, and the entire top-level tree is eight entries: .gitignore, LICENSE, README.md, controllers, converters, docs, examples and schema.

The name is already taken by a physical therapy clinic chain

One practical warning, because searching for this project by its bare name lands you somewhere else entirely. Fyzical Therapy and Balance Centers is a physical therapy clinic brand with locations people search near them, and the questions attached to that name are entirely clinic questions: which conditions it treats, whether it accepts insurance, what therapy costs, how many locations there are, pelvic floor work, and how to log in. Not one of those answers applies to a browser teleoperation platform, and the resemblance is one letter. So go to phyzical.org or search the repository name with elizaOS attached, and read schema/episode.schema.json before anything else. What you are looking for is a Python repository with five directories, two example episode files, a working converter, a working controller, and no hosting component in the tree at all. If a page you land on is selling appointments, it is the clinic.

Editorial conclusion

Phyzical fits a team that already runs elizaOS and is short of human demonstrations for a specific morphology, and who wants a converter they can read end to end in an afternoon. It does not fit anyone hoping for a dataset, because the two shipped episodes run three seconds and twelve seconds, and it does not fit anyone who needs the on-chain provenance claim to be verifiable from the repository, because no code in the tree touches a chain. Before you plan around it, confirm which chain the hosted backend anchors to, confirm the licence terms yourself since the repository metadata does not identify one, and treat the Fly controller as a fixed wiring diagram rather than a policy that learned anything.

Frequently asked questions

Official sources

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