PaperlayerView exact revision on arXiv

Source-linked AI summary

AssemblyGrid v1: A Benchmark for Multi-Robot Production with Temporary Coalitions, Local Information, and Geometric Constraints

Fouad Bahrpeyma, David Heik, Dirk Reichelt

arXiv:2609.16075v1cs.ROcs.AI

TL;DR

Flexible robotic production requires interdependent decisions about process progression, routing, resources, cooperation, and execution, but these mechanisms are often represented separately. AssemblyGrid v1 combines them in a reproducible task-level benchmark with controller-independent outcomes. Its reference and structured decentralized controllers achieve productive execution, while geometry interventions show reduced productive opportunity under stronger workspace interference.

  • Problem

    Flexible production couples process progression, routing, resource assignment, cooperation, and execution, while their integration with geometric feasibility and decentralized local information is less commonly represented in one benchmark.

    Source: §1 · pp. 1–3

  • Method

    AssemblyGrid v1 defines a reproducible task-level benchmark combining recipe and material progression, temporary coalitions, local decisions, geometric constraints, and outcomes independent of controller objectives.

    Source: §1 · p. 3, §2.2 · p. 6, §2.3 · p. 8

  • Results

    Across the official suite, centralized and structured decentralized references achieve productive execution, and a matched geometry intervention supports reduced productive opportunity under stronger workspace interference.

    Source: Productive concurrency · p. 24, §6 · p. 36

  • Takeaways & Limitations

    AssemblyGrid v1 provides a common production task for studying cooperative decision making with learning-based and non-learning controllers.

    Source: §1 · p. 3, §2.4 · p. 10

    The benchmark abstracts away robot-specific kinematics, trajectory planning, grasping, and dynamics; broader layouts, heterogeneous robots, and sensing uncertainty remain future extensions.

    Source: §2.1 · p. 6, §5.3 · p. 35

Abstract

from arXiv · show

Flexible robotic production requires joint decisions on process progression, material routing, resource assignment, temporary cooperation, and simultaneous execution, since each decision can affect the feasibility of the others. The challenge is greater under decentralized control, where each robot acts from bounded local information while system progress depends on collective decisions, shared resources, material state, and workspace compatibility. These properties closely match cooperative multi-agent decision making under partial observability and resource contention. This paper introduces AssemblyGrid v1, a reproducible benchmark for repeated multi-robot production that combines explicit process progression, decentralized observations, material transfer, temporary multi-robot coalitions, productive concurrency, and geometry-dependent feasibility within one task-level formulation. The benchmark includes Flow, Coalition, and Concurrency workload families, each with three scenario levels. Task success and evaluation measures are defined independently of learning reward and solution method, allowing learning-based and non-learning methods to address the same production problem. AssemblyGrid v1 is evaluated through executable conformance checks, mechanism studies, and algorithmic experiments using a privileged centralized reference, structured decentralized controllers, and MARL methods including IPPO, MAPPO, and QMIX. Results demonstrate productive execution under centralized and decentralized control. The MARL experiments further show that decentralized policies can learn effective production behavior from local observations and actions, supporting AssemblyGrid as a controlled benchmark for studying cooperative decision making in flexible robotic production.

1 Introduction

Flexible production couples operation choice, routing, resource assignment, concurrency, and geometric feasibility, making task-level control difficult under local information. AssemblyGrid v1 brings these mechanisms together in a reproducible benchmark for continuing multi-robot production.

