How a small, testable pipeline — fair work assignment, shortest-route planning and a live 2D map — attacks the single biggest waste in a warehouse: walking.
1. The problem: a picker's steps are the most expensive resource
Meet Hannah, a warehouse picker. Every shift she walks the length of a long-distance race leg — roughly 12–15 km, about 18,000 steps — and a third of her day is spent on foot. Most of that distance is wasted backtracking between the same aisles.
The consequences are familiar to anyone who has worked on a warehouse floor:
- Sore feet and fatigue by mid-shift
- Constant pressure to hit pick quotas
- Confusion over "what do I grab next?"
- Uneven workloads — some pickers slammed, others idle
The hidden cost is large. Unoptimized routes that simply follow the order in which tickets were printed add an estimated 30–50 % of avoidable walking to every pick round, and walking takes up around half of a picker's time — the single largest slice of the shift. Fatigue then feeds back into more mis-picks and more safety incidents.
2. Why the problem persists
Three gaps keep the floor slow and unfair:
- Walking in ticket order. Pickers follow the order the tickets were printed in, not the smartest path through the racks.
- No load balancing. There is no capacity-aware way to spread work, so some workers drown while others wait.
- No shared map. Planners cannot see or explain the plan — there is no single picture of the floor.
Stated this plainly, the solution space becomes obvious: optimize who picks what, optimize the order in which they walk, and make the result visible.
3. The approach: PickPath
PickPath is a prototype built around those two levers — assignment and routing — plus a visualization layer that makes the plan obvious to both pickers and planners. It deliberately focuses on picking only, leaving put-away, replenishment and packing out of scope.
| Goal | What it means |
|---|---|
| Less walking | The shortest feasible route for every worker, every round |
| Fair loads | Work balanced across workers under a hard per-zone capacity |
| Full visibility | One live, shared 2D map of the floor and every route |
4. Architecture: a four-stage pipeline
PickPath processes a scenario end to end in four stages:
- Input — Load. The warehouse layout and the pick tickets are loaded from portable CSV or JSON scenario files.
- Assign — Balance. Tickets are grouped by zone and balanced across workers under capacity. Anything that does not fit is queued for the next round — nothing is dropped.
- Route — Optimize. For each worker, the engine computes the shortest path: printer → all assigned bins → exit.
- Visualize — Animate. A cart walks each route on a 2D map, and a QR scan confirms every bin before the next stop is unlocked.
The reference scenario used throughout development contains 96 racks/bins, 6 workers (2 per zone) and 24 tickets across three zones (A, B and C) with different capacities.
5. Engine 1 — Fair, capacity-aware assignment
The rules
- Zone capacity is a hard cap per worker per round. In the reference scenario Zone A allows 5 picks, Zone B 20 and Zone C 80.
- Greedy / LPT balancing. Each ticket goes to the least-loaded eligible worker (the classic Longest Processing Time first heuristic for load balancing).
- Overflow, never drop. If the best worker is already at capacity for the current round, the ticket is queued into that worker's next round.
- Pluggable. The heuristic sits behind an interface so it can later be replaced by an exact solver (Integer Linear Programming or min-cost flow).
The algorithm
Tickets are first bucketed by (zone, task type). Within each bucket the engine repeatedly hands the next ticket to the least-loaded eligible worker:
for ticket in bucket:
best = min(eligible, key=lambda w: load[w])
if in_round[best] >= cap:
round[best] += 1 # overflow to the next round
in_round[best] = 0
assign(ticket, best) # never drop a ticket
load[best] += ticket.size
in_round[best] += 1
In the reference run, the two Zone B workers end up with exactly 12 / 20 picks each — perfectly balanced and well under the cap.
What the tests prove
Unit tests assert two invariants on every run: no worker ever exceeds their zone capacity, and every ticket is either assigned or explicitly queued — no ticket silently disappears.
6. Engine 2 — Shortest route on a real aisle graph
Modelling the route
Each worker's round is an open-path Travelling Salesman Problem (TSP) with fixed endpoints: the path must start at the label printer, visit every assigned bin exactly once, and end at the exit. Unlike the classic closed-tour TSP, the worker does not return to the start.
Distances that respect the floor
Straight-line (Euclidean) distance is meaningless in a warehouse — a picker cannot walk through a rack. PickPath therefore models the floor as an orthogonal aisle graph: nodes sit on walkable lanes, edges run along aisles, and cross-aisles connect them only where there are gaps between racks. Shortest-path distances between every pair of points of interest (printer, bins, exit) are pre-computed on that graph and fed to the route optimizer as a distance matrix.
Nearest-neighbour seed + 2-opt
The optimizer uses two well-known, fast heuristics:
- Nearest-neighbour seed. Starting at the printer, repeatedly walk to the closest unvisited bin, then finish at the exit.
- 2-opt local search. Repeatedly take a segment of the route and reverse it whenever doing so shortens the total path. Because the endpoints are fixed, only the interior of the route is ever reversed.
def two_opt(route, dist):
# route = [printer, bin_1, ..., bin_n, exit]; endpoints stay fixed
improved = True
while improved:
improved = False
for i in range(1, len(route) - 2):
for j in range(i + 1, len(route) - 1):
a, b = route[i - 1], route[i]
c, d = route[j], route[j + 1]
if dist[a][c] + dist[b][d] < dist[a][b] + dist[c][d]:
route[i:j + 1] = reversed(route[i:j + 1])
improved = True
return route
The guarantee
Because 2-opt only ever accepts improving moves, the optimized route can never be longer than its starting point. PickPath additionally checks the result against the naive ticket-order route and enforces in its test suite that optimized distance ≤ naive ticket-order distance — always. The visual difference is striking: the naive route is full of backtracking and crossings, while the optimized one flows along the lanes.
7. Making the plan visible: the live 2D simulation
Optimization that nobody can see is hard to trust. PickPath renders the warehouse top-down — zones, racks, printer and exit on one shared map — and animates each round:
- A cart moves along the route from the printer through every bin to the exit.
- It dwells at each pick with a status such as "Picking B2-4 · 3/8".
- A navigation-style panel gives turn-by-turn directions and a timeline.
- Play, pause, speed control and timeline scrubbing let planners replay any round.
Scan to advance
At each stop the worker scans the bin's QR code. A wrong scan blocks the next stop, so the worker physically cannot move on with the wrong item — a simple, effective guard against mis-picks.
8. Results
The headline results below are enforced by the automated test suite, not just claimed:
| Metric | Result |
|---|---|
| Route quality | 2-opt distance ≤ naive ticket-order distance, always |
| Ticket coverage | 100 % of tickets assigned or explicitly queued |
| Capacity violations | 0 — no worker exceeds their zone cap |
| Automated tests | 15, all green in CI on every push |
| Routing time | < 1 s for the 24-ticket scenario |
| Pick verification | 100 % of picks QR-verified; wrong bin blocked |
Total walking distance is printed per worker for every run, so the improvement is measurable rather than anecdotal.
Projected operational impact
The following figures are projections derived from the measured route and assignment gains, not measurements from a live deployment:
| Dimension | Projected impact |
|---|---|
| Time | 30–50 % less walking per round; +15–25 % more picks per hour from reclaimed walking time |
| Cost | ~20 % lower pick-labour cost per order line; ~2 hours of walking saved per picker per shift |
| Human error | ~30 % fewer fatigue-driven mis-picks; zero overloaded workers |
| Coordination | Manual dispatch replaced by one shared, explainable plan |
9. Engineering for production, not just for the demo
A hackathon prototype is only useful if it can grow. PickPath was built with that in mind:
- Containerized with Docker for repeatable runs.
- PostgreSQL for persistence, with an SQLite fallback for zero-setup local use.
- Portable JSON scenarios, so new layouts and ticket sets can be tested without code changes.
- Secure by default: non-root container images, no hard-coded secrets, and validated inputs at every boundary.
10. Roadmap
The tested foundation is ready for a pilot. The next steps are:
- Smarter solver. Swap the greedy heuristic for an ILP or min-cost-flow optimizer behind the same interface, and compare results on the same scenarios.
- Live order streams. Ingest real ticket streams from a warehouse management system and re-route dynamically as new orders arrive.
- KPI dashboard. Track distance saved and workload fairness over time, per worker and per zone.
11. Key takeaways
- In order picking, walking is the dominant cost — optimizing it pays off more than almost anything else on the floor.
- Two classic, well-understood techniques — LPT-style greedy balancing and nearest-neighbour + 2-opt routing — deliver most of the gain at sub-second speed.
- Model the real floor. Distances must follow aisles, not straight lines.
- Encode the guarantees as tests: capacity is never exceeded, no ticket is dropped, and the optimized route is never worse than the naive one.
- Make the plan visible. A live map and scan-to-advance turn an algorithm into something pickers and planners trust.
Smarter picking. Shorter walks. Fairer workloads.
Top comments (0)