{"id":"af23ac41-3089-49be-97ad-534d6e022b99","arxiv_id":"2506.17832","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":7,"one_line_summary":"After equalizing objective, training data, and feedforward information, reinforcement-learned and geometric quadrotor controllers perform nearly equally, with RL better in fast transients and geometric control better in steady state.","lead":"This paper shows that many previous claims that learning-based drone controllers beat classical geometric controllers were based on unfair comparisons, where the classical controller was not tuned as carefully or given the same information about the future path. After fixing these imbalances, the two controller types perform much more similarly, each with its own strengths.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Simulation-only ranking may invert on hardware because the motor model is first-order with no latency; the RL/GC ordering in Table IV and the abstract's agility claim rest on this.","rationale":"The reader's weakest_assumption is exactly the simulation-only limitation, and I agree it is the most load-bearing. The paper's protocol contribution (three asymmetries and their correction) is well-supported by Fig 2 and the ablations; that part does not depend on hardware. However, the abstract and Sec VI draw class-level conclusions: 'GC performing better in relatively slow or less agile tasks, but RL performing better when greater agility is required.' These conclusions are supported only by IsaacSim rollouts with a first-order motor model and no latency. The internal inconsistencies the reader identified (Table IV reward row vs the claim that GC outperforms RL on reward; Table IX Hover rows vs the slow-task claim) are real but secondary; they are wording-and-interpretation issues that can be repaired in revision. The simulation-to-hardware gap is structurally more fundamental because it threatens the class-level ordering itself. I do not think the concern warrants rejection: the authors explicitly acknowledge the limitation, they include domain-randomization and realistic-dynamics ablations, and they open-source the environment, so the comparison protocol is reproducible. CONDITIONAL is the right verdict: the class-level conclusions should be reworded as simulation-grounded or a hardware/high-fidelity check should be added before the qualitative claims about controller classes are relied upon.","tokens_in":17675,"tokens_out":1562,"duration_ms":14930,"concrete_test":"Run an identical best-of-best comparison (RL-Opt-Liss-FF vs GC-Opt-Liss-FF, same 1000-rollout protocol and same task/initial-condition distributions) on a real quadrotor or on a high-fidelity simulator incorporating measured motor latency, rotor drag, and actuator saturation (e.g., a Crazyflie-class platform with identified first-order-plus-delay motor model). If the position-RMSE and steady-state ordering in Table IV and Fig 3 changes (for example, GC no longer converges to zero or RL no longer shows transient advantage), the paper's class-level conclusions must be downgraded from general claims to simulator-specific findings; if the ordering persists, the concern is resolved.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim is that after symmetric optimization, data, and feedforward access, RL and GC perform near-parity, with GC better in steady state/slow tasks and RL better in transient/agile tasks. The load-bearing support for the ordering is the simulated dynamics in IsaacSim with a first-order motor model (Appendix D), and the authors explicitly acknowledge in Sec VI that all evaluations are in simulation. A first-order motor delay with no latency, no rotor drag, and no actuator saturation dynamics can favor GC because GC is derived from exactly the rigid-body-plus-first-order-motor assumptions, whereas RL can exploit the learned dynamics. Conversely, if real motors have higher-order lag, RPM limits, or voltage/speed coupling, the learned policy may retain transient advantage, so the near-parity and the specific GC steady-state advantage could change on hardware. This is not an internal inconsistency, but it is the least secure link in the central claim: the headline conclusions are stated as general properties of the two controller classes, not as properties of this simulator. The authors concede this in Sec VI, so the concern is a scope limitation rather than a protocol error, but it is load-bearing because the abstract makes comparative claims about controller classes, not about the simulator.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper addresses the methodology of comparing reinforcement-learned (RL) and geometric (GC) controllers for quadrotor trajectory tracking. It identifies three asymmetries in prior comparisons—access to the task objective, access to representative training data, and access to feedforward trajectory information—and proposes a symmetric protocol: optimizing both controllers on the same reward, tuning GC gains automatically (rather than by hand), and giving both controllers a horizon of future waypoints. Experiments in IsaacSim/IsaacLab on a quadrotor and a fixed-arm aerial manipulator show that correcting each asymmetry significantly improves GC performance and that, after leveling the playing field, RL and GC achieve near-parity in tracking quality. The paper further reports that GC has lower steady-state error while RL has better transient performance, and it demonstrates a ball-catching task where RL's transient advantage leads to higher catch rates. The authors open-source their simulator environments, controller implementations, and tuning code.","tokens_in":17812,"tokens_out":9813,"duration_ms":92975,"significance":"The paper makes a useful and timely contribution to the empirical comparison of learned and classical control methods. Its systematic isolation of three fairness asymmetries is a valuable methodological template: the experiments in Fig. 2 convincingly show that optimization objective, training data, and feedforward information each affect measured performance gaps. The open-source release of both controller implementations and the simulation environment is a practical contribution that should benefit the community. If the results hold, the finding that the RL/GC gap is much smaller than previously reported is an important corrective to a strongly held belief. However, the paper's directional claims about which controller class is better in which operating regime are not fully supported by its own data, and the simulation-only evidence limits the generality of the conclusions. The central protocol improvements are sound and independently valuable; the main weaknesses are in the interpretation and scoping of the results.","major_comments":[{"comment":"The conclusion in Section V-C and the abstract that 'GC performs better in relatively slow or less agile tasks' is contradicted by the paper's own numerical results. In the Hover task, which is the least agile task considered, Table IX reports that GC-Opt-Hover-None has a lower average reward (13.756 vs 13.918) and higher position RMSE (0.355 m vs 0.327 m) than RL-Opt-Hover-None, with only yaw RMSE favoring GC. In the Lissajous tracking task, Table IV shows that GC has higher average reward than RL only on the aerial manipulator (13.792 vs 13.621), while on the quadrotor RL has a higher reward (14.196 vs 13.447) and lower position RMSE on both morphologies. The text in Section V-C states 'GC outperforms RL on the reward objective' but this is not supported for the quadrotor, where RL's reward is larger. The authors should remove or substantially weaken the directional claim about less agile tasks, or re-analyze the data (e.g., by separating transient and steady-state error) to support it.","section":"Section V-C and Tables IV and IX"},{"comment":"The feedforward protocol for the GC is not implemented or reported in sufficient detail to support the claim that both controllers are 'best-in-class'. The paper states that a horizon of H=10 future positions and yaws is appended to the observation for both controllers and that this allows the GC to approximate high-order derivatives via finite differencing, but it does not specify the finite-difference scheme, the order/accuracy of the approximation, or how these approximate derivatives are substituted into the GC control law (Eqs. 6-9). This is a load-bearing detail because the standard geometric controller is designed to use exact reference derivatives. If the GC's derivatives are approximated from a relatively short horizon, the GC may be handicapped relative to its true best-in-class implementation. The manuscript should provide the finite-difference implementation and include an ablation comparing GC with exact derivatives versus the finite-difference version used here; without this, the measured near-parity could be an artifact of a suboptimal GC feedforward implementation.","section":"Section IV-C and Appendix B"},{"comment":"The headline conclusions are stated as general properties of the two controller classes, but all evaluations are performed in IsaacSim with a specific simulated dynamics model: a rigid body with a first-order motor model and no controller delay (Appendix D). The authors do acknowledge in Section VI that the evaluations are 'in simulation as opposed to on real hardware' and list this as a limitation, and they do include domain randomization (Table VI) and realistic dynamics (Table VII) ablations. However, the abstract and conclusions do not carry this qualification, so readers may take the directional claims (e.g., 'GC performing better in relatively slow or less agile tasks') as established for real platforms. Since the relative ordering could plausibly change with real actuator lag, saturation, or model mismatch, the central claims should be explicitly scoped to the simulated setting, or at least accompanied by a clear statement that hardware validation is future work.","section":"Section VI and Abstract"}],"minor_comments":[{"comment":"Controller naming is inconsistent across tables and text: for example, 'RL-Opt-Liss.-FF' in Table IV and 'RL-Opt-Lissajous-FF' in Table IX refer to the same model, and Section V-F uses 'GC-Complex' while Table VII uses 'GC-Realistic'. Please standardize the names.","section":"Throughout"},{"comment":"The caption says 'Results are shown as mean catch rate over 100 trials' but the text says '100 evaluations of 5 catch opportunities each'. Please clarify whether the reported success rates are per catch attempt or per 5-catch episode, and include confidence intervals or standard errors.","section":"Table V"},{"comment":"The reward function uses an exponential kernel for position error but an unweighted absolute-value term for yaw error; it is not stated whether the yaw error is wrapped to [-pi, pi] or computed as a geodesic distance, which affects the reward value and the GC tuning objective.","section":"Eq. (3)"},{"comment":"The 'Normalized Gap to Max Reward' metric is not defined precisely. Please specify the normalization (e.g., relative to the maximum reward of 15.0) and state whether the 1000 evaluations are sufficient for the median/inter-quartile comparisons to be statistically distinguishable.","section":"Section V-B (Fig. 2)"},{"comment":"Equations (6)-(9) rely on both position and orientation errors, but the observer that provides the state (position, orientation, velocities) to the GC is not described. If the GC is assumed to have perfect state feedback, this should be stated explicitly, along with the RL policy's observation assumptions, so that the comparison is transparent.","section":"Appendix B"},{"comment":"There is a typo in 'throughly benchmark' in Section I; also, the definition of the RL policy's action space and the scaling to thrust/moment limits (Section III-B) could be made more explicit by citing the platform's limits.","section":"Section I"}],"recommendation":"major_revision","confidential_remarks":"The paper's methodological contribution is strong and the open-source release is valuable. The main concern is that several central claims overstate what the data show. In particular, the abstract's statement that GC performs better in less agile tasks is contradicted by the Hover results in Table IX, and the feedforward implementation for GC is underspecified, making it hard to verify the 'best-in-class' claim. These issues are fixable with revised analysis and additional ablations, so I recommend major revision rather than rejection. The simulation-only limitation is acknowledged but should be more visible in the abstract and conclusions."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my read on arXiv:2506.17832. The paper identifies three real asymmetries in prior RL-vs-GC comparisons—objective, dataset, feedforward—and systematically corrects all three. The ablation in Fig. 2 convincingly shows each asymmetry matters, and the open-source implementation is a genuine service to the community. The central empirical finding, that after symmetric optimization the two controller classes are near-parity in simulation, is credible and should dampen some of the 'RL beats classical' hype.\n\nThat said, the paper overreaches in its summary claims. The statement that 'GC outperforms RL on the reward objective' is directly contradicted by Table IV on the quadrotor: RL's average reward is 14.196 vs GC's 13.447. The abstract's claim that GC performs better in 'slow or less agile tasks' is not supported by the data either—the Hover results in Table IX show RL with slightly higher reward and lower position RMSE, and there is no slow-trajectory condition anywhere in the experiments. These are secondary claims, but they appear in the abstract and discussion, so they need correction or at least careful qualification. The absence of any significance testing or effect sizes is also a real weakness; the standard deviations overlap substantially, so the qualitative ordering claims are shakier than the text suggests.\n\nThe stress-test concern about simulation-only evaluation is legitimate but not a protocol error. The first-order motor model with no latency may rank controllers differently than hardware would, and the authors concede this in Sec. VI. Still, the headline conclusions are about controller classes, not just this simulator, so the lack of hardware validation places a real limit on how far the claims should travel.\n\nThe core benchmarking protocol is a solid contribution and deserves to be widely used. The near-parity finding is important even if the secondary ordering claims need reining in. I'd send this to peer review with the expectation of major revision: fix the overclaims, add significance tests or effect sizes, and ideally include a slow-trajectory condition or make the agility-based ordering claim explicitly contingent on the simulation results.","headline":"A genuinely useful benchmarking protocol for RL-vs-classical comparisons, with credible near-parity results in simulation, but the paper overclaims in a couple of places and lacks hardware validation.","tokens_in":18451,"tokens_out":3646,"would_cite":true,"duration_ms":36865,"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":"After equalizing the task objective, training data, and feedforward information, reinforcement-learned and geometric quadrotor controllers perform nearly on par, with geometric control winning on steady-state error and RL winning on fast…","keywords":["quadrotor control","reinforcement learning","geometric control","trajectory tracking","benchmarking methodology","aerial manipulation","feedforward information","simulation-to-real transfer"],"falsifier":"Run the paper's best-in-class RL and GC controllers, with the same reward, the same tracking data, and the same 10-step lookahead, on a physical quadrotor with a fixed arm from the same set of initial perturbations, and plot position and yaw error over time; if GC's steady-state error does not converge to zero while RL retains its offset, or if RL's early-time error reduction is not faster than GC's, the central near-parity claim is falsified on hardware.","tokens_in":17357,"feed_emoji":"⚖️","tokens_out":11765,"duration_ms":111573,"temperature":0.7,"pith_summary":"This paper argues that the widely reported superiority of reinforcement learning over classical geometric control for quadrotor trajectory tracking is largely a benchmarking artifact. It identifies three ways prior comparisons favored RL: RL was optimized on the exact task objective and data while the classical controller was hand-tuned or tuned on hover data, and only RL was given information about the future trajectory. After equalizing these three factors, the paper finds the two controller classes perform about on par, with geometric control reaching lower steady-state error and RL recovering faster from large perturbations. The authors argue this protocol should be the default for comparing learned and model-based controllers, because each asymmetry alone can shift the apparent winner. The practical stakes are concrete: for slow tracking, classical control is better, while for agile, transient-dominated tasks such as catching a thrown ball, RL wins.","feed_headline":"Fair tests shrink the RL-vs-classical drone controller gap","feed_subtitle":"When both controllers get the same objective, data, and lookahead, the reported RL advantage mostly disappears.","key_machinery":"The mechanism is a symmetric benchmarking protocol that equalizes three previously asymmetric resources between controller classes: (1) the objective function, a single reward combining position, yaw, velocity, and angular-velocity error terms, used both to train RL and to automatically tune GC gains; (2) the data, with both classes optimized on rollouts from the same task distribution rather than a hand-tuned hover baseline; and (3) feedforward information, with both controllers receiving a horizon of $H=10$ future position and yaw waypoints, which GC uses to estimate high-order reference derivatives and RL simply appends to its policy observation. This protocol is what isolates differences in controller synthesis itself from differences in access to task information.","core_discovery":"The paper's central claim is that the performance gap between RL and geometric controllers shrinks to near-parity once the comparison is symmetric. The paper demonstrates this by isolating each asymmetry: optimizing GC gains with the same reward function used to train RL, tuning or training both controller classes on data from the same task distribution, and giving both controllers the same horizon of future waypoints ($H=10$). In the best-versus-best tracking comparison on a quadrotor, RL's position RMSE is $0.119$ m versus GC's $0.158$ m, but the time-series shows GC's error converging toward zero while RL retains a steady-state offset. The result is a regime split rather than a clear winner: GC has better steady-state behavior, while RL has better transient behavior, so conclusions about which class is superior depend on which phase of tracking the task emphasizes. This directly challenges the common literature claim that RL outperforms geometric control for agile trajectory tracking.","pith_inferences":["A natural extension is to apply the same three-way equalization to other learned-versus-classical benchmarks, such as RL versus model predictive control, where the classical side is often hand-tuned; the protocol would separate 'better controller' from 'better baseline tuning' claims.","The feedforward-horizon manipulation offers a direct test of why RL has a transient advantage: varying $H$ for both classes should continuously trade transient recovery against steady-state offset, and if RL's advantage persists even at very large $H$, the advantage comes from the learned policy rather than from lookahead access.","Because the paper's evaluations are simulated, the protocol's conclusions about which class wins which regime are predictions for hardware; repeating the exact protocol on a real platform would show whether the steady-state/transient split survives motor delay, saturation, and estimation noise."],"forward_implications":["Previous comparisons that pitted RL against hand-tuned, hover-tuned, or feedforward-less geometric controllers should be re-run under the symmetric protocol; the paper's asymmetry experiments show each of these choices alone widens the apparent gap.","For applications dominated by steady-state tracking, such as slow or less agile flight, geometric control is the better choice because its error converges to zero and it can match RL on the overall reward.","For applications dominated by transient response, such as recovering from a large perturbation or catching a thrown ball, RL is the better choice; in the paper's ball-catching test, the end-effector RL policy catches 65% of balls at the hardest time-to-catch setting versus 30% for GC.","Reporting only RMSE can mislead, because RMSE conflates a large initial transient with asymptotic offset; the paper shows two controllers can have close RMSE yet differ in which phase of tracking they handle well.","The open-source implementations give future studies a ready-made, equalized basis for measuring new learned or model-based controllers against strong baselines of both classes."],"supporting_citations":[{"why":"Supplies the Bayesian optimization-based automatic tuning used to give GC the same objective-driven parameter search as RL.","marker":"[1]"},{"why":"The prior deep-learning tracking work whose claimed advantage over a classical controller, a feedforward-less PID baseline, is re-examined as an asymmetric comparison.","marker":"[12]"},{"why":"Provides the geometric SE(3) control law that defines the GC controller class benchmarked here.","marker":"[15]"},{"why":"Introduces the differentially flat quadrotor controller lineage from which the GC cascade is derived.","marker":"[18]"},{"why":"A sim-to-real RL study whose classical baseline was a hover-tuned controller, illustrating asymmetric data access.","marker":"[20]"},{"why":"Supplies the massively parallel simulator-based RL training setup used to optimize the RL policy.","marker":"[22]"},{"why":"Provides the policy-gradient optimization algorithm used to train the RL policy.","marker":"[23]"},{"why":"Supplies the reward function and body-frame error observation representation this paper adapts for both controller classes.","marker":"[29]"}],"fun_headline_variants":["Fair drone tests shrink RL vs classical controller gap","RL drone edge vanishes when comparisons are fair","Steady-state vs agility: drone controller truth from fair tests","No winner: RL and geometric drone controllers after leveling","Drone tracking: RL leads transient, GC leads steady-state"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The entire ranking comes from simulation, so the load-bearing assumption is that the simulated rigid-body-plus-motor-delay dynamics behave like a real quadrotor in the ways that separate the two controller classes; if hardware differs in a class-dependent way, the measured near-parity could vanish.","fun_headline_variants_meta":{"raw":{"variants":["Fair drone tests shrink RL vs classical controller gap","RL drone edge vanishes when comparisons are fair","Steady-state vs agility: drone controller truth from fair tests","No winner: RL and geometric drone controllers after leveling","Drone tracking: RL leads transient, GC leads steady-state"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000771,"raw_usage":{"total_tokens":3470,"prompt_tokens":1056,"completion_tokens":2414,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":672,"completion_tokens_details":{"reasoning_tokens":2336}},"tokens_in":672,"tokens_out":2414,"duration_ms":16872,"temperature":1.0,"reasoning_tokens":2336,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T19:00:03.200535+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the paper's best-in-class RL and GC controllers, with the same reward, the same tracking data, and the same 10-step lookahead, on a physical quadrotor with a fixed arm from the same set of initial perturbations, and plot position and yaw error over time; if GC's steady-state error does not converge to zero while RL retains its offset, or if RL's early-time error reduction is not faster than GC's, the central near-parity claim is falsified on hardware.","supporting_citations":[{"cited_title":"Datt: Deep adaptive trajectory tracking for quadrotor control","cited_arxiv_id":null,"evidence_quote":"The prior deep-learning tracking work whose claimed advantage over a classical controller, a feedforward-less PID baseline, is re-examined as an asymmetric comparison."},{"cited_title":"Geometric tracking control of a quadrotor uav on se (3)","cited_arxiv_id":null,"evidence_quote":"Provides the geometric SE(3) control law that defines the GC controller class benchmarked here."},{"cited_title":"Design, modeling, estimation and control for aerial grasping and manipulation","cited_arxiv_id":null,"evidence_quote":"Introduces the differentially flat quadrotor controller lineage from which the GC cascade is derived."},{"cited_title":"Sim-to- (multi)-real: Transfer of low-level robust control policies to multiple quadrotors","cited_arxiv_id":null,"evidence_quote":"A sim-to-real RL study whose classical baseline was a hover-tuned controller, illustrating asymmetric data access."},{"cited_title":"Learning to walk in minutes using massively par- allel deep reinforcement learning","cited_arxiv_id":null,"evidence_quote":"Supplies the massively parallel simulator-based RL training setup used to optimize the RL policy."},{"cited_title":"Leveraging Symmetry to Accelerate Learning of Trajectory Tracking Controllers for Free-Flying Robotic Systems","cited_arxiv_id":"2409.11238","evidence_quote":"Supplies the reward function and body-frame error observation representation this paper adapts for both controller classes."}],"review_version":1}