1 Introduction

  • Operation choice, material routing, resource assignment, and geometric feasibility are coupled decisions that must be resolved together in flexible robotic production.The selected operation determines process state, resource assignments affect concurrency, and workspace geometry can make an otherwise valid assignment infeasible.Source: §1 · p. 2
  • MARL is relevant because agents must learn how locally informed decisions contribute to a shared production objective; a coalition is the temporary subset jointly executing one operation.Task-level cooperation among all agents is distinct from operation-specific coalition formation.Source: §1 · p. 2
  • Existing multi-agent and logistics benchmarks address partial observability, coordination, routing, congestion, and division of labor, while production-specific mechanisms remain distributed across benchmark traditions.Related work also treats physical cooperation at higher detail, often in individual assembly tasks or manipulation episodes rather than continuing production.Source: §1 · pp. 2–3
  • AssemblyGrid v1 combines typed material progression, temporary local coalitions, productive concurrency, and geometric admissibility in one benchmark definition.Task outcomes are defined independently of the controller and its learning reward.Source: §1 · p. 3
  • The benchmark organizes workload variation into Flow, Coalition, and Concurrency families, each evaluated under a common definition.Its design principles include explicit recipe progression, operation-specific temporary cooperation, separate information and manipulation locality, geometric constraints, and controller-independent outcomes.Source: §1 · p. 3

2 The AssemblyGrid v1 environment

AssemblyGrid v1 models repeated production in a task-level cell where recipes, local robot interactions, temporary coalitions, geometry, and decentralized choices shape execution. Benchmark outcomes are defined separately from learning rewards.

2 The AssemblyGrid v1 environment

  • Fixed-base manipulators occupy a lattice around left-to-right material flow, with overlapping workspaces shaping robot interaction and interference.Each robot is paired with a task-level agent, connecting physical interaction and material flow to recipe requirements and decentralized decisions.Source: §2 · pp. 4–5

2.1 Physical organization and local interaction

  • Observation, handoff, and manipulation have distinct locality relations; the default Moore-radius-one topology gives interior robots eight neighbors and limits official-grid coalitions to four.Mutually adjacent coalitions fit within a 2 × 2 block.Source: §2.1 · p. 5
  • Reach, workspace overlap, clearance, and interference constrain handoffs, cooperative work, and concurrency, while robot kinematics, trajectory planning, grasping, and dynamics remain outside the geometry abstraction.Geometric feasibility also contributes to abstract execution time.Source: §2.1 · p. 6

2.2 Product recipes and operation requirements

  • Recipes define required operations and their order, alternatives, materials, coalition roles, and duration, while separating what must be produced from which robots perform it and where.The precedence structure represents sequence and AND requirements, while XOR selects one alternative and closes its mutually exclusive siblings for that product unit.Source: §2.2 · p. 6

2.3 Local decisions and temporary coalitions

  • An execution candidate pairs a ready operation with a feasible robot set; admission checks material, roles, resources, reach, and geometric compatibility, and duration includes approach, processing, and retreat.Conflicts can arise from shared exclusive resources or simultaneous motion segments and target workspaces that violate clearance rules.Source: §2.3 · pp. 7, 9
  • Bilateral handoffs require matching choices, while a temporary coalition forms only when every required robot supports the same feasible candidate and commits until completion.Support can accumulate across decision epochs; after completion, coalition members return to the available resource pool.Source: §2.3 · p. 8

2.4 Decentralized information model

  • Benchmark outcomes use common production and task-success measures independent of learning reward, keeping methods with different internal objectives comparable on the same instances.Learning methods may add a reward and discount factor, while planners, schedulers, optimization methods, and heuristics can use the environment directly.Source: §2.4 · p. 10
  • Agents select actions from local execution information, including nearby state and participable candidates, without seeing global production state, remote contention, detailed intentions, or explicit messages.Training may use additional global information if the resulting execution policy still selects actions from each agent’s permitted local information.Source: §2.4 · pp. 9–11

3 Benchmark design, scenario suite, and measurement

This section presents AssemblyGrid v1’s reproducible benchmark design and workload suite, specifying shared geometry and runtime rules, product-success conditions, and measures that separate production outcomes from mechanism diagnostics, including useful recipe progress versus robot occupancy. It also identifies algorithm-independent lower bounds and invariants for benchmark implementations, with executable conformance checks reported in Section 4.

