Papers
Topics
Authors
Recent
Search
2000 character limit reached

GOTT: Framework for Dexterous Manipulation

Updated 9 October 2026
  • The framework GOTT is a dexterous-manipulation system that integrates robot-agnostic object motion and reach specifications, converting them into precise multi-fingered robot execution with a robust, closed-loop contact acquisition system known for its stability, despite various errors and imperfections during execution.
  • GOTT decomposes manipulation into three stages: reach (approach and initialization), acquire (stable contact), and move (object trajectory tracking), enhancing the success of dynamic manipulation tasks across varied robot arm hand configurations and motion blindspots.
  • The GOTT policies show high success on lifting, pouring, and erasing in laboratory conditions using a variety of robots and hand types. The best average success was 96% in MPEG lifting while in freezing of object motion.
  • Wherever possible, Falls are predicted and object motion predicted with realtime feedback control switching
  • Use of several visual and contact sensors to assess the performance and contact entry condition.
  • Flexible to integrate execution policy adjustments from future aware prediction and planning data from human actions, thus optimizing object specific reach parameters.

GOTT (“General Object Trajectory Tracking”) is a dexterous-manipulation framework that converts robot-agnostic object motion and an approximate reach specification into multi-fingered robot execution. Its central mechanism is a reusable, closed-loop contact-acquisition primitive that separates manipulation into reach, acquire, and move. The framework is designed to establish stable opposing contact despite imperfect initialization, object-pose error, object displacement, geometry mismatch, and differences among robot arms and hand morphologies (Liu et al., 2 Oct 2026).

1. Problem formulation and design principles

GOTT represents manipulation intent primarily through a desired object-pose trajectory,

τo={TO,t}t=0T,\tau_o=\{T_{O,t}\}_{t=0}^{T},

where TO,t∈SE(3)T_{O,t}\in SE(3) is the desired pose of the object frame at time tt. This representation is robot-agnostic: tasks such as sweeping, drilling, pouring, or erasing can be specified by object motion rather than by the joint trajectories of a particular robot.

An object trajectory alone does not specify the hand–object contact region, finger assignments, contact-establishment strategy, collision avoidance, or compensation for object-pose and geometry errors. A stable geometric grasp may also be functionally inappropriate. For example, grasping a drill by its chuck can prevent tool use, while a loose brush-handle grasp may fail during sweeping.

GOTT addresses this interface problem by requiring the upstream system to provide only an approximately reachable, task-relevant initialization. The local contact-rich interaction is delegated to a shared closed-loop policy. Its core interface is

(τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},

where ρ\rho is a reach specification describing how the hand should approach an appropriate contact region.

This decomposition differs from open-loop grasp execution. Open-loop methods assume that the object pose, approach trajectory, final hand configuration, and resulting contacts are sufficiently accurate before execution begins. GOTT instead allows the initial configuration to be a pre-grasp or approximate contact configuration and uses feedback to refine it.

2. Reach–acquire–move execution

GOTT executes manipulation in three sequential stages.

2.1 Reach

The reach specification is

ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),

where ξapp\xi_{\mathrm{app}} is an approach trajectory and ginitg_{\mathrm{init}} is an approximate hand configuration at the end of that approach. The latter is explicitly not required to be a final grasp.

The system switches from reach to acquisition when the minimum distance between the hand links and the object surface satisfies

dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},

where M\mathcal M is the object mesh. The upstream planner remains responsible for functional contact selection, collision-free approach, and downstream reachability, but it need not synthesize a perfectly executable multi-finger grasp.

2.2 Acquire

The contact-acquisition policy receives local hand–object geometry and proprioceptive history and outputs incremental wrist and joint commands,

TO,t∈SE(3)T_{O,t}\in SE(3)0

The policy operates closed loop and can respond to object-pose estimation error, object displacement, imperfect hand initialization, mesh-to-object mismatch, and uncertain or delayed contact.

Acquisition terminates through a separate proprioceptive contact predictor. Stable contact requires the thumb and at least one non-thumb finger to be predicted in contact for five consecutive control steps. This criterion encodes opposing contact rather than merely proximity or enclosure.

2.3 Move

