← Back to all articles
7 min

League of Robot Runners 2026: Rovnou Ranks 8th in the Combined Track

League of Robot RunnersMAPFcompetitionmulti-robotRovnou

Rovnou entered the 2026 League of Robot Runners, a large-scale multi-robot coordination competition sponsored by Amazon Robotics.

At the close of the Main Round submission system, Rovnou held 8th place in the Combined Track on the official leaderboard. That is 8th among the 68 entries shown, or approximately the top 12%, with a score of 5.55 and 134,905 completed tasks. The submission detail page lists a team size of one.

Leaderboard at the submission deadline

The leading three teams and Rovnou were:

RankTeamScore
1No Man's Sky10.629
2SmartPath9.639
3Trzy Kwaterki7.034
8Rovnou5.55

Rovnou's score comprised the following instance-level results:

InstanceTasks completedScore
bos6,8680.433
fulfill-A15,7260.576
fulfill-B32,0650.438
fulfill-C10,0820.453
iron57,0450.423
maze-A1270.605
maze-B2080.813
orz4,8950.229
rand-A6,6420.330
room-A5800.591
room-B6670.658
Total134,9055.55

Among the 11 instances, maze-B produced Rovnou's highest relative score at 0.813, while iron contributed the most completed tasks at 57,045. Map geometry, robot density, and delay conditions differed substantially between instances, making map-aware design essential.

What the competition tested

The League of Robot Runners models continuous robot work in settings such as warehouses and factories. The 2026 competition added stochastic action delays to the existing task-scheduling and path-planning challenge.

The Main Round ran from April 14 to July 22, 2026 (Anywhere on Earth, UTC−12). A total of 69 teams made 3,361 submissions. In the Combined Track, each entrant implemented all three layers:

  1. Task scheduling: deciding which robot should receive each task
  2. Path planning: producing collision-free routes for the fleet
  3. Execution policy: safely executing those plans when unexpected delays occur

This was a lifelong multi-agent path-finding problem, not a one-shot goal-reaching benchmark. Results depended on sustained throughput as well as planning quality, replanning latency, scheduler behaviour, runtime congestion, and memory use.

What Rovnou built during the competition

Rovnou's development focused on measuring the bottleneck of each map and delay condition rather than applying one configuration everywhere.

Map-specific execution

Robot density, corridor width, turning cost, and available compute time differ by map. We built policy dispatch that can select the planner, scheduler, agent cap, and compute budget for each problem class.

Route guidance and distance estimates

We added orientation-aware distance estimates, traffic-flow guidance, and diagnostics for intersections and narrow corridors. These tools make it possible to identify cases where individually short routes create fleet-wide congestion.

Task assignment

We tested candidate filtering, distance-table reuse, and parallel computation instead of exhaustively evaluating every task on every cycle. The experiments reinforced that choosing the next job can matter as much as planning the route to it.

Detecting and recovering from blocked doorways

Room-style maps can stall when several robots converge on a single entrance. We added diagnostics for waits, dependency chains, and doorway blockers, together with limited recovery mechanisms.

Reproducible measurement

We developed PlanViz inspection, log analysis, same-binary A/B and ABBA comparisons, build-and-run provenance checks, and regression tests. These controls separate increased mechanism activity or CPU usage from genuine improvement in completed-task throughput.

How the leading team implemented its solution

The supplied 26-page document, No Man's Sky team — League of Robot Runners 2026 solution, describes the architecture, planner, scheduler, map-specific configuration, and 87-submission development history of the first-place team.

1. A lightweight main-thread dispatcher

The main thread, called once per simulator tick, avoids heavy search. It collects state, launches asynchronous work, receives completed results, and commits plans.

Task assignment runs in a background scheduler thread, while path planning runs in an asynchronous planner worker. Within the planner worker, separate pools handle LNS improvement, GoalRows distance computation, and World prediction.

2. A World model that predicts the next execution boundary

The solution maintains a World model containing in-flight primitives, delays, already-issued action queues, and task progress. Planning starts from a predicted future boundary rather than always using the immediately observed state.

It selects one of three modes by map:

ModeBehaviourMain applications
SYNC_STEPPlans synchronously from the actual state; no prediction error but less compute timemaze, room
STEPPredicts the next boundary and computes asynchronously between ticksfulfill-A/B, iron, orz, bos, rand-A
LEAD_STEPLaunches just before the boundary to preserve a fresher snapshotfulfill-C

3. EPIBTX followed by parallel LNS/ALNS

The initial solution is built with EPIBTX, an extension of PIBT-style priority inheritance and backtracking. Multiple Large Neighborhood Search workers then repair local waits and congestion. Initial construction stays single-threaded to preserve quality; the improvement phase is parallel.

4. Shared exact distances and traffic rules

For each robot, the scheduler considers the nearest 100 tasks and combines a sparse Hungarian assignment with greedy matching. Planning uses a Guidance Graph, PriorityField, HeuristicMatrix, and DynamicHeuristicMatrix so that lane direction, intersections, and congestion influence its distance estimates.

5. Map-specific mechanisms

The document reports its largest gains as +152% from a lane Guidance Graph on orz, +91% from LEAD_STEP on fulfill-C, and +66% from exact GoalRows distances on iron. Its conclusion is that selecting the appropriate planning mode and heuristic for a map-specific bottleneck produced larger gains than tuning one global set of coefficients.

The document also reports that roughly one-third of the team's 87 submissions were regressions or isolation experiments. The broader lesson is not merely a list of algorithms: change one thing at a time, measure it, and make adoption decisions per map.

We have not speculated about SmartPath's or Trzy Kwaterki's implementation because the materials reviewed for this article do not provide evidence for their approaches.

What the result means for Rovnou

This leaderboard result demonstrates an integrated test of task assignment, path planning, and delay-aware execution across 11 large scenarios. It does not, by itself, prove real-warehouse safety, communications reliability, integration with an existing fleet-management system, or maintainability.

Rovnou will carry the competition's lessons—map-specific optimisation, predictive versus synchronous execution, and reproducible measurement—into traffic-control software that can be validated in real deployments.

Sources