3.1 Benchmark instances and reproducibility

  • Benchmark instances fix task-defining configuration and shared runtime semantics, while named geometry profiles specify spatial and timing assumptions for admissibility.Changing geometry changes the benchmark instance; matched geometry-control variants explicitly change geometry settings without silently redefining a workload family. Instance-generation, execution, and algorithm or training seeds serve distinct purposes.Source: §3.1 · pp. 11–12

3.2 The AssemblyGrid v1 scenario suite

  • The official suite has nine runnable scenarios across Flow, Coalition, and Concurrency, with three difficulty levels per family and MARL characterization across all levels.The detailed non-learning executability validation focuses on Coalition; all nine scenarios share default geometric checks, and matched geometry studies vary only the workspace-conflict radius while holding other stated conditions fixed.Source: §3.2 · pp. 12–13

3.3 Difficulty levels: easy, medium, and hard

  • Difficulty levels encode complete family-specific workloads, with Flow stressing serial routing, Coalition minimum cooperation, and Concurrency increasing overlap and contention.Flow expands from one to three to five unary operations. Coalition progresses from a fixed two-robot operation to variable two-to-four-robot cooperation and then a required four-robot operation; extra robots bring no benefit in the variable-arity operation. Concurrency retains two independent branches followed by a pairwise join while increasing WIP and release pressure.Source: §3.3 · pp. 13–15

3.4 Task success and evaluation modes

  • Product success requires terminal recipe output delivery, while continuing-production and finite-batch modes differ in evaluation boundary and appropriate performance outcomes.Continuing production uses a fixed horizon and does not define a single makespan; finite batches run until delivery or timeout, with makespan defined only for completed batches.Source: §3.4 · p. 15

3.5 Benchmark measures

  • Evaluation separates production outcomes from mechanism diagnostics and distinguishes admitted-product completion from offered-demand service.Continuing-production measures include delivered products and throughput, with demand-facing admission and fulfillment companions; admission, coalition, blocking, concurrency, utilization, occupancy, and geometry measures diagnose mechanisms. Admitted-product completion alone does not indicate high service of offered demand.Source: §3.5 · pp. 15–17

3.6 Productive concurrency

  • Productive concurrency measures recipe-advancing operations rather than robot occupancy, using state-dependent compatible-operation capacity and realized execution.Capacity depends on ready operations and conflicts, including robot, resource, route, and geometric constraints; its execution average depends on the states each controller visits. Logistics activities enable production but do not count as productive activities.Source: §3.6 · pp. 18–19

3.7 Conformance checks

  • Appendix B gives conservative robot-time, critical-path, and resource lower bounds, plus 11 invariants that implementations must preserve in every reachable state.Section 4 reports executable checks exercising these requirements.Source: §3.7 · p. 19

4 Benchmark validation

This section validates benchmark-rule conformance and controlled mechanism behavior, and examines productive execution under centralized, structured decentralized, and learned decentralized control. It also reports scenario-dependent production and algorithmic outcomes for IPPO, MAPPO, and QMIX under the shared evaluation protocol.

4.1 Evaluation protocol

  • The 270-run MARL campaign evaluates IPPO, MAPPO, and QMIX on 50 same-generator held-out instances per scenario, using final checkpoints without post-hoc selection.Each policy is evaluated after 1,536,000 training steps; MARL uncertainty is computed across ten training replicates, while deterministic-controller uncertainty is computed across 50 instances.Source: §4.1 · pp. 20, 22

4.2 Validation of benchmark mechanisms

  • Executable checks verify recipe and material semantics, while deterministic controls form two-, three-, and four-robot coalitions in one tick in all 20 trials per size, with or without the support-fraction cue.Official Coalition scenarios show scenario-dependent formation behavior: IPPO and MAPPO have more failed attempts in medium than easy or hard, while QMIX has very low coalition success throughout.Source: §4.2 · pp. 22–23