After stable contact is detected, the robot performs a short lift and tracks TO,t∈SE(3)T_{O,t}\in SE(3)1 with a pose-conditioned controller. If TO,t∈SE(3)T_{O,t}\in SE(3)2 denotes the estimated hand–object transform, a target hand pose is obtained from the desired object pose and the estimated grasp transform. The target is additionally corrected using observed object-pose error.

Conceptually, the target can be expressed as

TO,t∈SE(3)T_{O,t}\in SE(3)3

with an additional correction based on

TO,t∈SE(3)T_{O,t}\in SE(3)4

The move stage assumes that the hand–object transform remains approximately fixed after acquisition. This makes the framework suitable for grasp-and-move tasks, but limits deliberate in-hand manipulation, finger gaiting, unscrewing, and regrasping.

3. Reach-specification generation

GOTT keeps the contact-acquisition primitive and tracking backend fixed while allowing reach specifications to originate from different sources.

3.1 Future-aware object-centric planning

The default planner receives an object mesh, an object trajectory, and a task description:

TO,t∈SE(3)T_{O,t}\in SE(3)5

A vision-LLM processes four rendered object views and identifies functional parts and task-relevant grasp points. The selected two-dimensional points are back-projected onto the object mesh and aggregated into a task-relevant surface region

TO,t∈SE(3)T_{O,t}\in SE(3)6

The implementation forms the final region from the union of TO,t∈SE(3)T_{O,t}\in SE(3)7 cm surface neighborhoods around consistent back-projected points. For drill use, functional reasoning should select the pistol grip rather than the chuck.

BODex’s lightweight initialization procedure samples TO,t∈SE(3)T_{O,t}\in SE(3)8 candidate hand poses and joint configurations:

TO,t∈SE(3)T_{O,t}\in SE(3)9

Each candidate is approximate rather than a final grasp. GOTT then:

  1. plans a collision-free approach trajectory using cuRobo;
  2. assumes a temporary rigid hand–object attachment;
  3. rolls out the hand motion implied by tt0;
  4. solves arm inverse kinematics over the entire trajectory;
  5. rejects candidates with infeasible approaches, joint-limit violations, collisions, or failed inverse kinematics.

Among valid candidates, it selects the one minimizing cumulative arm motion,

tt1

This is future-aware because initial candidates that become infeasible during subsequent object motion are rejected.

3.2 Human and external specifications

Reach specifications can also be supplied by human demonstrations or external models. Such sources may provide a task-relevant contact region, an initial hand configuration, an approach trajectory, or a reference hand–object trajectory.

For DexYCB and OakInk demonstrations, the human approach segment is retargeted to the robot hand to obtain tt2 and tt3. The endpoint need not be an exact grasp because the acquisition policy refines it.

Object trajectories can originate from tracked human demonstrations using FoundationPose, generated videos with depth estimation and pose tracking, or manually specified object-pose keyframes interpolated into trajectories. The contact-acquisition and tracking components remain unchanged across these sources.

4. Contact-acquisition primitive and cross-embodiment control

4.1 Training and control setup

The primitive is trained with PPO in IsaacLab. Training uses:

  • 16 YCB objects;
  • multiple stable resting poses per object;
  • 4,000 initial hand configurations per object–resting-pose pair;
  • XHand, Sharpa Wave, and Allegro hands;
  • 4,096 parallel environments;
  • 2,000 PPO epochs;
  • 60 control steps per episode;
  • a 10 Hz control rate;
  • approximately tt4 million environment steps;
  • approximately 24 hours on one NVIDIA L40S GPU.

The policy must establish contact, lift the object at least tt5 cm, and maintain stability. Domain randomization varies object scale, mass, friction, restitution, robot-link friction and restitution, actuator stiffness and damping, and random push forces.

The observation contains per-link hand–object displacement, canonical hand-link positions, canonical joint positions, previous joint targets, and joint and link masks. Hand–object geometry is represented using tt6 sampled object-surface points. For canonical link tt7 at position tt8, the nearest-object displacement is

tt9

where (τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},0 is the object point cloud transformed into world coordinates.

The policy uses five frames of proprioceptive history, (τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},1, and produces a 32-dimensional action:

(τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},2

with

(τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},3

The first six components specify wrist translation and rotation deltas; the remaining 26 specify canonical hand-joint deltas. Actions are clipped to (τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},4 and converted to residual target commands. Wrist translation and rotation are scaled to (τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},5 m and (τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},6 rad per control step, respectively. The policy is an MLP with hidden layers (τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},7.

