Most robot-learning data records where the hand went. A robot has a different hand. What matters for training is what the object did, whether this robot can do that, and an honest no when it cannot. DXTR exists to test how far a phone and a careful record can take that idea.
Who built it
I'm Sri Kallakuri. I built DXTR end to end, alone: the capture app, the perception and retargeting pipeline, the simulation check and the ledger that records every outcome, including the retractions, the public playground, the collector marketplace, and the papers. One part of the approach, object-centric retargeting, is written up on arXiv; the concept is walked through on story.dxtr.co, and a sample of the corpus, with a pass, a fail or a refusal for every capture and robot pair, is on playground.dxtr.co.
Before DXTR
I spent six years at Standard AI building and leading the ML and computer-vision organisation, from head of robotics research to senior director of engineering, where we built and deployed the autonomous checkout product. Before that I co-founded Explorer.ai, which built HD maps and 3D perception for driverless cars; Standard Cognition acquired it in 2019. I helped lead the architecture of the India Energy Stack, a national digital public infrastructure programme. I did my master's at Carnegie Mellon and started out in research on human-activity understanding at ATR in Japan.
What I believe about robot data
Collection scales when it is frictionless, so a phone people already own comes first and dedicated hardware last. A demonstration is only worth its cost if the robot that will train on it can actually do it, so the check belongs before the operator hour, not after. And a record that publishes its failures and its retractions is worth more to a training team than one that publishes only its passes.