Productive concurrency.

  • Matched controls verify useful concurrency and geometric feasibility; increasing workspace interference reduces productive concurrency and deliveries for structured controllers while utilization remains nearly stable.In the concurrency control, allowing independent operations to overlap reduces completion time from Cmax = 11 to Cmax = 8, or 3 ticks (27.3%); geometry tests also classify reach and crossing-segment conflicts as specified.Source: Productive concurrency · pp. 23–24

4.3 Reference behavior across the official workload suite

  • The privileged Centralized reference achieves positive mean delivery in every official scenario, matching Parallel-aware in eight of nine scenarios.Their trajectories coincide when global operation selection admits the same operations as the local rule; they differ in Coalition-medium, which has a variable-arity operation.Source: Table 10 · p. 25, §4.3 · p. 25
  • Decentralized references support productive execution across workload families; PPO methods produce productive Flow behavior at all levels, while Coalition and Concurrency show distinct scenario-dependent signatures.These difficulty levels vary multiple scenario parameters, so their differences are descriptive rather than causal; causal attribution requires matched interventions.Source: Figure 5 · p. 26, §4.3 · p. 26

4.4 MARL-reference behavior and same-generator held-out evaluation

  • Training figures document the fixed 270-run protocol’s optimization behavior, not benchmark scores, reporting return, admissions, delivery, and actor-critic diagnostics across workload families.Coalition and Concurrency curves include admissions, whereas Flow curves omit coalition-formation measures because its official recipes contain only unary operations.Source: §4.4 · p. 29, Figure 6 · p. 29, Figure 7 · p. 30
  • IPPO and MAPPO develop sustained delivery across all three workload families, while the reported QMIX configuration produces little or no final-test output across the official suite.This characterizes the reported QMIX configuration and does not support a general claim about QMIX as an algorithm class.Source: §4.4 · pp. 30–31
  • MAPPO reaches high critic explained variance across nine scenarios, whereas IPPO remains markedly lower; both entropy trajectories decrease without collapsing to zero.The critic diagnostic alone neither identifies the cause of production differences nor demonstrates algorithmic superiority.Source: §4.4 · p. 33
  • Table 15 summarizes ten independently trained final checkpoints per family and difficulty level, each evaluated on the same 50 held-out instances, using mean delivered count and a 95% Student-t interval half-width.The interval half-width is t0.975,9 s/10, where s is the sample standard deviation of the ten per-policy means.Source: §4.4 · p. 33, Table 15 · p. 34
  • Held-out deliveries are lower than late training-curve values for IPPO in Coalition easy and medium, Concurrency hard, and Flow hard, and for MAPPO in Concurrency hard.Training rollouts sample policy actions on run-specific realizations, while final tests select the highest-scoring legal action on shared held-out instances.Source: §4.4 · p. 34
  • The experiments verify task-definition consistency, exercise recipe, coalition, productive-concurrency, and geometry mechanisms, and show that geometric interference changes productive opportunity and production.Coalition results depend on the canonical support-fraction observation; structured non-learning methods demonstrate productive executability, while 270 MARL runs characterize scenario-dependent behavior under one protocol.Source: §4.4 · p. 34

5 Discussion

The discussion finds effective decentralized execution in some reported configurations, while showing how concurrency and geometry affect production and delimiting the benchmark’s scope. It also identifies controlled extensions for future study.

5.1 Benchmark behavior across the official workload suite

  • IPPO and MAPPO had positive mean delivery in every scenario, though 4/90 and 1/90 replicates, respectively, delivered nothing; QMIX had 84/90 zero-output runs.The QMIX result is specific to the reported configuration, not the algorithm class.Source: §5.1 · p. 35
  • In QMIX runs, temporal-difference loss rose more than tenfold in 70/90 runs, alongside median absolute mixed-value growth of one to two orders of magnitude in every family.The reported diagnostics coincided with divergence.Source: §5.1 · p. 35
  • Difficulty labels are meaningful within each workload family, not across Flow, Coalition, and Concurrency.The families emphasize different workload structures.Source: §5.1 · p. 35