4.2 Reward structure

The reward combines distance, contact, lift, and object-stability terms:

(τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},8

The weights are

(τo,ρ)⟶robot execution,(\tau_o,\rho)\longrightarrow \text{robot execution},9

with object-stability weights annealed from ρ\rho0 to ρ\rho1 over ρ\rho2 steps.

The distance term prioritizes fingertips and the thumb:

ρ\rho3

The contact reward is

ρ\rho4

with force-based contact threshold ρ\rho5. Grasping requires thumb contact and contact by at least one non-thumb finger.

The lift reward activates only after opposing contact and rewards a lift of up to ρ\rho6 cm:

ρ\rho7

where

ρ\rho8

Planar displacement and orientation stability are encouraged through

ρ\rho9

and

ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),0

where

ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),1

4.3 Canonical representation across hands

GOTT maps different hands into a shared representation of 21 canonical links and 26 canonical joints. The links comprise one palm keypoint and four keypoints for each of five fingers. Missing links are filled using the nearest available links and indicated by a binary link mask.

The joint representation contains six thumb slots and five slots for each of the four other fingers. Native hand joints are mapped through an index map ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),2 and sign vector ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),3:

ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),4

Missing slots are zero-padded and masked. The active degrees of freedom are 12 for XHand, 16 for Allegro, and 22 for Sharpa Wave. No hand-specific encoder or decoder is used.

Canonicalization alone is not sufficient for morphology transfer. The experiments indicate that successful zero-shot transfer depends strongly on joint training across multiple hand morphologies.

4.4 Contact switching

A separate two-layer MLP contact predictor receives five-frame histories of joint positions, joint targets, and link positions. It predicts five finger-contact probabilities:

ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),5

At inference, probabilities are thresholded at ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),6, and the system switches to the move stage when the thumb and at least one other finger are predicted in contact for five consecutive steps. The predictor achieved per-step false-positive rates of ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),7–ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),8, false-negative rates of ρ=(ξapp,ginit),\rho=(\xi_{\mathrm{app}},g_{\mathrm{init}}),9–ξapp\xi_{\mathrm{app}}0, per-episode switch accuracy of ξapp\xi_{\mathrm{app}}1–ξapp\xi_{\mathrm{app}}2, and median switching lag of at most one step.

5. Evaluation and empirical results

5.1 Simulation lifting

The simulation evaluation uses 9,588 DexGraspNet object assets, 54,149 object-scale-pose instances, four object scales, and XHand, Sharpa, and Allegro hands. Success requires stable contact, a lift of at least ξapp\xi_{\mathrm{app}}3 cm, and stability over the evaluation horizon.

Method Setting Average success
BODex Open loop 38.7%
DRO Open loop 40.5%
CrossDex Specialist 46.6%
CrossDex Unified 51.7%
GOTT Specialist 75.4%
GOTT Unified 78.7%

The unified GOTT policy achieves ξapp\xi_{\mathrm{app}}4 average success. It was trained on only 16 YCB objects but evaluated on 9,588 DexGraspNet assets.

5.2 Real-world acquisition

Real-world experiments use Franka Research 3 and Tianji arms with XHand and Sharpa Wave hands. Object meshes are captured with an iPhone, SAM2 performs segmentation, and FoundationPose estimates and tracks six-dimensional object pose at ξapp\xi_{\mathrm{app}}5 Hz. GOTT runs at ξapp\xi_{\mathrm{app}}6 Hz.

Each platform performs 50 trials over ten objects, with success requiring a ξapp\xi_{\mathrm{app}}7 cm lift and stable holding for at least three seconds:

  • Franka–Sharpa: ξapp\xi_{\mathrm{app}}8;
  • Franka–XHand: ξapp\xi_{\mathrm{app}}9;
  • Tianji–XHand: ginitg_{\mathrm{init}}0.

The tested objects include five seen and five unseen objects.

5.3 Unseen hand morphologies

The unified policy is evaluated zero-shot on Allegro variants with removed finger links. Its average success is ginitg_{\mathrm{init}}1, compared with ginitg_{\mathrm{init}}2 for per-variant oracle policies. An Allegro-only policy achieves only ginitg_{\mathrm{init}}3 average success on these variants. The result indicates that cross-morphology training, together with canonicalization, is important for transfer.

