Physical AI · Egocentric grounding · Cross-embodiment transfer

The grounding and retargeting data engine for robot foundation models

grip.ai converts any egocentric human video into training-ready, embodiment-specific manipulation data — metric-grounded geometry, contact, and per-frame feasibility — and proves it works with a transfer benchmark we publish rather than a claim we assert.

The problem

Robot policies are starved of action-grounded data

There is roughly 1000× more human video of hands doing tasks than teleoperated robot data. It is also the wrong shape: internet video shows what the world looks like, not what it takes to act in it. The bottleneck is not architecture — it is grounded, cross-embodiment data.

01

Passive video has no action stream

Scraped footage ships semantics at best. Camera pose, hand geometry, contact, and metric scale must all be synthesized before a frame is worth anything to a policy.

02

Teleoperation does not scale

Rigs produce clean trajectories at painfully low throughput, on one embodiment, at a cost structure that cannot reach foundation-model scale.

03

Nobody can measure transfer

There is no neutral answer to "how much does this data improve my robot?" Without that number, data quality is a sales adjective instead of a measurement.

The engine

Video in. Embodiment-specific, training-ready data out.

One perception pass over human video produces an embodiment-independent artifact — hand keypoints, camera trajectory, wrist SE(3) motion, object tracks. Retargeting to a given robot is then a cheap, CPU-only pass. Adding a robot costs one pass, not a re-run.

Ground

Geometry from monocular video

Bimanual hand pose, SLAM camera trajectory, and wrist SE(3) deltas, fused into one unified schema with per-frame confidence.

Scale

Metric scale, not relative

Hand-size priors and hand–object contact constraints resolve monocular scale ambiguity, so actions live in meters in a world frame — validated against depth ground truth.

Retarget

Dexterous, feasibility-scored

Human keypoints to robot joint trajectories for multi-finger hands, with joint-limit slack, penetration, and velocity checks emitted as a per-frame quality signal.

Prove

QA and provenance by default

An automated QA battery gates every shard, and source, license class, and transform chain travel with the data — so redistributability is a queryable field, not tribal knowledge.

The flywheel

A loop that measures itself twice

Collect, ground, retarget, train, evaluate, mine failures, collect again. What makes the loop trustworthy is where it is measured: once on the labels, before any robot is involved, and once on the policy those labels produce. A defect that the first gate misses and the second catches is the most valuable thing the loop can find.

Embodiment-independent Measurement gate
1

Collect

Egocentric video plus whatever free semantic labels the source already ships.

Independent
2

Ground

Hand pose, camera pose, object tracks, wrist motion — the expensive geometric layer.

Independent
3

Eval-1 — labels

Are the labels right? Runs at full corpus scale, on human video, with no robot at all.

Independent
4

Pick embodiment

A named profile — backend, DoF, URDF, joint limits. The hinge where economics are set.

Per-embodiment
5

Retarget

Human hand to joint trajectories, CPU-only, resumable, namespaced per robot.

Per-embodiment
6

Train

Vision-language-action policy over the wrist-delta and finger-joint action chunk.

Per-embodiment
7

Eval-2 — policy

Do those labels teach a policy anything? The only signal that says useful, not merely self-consistent.

Per-embodiment
8

Insights

Error by slice, failure taxonomy — which verbs, scenes, and hands the corpus is failing.

Independent
9

Re-collect

The same machinery as stage 1 with a targeting spec attached. This is why the loop closes cheaply.

Independent

The loop splits deliberately: stages 1–3 and 8–9 are embodiment-independent and run once, while 4–7 are per-robot. One perception pass feeds every robot in the zoo — which is what makes cross-embodiment data economical instead of aspirational.

Embodiment zoo

Dexterous hands first, not parallel-jaw only

A robot is one declarative profile: backend, degrees of freedom, URDF, finger layout, joint limits. Perception never re-runs when a hand is added — which is why the zoo grows by a config entry and a cheap pass rather than a pipeline rebuild.

ProfileDoFRole
leap16Primary target — inexpensive, clean URDF, widely used in academic work
allegro16Second dexterous hand for cross-hand generalization
shadow24High-DoF ceiling for the retargeting problem
inspire12Lower-DoF dexterous point on the curve
sharpa22Reference profile, retained for shard compatibility
gripper1–2In build — parallel-jaw floor, proving transfer across a large DoF gap
The benchmark

The number buyers actually care about

Every data vendor claims quality. We are building the neutral, reproducible scorecard that settles it: for a fixed policy and a fixed target embodiment, how many real robot demos does it take to reach a success threshold when pretrained on data source D? Report the curve, not a single point.

Headline

Sample-efficiency per embodiment

Robot demos required to hit a success threshold, per data source: engine-produced vs. raw human video vs. teleop-only.

Axis

A dexterous task family

Multi-finger tasks that parallel-jaw-only pipelines structurally cannot score. Our differentiator, made measurable.

Axis

$ per usable episode

Cost and wall-clock per curated episode, published. Nobody else reports it, and it is the number that decides whether a corpus is affordable.

Axis

Ablations that keep us honest

With and without object grounding, metric scale, and feasibility filtering — so each engine component has to earn its keep in public.

Early access

Bring us your embodiment

We are working with a small number of teams training manipulation policies — VLA labs, dexterous-hand makers, and sim/eval vendors. If you have a robot and a data problem, we would like to run your embodiment through the engine.

Or reach us directly at info@grip-ai.net