5.2 Productive concurrency and geometry

  • Matched controls show that overlapping independent operations shorten completion time, while stronger workspace interference reduces concurrency and deliveries for all three structured controllers.Conflict-radius increases geometry-blocked activities and lowers visited-state capacity, while utilization barely changes; easy-to-hard Concurrency scenarios are not one-factor interventions.Source: §5.2 · p. 35

5.3 Scope and limitations

  • The benchmark abstracts inverse kinematics, joint limits, dynamics, and grasp physics; evaluation generalizes across 50 unseen instances from the same scenario generator, not new layouts or scales.Coalition experiments also keep the support-fraction cue fixed; broader settings remain future work.Source: §5.3 · p. 35

5.4 Future research enabled by AssemblyGrid v1

  • Future studies can vary production-system structure or extend controllers and test declared geometry changes, while adding communication, generalization splits, disturbances, higher-detail geometry, or richer process models.The discussion recommends introducing one explicitly defined source of variation at a time to keep benchmark comparisons stable.Source: §5.4 · pp. 35–36

6 Conclusion

AssemblyGrid v1 defines a reproducible task-level benchmark integrating production progression, local information, temporary coalitions, concurrency, and geometry-dependent feasibility. Its conformance and mechanism checks and reported controller results support productive execution, while physical robot validity and transfer remain outside scope.

6 Conclusion

  • AssemblyGrid v1 combines recipe and material progression, temporary coalitions, bounded local information with a support-fraction cue, productive concurrency, and geometry-dependent admissibility in one reproducible task definition.The reference implementation passes conformance checks and realizes the intended recipe, coalition, concurrency, and geometry mechanisms.Source: §6 · p. 36
  • Centralized and structured decentralized references achieve productive execution, while IPPO and MAPPO yield positive mean final-test delivery under their distinct information and decision regimes.The matched geometry intervention also supports that workspace interference reduces productive opportunity and production.Source: §6 · p. 36
  • Physical robot validity, perception, alternative coordination interfaces, learned communication, robustness, and transfer remain beyond this research’s scope.Source: §6 · p. 36

A Reproducibility, versioning, and reference implementation

The appendix separates release and implementation information from the formal benchmark definition. It identifies the default geometry profile and distinguishes task-level abstraction from higher-detail robot-model evaluations.

A Reproducibility, versioning, and reference implementation

  • Appendix A records release-level information for reproduction and interpretation without changing the benchmark task definition, separating abstraction, experimental archive, and software-interface details.Source: A Reproducibility, versioning, and… · p. 41

A.1 Geometry profile and release identity

  • The release uses recipe schema assemblygrid-recipe-v1 and default geometry profile abstract-v1; robot-model kinematics, joint limits, link-level collision checking, dynamics, contact, or hardware execution are higher-detail extensions.A dimensional mapping to a particular manipulator, including a UR10 interpretation, does not change the task-level abstraction.Source: §A.1 · p. 42

A.2 Release identifiers used for reproducibility

The appendix maps semantic benchmark terms to release identifiers for software traceability. It also lists identifiers for the official scenario recipes.

A.2 Release identifiers used for reproducibility

  • Software identifiers map semantic measures to implementation keys, including proposal_support, completion_rate, coalition_success_rate, team_formation_failures, and legacy blocking and capacity keys.These identifiers do not alter the corresponding benchmark definitions.Source: §A.2 · p. 42
  • The fixed MARL training reward is coalition_milestone_v1, and the release assigns distinct recipe identifiers to Flow and Coalition levels while reusing parallel_branch_light for all Concurrency levels.The Flow identifiers are solo_inspection, flow_serial_3, and flow_serial_5; Coalition uses pair_assembly, supported_insert, and standard_abc.Source: §A.2 · p. 42

A.3 Experimental archive and evaluation records

