Think of RCS task scheduling as a hospital emergency triage desk. Patients (tasks) keep arriving; the triage nurse (the scheduler) decides by severity (priority) who goes into the trauma bay (a robot) first. The emergency lane exists for genuine emergencies — but if every family shouts "ours is urgent," triage collapses. RCS task priority configuration does exactly this job: it decides who boards first and who waits.
How It Works: Queues, Weights, and the Dispatch Cycle
The RCS is the brain of the robot fleet. Every 100 ms to about a second, it runs a dispatch cycle: score every waiting task, sort, and assign the highest scorers to idle robots. A task's score looks roughly like this:
task score = priority weight × f(wait time, distance, battery, task type)
Rush-order preemption literally means seizing. Note what gets seized: not a place in line, but capacity. Robot time is fixed — every minute a rush order takes is a minute a normal task waits.
You can think of it as a highway toll plaza: the ETC lane (high priority) moves first while the cash lane (normal tasks) queues. But you can't just keep adding ETC lanes — make every lane ETC and nobody is cutting any line; the plaza still jams. Priority only means something when it's scarce.
The f() in the formula deserves a closer look: wait time guards against "waiting forever," distance picks the nearest robot, battery filters out low-charge units, and task type distinguishes hauling, lifting, and charging jobs. A P2 task that has waited 10 minutes can outscore a freshly arrived P1 once aging kicks in — that is the whole point of aging, and also the setting most people casually disable and later regret the most.
Three Ways to Configure Preemption, and What Each Costs
Setup A: priority weighting. Crank the rush order's priority weight — say normal tasks at 5, rush orders at 50. One parameter, dead simple. The cost: crank it too hard (say 100) and low-priority tasks never get served. That's starvation, and it will drag a normal wave to its death.
Setup B: preemptive reassignment. When a rush order arrives, commandeer a robot that's working a low-priority task; the interrupted task rolls back and re-queues. Fastest response. The cost is deadhead: the interrupted trip was wasted mileage, and now it has to run again.
Setup C: reserved capacity. Hold 10–20% of the fleet out of normal waves, dedicated to rush orders. The most stable option. The cost is idle capacity on quiet days — soldiers you feed for a thousand days for one day of battle.
| Setup | Rush response | Impact on normal waves | Complexity | Fits |
|---|---|---|---|---|
| A Weighting | Fast | Kills the wave if over-cranked | Low | Rush share steadily under 5% |
| B Preemption | Fastest | More deadhead, task rollbacks | Low | Rare rushes needing second-level response |
| C Reserved capacity | Consistently fast | Almost none | Low | Volatile rush share with clear peaks |
A project I tuned in 2025: an e-commerce warehouse in eastern China, 180 AMRs. Rush weight set to 50. At a normal 3% rush share, everything was fine; on the 618 shopping festival day, rush orders spiked to 15%, average wait for normal tasks jumped from 50 seconds to 4 minutes, and wave on-time rate dropped 12 points. The logs showed one low-priority task waiting 47 minutes — textbook starvation. Root cause was a single missing piece: weighting configured, no aging mechanism.
How to pick among the three? Look at rush share: steadily under 5%, use A — cheap and sufficient. Rare but second-level response needed (a production line about to starve), use B. Volatile with clear peaks (big sales events, quarter-end), use C. Most warehouses end up with an A+C hybrid: weighting on normal days, reserved capacity switched on two weeks before peak. The dividing line isn't technical, it's the business rhythm — which is why nine out of ten people who copy another warehouse's parameters end up rolling back.
The Field-Tested RCS Task Priority Setup: Tiers, Aging, Reserved Capacity
Tiers. P0 genuine rush (keep under 5% of volume) / P1 priority waves / P2 normal / P3 deferrable (replenishment, cycle counts). The iron rule for what counts as "rush": not that sales says it's urgent, but that the SLA deadline is under X hours away. When sales says "this batch is urgent," ask two questions first — "what's the SLA penalty, and do we lose the customer?" Can't answer? It goes in P2. This is where fake requirements breed, and I never hold back calling them out.
Aging. Tasks that wait too long get automatically promoted — the floor that prevents starvation:
effective priority = base weight + factor × wait time / threshold
Without aging, even beautifully tuned weights are a time bomb: quiet on normal days, guaranteed to blow up at peak.
Reserved capacity. 15–20% in peak season, 5–10% off-peak, adjusted dynamically with rush share — never hard-coded. Remember: weights reorder the queue; they don't create capacity. If rush share pushes past 10% and you're still just tuning weights, you're using the wrong tool.
The Maintenance Traps: Configure Once, Suffer Forever
Trap 1: tune once, run for a year. Peak season changes the SKU mix and the wave rhythm, but the weights are still last year's. Priority configuration should follow the wave plan — review at least quarterly, and always re-tune before peak.
Trap 2: testing without load, so starvation never shows. Tests only watch average wait time — and averages are the most dishonest metric there is. The number that matters is the maximum wait time of low-priority tasks. When that climbs, starvation is coming.
Trap 3: bracing against an over-limit rush share. If rush orders stay above 10% of volume long-term, that's not a scheduling problem, it's a capacity problem: add robots, or demote some "rush" orders back to P2. You can't patch a capacity gap with scheduler parameters.
Trap 4: letting anyone mark P0. The biggest enemy of priority isn't the parameters — it's people. P0 marking rights must be restricted: who can mark, whether it needs approval, and a monthly audit of the true P0 share. Leave marking open and P0 will exceed 20% within three months; no tuning saves you after that.
So is the priority setup worth it? Watch one pair of numbers: rush-order on-time rate hitting target while average wait time for normal tasks stays flat. Both true, and the configuration is right. Only one true, and you're fooling yourself.
By Da Liu, Automation Engineer
