Cart picking as one optimization problem
In a cart picking system, empty boxes ride on a cart and a worker walks the warehouse filling them. Which boxes share a cart, and in what order the cart moves, decide most of the productivity. This is how the problem was reframed, what the model does, and a version of its core you can run.
Why this is not a routing problem
The picking time per SKU is largely fixed. What varies is how far the worker walks and how long carts wait for each other at busy locations. That makes the lever movement distance and bottleneck waiting, not scanning speed.
But movement cannot be optimized one cart at a time. The system has to decide which orders are mapped to which boxes, which boxes go on which cart, in what order a cart visits its locations, and how to keep several workers from arriving at the same aisle at once. Because one order may need several locations, the problem does not reduce to a travelling-salesman or vehicle-routing formulation — the assignment of boxes to carts changes the routes, and the routes change which assignment is good.
Reframing the objective
Rather than minimizing metres, the model minimizes a lexicographic cost per cart. A cart that stays in one zone beats a cart that saves a few metres by crossing zones; among carts with the same zone count, fewer aisles win; only then does travel time decide. Every comparison, swap and search in the system respects this order.
| Level | What it counts | Why it comes first |
|---|---|---|
| 1 · Zones | Distinct zones a cart enters | Zone changes are the longest walks and the most common source of congestion. |
| 2 · Aisles | Distinct aisles entered | Each aisle is an entry, a sweep and an exit; fewer aisles means fewer detours. |
| 3 · Travel | Walking time of the best route | Decides ties, and keeps the sweep inside each aisle efficient. |
Two operating modes share this core. In the real-time mode the system is asked, box by box as orders arrive, "what should the next cart carry?" and must answer in a few seconds. In the batch mode it receives a whole wave, groups every box into trips, and decides the order in which workers are dispatched so they do not pile into the same aisle.
Left: the cart a first-come rule would send out, walked by nearest neighbour. Right: the cart the model chooses and its exact route. Shuffle the orders for a new wave, or switch to "Whole wave" to see every box packed into trips and dispatched so workers avoid the same aisle. The full control panel (every parameter, routes, tables) is one link away. The layout, orders and names are generated — no real centre data.
Inside the model
A two-stage route
Routing is split so each stage stays exact and fast. Inside an aisle, a dynamic program sweeps the picks along the aisle axis with at most one turn-back, treating picks within a few slots of each other as reorderable. Across aisles, a second dynamic program orders the aisles so that each zone is entered once and traversed in one direction, keeping the entry and exit pick of every aisle as its state. The two stages give the exact best route under those rules in milliseconds, which is what makes the search layers above affordable.
Choosing the next cart in real time
- Smallest aisle set. Among the boxes waiting, find the fewest aisles that can fill a cart, preferring sets that open no new zone; exhaustive over small combinations, with ties broken by the trial route.
- Three-cart lookahead. Build the cart plus the two that would follow, then let an integer program re-partition the three; the re-partition is accepted only if it is at least as good under the lexicographic key and the first cart's route.
- Improvement passes. Up to twenty rounds of add, move, swap-between-carts and swap-with-pool, each accepted only if it does not worsen the key. Only the first cart is returned; the others are a preview.
Planning a whole wave
In batch mode the boxes are grouped by the set of zones they need, trips are filled from the smallest aisle set that still fills a cart, and pairs of boxes are swapped between trips while the total zone count, aisle count and travel fall. The dispatch order is then chosen so that trips running at the same time on different workers share as few aisles and locations as possible — a direct attack on bottleneck waiting.
What it changed
The practical contribution was less the solver than the standardization: order information, SKU locations, cart capacity, movement distances and operating constraints were defined once as common inputs, so a centre with a different layout plugs into the same optimization framework instead of getting a new one. The work fed the broader logistics AI roadmap alongside the QPS decision agent.
Limitations
- The productivity figure is a simulation estimate against the existing assignment and routing practice, not a field A/B test.
- Picking time is treated as fixed; the model does not shorten the scan-and-place step itself.
- Congestion is handled at planning time by separating concurrent trips, not by re-routing carts on the floor.
- The live model above uses reduced search budgets and a browser linear-programming solver for the re-partition step; the production solver is not published.
About the demo and confidentiality
Everything in the embedded model — the floor plan, aisles, orders, SKU codes and location names — is generated from a seed. No centre layout, customer, system name or operational figure appears, and the algorithm shown is a re-implementation of the decision logic, not the production code.