Launch HN: Hebbian Robotics (YC S26) – Build scalable robotics data pipelines

Hebbian Robotics (YC S26)

Open source SDK for scalable multimodal data pipelines in robotics and physical AI

Hebbian Robotics (YC S26) is building HFlow, an open source SDK for scalable multimodal data pipelines in robotics and physical AI. It makes data tooling and practices typically developed inside large robotics teams accessible to teams of any size.

We believe processing data is a major bottleneck in robotics. A corpus can combine video, state, actions, timestamps, and metadata from many recording systems. Teams often feel the problem first in quality control: determining whether cameras froze, streams drifted out of sync, required topics disappeared, or duplicate recordings entered the corpus. As the corpus grows, fragmented scripts make it difficult to know what ran, audit the results, or reproduce a dataset.

Teams can start with HFlow's built-in checks, write new transformations, checks, labels, and enrichments, or connect processing code they already use. HFlow handles the orchestration, storage, versioning, and curation around those steps.

HFlow stamps each processed episode with its provenance, renders the pipeline as a graph, and records metadata and quality evidence in a queryable catalog. You can trace how outputs were produced, monitor every stage, and investigate a corpus without loading the underlying recordings.

MCAP is HFlow's v1 input and output boundary because it efficiently stores and serves synchronized video, state, action, and other time-series streams. That format requirement does not define where the data comes from: human-worn cameras, teleoperated robots, autonomous policies, and other collection systems can all feed the pipeline once their data is represented as a supported MCAP episode.

Status: pre-v1, with the core lifecycle working end to end. HFlow is ready to try locally. See what is implemented and open issues for current details and remaining work.

Help grow the open robotics community. Star the repository , share it with your network, or contribute . Our goal is an open source community where anyone can participate in building the future of robotics. No robot hardware is required to contribute.

HFlow's boundary

Input Supported standard MCAP episodes directly; LeRobot Dataset v3 repositories through hflow import lerobot

Processing Your Python transforms, checks, labels, and enrichments

Execution In-process for development; generated Airflow 3 DAGs for scheduled runs

Durable output Canonical MCAP episodes, provenance, artifacts, and a Parquet catalog

Curation DuckDB SQL that writes a version-pinned manifest

What you get

Human and robot data move through a four-stage lifecycle:

collection --> ingestion ---------------> curation ------> delivery (landing (transform -> QC gate -> (SQL over (curated MCAP + bucket) enrich, as an episode manifest; convert Airflow DAG) catalog) for training)

- Your processing code stays yours. Transformations, quality checks, labels, and enrichments are plain Python functions in your own environment. Existing code plugs in through small adapters instead of being rewritten for a proprietary framework.

- Episodes are MCAP, the container that ROS 2 records natively and Foxglove / Rerun open directly, written with two tunings described in Dyna's article: in-band H.264 with GOP length matched to how the data is read, and topic-group chunking (camera streams and state streams never share a chunk, so a training sample costs one read per group instead of one per topic).

- Processed episodes carry their provenance. The file itself records the schema, pipeline, and tool versions that produced it, plus its source URI when available. Catalog records connect measurements and outcomes to step versions, making it easier to trace a bad result back to its origin.

- The pipeline is visible as a graph. HFlow renders Airflow DAGs so you can see how stages connect and monitor task status, logs, retries, and reruns.

- Quality checks produce reusable evidence. Accessors extract the inputs existing processing code expects (numpy arrays, MP4 paths, JPEG frames), and results land as queryable measurements rather than hardcoded verdicts. Different datasets can apply different thresholds without processing the media again.

- Query the corpus without loading the recordings. Metadata, quality measurements, tags, version stamps, and artifact locations live in the Parquet catalog. DuckDB can answer corpus-wide questions and build manifests without opening the underlying MCAP files.