The archive documents the MARL campaign, its matched training and evaluation splits, and the records used for final reporting. Canonical validation and test instances are shared across methods, while each run trains on its own seeded realizations.

A.3 Experimental archive and evaluation records

  • Each run trains on five run-specific realizations, while all methods use the same canonical validation and final-test instances.The final-test split contains 50 instances per scenario; validation is for online monitoring only, not early stopping, model selection, or final-test selection.Source: §A.3 · pp. 42–43
  • Training and test realizations share scenario parameters and a generator, differing only by seeds that determine access patterns, material sources, and product masses.Due slack does not affect v1 dynamics, and payload feasibility never binds under official mass and payload ranges.Source: §A.3 · p. 42
  • Reported final-test figures use each run’s final-checkpoint evaluation means; periodic checkpoints were not retained.The validation split does not select the reported checkpoint.Source: §A.3 · p. 43
  • The campaign comprises 270 completed runs: ten seeds for each of three methods, three workload families, and three difficulty levels, trained for 1,536,000 steps each.Zero-production outcomes remain valid replicates; pilot, incomplete, and other separately tracked runs are excluded from reported aggregates.Source: §A.3 · p. 43
  • Released instances record runtime configuration and content identity, and a SHA-256 manifest binds archived evaluation records to their counterparts.The archive also retains training histories for all 270 runs.Source: §A.3 · p. 43

A.4 Reference implementation interface

The reference implementation exposes the decentralized interface while retaining a separate privileged global-state interface. Candidate generation preserves local visibility without revealing hidden joint-feasibility conflicts.

A.4 Reference implementation interface

  • The implementation provides decentralized observations and candidate-specific actions alongside a distinct privileged global-state interface for centralized references and centralized-training methods.It also exposes deterministic reset and step semantics, action masks, separate generation and execution seeds, and benchmark KPI logging.Source: §A.4 · p. 43
  • Candidate identity follows a canonical key and realization rule, and candidates are generated at most once per key.The reference implementation provides 32 pick-option and 64 operation-option slots per agent, with no addressability errors in official scenarios or reported experiments.Source: §A.4 · p. 43
  • Candidates are built from ready operations, required holders, and capable robot subsets, then filtered for structural and task-level geometric admissibility.Each robot sees only candidates containing it; hidden remote trajectory conflicts and globally contended resources are left for capacity diagnosis or joint admission.Source: §A.4 · p. 43
  • Optional Gymnasium and PettingZoo adapters and reward helpers are convenience layers that do not change benchmark semantics.Decentralized execution retains aggregate local candidate-support fraction without adding a free-form or addressable communication channel.Source: §A.4 · pp. 43–44

A.5 Reference MARL configurations

Table 17 documents the MARL configurations used in the full-suite campaign. Its method-level settings define the reference implementations for the reported characterization.

A.5 Reference MARL configurations

  • The recorded settings are intended to support reproduction of the 270 reference training runs.These are method-level settings for the reported campaign.Source: §A.5 · p. 44
  • The configurations define the reference implementations used in the reported MARL characterization.The passage does not specify individual method settings.Source: §A.5 · p. 44, Table 17 · p. 45
  • Table 17 lists the configurations of the MARL methods used in the reported full-suite campaign.The supplied passage identifies the table’s scope but does not provide its configuration values.Source: §A.5 · p. 44, Table 17 · p. 45

A.6 Executable conformance mapping

The conformance mapping links formal benchmark invariants to executable checks in the released implementation. Additional checks verify implementation consistency and bind the reported suite to an auditable release record.

