{"id":"fbbd75bc-5b2d-44a3-8c5f-6571868188b6","arxiv_id":"2411.08851","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"E-ARC reuses a small database of subproblem solutions to resolve multi-robot conflicts, improving planning efficiency over standard ARC and full-database Lightning at scales up to 32 mobile and 16 manipulator robots.","lead":"This paper introduces E-ARC, a planning method that resolves collisions between multiple robots by reusing precomputed solutions to small, local coordination problems. It reports faster planning than prior methods in simulations with up to 32 mobile robots and 16 manipulator robots.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The claimed speedup hinges on the unverified premise that conflicts are mostly low-dimensional; the paper never measures the database hit rate, so the central claim is not yet supported.","rationale":"The reader's weakest assumption identifies the locality premise, and I agree that premise is load-bearing: the database is only useful if the subproblems that actually arise are low-dimensional. However, the paper's reported speedups over ARC, if taken at face value, already suggest the database helps in the tested scenarios. The more direct gap is that the paper never measures how often the database actually resolves a conflict versus falling back to ARC. Without a hit-rate measurement, the speedup could in principle come from unstated implementation details or from an easier trial distribution rather than from the database retrieval mechanism itself. This matters because the central claim is explicitly about 'using a database' to achieve scalability. Additionally, the lack of error bars or statistical tests makes it impossible to know whether the 1.3–1.7x speedups over ARC are real or within sampling noise. The proposed instrumentation check would settle both questions in one run: it quantifies the hit rate and provides confidence intervals for the time differences. I do not see an internal inconsistency or a fundamental algorithmic flaw; the method is a reasonable extension of ARC. The verdict should remain conditional until such evidence is provided, matching the reader's assessment.","tokens_in":9839,"tokens_out":8675,"duration_ms":77586,"concrete_test":"Instrument E-ARC to log per-conflict resolution outcomes: number of subproblems, dimensionality, method used (database vs fallback), and time spent; re-run the four reported scenarios (mobile with/without obstacles, manipulator with/without obstacles) for 100 trials and report the database hit rate and 95% bootstrap confidence intervals for the difference in planning time between E-ARC and ARC. If the hit rate is below 50% in any advertised scenario, or if the confidence interval for the time difference includes zero, the central claim that the database enables the speedup is not supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim that E-ARC solves larger MRMP problems using a small database depends on the premise, stated in Section I and borrowed from [1], that 'most conflicts require the coordination of only a few robots.' This premise is not re-validated in the obstacle or manipulator settings: Section IV.A states the manipulator database contains only 2-robot subproblems, and the authors explicitly defer 'managing and classifying multi-robot transformations involving more than two fixed-based manipulator robots' to future work. Crucially, neither the paper nor the appendix reports the database hit rate—the fraction of conflicts resolved by Algorithm 2 rather than by fallback traditional planning. If that fraction is small, E-ARC reduces to ARC plus retrieval overhead, and the reported planning-time advantages (e.g., 3.05 s vs 5.24 s for 32 mobile robots; 5.53 s vs 9.1 s with obstacles) could reflect noise or implementation differences. Those averages are reported without error bars or statistical tests, even though 100 trials with random starts/goals in sampling-based planners typically exhibit large variance. The method is plausible, but the quantitative claim is not yet established.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes E-ARC, an extension of the authors' earlier ARC algorithm for multi-robot motion planning. E-ARC first builds a database of precomputed solutions to low-dimensional subproblems (involving 2-4 mobile robots or 2 fixed-base manipulator robots) in small local environments; at query time, when ARC detects a conflict between two paths, E-ARC transforms a candidate set of nearest database entries to the local frame, validates or repairs them, and falls back to ARC's hierarchy of sampling-based planners only when retrieval or repair fails. The experiments compare E-ARC to Lightning (a full-problem experience-based planner) and ARC across mobile and manipulator scenarios, with and without random obstacles, for up to 32 mobile and 16 manipulator robots, reporting planning time, database construction time, and success rates over 100 trials per setting. The main claimed contributions are a fast-to-construct compact database, a framework for reusing subproblem solutions in continuous MRMP, and experimental evidence of improved scalability.","tokens_in":10064,"tokens_out":7409,"duration_ms":64333,"significance":"The idea of replacing from-scratch planning for local conflict-resolution subproblems with a small database of low-dimensional solutions is sensible and potentially valuable; if the speedups are robust, the method would be a practical way to add experience reuse to continuous multi-robot planning without an exponentially growing database. The paper also honestly discloses that the manipulator database is restricted to 2-robot subproblems and defers more general multi-robot transformations to future work. It reports a large number of trials (100 per configuration) and compares against an established external baseline (Lightning) as well as the authors' own prior method, so the main concern is not circularity. However, the quantitative evidence as presented is insufficient: the headline speedups are mean values without variance or significance information, and the paper never measures the extent to which the database actually replaces from-scratch planning. Those omissions are fixable and do not, in my view, invalidate the approach.","major_comments":[{"comment":"Only mean planning times are reported for the 100 trials. Sampling-based planners of the kind used here (PRM, RRT-Connect, DecoupledPRM, CoupledPRM) typically exhibit large variance across random starts and goals, yet no standard deviation, confidence interval, or paired significance test is given. For instance, the claimed advantage for 32 mobile robots without obstacles (E-ARC 3.05 s vs ARC 5.24 s) and the obstacle-case advantage (5.53 s vs 9.1 s) could be within trial-to-trial noise. Because faster planning is the central claim, per-trial distributions or paired tests are needed; the 1,000 s timeout (Section IV.A) also censors the data and should be handled accordingly.","section":"Section IV.B, Figs. 5-8"},{"comment":"Neither the main text nor the figures report how often Algorithm 2 resolves a conflict directly from the database, how often it repairs a retrieved path, and how often line 11 of Algorithm 1 falls back to TraditionalPlanning. The entire advantage of E-ARC over ARC is supposed to come from replacing from-scratch subproblem planning with database reuse; without a usage breakdown this advantage cannot be attributed to the database, and the reader cannot test the Section I premise (taken from [1]) that most conflicts need only a few robots. This is especially important because Section IV.A restricts manipulator subproblems to two robots, a setting in which the premise is not re-established.","section":"Section III.C (Algorithms 1 and 2), Section IV.B.1"},{"comment":"Algorithms 1 and 2 depend on several parameters whose values are never specified: k in Algorithm 2, the time-window size used to build Q' from a conflict, the maxCollisions threshold for repair, the database size n, the dimensionality mix of stored mobile-robot subproblems, and the size of the reduced environment E'. These choices can materially change hit rates and planning times; without them the experiments are not reproducible, and without sensitivity analysis one cannot tell whether a good setting was selected by tuning. Please report the values and provide at least a basic sensitivity study for k, the window size, and n.","section":"Section IV.A, Algorithms 1-2"},{"comment":"The database construction-time comparison appears asymmetric: E-ARC reuses a single database for all robot counts, while Lightning's database is allowed to grow proportionally with the number of robots. If Lightning's reported construction times (e.g., 2,607.2 s for 16 mobile robots and 6,508.24 s for 16 manipulators) are per robot-count setting, the 'up to 342 times faster' claim partly reflects this asymmetry rather than the intrinsic cost of the database. Please report database sizes (number of entries and DOFs) for both methods, clarify whether Lightning's times are cumulative or per setting, and, if possible, compare at matched robot counts.","section":"Section IV.A, Figs. 5-8"}],"minor_comments":[{"comment":"The heading 'Scenario II: Mobile Robots' should read 'Scenario II: Manipulator Robots', since the section studies 5-DOF planar manipulators.","section":"Section IV.C"},{"comment":"The abstract contains a stray LaTeX comment ('%leverages') after 'approach that'; remove it.","section":"Abstract"},{"comment":"There are several typos: 'Thunder [3], extend this with .a roadmap spanner' and 'stores ... efficiently these subproblem solutions efficiently'.","section":"Section II.D"},{"comment":"Reference [6] is incomplete; it gives only a title and no venue, year, or publication information.","section":"References"},{"comment":"The caption appears to reverse the order of the environments: the text says (a) is empty and (b) has obstacles, whereas the caption says 'both with (b) and without (a)'.","section":"Figure 4 caption"},{"comment":"No code or data availability statement is included; adding one would improve reproducibility.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"I see no evidence of intentional circularity; E-ARC extends the authors' own ARC and is compared against the external baseline Lightning. The main risk is overclaiming speedups without statistics and without database-usage measurements. This can be addressed with additional analysis, so I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague, quick take on arXiv:2411.08851.\n\nThe genuinely new thing is the combination: it takes the ARC subproblem idea and adds a Lightning/Thunder-style database retrieval step in continuous space, for both mobile and manipulator robots. That combination is not in the cited prior work—DDM/DCBS are grid-based MAPF methods, and Lightning/Thunder are single-robot. The database construction numbers are the strongest part: a single mobile database built in 7.42 seconds reused across all robot counts, versus Lightning's multi-thousand-second databases; similarly 19.12 seconds for manipulators versus 6,508 seconds. The direction of the planning-time comparisons is also consistent across every reported configuration, and success rates match or exceed the baselines. So the core idea—store low-dimensional subproblem solutions, retrieve and repair before falling back to ARC—is well motivated and looks like a real improvement.\n\nWhere I would push hard before trusting the exact numbers: nothing in the results has error bars, confidence intervals, or significance tests, and 100 random trials in sampling-based planners typically show large variance. Key parameters are not disclosed: k, the time window, the maxCollisions repair threshold, database size n. There is no code or data. The load-bearing premise—that most conflicts involve only a few robots—is quoted from the authors' earlier ARC paper and not re-tested in the new obstacle and manipulator settings. That matters most for manipulators, where the database contains only 2-robot subproblems and the authors explicitly defer more-than-two-robot manipulator coordination to future work. The stress-test concern is fair: without a database hit rate, we cannot tell whether the speedups come from retrieval or mostly from the ARC hierarchy plus implementation details.\n\nThat said, the paper is not circular and does not strawman its baselines. ARC is a strong prior method from the same group, Lightning is a fair external experience-based baseline, and the reported direction of effect is uniform across scenarios. I also do not count the heavy self-citation against it, since E-ARC is literally an extension of ARC.\n\nWho is this for? People working on multi-robot motion planning, experience-based planning, and coordination for warehouse or manufacturing fleets. It deserves a serious referee: a good reviewer could ask for hit-rate measurements, variance reporting, parameter disclosure, and code or data, and the paper would be much stronger after that. I would not desk-reject it, but I would not accept it in its current quantitative state either.\n\nRecommendation: send it to peer review with the expectation of major revision.","headline":"E-ARC is a plausible and genuinely new continuous-space subproblem database instantiation of ARC, but the quantitative speedup claims lack error bars, a reported database hit rate, and key parameter details.","tokens_in":10600,"tokens_out":2145,"would_cite":true,"duration_ms":21683,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that storing solutions to two-to-four-robot subproblems and retrieving them during conflict resolution lets experience-based multi-robot planning scale to 32 mobile or 16 manipulator robots faster than planners that…","keywords":["multi-robot motion planning","experience-based planning","subproblem databases","conflict resolution","mobile robots","manipulator robots","sampling-based planning","E-ARC"],"falsifier":"Record the number of times E-ARC expands a subproblem to include a third, fourth, or fifth robot before finding a solution; a large count in the 16-manipulator obstacle scenario would falsify the premise that two-robot subproblems suffice.","tokens_in":9632,"feed_emoji":"🤖","tokens_out":10639,"duration_ms":220872,"temperature":0.7,"pith_summary":"This paper claims that experience-based multi-robot motion planning can be made scalable by storing solutions to small, local collision subproblems instead of building databases for entire robot teams. The proposed method, E-ARC, works inside the ARC conflict-resolution framework: when two paths collide, it isolates the conflicting robots into a local subproblem, looks up a matching solution in a database of two-to-four-robot subproblems, and only replans from scratch if the database has no usable entry. In experiments with up to 32 mobile robots and 16 manipulator robots, E-ARC plans faster than the Lightning experience-based planner and the ARC baseline while constructing its database up to 342 times faster than Lightning's. The paper argues this matters because a compact database sidesteps the exponential growth that makes prior experience-based MRMP databases impractical for large teams.","feed_headline":"Tiny subproblem database speeds planning for 32-robot teams","feed_subtitle":"By storing only two-to-four robot conflict solutions, E-ARC beats full-team planners in tests.","key_machinery":"The mechanism that carries the argument is a subproblem database paired with a conflict-driven retrieval loop. A detected conflict between paths of robots $r_i$ and $r_j$ defines a local subproblem $(E', R', Q')$, where $R'$ contains the conflicting robots, $Q'$ takes start and goal configurations from a time window around the conflict, and $E'$ is a bounding region of configuration space just large enough to contain the local planning; the database is then queried for the $k$ closest stored solutions of the same dimensionality, transformed to the conflict location (translation for mobile robots, relative base transformation for manipulators), validated for collisions, and either connected to the subproblem, repaired, or rejected in favor of the ARC hierarchical planner. The database is built offline by solving random low-dimensional subproblems in isolation, exploiting the observation from the prior ARC analysis [1] that most conflicts involve only a few robots. The subproblem creation and expansion rules come from ARC, while the retrieve-and-repair logic is adapted from Lightning.","core_discovery":"At the center of the paper is the claim that most conflicts in large multi-robot problems can be resolved by coordinating a small number of robots, so a database of low-dimensional subproblem solutions can substitute for a full-team database. E-ARC builds a single database of solutions for randomly generated subproblems of two, three, and four robots for mobile robots, and two-robot subproblems classified by base transformation for fixed-base manipulators; at planning time, each detected conflict is converted into a local subproblem and the database is queried with a k-nearest search, with invalid candidates repaired or discarded before the planner falls back to sampling-based methods. The reported results show that this compact database (7.42 seconds to construct for mobile scenarios, 19.12 seconds for manipulators) is reused across all team sizes and outperforms Lightning, which requires databases that grow from 18.79 to 2,607.2 seconds for 2 to 16 mobile robots and fails on 32 mobile robots, while E-ARC succeeds in all trials there. The paper frames this as evidence that 'doing more with less' is possible in experience-based MRMP.","pith_inferences":["A testable extension would be to measure the distribution of conflict group sizes in the obstacle-laden manipulator scenarios; if subproblems requiring five or more robots occur often, the 2-robot-only manipulator database would force frequent fallback and the speedup would shrink.","The database in the paper is built in empty environments, yet experiments include random obstacles; an inference is that storing subproblem solutions with a few obstacle configurations could improve retrieval accuracy and further reduce repair calls in cluttered settings.","The k-nearest retrieval criterion could be replaced by a learned similarity metric over subproblem queries, which might improve match quality without enlarging the database; the paper's results do not test this.","Because E-ARC reports time to first solution rather than solution cost, an implicit open question is whether database reuse changes path quality, which would matter in applications with long-term energy or safety constraints."],"forward_implications":["A single compact database can serve many team sizes and obstacle layouts, so experience-based MRMP can scale to dozens of robots without the memory and querying costs of a full-team database.","Because the database is orders of magnitude cheaper to build (up to 342 times faster in the reported experiments), experience-based planning becomes practical for new environments where no large prior solution library exists.","For fixed-base manipulators, classifying subproblems by relative base transformations lets a small 2-robot database resolve conflicts in teams of up to 16 robots.","E-ARC's speedup over ARC grows with team size, suggesting that database lookup replaces progressively more expensive from-scratch composite-space planning as conflicts accumulate."],"supporting_citations":[{"why":"Defines the ARC subproblem-decomposition and conflict-expansion framework that E-ARC extends, and supplies the observation that most conflicts involve only a few robots.","marker":"[1]"},{"why":"Introduces the Lightning retrieve-and-repair experience database baseline that E-ARC adapts and compares against.","marker":"[2]"},{"why":"Proposes the subproblem-solution database idea for grid-based multi-robot pathfinding that motivates E-ARC's low-dimensional storage.","marker":"[4]"},{"why":"Shows how sparse roadmap spanners manage experience databases, informing E-ARC's database construction and retrieval efficiency.","marker":"[3]"},{"why":"Provides the RRT-Connect path connection and repair primitive used to splice retrieved subproblem solutions.","marker":"[17]"}],"fun_headline_variants":["Tiny database, huge robot teams: E-ARC plans 32 robots in seconds","E-ARC: subproblem solutions replace full-team databases for MRMP","Smaller database, bigger robot swarms: E-ARC beats Lightning","Quick database build, fast planning: E-ARC handles 32-robot teams","Experience reuse with few robots: E-ARC scales to 32-robot MRMP"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The approach depends on most real multi-robot conflicts being resolvable by coordinating only two to four robots, so a small database of low-dimensional subproblem solutions can cover the conflicts that actually arise.","fun_headline_variants_meta":{"raw":{"variants":["Tiny database, huge robot teams: E-ARC plans 32 robots in seconds","E-ARC: subproblem solutions replace full-team databases for MRMP","Smaller database, bigger robot swarms: E-ARC beats Lightning","Quick database build, fast planning: E-ARC handles 32-robot teams","Experience reuse with few robots: E-ARC scales to 32-robot MRMP"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000543,"raw_usage":{"total_tokens":2606,"prompt_tokens":957,"completion_tokens":1649,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":573,"completion_tokens_details":{"reasoning_tokens":1545}},"tokens_in":573,"tokens_out":1649,"duration_ms":13105,"temperature":1.0,"reasoning_tokens":1545,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T21:15:26.471117+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Record the number of times E-ARC expands a subproblem to include a third, fourth, or fifth robot before finding a solution; a large count in the 16-manipulator obstacle scenario would falsify the premise that two-robot subproblems suffice.","supporting_citations":[{"cited_title":"A robot path planning framework that learns from experience,","cited_arxiv_id":null,"evidence_quote":"Introduces the Lightning retrieve-and-repair experience database baseline that E-ARC adapts and compares against."},{"cited_title":"Ddm: Fast near-optimal multi-robot path planning using diversified-path and optimal sub-problem solution database heuris- tics,","cited_arxiv_id":null,"evidence_quote":"Proposes the subproblem-solution database idea for grid-based multi-robot pathfinding that motivates E-ARC's low-dimensional storage."},{"cited_title":"Experience-based planning with sparse roadmap spanners,","cited_arxiv_id":null,"evidence_quote":"Shows how sparse roadmap spanners manage experience databases, informing E-ARC's database construction and retrieval efficiency."},{"cited_title":"RRT-connect: An efficient approach to single-query path planning,","cited_arxiv_id":null,"evidence_quote":"Provides the RRT-Connect path connection and repair primitive used to splice retrieved subproblem solutions."}],"review_version":1}