5.4 End-to-end object-centric tasks

Four real-world tasks are evaluated on Franka–Sharpa: trash cleanup with a brush, mustard pouring, whiteboard erasing, and drill use. Each is repeated ten times.

Method Average grasp success Average task success
DRO 57.5% 35.0%
BODex 57.5% 35.0%
GOTT 87.5% 80.0%

GOTT therefore improves average end-to-end task success from ginitg_{\mathrm{init}}4 to ginitg_{\mathrm{init}}5. Baseline failures include unsuitable contact regions, object displacement during approach, cage-like grasps without firm opposing contact, and slipping during object motion. DRO achieves ginitg_{\mathrm{init}}6 on trash cleanup because its loose brush-handle grasp does not survive sweeping.

5.5 Human demonstrations and workspace robustness

All 499 left-hand DexYCB sequences are tested after retargeting the human approach to XHand. GOTT achieves ginitg_{\mathrm{init}}7–ginitg_{\mathrm{init}}8 success across IsaacLab, ManiSkill, and MuJoCo, compared with ginitg_{\mathrm{init}}9 for kinematic replay in MuJoCo. SPIDER achieves dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},0, but requires physics-informed optimization for each demonstration and reoptimization when object states or trajectories change.

In 600 simulated SimToolReal eraser episodes, SimToolReal achieves dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},1 near its training configuration but drops to dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},2 below table offset dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},3 m. GOTT achieves dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},4 near the training configuration and dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},5 below that offset. GOTT’s failures are mainly associated with arm inverse-kinematics singularities under constrained end-effector orientations.

5.6 Ablation findings

The full unified policy achieves dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},6 average success. Removing link-position observations reduces this to dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},7, while using only one history frame reduces it to dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},8. Removing the contact reward or lift reward reduces average success to dmin⁡(hand,∂M)<ϵapproach,d_{\min}(\text{hand},\partial\mathcal M)<\epsilon_{\mathrm{approach}},9 and M\mathcal M0, respectively. Removing the distance reward gives M\mathcal M1 average success on training hands but reduces unseen-Allegro performance from M\mathcal M2 to M\mathcal M3.

These results associate performance with temporal proprioceptive history, explicit per-link geometry, contact reward, and lift reward. The distance term has a smaller effect on training-hand success but helps avoid finger inversion and distorted bending and improves morphology transfer.

6. Scope, limitations, and technical significance

GOTT’s sequential decomposition does not eliminate high-level planning failures. If the reach specification is poor, the acquisition policy may fail rather than request a revised plan. The approach also depends on SAM2 segmentation, FoundationPose tracking, calibrated hand kinematics, object meshes, and the mapping into canonical link and joint representations. Severe hand–object occlusion can corrupt pose estimates, and the current system does not use tactile or visuotactile sensing.

The move controller assumes an approximately fixed hand–object transform,

M\mathcal M4

which limits deliberate in-hand manipulation. Arm-specific reachability and inverse-kinematics feasibility remain necessary; the workspace experiments demonstrate that GOTT can still fail because of arm singularities or constrained orientations. The method is primarily evaluated on rigid-object grasp acquisition followed by object motion and does not establish universal performance for deformable objects, highly dynamic manipulation, tactile-only manipulation, or arbitrary changes in hand topology.

The central technical contribution is an interface between object-centric intent and embodiment-specific control:

M\mathcal M5

Its empirical significance lies in treating contact acquisition, rather than only grasp synthesis or trajectory tracking, as a reusable dexterous-control primitive. The reported results include M\mathcal M6 average simulated lifting success for the unified policy, M\mathcal M7, M\mathcal M8, and M\mathcal M9 real-world lifting success across three arm–hand platforms, TO,t∈SE(3)T_{O,t}\in SE(3)00 average end-to-end task success, and TO,t∈SE(3)T_{O,t}\in SE(3)01 zero-shot success on unseen Allegro variants. GOTT consequently provides a modular mechanism for connecting foundation-model, human-demonstration, video-derived, or manually specified object-centric intent to reliable multi-fingered robot execution.

Definition Search Book Streamline Icon: https://streamlinehq.com
References (1)

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to GOTT.