A.6 Executable conformance mapping

  • Table 18 maps benchmark invariants to executable checks, making the formal definition traceable without making Python function names part of benchmark semantics.The table presents the principal mapping used by the conformance suite reported in Section 4.Source: §A.6 · p. 45, Table 18 · p. 46
  • Additional checks verify WIP accounting, candidate-support consistency, realized concurrency against declared capacity, and exact capacity solutions against hand-derived small cases.One constructed case checks that greedy selection is suboptimal.Source: §A.6 · p. 46
  • The public release record binds the 203-check suite to the benchmark version, immutable source or archive identifier, test command, software environment, and invariant mapping.These checks support reproducibility but do not define additional benchmark objectives.Source: §A.6 · p. 46

B Formal AssemblyGrid v1 definition

This section formally defines AssemblyGrid v1 as a controller-independent production problem, specifying its state, dynamics, constraints, feasibility, and evaluation. It also establishes algorithm-independent reference bounds and semantic invariants for simulator conformance across material and recipe state, coalitions, resources, decentralized observations, and accounting.

B.2 Entities and state variables

  • The global state tracks robots, products, materials, recipes, candidates, coalitions, commitments, resources, production status, and time, but includes no agent-authored communication state.Privileged or extension variables do not become required observations or instance parameters merely because an implementation stores them.Source: §B.2 · p. 47

B.3 Configuration parameters and instance identity

  • Official instances define problem quantities and identity through their grid, geometry, recipes, resources, release and WIP settings, durations, rules, observations, initial conditions, and seed; algorithm settings remain method configuration.Due dates and productive weights affect optional diagnostics or the privileged reference’s weighted selection, not benchmark dynamics or measures.Source: §B.3 · pp. 47–49

B.4 Rules and transition logic

  • Products enter under release and capacity rules, operations follow recipe readiness and resolved XOR choices, and cooperative work requires independent support for the same candidate before joint admission.Admitted activities reserve robots, materials, resources, and workspace for their duration; successful completion advances product state, and success requires delivery of the terminal output.Source: §B.4 · pp. 49–50

B.7 Structural relations and interaction graphs

  • Local observation, handoff, and manipulation use distinct robot relations; workspaces determine reach, and neighboring robots can transfer material only within their shared workspace.The three relations coincide geometrically in the default configuration but remain semantically distinct; internal material routing need not be monotone.Source: §B.7 · pp. 51–52

B.5 Hard constraints

  • Candidate feasibility checks readiness, inputs, coalition bounds, locality, roles, and workspace targets; joint admission additionally resolves exclusive resources and geometric conflicts without exposing hidden global state locally.Instances are valid only when a policy-independent successful execution exists, including feasible material routes, handoffs, operation candidates, and resource capacities.Source: §B.5 · pp. 50–51, §B.8 · p. 52

B.8 State-dependent feasibility

  • Productive concurrency is the maximum set of compatible recipe-operation activities that preserves existing commitments and respects resource capacities; logistics reservations constrain feasibility but do not count as productive activities.Product progress is monotone: an activity is productive only if its completion advances a product’s state.Source: §B.8 · p. 53

B.9 Assumptions and abstractions

  • The benchmark assumes synchronized discrete time, fixed robot bases, perfect local task-level sensing, abstract geometry, deterministic durations, homogeneous robots, monotone progress, and non-adversarial cooperation.Physics, perception, disturbances, heterogeneous capabilities, skills, value semantics, and standardized out-of-distribution splits are extensions that must be reported explicitly.Source: §B.9 · p. 53

B.11 Performance and diagnostic metrics

  • Evaluation metrics are independent of training reward and do not alter dynamics; they cover production, flow, cooperation, occupancy, blocking, and productive concurrency, with timeout and makespan reported distinctly.Execution-averaged capacity depends on the states a controller visits; optional geometry and logistics diagnostics are distinguished from measures requiring higher-detail extensions.Source: §B.11 · p. 54
  • Robot exclusivity bounds concurrent operations of coalition size k by floor(MN/k), while batch-level bounds accommodate changing coalition sizes without assuming independent 2 × 2 machines.These are conservative, algorithm-independent validation references, applied before locality, reachability, precedence, and motion constraints.Source: §B.11 · pp. 54–55
  • A product’s lower-bound completion time combines critical-path, required-transfer, abstract-motion, and exclusive-resource bounds, whose terms need not be independent.For finite batches, the bound also includes the batch-level lower bound induced by exclusive-resource workloads.Source: §B.11 · p. 55
  • Robot-time workload sums declared operation durations as a lower bound when all recipe operations execute; for exclusive alternative routes, it covers only the realized route.The declared-operation sum applies to every official recipe.Source: §B.11 · p. 55

