5 min

6th in the Combined Track at League of Robot Runners 2026, as a Team of One

roboticsmapfalgorithmcompetitioncpp

I entered the Combined Track of League of Robot Runners (LoRR) 2026 as the sole member of Rovnou. The organizers awarded Rovnou the Top 10 Award (6th Place) — Combined Track in the Main Round. Their final-results announcement was posted in September; the exact award and placement were confirmed in the organizers' September 29 award email. The company announcement is on BreakAI's news page; this post is the personal, technical record.

Updated September 29, 2026. The July 22 deadline leaderboard showed Rovnou 8th among 68 displayed entries, with a score of 5.55 and 134,905 completed tasks. Those figures below describe that historical snapshot, not the final award placement.

What the contest is

LoRR is a multi-robot control contest sponsored by Amazon Robotics, modeled on warehouse and manufacturing floors. The 2026 edition ran about three months, from April 14 to July 22, with 3,361 submissions from 69 teams.

The problem is lifelong Multi-Agent Path Finding (L-MAPF): hundreds to thousands of robots on a grid map receive a continuous stream of delivery tasks, and you compete on the number of tasks completed within the time limit, without collisions.

  • Robots have only four primitives — forward, rotate right, rotate left, wait — and each takes multiple ticks to complete, so you cannot negotiate an intersection tick by tick
  • New for 2026: motion delays. Robots stall stochastically and do not follow the plan you gave them
  • In the Combined Track, entrants implement everything: the task scheduler, the path planner, and the executor

Scoring sums eleven instances with very different characters — fulfillment warehouses, iron, mazes, rooms — so polishing a single algorithm is not enough by design.

What I built — a planner stack organized by timescale

The submitted stack was designed from the problem statement up, with layers separated by timescale:

static  (preprocess): map analysis, corridor/capacity extraction, all-pairs distance oracle
slow    (~100 ticks): capacity-constrained multi-commodity flow -> a persistent direction field
middle  (~10 ticks) : demand shaping (per-region task quotas), guide-path supply
fast    (every tick): one step of iterative PIBT + time-window reservations

The idea is a division of labor: the slow layer decides the traffic policy — which corridors not to congest — and the per-tick collision avoidance (PIBT) just follows it cheaply. Congestion changes on the scale of hundreds of ticks, so re-deriving everything every tick is wasted computation.

Replay visualization of a local benchmark: 2,500 robots moving across the warehouse map (color = robot heading), rendered from the run's output JSON with a purpose-built renderer
Replay visualization of a local benchmark: 2,500 robots moving across the warehouse map (color = robot heading), rendered from the run's output JSON with a purpose-built renderer

On the implementation side, every painful measurement got promoted into a design rule. A few examples:

  • Freeze configuration at startup. getenv snuck into a hot path twice; the worst case was hammered from 24 threads and cost 52% of the iron score. Environment variables are now resolved exactly once at startup
  • No recursion. Naive recursive priority inheritance in PIBT is a stack-overflow seed, so it is implemented iteratively with an explicit stack
  • Parallelize across layers, not by racing. Running multiple solutions in parallel and picking the best hit a selection-overhead ceiling in my experiments

The gap to first place, itemized

More instructive than the rank was the itemized gap to the winner (No Man's Sky, score 10.629). Comparing completed tasks per instance, the gap is far from uniform:

InstanceRovnou1st placeRatio
orz4,89521,3484.36
rand-A6,64219,9643.01
iron57,045132,6942.33
fulfill-B32,06571,5602.23
maze-B2082371.14

On maze-type maps we are nearly even; the gap widens on large, congestion-dominated maps. My reading: the per-tick collision avoidance is not where I lost — the difference sits in the upper layers, in how far ahead congestion is anticipated and dissolved.

Heatmap of cells where robots stall (local benchmark). Stops concentrate at one-cell-wide doors and the outer ring — congestion handling is the upper layers' problem
Heatmap of cells where robots stall (local benchmark). Stops concentrate at one-cell-wide doors and the outer ring — congestion handling is the upper layers' problem

What I learned from the winner's write-up

The winning team published their solution, and I studied it after the deadline. What stayed with me:

  • The main thread is a dispatcher only; all heavy search runs in parallel in the background
  • A World model faithfully replicating the simulator predicts the future, so plans are built ahead of time between communication windows
  • An EPIBT extension (EPIBTX) constructs the initial solution; parallel LNS/ALNS improves it continuously
  • As a development process, they are strict about "one change at a time, measured per map, accepted or rejected on the numbers"

That last point is the same conclusion I reached while building isutools and tuning private-isu in the same period. Different fields, same convergence: the closer to the top, the more it becomes "decide by measurement, not intuition."

Reflections

Competing with the top teams for three months as a team of one was, plainly, a good experience. At the July deadline, the completed-task gap to first place was roughly 2x across the 11 instances; that difference is not something algorithm knowledge alone would close. It is better described as a gap in the measurement infrastructure and development process that support prediction, parallelism, and per-map tuning.

The traffic-control stack built for this contest will continue to evolve toward real warehouse environments as Rovnou. A contest score does not certify real-world safety — that stays a separate question — but the knowledge carries over.

Links