DXTR FAQ

Object-centric retargeting treats the object’s 6-DoF trajectory as the goal of a demonstration, not the human’s joint angles. From one phone capture DXTR recovers the path the object took through the task, and then each robot solves its own grasp and its own joint motion to move that object along that same path. The object is never rescaled to make a body fit.

Teleoperation records one specific robot being driven by a person, so the episode is bound to that robot and costs an operator’s time per episode. DXTR records a person doing the task with their own hands on a phone, and re-solves the result per robot body — one capture yields trajectories for every embodiment in the registry. The trade is honest: teleoperation gets feasibility for free because a real robot did the motion, while DXTR has to recover the geometry and then prove feasibility in simulation before anything ships.

Eight embodiments are retargeted today: Franka Panda, UR5e, PR2, MyCobot 280, Unitree G1, Apptronik Apollo, Fanuc LR Mate 200iD and SO-101. Seven of them make up the public playground fleet; SO-101, the first five-DoF arm in the registry, is in the paper’s record and not yet on the playground. Every body keeps its arm clear of the reconstructed scene, and a body with an actuated, scorable gripper also chooses its own grasp on the reconstructed object. Two do not: Apollo has no actuated gripper and refuses with no_actuated_gripper, and the Unitree G1’s three-finger Dex3 closes but its closure is not yet scorable, so both are scored on arm motion alone. Adding a robot means adding a URDF and a gripper spec to the registry — it does not mean re-collecting the data.

The DXTR Eye iOS app records RGB video at 1920×1440, per-frame LiDAR depth, and ARKit camera pose while a person performs the task. It runs eyes-free: audio coaching and simple hand gestures start, stop and cancel each take, so the collector never touches the screen mid-demonstration. It requires an iPhone Pro or Pro Max (or an iPad Pro) with a LiDAR sensor.

Every retargeted episode is replayed in simulation against the object’s tolerance tube before it ships. If the object follows its path inside the tube, the episode passes. If it does not — the reach is short, no grasp holds across the whole contact interval, the arm cannot clear the scene — the episode ships an explicit infeasibility certificate naming the sub-interval and what blocked it, instead of a silently rescaled trajectory that looks clean and is not. This is checked in simulation at the kinematic tier: pass, fail or refused, each with its reason. Not every non-pass is the same, and the playground counts the two kinds separately rather than pooling them. A robot that refuses before it moves ships a rest pose and the named reason. A robot that attempted the task and then missed the tube ships the trajectory it produced together with the certificate saying where it left the tube — that one is a failure in replay, not a refusal, and it is the worse of the two because the system moved without knowing. Most non-passing outcomes on the playground today are the second kind.

LeRobot datasets per robot — the format the pi0, ACT and Diffusion Policy stacks read — and MCAP for the raw multimodal record, which opens in Foxglove. Both are downloadable from the portal or pulled from the keyed public API at api.dxtr.co.

Robotics labs and data teams that need manipulation demonstrations for a particular embodiment and would rather not stand up a teleoperation rig or a capture fleet to get them. There are two ways in: record with the Eye app as a collector, or license retargeted trajectories for your robot — or the pipeline that produces them from a human capture.

Tell us the robot and the tasks and we will scope a capture — srikanth@dxtr.co. If you would rather drive it from a script, the public API at api.dxtr.co commissions captures, reviews what comes back, and pulls robot-ready exports; the OpenAPI document is at /v1/openapi.json and the written docs are at app.dxtr.co/docs.

An iPhone Pro or Pro Max with a LiDAR sensor, or an iPad Pro. Capture uses LiDAR depth and ARKit scene data, so it will not start on a non-LiDAR device — a regular iPhone will not work. The app is distributed through TestFlight; you will need Apple’s free TestFlight app installed first. Camera and microphone access are required to record a demonstration; location is never used and there is no advertising or tracking.

The collection catalog currently holds 200 phone-capturable tasks across 19 categories — everyday manual work of the pick, place, pour, open and transport kind. The practical filter is whether the task is something a person can do with their own hands, in a room, with a phone mounted at eye level. Customers can also describe their own task in the portal — optionally AI-drafted — and broadcast it to approved collectors.

The figure published on dxtr.co is the median object-track p95 over the scored window, across the passing robot–episode outcomes. Read it precisely, three times over. First, it is a simulation figure — how far the object drifted from its recorded path in replay while the object contract was driving — not ground-truth accuracy against a physical robot; nothing on this site ran on hardware. Second, it is a median across bodies and captures, so half the passing outcomes are worse than it, and it says nothing about the ones that did not pass. Third, it is not the outcome. The outcome is the replay against the object’s tolerance tube on the contact window — the frames where the object is in contact and moving — at kinematic feasibility · ±50 mm / ±15° · in simulation, with the frozen strict reference class (±10 mm / ±5°) printed beside it per capture. That is pass or not-pass, not a residual. The playground states the scored window per capture, as “contract drove x s of y s”. The figure moves as captures re-solve, and the homepage is recomputed from the run bundles every time the site is published.

That is the shape of the system: a robot enters the registry as a URDF plus a gripper specification — maximum width, finger geometry, end-effector frame, reach — and existing captures are re-solved for it. Nothing is re-collected, because the goal stored per episode is the object’s trajectory rather than any particular arm’s motion. Tell us the robot and the tasks and we will scope it: srikanth@dxtr.co.

No. Customers receive episodes and derived datasets under a pseudonymous collector alias — never a name, email or contact details — and aliases are masked per organisation, so the same collector cannot be correlated across customers. Collectors are instructed not to record identifiable bystanders, faces, voices or personal documents. The full detail is in the Privacy Policy.

Worth stating plainly. Contact forces are inferred, not measured — a phone has no force sensor, so if your task turns on force control this is not a substitute for a teleoperation rig. Quality depends on object pose recovery and metric reconstruction, so a task where the object is never clearly visible is a hard case. Frames where nothing moves — a press, a wipe, a reach to a switch — have no object trajectory to follow and fall back to wrist imitation, labelled as such. The check is at the kinematic tier: it establishes that the object followed its path in simulation, not that a physical robot reproduced it. Articulated objects, and bimanual and mobile-base support, are the next tiers on the same certificate machinery rather than shipped capability.

They are the reference points on the hand side of the line, and the difference is in what each one records. DexPilot and AnyTeleop take camera observations of a human hand and produce joint commands for a robot hand-arm system in real time. EgoMimic takes head-mounted video of a person doing the task and uses it as training data alongside robot data. UMI takes video and pose from a handheld gripper-shaped device and produces end-effector pose and jaw width. In each case the recorded quantity is the human’s motion or the device’s, and a mapping step turns it into commands for a particular body. DXTR records the object’s 6-DoF path instead, re-solves grasp and joint motion per robot, and replays each result in simulation against the object’s tolerance tube. That is a different trade, not a measured improvement — we have not run those systems. The object contract is blind to frames where nothing moves, which is why the shipped policy is a hybrid of both contracts, with every frame labelled by which rule it obeyed.