Gripper-in-hand data collection decouples demonstration acquisition from robot hardware, but whether a trajectory is executable on the target robot remains unknown until a separate replay-and-validate stage. Failed demonstrations therefore inflate the effective cost per usable trajectory through repeated collection, diagnosis, and validation. Existing collection-time feedback systems mitigate this issue but rely on head-worn AR/VR displays, robot-in-the-loop hardware, or learned dynamics models; real-time executability feedback has not yet been integrated into the gripper-in-hand data collection paradigm. We present FeasibleCap, a gripper-in-hand data collection system that brings real-time executability guidance into robot-free capture. At each frame, FeasibleCap checks reachability, joint-rate limits, and collisions against a target robot model and closes the loop through on-device visual overlays and haptic cues, allowing demonstrators to correct motions during collection without learned models, headsets, or robot hardware. On pick-and-place and tossing tasks, FeasibleCap improves replay success and reduces the fraction of infeasible frames, with the largest gains on tossing. Simulation experiments further indicate that enforcing executability constraints during collection does not sacrifice cross-embodiment transfer across robot platforms. Hardware designs and software are available at https://github.com/aod321/FeasibleCap.
Figures & tables
Fig. 1: FeasibleCap overview. An iPhone is mounted on a handheld gripper, providing real-time feasibility feedback via an on-screen indicator. The indicator turns red as the end-effector approaches workspace boundaries or joint-rate limits, guiding demonstrators to stay within the target robot’s executable region.
No HMD
No robot
Model-free
Feedback
Paradigm
ARCap [ 7 ]
×
✓
✓
V+H
Hand track.
ARMADA [ 8 ]
×
✓
✓
V
Hand track.
ARMimic [ 9 ]
×
✓
✓
V
Hand track.
FABCO [ 10 ]
✓
✓
×
V+H
Gripper
JoyLo [ 13 ]
✓
×
✓
H
Teleop.
FeasibleCap
✓
✓
✓
V+H
Gripper
TABLE I: Comparison of collection-time feedback systems. FeasibleCap is the only system that requires no head-worn display, no robot during collection, and no learned dynamics model.
Fig. 2: Open-loop vs. closed-loop demonstration collection. Top : without guidance, infeasibility is discovered only at replay time, requiring costly re-collection. Bottom : FeasibleCap evaluates embodiment constraints in real time and feeds back visual and haptic cues, enabling the demonstrator to correct motions on the fly.
Fig. 3: FeasibleCap system architecture. Top (Record) : the iPhone processes each ARKit frame along two parallel paths—Path A streams compressed images and poses to the Raspberry Pi for synchronized multi-sensor recording in MCAP format; Path B runs the on-device feasibility pipeline (IK → FK → self-collision → feasibility check) and closes the feedback loop via AR ghost rendering and haptic vibration. The green arrow denotes the real-time closed-loop guidance, the core contribution of this work. Bottom (Replay) : the iPhone triggers playback; the Raspberry Pi reads the MCAP trajectory and sends control commands to the target robot arm.
Condition
Pick-and-Place
Tossing
Overall
Baseline (no guidance)
8/10
2/10
10/20
FeasibleCap (ours)
10/10
6/10
16/20
TABLE II: Replay success rates. Each cell reports the number of demonstrations (out of 10) successfully replayed on the Realman RM75.
Fig. 4: Per-frame feasibility timelines for representative trials. Each bar represents one trajectory; frames are colored green (feasible), yellow (warning), or red (infeasible). (a) Baseline, pick-and-place: 56% infeasible. (b) FeasibleCap, pick-and-place: 0% infeasible. (c) Baseline, tossing: 53% infeasible. (d) FeasibleCap, tossing: 14% infeasible.
Constraint URDF
Replay
Success Rate
RM75
RM75 (same, real)
8/10
Franka
RM75 (cross, real)
7/10
RM75
Franka † (cross, sim)
8/10
TABLE III: Cross-embodiment replay success rates (FeasibleCap). “Constraint URDF” is the robot model used for feasibility guidance during collection. “Replay” indicates the robot (and environment) on which the trajectory is executed. All demonstrations are collected with FeasibleCap guidance enabled. † Simulation replay.
Behavior cloning for robot manipulation relies on expert demonstrations. However, for tasks that require dynamic stability, precise contact timing, or dexterous coordination, human operators may find it hard or even impossible to collect data. We study this infeasible-demonstration regime and propose GLIDE: Guardrails for Learning from Infeasible Demonstrations Efficiently, a framework that infers task-specific failure modes and converts them into executable guardrails for data collection and policy deployment. Given a task description and the conditioning teleoperation code, GLIDE writes guardrails that use system states to filter teleoperation and policy commands, constrain failure-prone actions, and iteratively improve from trajectory feedback. Across three tasks, GLIDE discovers emergent guardrails that go beyond domain-expert hardcoded ones, improving data collection over naive VR teleoperation and domain-expert hardcoded guardrails. After refinement, GLIDE raises data-collection success from 0-10 percent to 70-90 percent across the three tasks. During policy execution, mixed-data guarded policies reach 70 percent, 60 percent, and 60 percent success on Tomato plate transfer, Marker handover and stand, and Wine serving tasks. These results show that GLIDE can support policy learning when direct demonstrations are infeasible. Project website: http://guardrail-policy.github.io/
Human demonstrations offer a scalable way to collect manipulation data, but their contacts may be unstable or infeasible when transferred to a robot hand. Collecting demonstrations directly on the target robot avoids this mismatch but substantially increases the cost of data collection. To address this trade-off, we present Touch2Robot, a framework that lets humans collect demonstrations while seeing how the target robot hand would contact the object. We capture human hand motion, tactile-glove measurements, and object motion during human manipulation. These recordings guide object-specific RL policies to reproduce the demonstrated object motion while favoring contacts consistent with the recorded human touch. We distill the learned behaviors into a unified real-time retargeter that maps incoming human observations and object geometry to robot hand configurations. During collection, the predicted robot configuration is synchronized with the tracked object pose in simulation to reconstruct robot-object contacts, which are visualized to help the demonstrator adapt subsequent interactions to the target hand. Across four real-world tasks, Touch2Robot improves average real-robot replay completion from 37.9% to 72.1% over visual-only feedback, while reducing the collection time per replay-successful demonstration from 58.6s to 18.2s. Reconstructed target-hand contacts achieve 44.2% F1 against real-robot tactile measurements, and policies trained on Touch2Robot demonstrations improve downstream Diffusion Policy performance by 29.1 percentage points over visual-only feedback. These results show that bringing robot touch into the human demonstration loop improves both the quality and efficiency of scalable dexterous data collection. Project webpage: https://Touch2Robot.github.io/.
Shengcheng Luo, Xiaoyang Cheng, Hong Ying +6
ShanghaiTech University · Beijing Institute for General Artificial Intelligence (BIGAI) · Shanghai Jiao Tong University +1
Human demonstrations are today used largely for pretraining vision-language-action models, with little ability to use the same data for target-embodiment or task-oriented training, which scalable deployment of robots in industrial and general environments depends on. A human demonstration recorded on a simple and scalable device such as a mobile phone can serve as post-training data for a robot whose body differs in structure and capability from the human who recorded it. This is made possible not by retargeting the hand's motion but the object's. A capture yields a body-free record: the object's pose over time, its contact intervals, and a reconstructed 3D object with provenance. Any robot, given as a URDF and a short descriptor, is solved against that record and scored in simulation against the demonstrated object motion as ground truth: the human-to-simulation leg of human-to-simulation-to-robot transfer, measured per robot. Each (robot, episode) pair gets one outcome: pass, failure with a named mode, or refusal, with its reason, before any motion. The method runs as a working system over a growing collection; the set analysed here is a sample of it: 42 captures solved on 8 robots, 157 pairs, of which 31.2% pass, 52.2% fail, 14.0% are refused and 2.5% are unauditable (kinematic feasibility, +/-50 mm / +/-15 deg, in simulation). Refusals held up: every pair the checks refuse on stored evidence yet ran anyway failed (13 of 13; 5 on a body whose public model welds its hand). A description file could not be shown to screen a robot: its outcomes were barely more predictable than guessing. No policy has yet been trained on the record. The record decides what a robot may post-train on; whether the policy then works on the real robot is the simulation-to-robot question, answered downstream.