{"id":"0f2e64f1-92f0-4e59-8afc-9e5bc5159c05","arxiv_id":"2505.00991","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":5,"one_line_summary":"DexCtrl jointly predicts joint actions and adaptive PD controller gains from proprioceptive history, improving sim-to-real transfer for dexterous manipulation tasks.","lead":"This paper presents DexCtrl, a method that makes a simulated dexterous hand policy also predict the stiffness and damping gains of its joint controller, adjusting them every step from recent history. The idea is to reduce the sim-to-real gap caused by controller mismatches without manual gain tuning or heavy randomization, and tests on in-hand rotation and flipping show gains over fixed-gain baselines.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Control-parameter module is trained with oracle actions as its cross-attention query but deployed with student-predicted actions, so the adaptive gains are learned under a different input distribution; this train/test mismatch is not addressed.","rationale":"The paper's real-world rotation results provide some empirical support for the central claim, and the adaptive-gain idea is clearly motivated. The reader's CONDITIONAL verdict is appropriate. However, the most load-bearing technical concern is not exactly the one the reader emphasized. Rather than the fidelity of the diagonal PD controller or the sufficiency of ten history steps, the sharper issue is an internal train/test mismatch: the control-parameter module is trained open-loop with oracle actions as queries, while deployment feeds it student-predicted actions. The paper provides no mechanism to make the K module robust to this shift, and the only stated noise injection targets current joint trajectories, not the query action. This matters because the entire contribution hinges on the learned relationship between actions and controller parameters being valid under the deployed policy. The proposed concrete test—retraining with student-predicted action queries and re-evaluating on the same objects—would settle whether the Table 3 margin is a genuine effect of the adaptive-gain mechanism or an artifact of the training distribution. Since this is an addressable verification requirement rather than a demonstrated failure, the verdict remains CONDITIONAL, matching the reader's assessment. Independent support in the paper is limited: all quantitative tables lack error bars, no code or data is provided, and the flipping evidence is mostly qualitative, so the extra condition is warranted.","tokens_in":9599,"tokens_out":9023,"duration_ms":105593,"concrete_test":"Retrain the control-parameter module using the action module's predicted action â_t as the cross-attention query (or â_t plus Gaussian query noise matched to the action module's error distribution), keeping all other training details unchanged. Then re-run the closed-loop rotation evaluation in simulation, and if the simulation margin persists, on the same twelve real objects. If the retrained variant's RotR margin over Ours w/o PD collapses toward zero, the current adaptive-gain advantage is an artifact of oracle-action training queries; if the margin remains comparable to Table 3, the train/test mismatch is not the cause of the reported improvement.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3.2 defines the control-parameter module as cross-attention where 'current action serves as query and historical input serves as key and value,' and states that training is open-loop with 'all input data is directly retrieved from the collected simulation dataset.' In Figure 2a, the control-parameter module receives only the state s_t and is trained against the oracle's K_t; in Figure 2b, it receives the action module's predicted action â_t as the query. Thus the K module never sees student-predicted actions during training. At deployment, any deviation of â_t from the oracle action is an out-of-distribution query, and the K module may return gains that were never paired with such an action in training. The only robustness mechanism mentioned—Gaussian noise added to current trajectory values during student training (Section 3.2)—does not cover the query action. This is load-bearing because the paper's central claim is that jointly predicting actions and controller parameters improves sim-to-real transfer; the real-world advantage in Table 3 (RotR 11.04 versus 4.99 for Ours w/o PD) could partly reflect a favorable accident of this mismatch rather than a learned action-K relationship. A secondary but related concern is that the K module's inputs also include its own previously predicted K values at inference, whereas training uses oracle K values, compounding the distribution shift.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes DexCtrl, a sim-to-real transfer framework for dexterous manipulation in which a student policy is distilled from a simulation-trained RL oracle into two modules: an action prediction module and a control-parameter prediction module. At each step the action module outputs desired joint positions from a ten-step history of proprioception, and the control-parameter module outputs diagonal PD gains K = {K_P, K_D} using the current predicted action as a cross-attention query. The authors argue that jointly predicting actions and controller parameters adaptively reduces the low-level controller gap, avoiding manual tuning and heavy randomization. The method is evaluated on two contact-rich tasks, in-hand rotation and flipping, on the LEAP hand, both in simulation and on real hardware, with comparisons against a manually tuned baseline and an action-only ablation (Ours w/o PD). The main empirical result is a real-world rotation advantage: DexCtrl achieves an average RotR of 11.04 versus 4.99 for Ours w/o PD and 2.43 for manual tuning (Table 3).","tokens_in":9909,"tokens_out":4579,"duration_ms":49232,"significance":"If the central claim holds, DexCtrl identifies controller-parameter mismatch as a distinct and addressable component of the sim-to-real gap, offering a practical alternative to manual gain tuning and aggressive domain randomization. The paper has genuine strengths: the real-world rotation evaluation uses unseen objects and is a real transfer test; the ablation Ours w/o PD isolates the contribution of adaptive gains; and the analysis in Section 4.5 relating learned stiffness to object mass and friction is a useful first step toward interpreting the mechanism. The paper also explicitly acknowledges its limitations, including the absence of force/tactile sensing and the restriction to a single hardware platform. However, the current evidence is not yet conclusive: the train/test distribution shift in the control-parameter module is unaddressed, the quantitative claims lack statistical support, and the real-world flipping evaluation is only qualitative. These issues are fixable within the manuscript's scope, so the appropriate decision is major revision rather than rejection.","major_comments":[{"comment":"The control-parameter module is trained open-loop with oracle actions as the cross-attention query and oracle K values in the historical input, but at deployment the query is the student-predicted action â_t and the history contains previously predicted K values. The Gaussian noise added to current trajectory values during student training does not cover either of these shifted inputs. Because the paper's central claim is that jointly predicting actions and controller parameters improves transfer, the real-world gain of DexCtrl over Ours w/o PD (Table 3, RotR 11.04 vs 4.99) could reflect behavior under this out-of-distribution query rather than a genuinely learned action–K relationship. Please add an experiment that isolates this effect, for example evaluating the K module at inference with oracle actions as queries versus student-predicted actions, or fine-tuning with closed-loop student rollouts in a DAgger-style procedure, and report both RotR and K-module prediction error.","section":"§3.2, Fig. 2"},{"comment":"All quantitative tables report only mean values, with no standard deviations, per-trial distributions, or trial counts, despite repeated claims of 'significant' improvement in Sections 4.2–4.4. In addition, the text states that twelve real-world objects were used for rotation, but Table 3 lists only five objects (Cube, Bottle, Apple, Yogurt, Baseball), and the real-world flipping claim rests on a visualization (Figure 3) rather than a quantitative table. Please provide per-trial data or at least standard deviations and trial counts for every table, clarify the twelve-object discrepancy, and either add quantitative flipping results or temper the corresponding claim.","section":"§4.3, Tables 3–4"},{"comment":"The simulation experiments in Tables 1 and 2 also report only means, and the claim that DexCtrl 'significantly outperforms' the baselines is not supported by any uncertainty quantification or significance test. Since these tables are used to support the fundamental claim that adaptive controller parameters improve performance even without a controller gap, please report standard deviations or confidence intervals over the 1024 randomized initial poses, and state whether the differences are statistically significant.","section":"§4.2, Tables 1–2"}],"minor_comments":[{"comment":"The text says 'twelve different real-world unseen objects' but Table 3 has five object columns; please make the object count and selection procedure consistent between text and table.","section":"§4.3"},{"comment":"The baseline name 'Ours w/o PD' is potentially misleading: the ablation removes the adaptive PD parameter prediction module but retains a PD torque controller. A name such as 'Ours w/o adaptive K' or 'Ours w/ fixed K' would be clearer.","section":"§4.1"},{"comment":"The sentence 'the lightest and smoothest objects exhibit the highest speed and lowest stability, respectively' is not fully supported by Table 4: the friction-small RotR is 10.414, friction-medium is 9.386, and friction-large is 10.681, so the friction trend is not monotonic. Please either qualify this statement or provide additional evidence.","section":"§4.4"},{"comment":"The notation [q_d, q̇_d] ∈ R^32 and [q_c, q̇_c] ∈ R^32 is slightly confusing because q_d and q̇_d are each 16-dimensional; consider stating this explicitly to avoid an apparent dimension mismatch in Eq. (1).","section":"§2"},{"comment":"The hardware name is written inconsistently as 'LEAP hand' in Section 2 and 'LeapHand' in Section 7; please unify the capitalization.","section":"Global"}],"recommendation":"major_revision","confidential_remarks":"The paper presents a promising idea and a genuine hardware evaluation, but the empirical reporting and the unresolved train/test distribution shift in the K module are substantial enough that I recommend major revision. The real-world rotation result is the paper's strongest asset, and the proposed isolation experiment (oracle-action query vs predicted-action query) would directly test whether the learned action–K coupling is the source of the gain. I would not reject: the issues are addressable within the paper's scope, and the central claim remains defensible if the requested experiments and statistics are added."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThe headline is simple: this paper has a genuinely useful idea—predicting diagonal PD gains together with joint actions from a window of proprioceptive history—and it shows real-robot rotation results that beat manual tuning and an action-only variant by a large margin (RotR 11.0 vs 2.4 and 5.0). That margin is the strongest evidence in the paper. The combination is new relative to the cited RMA and spin-pen work, and the cross-attention design for gain prediction is a sensible way to condition gains on the current action.\n\nThe soft spots are real but fixable. First, the gain module is trained open-loop with the oracle action as the cross-attention query, but at deployment it sees the student’s predicted action. Nothing in the paper addresses that distribution shift; Gaussian noise on trajectory observations does not cover the query action. The real-world advantage could partly come from the gains being useful regardless of that mismatch, but the paper doesn’t disentangle this. Second, all tables report means only, yet the text claims “significantly outperforms.” There are no error bars or significance tests. The real-world rotation table lists five objects while the text says twelve, which needs reconciling. Flipping evidence is qualitative. Third, an appendix is referenced for reward details but is missing in this version, and no code or data is provided, which undercuts reproducibility. The load-bearing assumption that a diagonal PD controller with gains learned in simulation transfers to the real LEAP hand is not independently verified, though the hardware results suggest it works reasonably well.\n\nWhat the paper does well: the learned stiffness analysis (Figures 6 and 7) shows the gains respond systematically to object mass and friction, supporting the interpretation. The limitations paragraph honestly states the proprioception-only sensing and the single-platform evaluation. The related work is relevant and not overloaded with self-citations.\n\nOverall, the central claim is plausible and supported, but the evidence is less rigorous than the text implies. The paper deserves peer review; a referee should ask for error bars, a resolution of the object-count discrepancy, and either an analysis or an experiment addressing the action-query mismatch (e.g., fine-tuning the gain module with student actions or adding action noise during training). I’d bring it to a reading group: the idea is worth discussing and the mismatch is a good teaching case.\n\nRecommendation: send it to peer review, and expect revision.","headline":"Jointly predicting PD gains with actions is a plausible and apparently effective sim-to-real idea, but the evidence is thinly reported and the gain module has an unaddressed train/test mismatch.","tokens_in":10430,"tokens_out":3870,"would_cite":true,"duration_ms":38295,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"DexCtrl claims that jointly predicting actions and controller parameters from recent joint history closes more of the sim-to-real gap than fixed-gain tuning.","keywords":["dexterous manipulation","sim-to-real transfer","adaptive control","controller parameter prediction","in-hand rotation","object flipping","proprioception","reinforcement learning"],"falsifier":"Run the same DexCtrl action sequence on the real hand with the predicted gains frozen at their time-averaged values. If rotation speed stays near the adaptive value, per-step gain variation is not the causal driver; if it collapses toward the action-only baseline, the adaptive gain schedule is doing the work.","tokens_in":9424,"feed_emoji":"🖐️","tokens_out":6648,"duration_ms":59091,"temperature":0.7,"pith_summary":"This paper identifies the low-level torque controller as a neglected source of the sim-to-real gap in dexterous manipulation: the same desired joint trajectory produces different contact forces when gains differ. It proposes DexCtrl, which on every control step outputs not only the next desired joint position but also the diagonal PD gains $K_P$ and $K_D$, using the past ten steps of desired and actual joint trajectories plus previous gains. A policy trained this way adapts stiffness and damping during execution, so the sim-to-real mismatch is addressed without manual gain tuning or heavy controller randomization. In real-world tests on a 16-DOF hand, DexCtrl's average rotation speed was 11.04 compared with 2.43 for a manually tuned fixed-gain baseline and 4.99 for an action-only variant, and the method also generalized to a table-flipping task.","feed_headline":"Adaptive gains beat hand-tuned controllers in real dexterity","feed_subtitle":"Jointly predicting actions and stiffness from joint history lifts in-hand rotation on a 16-DOF hand without manual tuning.","key_machinery":"The load-bearing mechanism is a per-step diagonal PD torque controller, $\\tau = K_P(q_d - q_c) + K_D(\\dot{q}_d - \\dot{q}_c)$, whose gain vector $K = \\{K_P, K_D\\} \\in \\mathbb{R}^{32}$ is predicted at every time step alongside the desired joint action. A self-attention module maps the last ten steps of desired and actual joint trajectories to the next action, and a cross-attention module uses the predicted action as query against the same history to produce the next gains. During training, an oracle PPO policy with access to object properties collects data in simulation, and two student modules are distilled from that data in open loop; at deployment the modules run closed loop with real sensor readings, with gains linearly mapped from simulation to the real system using only approximate upper and lower bounds. This design also puts controller parameters in the observation, so force interactions can be reasoned about from proprioception alone.","core_discovery":"The central claim is that controller parameters should be treated as part of the policy's output and observation, not as fixed training hyperparameters. By jointly predicting actions and gains from proprioceptive history, the policy can estimate the manipulated object's mass and friction from ten steps of joint data alone, without vision or force sensing, and can adjust contact forces to keep the object stably rotating or flipping. The paper shows the learned stiffness responds systematically to object properties: predicted $K_P$ rises with object mass, while friction produces task- and joint-specific stiffness patterns. On hardware with unseen objects, this adaptive gain schedule substantially outperforms both manual tuning and an action-only variant, and the gap is larger in the real world than in simulation, which the paper takes as evidence that per-step gain adjustment is exactly what the sim-to-real gap requires.","pith_inferences":["The predicted gain schedule can be read as an implicit mass-and-friction estimator: because stiffness separates systematically by object mass, the cross-attention module could be reused for proprioceptive system identification.","If the gain prediction module is as transferable as the action module, the paper's future plan of sharing one controller-parameter module across tasks is likely to work; a concrete test is training the module on rotation and evaluating it on flipping without retraining.","With force or tactile feedback added, the rough linear gain mapping could be replaced by online fine-tuning, which would likely improve contact-rich cases where ten steps of history cannot fully disambiguate state.","The underlying principle, making controller gains a learned output rather than a randomized or hand-tuned fixed value, should apply to other impedance-controlled contact tasks such as assembly or insertion, where the same PD torque law governs behavior."],"forward_implications":["In zero-shot real-world transfer, DexCtrl's average RotR is 11.04, versus 2.43 for manual tuning and 4.99 for the action-only variant.","DexCtrl improves over the manual-tuning baseline even when there is no controller gap in simulation, so adaptive gains help stability and speed beyond domain adaptation.","Including controller parameters in the observation lets the policy reason about contact forces without vision, force, or tactile sensing.","Only approximate upper and lower gain bounds are needed for the sim-to-real mapping, reducing the human tuning burden.","The same method transfers to a flipping task, where contact with the table makes the task more sensitive to gain variation."],"supporting_citations":[{"why":"Defines the manual-tuning baseline: an oracle policy trained with carefully tuned fixed controller parameters and small randomization, which DexCtrl is compared against in sim and real.","marker":"[5]"},{"why":"Supplies the idea of distilling object properties from ten steps of historical proprioception, plus the RotR and TTF evaluation metrics.","marker":"[6]"},{"why":"Provides the action-only student policy design and the controller-randomization strategy used as a baseline.","marker":"[7]"},{"why":"Supplies the similar action-prediction-from-historical-trajectory formulation that the action module builds on.","marker":"[8]"},{"why":"Exemplifies the controller-parameter randomization approach that the paper argues increases training difficulty.","marker":"[12]"}],"fun_headline_variants":["DexCtrl: Learn gains, not just actions, for real dexterity","Adaptive stiffness from history boosts sim-to-real dexterity","Controller gains learned on the fly close sim-to-real gap","No manual tuning: DexCtrl learns gains from joint history","On real hardware, learned gains outperform hand-tuned ones"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The approach assumes that a diagonal PD controller with only two gains per joint describes the real hand's low-level dynamics well enough that gains learned in simulation remain meaningful after a rough linear mapping, and that ten steps of joint history can infer the object's mass and friction without vision or tactile feedback.","fun_headline_variants_meta":{"raw":{"variants":["DexCtrl: Learn gains, not just actions, for real dexterity","Adaptive stiffness from history boosts sim-to-real dexterity","Controller gains learned on the fly close sim-to-real gap","No manual tuning: DexCtrl learns gains from joint history","On real hardware, learned gains outperform hand-tuned ones"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000972,"raw_usage":{"total_tokens":4104,"prompt_tokens":889,"completion_tokens":3215,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":505,"completion_tokens_details":{"reasoning_tokens":3128}},"tokens_in":505,"tokens_out":3215,"duration_ms":21239,"temperature":1.0,"reasoning_tokens":3128,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T04:29:41.506475+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same DexCtrl action sequence on the real hand with the predicted gains frozen at their time-averaged values. If rotation speed stays near the adaptive value, per-step gain variation is not the causal driver; if it collapses toward the action-only baseline, the adaptive gain schedule is doing the work.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the manual-tuning baseline: an oracle policy trained with carefully tuned fixed controller parameters and small randomization, which DexCtrl is compared against in sim and real."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the action-only student policy design and the controller-randomization strategy used as a baseline."}],"review_version":1}