Here's the bottom line: RCS task allocation is not "send whoever is closest." The four variables that actually decide allocation quality are distance, battery, task type, and congestion — weighed together. I've seen the closest-first default fail three times, with the same script every time. Get the allocation logic right, and a 20-bot AMR fleet can cut its deadhead rate from around 40% to under 25%, with peak-hour aisle gridlock basically gone.
Why Closest-First Allocation Keeps Failing
September 2023, a 3PL apparel warehouse in eastern China, 18 lift-type AMRs going live. The RCS ran the vendor's default policy: pure closest-first allocation. On launch-day promo, six inbound tasks dropped at once. The RCS dispatched the six nearest bots — and all six converged on the same main aisle. The front bots waited for the rear bots to yield; the rear bots were blocked by the front. Eleven minutes of standstill. Meanwhile four outbound tasks at the far end sat with no bots available — the nearest ones were all stuck in the jam. I've seen this exact failure three times.
Closest-first optimizes one dispatch's deadhead distance and ignores what the fleet looks like after the dispatch. Sending six bots the same direction at once is manufacturing your own traffic jam.
The Four Variables RCS Allocation Actually Uses
On my go-live-eve checklist, task allocation gets four line items, verified one by one:
- Distance — not straight-line distance, but deadhead path length: the actual travel distance from bot to task, including one-way aisles and detours. Plenty of tasks are 30 meters as the crow flies and 120 meters of actual driving.
- Battery — bots below 30% state of charge should be automatically deprioritized to short trips only; below 20%, locked out of new tasks and sent to charge. I saw a project where the RCS gave a cross-zone long haul to a bot at 12%. It died mid-aisle, blocking a main artery until someone pushed it out by hand.
- Task type — not all bots can do all jobs. Lift-type versus fork-type can't be mixed, and heavy pallets (over a ton, say) only go to heavy-duty models. The RCS task pool must be filtered by vehicle capability tags before any allocation happens.
- Congestion — will another bot enter the target aisle in the next two minutes? The RCS should allocate by reservation: when dispatching, reserve the path, and cap same-direction entries per aisle (usually two or three, depending on aisle width).
My recommended priority order: task type (hard filter first) → battery (hard constraint) → congestion (dynamic penalty) → distance (tiebreaker). Most RCS defaults put distance first. That's the root cause of the failures.
Robot Task Allocation Strategies Compared: Picking One of Four
| Strategy | Logic | Strengths | Weaknesses | Best for |
|---|---|---|---|---|
| Closest-first | Shortest deadhead wins | Simple, fast response | Pileups, ignores battery | Fleets under 10 bots, off-peak |
| Zone assignment | Warehouse split into zones, fixed bots per zone | Zero cross-zone deadhead, easy to reason about | Load imbalance; a hot zone collapses | Warehouses with stable task distribution |
| Auction-based | Tasks broadcast; each bot bids its cost; lowest bid wins | Near-global optimum, naturally accounts for battery and distance | Complex; needs serious RCS compute | Fleets over 30 bots |
| Pre-assignment + dynamic replanning | Plan 5 minutes ahead, replan live on congestion | Steadiest at peak, least gridlock | Needs order forecasts from the WCS | E-commerce warehouses with sharp peaks |
How to choose? Three questions: ① Is the fleet bigger than 20 bots? If yes, drop closest-first. ② Are there obvious peaks? If yes, use pre-assignment. ③ Can your RCS hardware run auctions? If not, fall back to zones with manual tuning. Don't worship the fanciest algorithm — the one that runs stably wins.
Go-Live-Eve Checklist: RCS Task Allocation Edition
- Low-battery lockout thresholds set? I use 20% lockout, 30% deprioritize.
- Vehicle capability tags matched to task types? Run one negative test: deliberately issue a mismatched task and confirm the RCS rejects it.
- Per-aisle concurrency caps set? Set main arteries and branch aisles separately.
- Deadhead baseline measured? Week one: track empty-travel mileage divided by total mileage daily. Above 35%, retune.
- RCS versus WCS responsibilities documented? Who splits tasks, who assigns bots, who owns the fallback when the interface times out — all in writing.
Three Expensive Failure Modes
Failure 1: bot pileups in one aisle. May 2024, a beauty e-commerce warehouse in southern China, 24 AMRs. At the midnight promo, 40 outbound tasks dropped within 10 seconds. Closest-first sent 14 bots into the same main aisle toward the outbound dock. Total gridlock. The fix: add aisle reservation to the RCS — when same-direction entries exceed three, later tasks auto-reroute or delay dispatch by 30 seconds. After the change, main-aisle traverse time under equal wave sizes fell from an average of 9 minutes to under 3.
Failure 2: blurred lines between RCS, WCS, and PLC. The most common root cause of doomed projects. The division of labor should be: the WCS breaks orders into move tasks (move what from A to B); the RCS assigns tasks to specific bots, plans paths, manages traffic, and schedules charging; the PLC only handles low-level hardware (rollers, lifts). I saw a project where both the WCS and the RCS planned paths, and the two route plans fought each other — bots spinning in place at intersections. The cure: write the interface contract in stone. The WCS issues tasks, never routes. Routes are 100% RCS territory.
Failure 3: dispatching without checking battery. Covered above — a low-battery bot on a long haul is a time bomb. One extra detail: charger locations belong in the allocation model. When dispatching, give low-battery bots tasks that end near a charger, so they finish the job and roll straight into charging. Two birds, one trip.
One Counterintuitive Call: Don't Run the Fleet at Full Load
Many warehouse owners think a bot sitting idle is money wasted. Wrong. My rule: always keep 15–20% of the fleet as flex capacity. Tasks come in waves; a fully loaded fleet hit by a wave has no bots to dispatch, so everything queues, and queuing delays all tasks together. With 20% held in reserve, the wave gets absorbed and average task wait time actually drops. At that beauty warehouse, we held 4 of 24 bots as flex (emergency tasks only) — and average task wait during the promo fell by roughly a third versus running all 24. The trade-off: four bots look idle locally, but the whole system runs faster globally. That's the hardest lesson in RCS task allocation — the optimal assignment isn't the one that keeps every bot busy; it's the one that keeps the system unblocked.
By Lin Xiao, WMS Implementation Consultant