B.12 Formal invariants

  • Material conservation requires a single consistent location and ownership state; cooperative support cannot duplicate material, and completed operations remain in product progress.New material items may arise only through explicitly declared recipe output transitions.Source: §B.12 · p. 55
  • Recipe, locality, lifetime, and arity invariants require valid predecessor and XOR constraints, terminal-only delivery, connected committed coalitions, fixed activity membership, and declared coalition-size and role coverage.Completed and executing operation sets must be disjoint; coalition size must fall within the operation’s interval and not exceed kmax_topo.Source: §B.12 · p. 55
  • Robots and other exclusive resources cannot enter incompatible overlapping activities, and finite-capacity resources cannot exceed declared capacity.Source: §B.12 · p. 55
  • Decentralized observations use only own state, declared local dynamic state, and public information; action masks hide no global feasibility oracle, preserve a legal action, and accounting keeps released, delivered, and WIP counts consistent.Appendix A maps invariants to implementation checks; claimed exact diagnostic solvers must match independently derived reference optima on small validation instances.Source: §B.12 · p. 55

B.10 Structural instance descriptors and experimental factors

Structural descriptors summarize instance properties and matched interventions, but do not define a universal scalar difficulty. Coalition demand is constrained by manipulation topology, while several other factors remain extensions.

B.10 Structural instance descriptors and experimental factors

  • These descriptors summarize structural properties but do not define a universal scalar difficulty.Source: §B.10 · p. 54
  • Descriptors cover robot count, WIP cap, recipe operations, active product types, coalition fraction, and minimum coalition requirements.The coalition fraction is the share of recipe operations requiring more than one robot.Source: §B.10 · p. 54
  • Recipe DAG depth, maximum antichain width, join and XOR counts, spacing ratio, conflict radius, and geometry profile describe additional instance structure.Spacing ratio compares nominal robot-base spacing with reference reach.Source: §B.10 · p. 54
  • Required coalition size must satisfy the active manipulation-topology bound, so scenario design cannot vary coalition demand independently of topology.Source: §B.10 · p. 54
  • Communication noise, disturbances, skill learning, and held-out transfer splits are extension factors rather than structural descriptors of the official workload.Source: §B.10 · p. 54

C Benchmark scope and extensions

Table 24 distinguishes mechanisms represented in AssemblyGrid v1 from properties varied experimentally and outcomes measured. Its scope summary also separates modeled properties from named extensions and version changes.

C Benchmark scope and extensions

C.1 Reading the scope summary

  • The table separately asks whether a property is modeled, varied across evaluated instances, and measured in reported results.For example, temporary coalitions are varied across Coalition scenarios and reported through formation success and failure counts, while privileged global state is a training interface, not an outcome.Source: §C.1 · p. 56
  • Filled, open, dash, and n/a marks distinguish direct presence, partial or coarse presence, unvaried or unmeasured properties, and properties outside AssemblyGrid v1.Source: §C.1 · p. 56, §C.2 · p. 57

C.2 Scope entries and extensions

  • A property requiring an extension needs its own specification and evaluation protocol; adding it to the canonical task changes the benchmark version.Varying an already modeled property instead extends the experimental design without changing the underlying task.Source: §C.2 · p. 56
  • The summary describes the released AssemblyGrid v1 only, does not compare other benchmarks, and still evaluates controllers against modeled mechanisms they ignore.Source: §C.2 · p. 56

Related papers

Loading 2609.16075v1…