IT 19 052

Examensarbete 30 hp
September 2019

Artificial Intelligence for

Warehouse Picking Optimization
- An NP-Hard Problem

Louis Janse van Rensburg

Institutionen för informationsteknologi

Department of Information Technology
1
 Abstract
Artificial Intelligence for Warehouse Picking
Optimization - An NP-Hard Problem
Louis Janse van Rensburg

Teknisk- naturvetenskaplig fakultet

UTH-enheten This master thesis work demonstrates an approach to processing warehouse
management system log-dump datasets and architectural CAD floor maps for
Besöksadress: graphical network representation of large warehouse environments. This
Ångströmlaboratoriet
Lägerhyddsvägen 1 representation enables use of stochastic search and linear programming algorithms
Hus 4, Plan 0 (Simulated Annealing and Concorde TSP Solver) for the purpose of warehouse
pick-run routing optimization (a case of the NP-Hard Travelling Salesperson
Postadress: Problem). By comparing over 20 000 historic routes with optimized routes for the
Box 536
751 21 Uppsala same pick-run instances, it is shown that optimized routing reduces distance travelled
by warehouse forklift pickers at an Ahlsell Warehouse by approximately 15%, and
Telefon: that solving these optimal routes can be achieved, for practical purposes, in
018 – 471 30 03 near-instantaneous time.
Telefax:
018 – 471 30 00

Hemsida:
http://www.teknat.uu.se/student

Handledare: Lijo George

Ämnesgranskare: Michael Ashcroft
Examinator: Mats Daniels
IT 19 052
Tryckt av: Reprocentralen ITC
1
 III
V

Acknowledgements

Thank you to Adjunct Lecturer Michael Ashcroft, Lijo George, Johan Oxenstierna, Se-
nior Lecturer Justin Pearson, Professor Pierre Flener, Lecturer Olle Gällmo, Associate
Professor Matteo Magnani, Senior Lecturer Mohammed Faouzi, Marcel Wong, Michele
Zevasus, Anirudh Jaengam, Suraj Murali, Sujata Tamang, Ingrid Burrowes and Tania
Shaw.

© Louis Janse van Rensburg Uppsala University

Table of Contents IV
VI

Table of Contents

Abstract II
III

Acknowledgements III
V

IX
List of Figures VII

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Literature Review 3
2.1 Overview of Warehouse Operations, Operational Costs and Bottlenecks 3
2.2 The Warehouse Management System (WMS) . . . . . . . . . . . . . . . . 4
2.3 Overview of Warehouse Optimization - Static and Dynamic Approaches 5
2.3.1 Warehouse Layout Design . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2 Rack Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.3 Storing Policies (Random/Chaotic vs Dedicated/Slotting) . . . . 6
2.3.4 Order Picking Strategies . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Pick-Run Routing Optimization . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1 ’Cross-Aisle’ Nomenclature for Standard Warehouses . . . . . . . 9
2.4.2 Static Routing Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.3 Extending Static Routing Heuristics to Layouts with three or more
Cross Aisles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.4 Hybrid Approaches (Picker Routing Heuristics + Dynamic Pro-
gramming) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4.5 Exact Algorithms for determining the Optimal Route in Standard
Warehouse Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.6 Limitations to Generalizing the Exact Dynamic Programming Pro-
cedure [21][10][22] to Wide-Aisle, Non-Standard Warehouses . . 17
2.4.7 Meta-Heuristic Approaches for Optimum Pick-Run Route Ap-
proximation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.4.8 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Problem Specification 21
3.1 Shortest Path Assumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

© Louis Janse van Rensburg Uppsala University

Table of Contents V
VII

3.2 Problems of Interest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2.1 Graph Network Representation (Pre-processing and Pre-computation) 21
3.2.2 Extraction of Historic (Human Picker) Pick-Runs from the WMS
Log Data for Problem Instance Generation . . . . . . . . . . . . . 22
3.2.3 Experimentation and Evaluation . . . . . . . . . . . . . . . . . . . 22

4 Methodology 23
4.1 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 WMS Log Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.2 Architectural CAD Drawing . . . . . . . . . . . . . . . . . . . . . 23
4.2 Main Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Main Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.1 Unobstructed Node Pairs Connectivity Algorithm for Adjacency
Matrix Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2 Weighted Adjacency Matrix Generation Algorithm . . . . . . . . 28
4.3.3 Floyd-Warshall All Node Pairs Shortest Path and Shortest Path
Distance Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3.4 Simulated Annealing . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.5 Concorde TSP Solver . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Main Data Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.4.2 Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.3 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.4 Python Dictionaries . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4.5 Graph Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Graph Network Representation . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5.1 The Problem of Missing Data . . . . . . . . . . . . . . . . . . . . . 37
4.5.2 Data Gathering - Warehouse Site Visit . . . . . . . . . . . . . . . . 38
4.5.3 Data Processing for Graph Network Construction . . . . . . . . . 40
4.5.4 Graph Network Generation . . . . . . . . . . . . . . . . . . . . . . 52
4.5.5 Mapping of WMS Location Tags to Nodes in G for Live Picker
Route Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6 Extraction of Historic Pick-Run Instance Data . . . . . . . . . . . . . . . . 54
4.7 Experimentation and Evaluation . . . . . . . . . . . . . . . . . . . . . . . 55
4.7.1 Total Tour Distance Comparison - Optimized (Simulated Anneal-
ing and Concorde) vs Historic Pick-Run Tours (N = 20854) . . . . 55
4.7.2 Trial and Error Tuning and Evaluation of Simulated Annealing . 56
4.7.3 Evaluation of Concorde TSP Solver . . . . . . . . . . . . . . . . . 56

5 Results, Analysis and Discussion 57

5.1 Total Distance Comparisons: Optimum vs Optimized vs Historic Routes 57
5.2 Random Sample Set Generation for Performance Analysis . . . . . . . . 58

© Louis Janse van Rensburg Uppsala University

Table of Contents VI
VIII

5.3 Parameter Tuning - Simulated Annealing . . . . . . . . . . . . . . . . . . 58

5.3.1 Energy and Exploration . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Run-time Comparisons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Distance Reduction Comparisons: SATP and SADP relative to Optimum
(CTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

6 Future Work 66

7 Conclusions 67

Literature 68

© Louis Janse van Rensburg Uppsala University

List of Figures VII
IX

List of Figures

Figure 2.1: Overview of Warehouse Functions . . . . . . . . . . . . . . . . . . . . 4

Figure 2.2: WMS Order Fulfillment . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Figure 2.3: Rack Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Figure 2.4: Cross-Aisles in Standard Warehouses . . . . . . . . . . . . . . . . . . 9
Figure 2.5: Transversal Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 2.6: Return Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Figure 2.7: Midpoint Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2.8: Largest Gap Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Figure 2.9: Composite Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Figure 2.10: Heuristics for Layouts with Middle Aisles . . . . . . . . . . . . . . . 13
Figure 2.11: Aisle-by-Aisle Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 2.12: Combined and Combined+ Heuristics . . . . . . . . . . . . . . . . . . 15
Figure 2.13: Determining the Optimal Tour in Single Block Standard Warehouse 16

Figure 4.1: Warehouse Floor CAD Drawing . . . . . . . . . . . . . . . . . . . . . 25

Figure 4.2: Illustration of how Graph Connectivity was Established . . . . . . . 26
Figure 4.3: CAD Map Rack Label Correspondence to Log Data Rack Attributes 37
Figure 4.4: Rack Segment Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 4.5: Plotted Polygonal Representation of Warehouse Floor Structures . . 41
Figure 4.6: Illustration of the Problem of Mapping WMS Location tags to Nodes
in Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Figure 4.7: Plotted Nodes and Polygons . . . . . . . . . . . . . . . . . . . . . . . 51
Figure 4.8: Depot Node and Examples of Pick-Point Nodes, Obstacle Corner
Nodes, and Dummy Obstacles. . . . . . . . . . . . . . . . . . . . . . 52
Figure 4.9: A Virtual Warehouse - Graph Network G . . . . . . . . . . . . . . . . 53
Figure 4.10: Illustration of Problem Instance Distance Matrix Extraction. . . . . . 54
Figure 4.11: Distribution of Extracted Historic Pick-Run Instance Problem Sizes. 55

Figure 5.1: Comparison of Total Route Distances: Historic Routes vs Simulated

Annealing (Default Parameters) vs Simulated Annealing (Tuned Pa-
rameters) vs Concorde (Optimal) . . . . . . . . . . . . . . . . . . . . . 57
Figure 5.2: Example Pick-run: Historic vs Optimum . . . . . . . . . . . . . . . . 58
Figure 5.3: Exploration Chance Counts - SADP . . . . . . . . . . . . . . . . . . . 60
Figure 5.4: Exploration Chance Counts - SATP . . . . . . . . . . . . . . . . . . . 60
Figure 5.5: Exploration Counts - SADP . . . . . . . . . . . . . . . . . . . . . . . . 61

© Louis Janse van Rensburg Uppsala University

 X
List of Figures VIII
X

Figure 5.6: Exploration Counts - SATP . . . . . . . . . . . . . . . . . . . . . . . . 61

Figure 5.7: Run-time Comparison SADP vs CST . . . . . . . . . . . . . . . . . . 63
Figure 5.8: Run-time Comparison SATP vs CST . . . . . . . . . . . . . . . . . . . 63
Figure 5.9: Concorde for Larger Instances . . . . . . . . . . . . . . . . . . . . . . 64
Figure 5.10: SADP Distance Reduction: Percentage Error Deviation from Opti-
mum (CTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figure 5.11: SATP Distance Reduction: Percentage Error Deviation from Optimum
(CTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

© Louis Janse van Rensburg Uppsala University

Introduction 1

1 Introduction

Warehouse optimisation has traditionally been a field of Operations Research where

efforts are directed toward generating static solutions to isolated problems in highly
modularized warehouse control systems [1]. In order to meet growing consumer demand
and remain competitive, warehouse operators are turning away from static control
systems and are instead embracing chaotic storage and dynamic picker routing practices
[2]. This thesis explores warehouse optimization theory and practice, and outlines the
design and implementation of an online pick-run routing optimization pipeline built as
a result of processing a log data set and an architectural CAD drawing.

1.1 Background
This thesis project was undertaken on-site at Sony Mobile Communications (SMC), in
Lund, Sweden, as part of SMC’s initiative to develop industrial business-to-business use
cases for applied artificial intelligence (AI), machine learning (ML) and deep learning
(DL) technologies. The catalyst for the project was a data set, made available to SMC
for data mining following a collaborative data-sharing agreement between SMC and
Consafe Logistics (CL), a leading European warehouse software solutions provider
that services 850 warehouse sites across 30 countries. This data-set is a log-dump of
internal warehouse operations occurring at the Ahlsell Warehouse Gardemoen site in
Oslo, Norway, over a two month period in 2015 (two 2018 datasets were later made
available). Predominantly, the log-data recorded ‘picking’ events of warehouse personnel
(‘pickers’) operating forklifts to collect goods stored in the warehouse to satisfy orders
placed by Ahlsell’s customers. The ongoing goal of the collaboration between CL and
SMC is to develop AI optimization technology to improve the warehouse pick-rate key
performance indicator (KPI).

1.2 Motivation
The motivating challenge for this thesis work is to apply AI methodologies to improve
the pick-rate KPI of an Ahlsell warehouse. In general, warehouse optimisation is an
exciting field for applied computer science as necessary conditions are satisfied for the
design and implementation of dynamic, end-to-end, artificially intelligent warehouse
control systems. These conditions are; i) the availability of ample amounts of data
(logged by warehouse management systems) capturing the warehouse environment

© Louis Janse van Rensburg Uppsala University

Introduction 2

and its processes, ii) access to powerful cloud-based CPUs and GPUs that enable online
inference and near-instantaneous solving (else, approximation to optimal solutions) of
complex combinatorial problems, and iii) open-source access to a variety of AI, ML,
and DL tools. Although this applied AI thesis project falls far-short of implementing an
end-to-end AI warehouse optimization system, the motivation to do so has resulted in
the successful development of pick-run optimization software that is to be trialed at the
Ahlsell Warehouse Gardemoen site in 2019.

1.3 Aim
The aim of this work is to datamine and process available resources (WMS log-dump
dataset and an architectural CAD drawing of the warehouse floor layout) and implement
AI methods to create an online application that improves the pick-rate KPI of the Ahlsell
Warehouse Gardemoen Site in Oslo. The deductive rationale behind this aim is that:

(Premise 1) The pick-rate is inversely proportional to the time spent picking.

(Premise 2) Time spent picking is a function of distance travelled by pickers
carrying out pickruns.
(Conclusion) Minimizing distance travelled by pickers on pickruns will
therefore reduce time spent picking, increasing the number of picks per unit
time.

There are caveats to accepting the above conclusion. Namely, modification of

routes travelled by pickers could lead to increased congestion that would cause delays,
as existing picker traffic norms could be violated.

© Louis Janse van Rensburg Uppsala University

Literature Review 3

2 Literature Review

2.1 Overview of Warehouse Operations, Operational Costs and

Bottlenecks
Warehouses operate within a logistics supply chain, and the main activities involved in
warehouse are receiving goods, item storing and put-away, picking, order-consolidation
and checking, packing, and shipping:

1. Trucks deliver manufactured consumer goods to a given warehouse where goods

enter the goods-receiving phase. Goods are unloaded, inspected for quality assur-
ance and then registered in the WMS as having been received [3]. Receiving goods
is, on average, estimated to account for 10% of warehouse operational costs [4]

2. Received items then enter the storage and put-away phases where they are trans-
ported internally to appropriate storage locations (assigned by the WMS) given
item volume, dimensions and weight. Items can also be cross-docked (transported
directly to outbound shipping areas) [3]. Item storing and put-away are estimated
to account for 15% of warehouse operational costs [4].

3. In order to satisfy orders placed by customers, warehouse pickers are assigned pick-
lists (in the Ahlsell warehouse, the picklist is displayed on an interface mounted
on the picker’s forklift) and subsequently travel, search-for and extract items on
pick-runs starting and ending at a depot, located near an outbound shipping zone.
Picking is estimated to account for between 50%-70% of warehouse operational
costs, and travelling alone accounts for 55% of the time pickers spend carrying out
pick-runs [1] [4].

4. Orders are then consolidated, checked for accuracy and completion, and packaged
[3].

5. Packaged items are then loaded optimally (given the available space) onto trucks
that service customers and intermediary distributors located at various points
along predefined transportation routes [3]. For a given warehouse there are a
limited number of outbound transportation ’docks’ where trucks can be parked
and filled with packaged goods. It is the task for warehouse personnel (reliant
on the WMS) to ensure that orders are picked efficiently and readied on time for
outbound transportation, otherwise costly knock-on delays are incurred.

© Louis Janse van Rensburg Uppsala University

Literature Review 4

Given that picking is the most expensive and time consuming operation in warehousing,
and that travel time accounts for the majority of time spent picking (where time is a func-
tion of distance travelled), optimizing pick-run routes travelled by pickers to minimize
travel distance is therefore a focal point in the warehouse optimization literature.

Figure 2.1: Overview of Warehouse Functions as depicted in [3].

2.2 The Warehouse Management System (WMS)

WMS companies provide warehouse operators with control in the form of enterprise
resource planning, inventory management, and task scheduling software services. They
also provide interfaces for warehouse personnel and integrate self-storage machinery,
automated picking machinery, and conveyor-picking machinery into the control system.
In order for WMS companies to remain competitive in a saturated market, product
development is concerned primarily with optimization of warehouse processes [5].
A difficulty facing optimization of an existing WMS architecture is that WMSs
are modular. For instance, in this project, the WMS servicing the Ahlsell Gardemoen
warehouse separates distinct process (order line generation, box calculation, constraint
enforcement and order interleaved pick-run list generation). For this project, picking
events were visible as post-hoc timestamped events in the WMS’s picking data dump.
However, no specifications on box calculation algorithms and warehouse constraints
were provided.

© Louis Janse van Rensburg Uppsala University

Literature Review 5

Figure 2.2: WMS Order Fulfillment Schema.

2.3 Overview of Warehouse Optimization - Static and Dynamic

Approaches
2.3.1 Warehouse Layout Design

Warehouse floor design is concerned with the sectioning and placement of racks, picking
depots, automated storage and picking machinery, conveyors, carousels and inbound-
/outbound processing zones [6]. The main objective of warehouse floor layout opti-
mization is to create warehouse environments that enable humans and machines to pick
efficiently. Design effort is predominantly directed towards optimizing rack layout with
the objective to reduce distance traveled during pick-run execution, and optimizing
layout is claimed to have the greatest impact on pick-run travel distance relative to other
travel distance minimization strategies [7].
A problem faced by warehouse designers, however, is that customer orders are
subject to change over time and this has the implication that the variance in physical
dimensions of goods is also subject to change. Furthermore, warehouse machinery
(automated storage, picking machinery and conveyors) become outdated quickly and
are limited to handling goods with restricted physical dimensions (goods handled by
automation in the Ahlsell warehouse considered in this project work vary less in physical
dimensionality and tend to be smaller than goods handled by the forklift pickers). Still,
warehouse layout optimization is not entirely limited to a one-off design decision as
warehouse racks are demountable and can be moved around the warehouse floor space,
however, changing the warehouse layout can be disruptive and costly.

2.3.2 Rack Layout

The literature identifies various rack layout policies [3] [7] [8] [9]. These include:

• Traditional layout (TL)

• Traditional layout with a middle cross aisle (TL-MA)

© Louis Janse van Rensburg Uppsala University

Literature Review 6

• 90 degree rotated traditional layout with middle cross aisle (R-TL-MA)

• Fishbone layout (FBL)

• Flying-V layout (FVL)

• Inverted-V layout (IVL)

Figure 2.3: Rack Layouts adapted for reuse here from [3].

Introduction of the middle cross aisle (see TL-MA and R-TL-MA in Figure 2.3) to
the traditional layout is claimed to reduce warehouse pick-run distance at the cost of
losing available storage space [10]. V-shaped and Fishbone layouts are claimed to result
in pick-run travel distance minimization of 10%-20% when compared with middle aisle
layout contexts [8], and the Inverted-V layout is claimed to provide an additional 3%
distance minimization [9]. Pick efficiency gain resulting from rack layout optimization is
nonetheless subject to the interdependencies between warehouse design and i) routing
strategies used by pickers, ii) the space available for travel through aisles and at cross
junctions, iii) vehicles being used by pickers (i.e. forklifts or carts), iv) order size and
order item frequencies, v) order picking policies, and vi) the goods storing policy [3].

2.3.3 Storing Policies (Random/Chaotic vs Dedicated/Slotting)

Storing policies define how incoming goods are stored in the warehouse and must
balance both maximal utilization of available space and minimization of picker traveling
distance [11]. The two main approaches to storing are i) random (or, chaotic), and ii)
dedicated (also referred to as slotting) [12]. In random storing, incoming goods are
simply stored at the nearest available pallet location. The downside to random storing is
that it can result in increased picker travel distance [11]. In dedicated storing, goods are
assigned specific storage locations [13]. The problem with static (or one-off ) dedicated
storing is that warehouse storage space may be sub-optimally utilized [11].
Association rule algorithms from the data mining literature [14] have been used
in the development of dynamic slotting policies where between-goods co-frequencies

© Louis Janse van Rensburg Uppsala University

Literature Review 7

in historical orders are mined in order to generate inferences about item associations
in future orders [14]. For example, consider four items A, B, C and D that, individually,
have equal order frequencies. Assume that i) items A and B feature very frequently
together in customer orders, ii) item C features moderately frequently with all other
items A, B and D, and iii) item D features moderately frequently with item C, while
featuring rarely with items A and B. A dedicated storage policy based on association
rules would minimize the distance between the storage locations of items A and B; item
C would be stored between the cluster of items A and B, and item D; and item D would
be expected to be placed furthest from items A and B. The benefit to this strategy is that
in the face of seasonal order fluctuations, storage space can be maximally utilized and
picker travel distance can be minimized.
Slotting works well in environments where order frequencies are predictable,
however, in warehouse contexts where orders are less predictable, chaotic storage is
preferable. For e-commerce warehousing companies, such as Amazon, highly variable
customer orders for a wide range of goods has resulted in the adoption of chaotic storage
policies over slotting policies [15].

2.3.4 Order Picking Strategies

Order picking strategies determine how pick lists are generated. There are three main
types of picking strategies, these are i) single order picking [3], ii) order interleaved
picking (or, batching) [16] and iii) zoning [17]. Both ii) and iii) are implemented in order
to reduce picker travel time otherwise incurred by the single order picking strategy.
In single order picking, warehouse pickers (driving forklifts or pushing carts) are
assigned pick-runs where they simply pick the items belonging to a single order. In
order interleaved picking, the full capacity of the vehicle (forklift or cart) is utilized such
that multiple items from distinct orders can be picked on the same pick-run. Zoning
ensures that the picker only picks items stored in a given material handling area, or
warehouse section. Zoning is an add-on strategy to order interleaved picking, and both
order interleaved picking and zoning strategies can result in the splitting of a given
order such that the work to pick the order is shared between pickers. Although zoning
is claimed to reduce congestion, its downside is that order splitting occurs considerably
more often compared to pure order interleaving, leading to bottleneck delays at the
order consolidation step as multiple pickers may fail to finish picking their respective
pick lists at the same time [3].
In the trial warehouse considered for this thesis project, both order interleaved
picking and (relaxed) zoning strategies are used, however, the assigned zones are
large (pick-runs most often occur in one of four warehouse sections each having an
approximate floor space of 100m x 75m). Regardless of the order-picking strategies used
in a given warehouse, the number of possible ways to route a pick-run is factorial in the
number of item locations to visit, and determining an optimal order in which to pick
goods is a case of the Travelling Salesperson Problem (TSP).

© Louis Janse van Rensburg Uppsala University

Literature Review 8

2.4 Pick-Run Routing Optimization

The pick-run routing problem is a case of the (TSP) and assuming P , NP, it is NP-Hard:

Given a depot (start and end location), and a list of locations to visit (items to pick in
the warehouse), what is the sequence of locations to visit that specifies the minimal
length tour?

The literature outlines three approaches to pick-run routing optimization:

1. Static routing heuristics, i.e. routing rules that human pickers follow [18] [19] [20].

2. Scalable algorithms that either determine the optimal route [10][21][22], or approx-
imate it [23] [24].

3. Hybridization of both picker routing heuristics and algorithmic approaches [20][25][26].

The case for implementing static routing heuristics (picker routing rules) over
algorithmic computation is that routing heuristics define easy rules for pickers to follow
(arguably leading to reduced pick errors), albeit at the cost of increased tour distance
when compared to the optimal solution [18][20]. The problem for static routing heuristics
is, however, that they do not scale well in layouts with more than two cross aisles
(see 2.4.1 below for clarification on cross aisle nomenclature) [20]. Although efficient
dynamic programming algorithms determining optimal tours have been developed for
the single block traditional layout [21] and traditional layout with one middle cross aisle
[10], ‘unpredictable computation times’ [20] of the Branch and Bound (BAB) algorithm
[27] to solve instances in less trivial environments (with four or more cross aisles) have
historically forced researchers to develop cumbersome hybridized (computation + picker
routing rules) heuristics [20] [25] [26].
As of 2018, however, [22] have extended the dynamic programming approaches of
[21] and [10] to solve (within reasonable time, t < 1 s) pick routes to optimality in layouts
with up to six cross aisles for instances with n pickingAisles = 60 and nitems = 240. The
authors also introduce an exact, poorer performing mixed integer programming (MIP)
methodology and compare the performance of both MIP and dynamic programming
solvers to the Concorde TSP solver [28], currently considered the State of the Art solver
for the TSP that has been shown to solve all TSPLIB [29] instances of up to 89500 cities
to optimality [30]. Problematically, implementation and evaluation of exact solution
methodologies introduced in [21], [10] and [22], have been limited to standard warehouse
rack layouts that are unlike the layout of the trial warehouse considered in this project.
For optimal route approximation in both standard and non-standard warehouse
layouts researchers have proposed meta-heuristic methods including Simulated Anneal-
ing [24], Genetic Algorithms [23] and Ant Colony Optimization [31]. For the remainder
of this chapter static routing heuristics, hybrid approaches, exact solution and optimum
approximation algorithms are discussed.

© Louis Janse van Rensburg Uppsala University

Literature Review 9

2.4.1 ’Cross-Aisle’ Nomenclature for Standard Warehouses

The pick-run route optimization literature focuses predominantly on routing pickers

in standard warehouse layouts that are characterized by having one or more blocks of
parallel and equal length racks (see 2.4 below). In standard warehouses, a cross aisle is
any aisle running perpendicular to the lengthwise axis of parallel racks. A block refers to
a section of parallel racks with cross aisles skirting the back and front of the section of
racks. The standard warehouse rack layout is therefore any traditional rack layout with:

• Two cross aisles at the front and back of the block(s) of racks.

• Zero or more cross aisles separating smaller blocks of equal dimension.

Any standard rack layout with n blocks therefore has n + 1 cross aisles. Hence,
the single block traditional rack layout with no middle aisle has two cross-aisles, the
traditional layout with a middle cross aisle that splits the racks into two blocks of equal
dimensions has three cross aisles, and so on.

Figure 2.4: Cross-Aisles in Standard Warehouses.

2.4.2 Static Routing Heuristics

Petersen [18] compared optimal routes computed by the BAB algorithm (developed for
the TSP in [27]) against routes generated by five routing heuristics: Transversal (also
referred to as S-Shape in [20]), Return, Midpoint, Largest Gap and Composite in the
context of a single block layout with two cross aisles.
The Transversal heuristic defines the route to be taken as follows: The picker enters
the nearest end of the first picking aisle on the side of the block nearest the depot, and
exits the same aisle at the opposite end. The picker continues to enter and exit opposite
ends of all aisles containing items that require picking (in a left to right or right to left

© Louis Janse van Rensburg Uppsala University

Literature Review 10

fashion, depending on the location of the depot), skipping aisles that do not contain
items for picking.

Figure 2.5: Transversal heuristic as depicted in [18].

The Return heuristic requires that the picker enters and exits the same access point
of any aisle containing pick items. Hence one of the (front/back) cross aisles is not
traversed in a given pick-run.

Figure 2.6: Return heuristic as depicted in [18].

The Midpoint heuristic splits the block in half along the axis perpendicular to the
length of the racks. This heuristic requires that the picker first traverses one cross aisle
in the direction away from the depot, entering and exiting each picking aisle containing
pick items in the half-section adjacent to the cross aisle from where the picker has entered.
The picker must not travel beyond the midpoint and once all items located on one side
of the midpoint are collected, the picker then travels to the opposite cross aisle to pick
items in the same way, this time traveling toward the depot.

© Louis Janse van Rensburg Uppsala University

Literature Review 11

Figure 2.7: Midpoint heuristic as depicted in [18].

The Largest Gap1 heuristic is similar to the Midpoint heuristic in that the picker
first traverses one (front/back) cross aisle in the direction away from the depot, entering
and exiting a given picking aisle (otherwise, skipping an aisle) containing pick items
from the same access point. The picker then returns toward the depot along the opposite
(back/front) cross aisle, entering and exiting (otherwise, skipping) each aisle from the
same cross aisle access point. The difference between the largest gap and mid-point
heuristic is that largest gap segments each picking aisle into gaps, or distances i) between
the front aisle and the first item to be picked, ii) between any two adjacent pick locations,
and iii) between the last item and back cross aisle. The largest of these gaps demarcates
a section of the aisle that is not traversed.

Figure 2.8: Largest Gap heuristic as depicted in [18].

The Composite heuristic (developed by Petersen in [19]) combines the Return

and Transversal heuristics. For a given picking aisle the Return heuristic is applied
when the travel distance between two farthest pick items located on adjacent racks that
face adjacent picking aisles can be minimized when compared to the travel distance
that would result from carrying out the Transversal heuristic. Otherwise, the picker is
expected to route themselves between aisles according to the Transversal heuristic.
1A gap is defined by [32] as "the distance between any two adjacent picks, between the first pick and the
front aisle, or between the last pick and the back aisle. The largest gap is the part of the aisle that is not
visited by the order picker."

© Louis Janse van Rensburg Uppsala University

Literature Review 12

Figure 2.9: Composite Heuristic developed in [19] as depicted in [18].

Evaluation of Static Routing Heuristics in Layouts with two Cross Aisles

Petersen [18] applied the bonferroni t-test to compare route distances generated by
all heuristics and the optimal routes for pick-run instances of increasing size nitems =
{5, 15, 25, 35, 45}, with sample size for each instance size class of n pickruns = 30. Of
the heuristics, the Return heuristic performed worst. For the remaining heuristics, all
performed significantly worse compared to the BAB solver and the difference in mean
route distance compared with the optimal route distance across increasing instance sizes
ranged between 5%-20%. Of the heuristics, the Largest Gap performed best for instance
sizes nitems = {5, 15, 25}, and Composite performed best for the larger instance sizes.

2.4.3 Extending Static Routing Heuristics to Layouts with three or more

Cross Aisles

Roodbergen and De Koster [20] adapted the Transversal (which they referred to as the
S-Shape heuristic) and Largest Gap heuristics to traditional layouts with three to eleven
cross aisles. For both heuristics, the picker is first required to traverse through the aisle
nearest the depot towards the farthest block. In the case of the Largest Gap heuristic,
distinct blocks are picked one-by-one, according to the procedure described above in
section 2.4.2, starting with the farthest block and finishing with the block closest to the
depot.
In the case of the Transversal heuristic the picker enters and exits opposite ends 2
of sub-aisles containing items to pick, skipping sub-aisles that do not contain pick items.
In comparison to the optimal route and hybrid heuristics (see section 2.4.4 below), static
heuristics perform poorly [20].

2 Theauthors specify the exception that the picker may exit from the same entry point if all items in the
block have been picked.

© Louis Janse van Rensburg Uppsala University

Literature Review 13

Figure 2.10: S-Shape (Transversal) and Largest Gap heuristics as depicted in [20].

2.4.4 Hybrid Approaches (Picker Routing Heuristics + Dynamic

Programming)

Sub-optimal performance of static routing heuristics applied to layouts with 3 or more

cross aisles have lead researchers [20] [25] [26] to hybridize picker routing heuristics with
dynamic programming methods. The problems faced when defining route heuristics
in layouts with 3 or more cross aisles relate to i) the sequence (if any) in which to
visit distinct blocks, and ii) how to best utilize cross aisles when transitioning between
(picking) sub-aisles. For the hybrid approaches discussed below, we can assume that the
depot is located at the bottom left corner of the rack layout (as depicted in Figure 2.11).
Vaughn and Petersen [25] developed an Aisle-by-Aisle heuristic that requires the
picker to pick all items in an aisle before moving onto the next aisle (left-to-right). The
heuristic is aided by dynamic programming where partial order sub-graphs are first
constructed for each aisle, and then optimally joined so that cross-aisles are effectively
traversed when the picker transitions between consecutive picking aisles. Roodbergen[4]
introduced two hybrid heuristics also invoking dynamic programming called Combined
and Combined+ .

© Louis Janse van Rensburg Uppsala University

Literature Review 14

Figure 2.11: Vaughn and Petersen’s [25] Aisle-by-Aisle Heuristic as depicted [20].

The Combined heuristic i) generates partial order sub-graphs for distinct blocks
using dynamic programming and ii) constructs a route by combining these shortest
paths such that picker first moves along the aisle nearest the depot toward the farthest
block. The picker picks all items belonging to distinct blocks according to the partial
route generated in i), working backwards block-by-block towards the depot.
The Combined+ heuristic first computes the route according to the Combined
heuristic. Secondly, it requires that the picker picks aisles in the final block (closest to the
depot) from right to left in order to minimize return distance to the depot. Thirdly, if
no items require picking in the first sub-aisle of the block closest to the depot (which
is traversed en-route to the farthest block in the Combined heuristic) and the second
sub-aisle of the first block does contain pick items, the heuristic requires that the picker
traverses and picks items in the second sub-aisle in the block closest to the depot en-route
to the farthest block. Finally, the picker picks items according to the shortest partial
order sub-graph tour, computed for the remaining items in the block closest to the depot,
before returning to the depot.

© Louis Janse van Rensburg Uppsala University

Literature Review 15

Figure 2.12: Combined and Combined+ Heuristics as depicted in [20].

Roodbergen[4] assessed the performance of the hybridized Aisle-by-Aisle, Com-

bined and Combined+ heuristics, (as well as static heuristics Transversal and Largest
Gap, mentioned in section 2.4.3). The authors concluded that even though, overall,
the Combined+ heuristic performed best compared to the other heuristics, the routes
produced by this heuristic did not consistently approximate the optimal route (calculated
with the BAB solver). Sub-optimal results produced by both static and hybrid heuristics
have lead researchers to abandon heuristic approaches in favor of purely algorithmic
approaches. In practice, however, heuristics are still used today, in both standard and
non-standard warehouse layouts 3 .

2.4.5 Exact Algorithms for determining the Optimal Route in Standard

Warehouse Layouts

Ratliff and Rosenthal [21] first developed a graph based dynamic programming proce-
dure to determine the optimal pick sequence in a single block traditional layout with
cross aisles at the front and back of the block. The authors exploited the necessary and
sufficient conditions for any sub-graph to be considered a partial tour sub-graph (PTS),
as well as the fact that in such a layout picking aisles are of equal length, and cross
aisles are of equal length. The authors were able to determine a procedure that first
i) constructs candidate PTSs for each aisle containing pick locations, and secondly ii)
joins the PTSs iteratively by assessing cross aisle arc configurations between consecutive
picking aisle PTSs to construct the optimal tour (see figure 2.13). They showed the
3 Anecdotally, two warehouse sites located in Malmö, Sweden, and Oslo, Norway, were visited during this
project. In both contexts (with standard layout and non-standard layout, respectively), pickers are still
expected to use heuristics (routing rules) to complete pick-runs.

© Louis Janse van Rensburg Uppsala University

Literature Review 16

optimal tour could be determined linearly in the number of piking aisles. The authors
acknowledged that their approach is not suitable when picks of adjacent racks facing
an aisle required crossing the aisle more than once [21]. The reason for this is that the
authors’ graph representation is constructed based on the assumption that each aisle
has zero width. This simplified graphical representation has persisted in the literature
where it has been applied to standard warehouses with 3 cross aisles [10] up to 11 cross
aisles [22].

Figure 2.13: Determining the optimal tour in single block standard warehouse as
depicted in [21].

Roodbergen and De Koster [10] extended the procedure outlined by Ratliff and
Rosenthal to develop a linear time (in the number of aisles and items to pick) algorithm
for solving pick-run instances in a standard warehouse with three cross aisles. Pansart,
Catusse and Cambazard [22] adapted the procedure to run exponentially in the number
of cross-aisles, solving instances in layouts with up to six cross aisles, n pickingAisles = 60
and nitems = 240. These authors also introduce a poorer performing mixed integer
programming (MIP) methodology that is able to handle item precedence constraints (a

© Louis Janse van Rensburg Uppsala University

Literature Review 17

functionality that is important when item packaging rules necessitate, for instance, that
heavier goods are to be picked first to be placed at the bottom of a box). Interestingly,
the authors demonstrate improved computation time for the dynamic programming
procedure when compared to Concorde TSP Solver for instance layouts with up to six
cross aisles. However, they cannot produce a solution within a 30 minute timeout for
instances with 11 cross aisles (n pickingAisles = 60 and nitems = 240), where as Concorde
TSP Solver produces a solution for the same instance in under 2 seconds.

2.4.6 Limitations to Generalizing the Exact Dynamic Programming

Procedure [21][10][22] to Wide-Aisle, Non-Standard Warehouses

The procedure developed by [21] and adapted by [10] and [22] to solve the picker
routing problem in standard warehouses does not generalize to large, wide-aisle, non-
standard warehouse environments with path obstacles. The reason for this is because
non-standard warehouse environments violate the necessary conditions for problem
modeling specified by the authors. These conditions are that:

1. The warehouse rack layout has one [21] or more [10][22] rectangular blocks of
parallel racks, where middle cross aisles separate distinct blocks.

2. All aisles are of equal length.

3. All cross aisles are of equal length.

The warehouse considered for the current implementation fails to satisfy each of
the above conditions. That is, i) the warehouse contains multiple irregularly shaped
blocks of parallel racks (in addition to standard rectangular blocks), ii) aisles are of
different lengths, and iii) cross aisles are of different lengths.
Furthermore, Ratliff and Rosenthal [21] cautioned against the use of their approach
to solve picking routes where pickers must cross the width of an aisle more than once to
pick items located on opposing racks. Randolph [33] demonstrated that picker routing
is sensitive to aisle width, for high density pick-runs or in the case of wide aisle contexts.
This is a problem for [22] who maintain the no aisle width assumption while testing
their procedure on instances where multiple aisle crossings take place. In the Ahlsell
warehouse, the forklift aisle width range is between 3.2 m and 3.6 m (unlike cart picking
aisles that can be as narrow as 1.2 m [34]), and pick runs frequently require picking of
goods on opposing racks skirting a given aisle.
The dynamic programming procedure requires rectilinear representation of the
graph network. This introduces the assumption that while travelling, the direction
change of a picker can only occur at 90 , 180 and 270 , thus, distance travelled by
pickers is calculated according to the L1-Norm, or, Manhattan distance. In reality,
however, pickers travel along the hypotenuse (i.e. cut corners) when unobstructed 4 .
Hence, distance calculations in the current work (L2 Norm, or Euclidean distance, see
4 This was observed at two warehouse sites, and was confirmed by warehouse site managers at both sites.

© Louis Janse van Rensburg Uppsala University

Literature Review 18

chapter 4) are argued to be more sensitive, as the no aisle width assumption is abandoned,
and actual picker behaviour is taken into account.
Finally, the abstract problem representations given in [21], [10] and [22] do not
deal with the problem of path obstructions in the warehouse space due to the reason that
they assume pickers travel around or within distinct blocks of racks. In a non-standard
warehouse such as the one considered in this thesis, there are multiple obstacles (walls,
machinery, conveyors etc. . . ) that must be circumnavigated by pickers.

2.4.7 Meta-Heuristic Approaches for Optimum Pick-Run Route

Approximation

The main drawback to adopting meta-heuristic methods for solving combinatorial

optimization problems is that there is no way to prove a given solution is optimal.
Nonetheless, meta-heuristic methods are desirable when the time window for producing
a solution is limited [35]. For the current implementation, the time window allowed for
optimizing a given pick-run route is 1 second 5 . Irrespective of pick-run instance size, the
number of iterations (in the case of Simulated Annealing and Ant Colony Optimization
(ACO)) or generations (in the case of Genetic Algorithms) before stopping can be tuned
so that a solution can be produced within the specified time window.
Antosiewicz, Koloch and Kaminski [35] compared the performance of meta-
heuristics as applied to the TSP on six randomly generated instances of size {20, 20,
50, 50, 80, 80} as well as two TSPLIB instances att48 and eil76. The outcome variables
were solution quality and solution consistency under a fixed stopping time (100 s), and
computation time when solving instances to optimality. The meta-heuristics assessed
were Simulated Annealing, Genetic Algorithm, Harmony Search, Quantum Annealing,
Particle Swarm Optimization and Tabu Search - the Greedy 2-Opt heuristic method was
also assessed. The authors showed that Simulated Annealing consistently produced the
best results under fixed stopping times and that it was only marginally slower than Tabu
Search when computing the optimal solution. In the warehouse optimization literature,
Genetic Algorithms, ACO and Simulated Annealing have been implemented specifically
in the context of warehouse pick-run routing, however, these implementations have
relied on rectilinear graphical representation (unlike the precise graphical representation
developed in this thesis).
ACO is an iterative population based method modelled on the ability of ant
colonies for path finding through the release of chemicals (or pheromones) of ants trav-
elling to a food source on what are initially random paths [35]. It has been used to
approximate optimal solutions to TSP instances in [35] and has been proposed as a
means for warehouse pick-run route optimization in [31]. A Genetic Algorithm is a pop-
ulation based meta-heuristic, inspired by natural selection, which optimizes population
fitness over generations through mutation, crossover and selection. It has been applied
to the TSP in [35], and specifically to pick-run route optimization in [23]. Simulated
5 This time window was specified in consultation with Consafe Logistics.

© Louis Janse van Rensburg Uppsala University

Literature Review 19

Annealing is an iterative, single solution evaluation method modelled on the natural

phenomenon of metallurgic annealing [36]. Given [35] demonstrated that Simulated
annealing consistently produces best results when compared to other meta-heuristics,
it has been chosen as the meta-heuristic to be implemented in the current work, and is
discussed in more depth here (see Chapter 4 for a detailed implementation description).

2.4.8 Simulated Annealing

In metallurgic annealing, a metal (collection of atoms) is considered to undergo dynami-

cal state changes. The goal is to first heat up, and then gradually reduce the temperature
of a given metal at such a rate that allows the metal to transition to its lowest energy state
(given the final temperature) where all molecules in the metal crystallize in the same
way (resulting in production of high-strength metal). The case made by [36] is that the
process of producing the final state in (successful) metallurgic annealing is analogous to
finding the global optimum in a discrete search space. Correspondingly, unsuccessful
metallurgic annealing can result in meta-stability[36]. That is, the metal as a whole
has solidified, but molecular crystallization of the metal has occurred non-uniformly
(resulting in the production of poor quality, low-strength metal). Simulated Annealing
has been used to approximate optimum tours to TSP problems in [36], [37] and [35] and
has been specifically applied to warehouse pick-run route optimization in [38] and [24].
The main parameters of Simulated Annealing are starting temperature, stopping
temperature, some cooling schedule (characterized by a temperature cooling constant a
and number of iterations that pass between temperature updates), the maximum allow-
able iterations, and a candidate solution acceptance policy. As applied to combinatorial
optimization problems, and specifically to the TSP, Kirkpatrick, Gelatt and Vecchi [36]
have modelled the acceptance probability on the work of Metropolis Et Al [39] who
developed an efficient method for simulating behaviour (energy states) of groups of
atoms in equilibrium at some temperature. During an iteration of Simulated Annealing,
given i) the current temperature T, ii) a current solution S and newly generated (or
neighbour) solution S0 , iii) each solution’s fitness (or, energy in metallurgic annealing,
which is analogized to denote tour distance in a TSP solution) E(S), E(S0 ), and the iv)
change in fitness, E = E(S0 ) E(S), the probability P(S, S0 , T ) of transitioning from S
to S0 , is given by
8
<1, if E < 0.
P(S, S0 , T ) = (2.1)
:exp( E/T ), otherwise.

The function of temperature T is such that initially (starting at a high-energy

state) there is a tendency for the algorithm to transition to sub-optimal states (the fittest
solution so far S⇤ is stored and updated when a fitter solution is found). For simulated
annealing implemented with the common exponential (also known as the multiplicative

© Louis Janse van Rensburg Uppsala University

Literature Review 20

monotonic) cooling schedule, this capacity for exploration declines at each iteration i with
every scheduled update of temperature Ti+1 aTi , 0 < a < 1.
For monotonic cooling schedules (including exponential, quadratic, trigonometric
and linear cooling schedules), temperature Ti+1 at iteration i + 1 is always lower than Ti .
This is, however, not the case for Simulated Annealing implemented with an entropy-
based (also known as the non-monotonic adaptive) cooling schedule introduced by [40]
(which can be combined with any of the standard monotonic functions, and is shown
combined below in 2.2 with the exponential cooling schedule). Given the best solution
found so far S⇤ , and its fitness E(S⇤ ), the current solution S, and its fitness E(S)

T(i+1) µaTi (2.2)

where
E(S) E(S⇤ )
µ=1+ (2.3)
E(S)
This adaptive factor accounts for the entropy of the current solution, or, in other
words, the relative difference between the energy of the current state E(S) and that
of the best state realized so far E(S⇤ ) 6 . Problematically, however, employing this
cooling schedule may result in failure to converge, as temperature may spike and
remain high until the algorithm terminates, resulting in over-eager exploration whenever
E(S) < E(S0 ). This was found to occur in few cases during an attempt to implement the
non-monotonic adaptive cooling schedule in this project. The non-monotonic adaptive
cooling schedule was abandoned and is omitted from methodological description in
chapter 4.

6 In [40], an estimation of the energy of the optimum is used instead of the energy of local optima.

© Louis Janse van Rensburg Uppsala University

Problem Specification 21

3 Problem Specification

This chapter outlines the main assumption of the work and specifies the problems faced
in this thesis project.

3.1 Shortest Path Assumption

There is one assumption maintained in this work:

A warehouse picker always takes the shortest path (that may require navigation
around obstacles) when travelling between any consecutive locations that must be
visited on a pick-run.

Although the assumption above may seem problematic, it is already part of the
picker job-description. That is, for a given ordered pick list, pickers are required to
travel optimally between any pair of pick locations. For experienced pickers carrying
out pick-runs where items are located in proximity (i.e. in the same aisle, or in adjacent
aisles) to one another, this requirement is trivial. However, for less experienced pickers
carrying out pick-runs where items are sparsely located in the warehouse space, this
assumption ought to be subject to scrutiny.

3.2 Problems of Interest

The problems of interest in this thesis project relate to processing raw data (WMS log
data sets and warehouse floor CAD drawing) for data structure generation (see 3.2.1
below), historic pick-run instance extraction (see 3.2.2), algorithmic implementation and
evaluation (see 3.2.3).

3.2.1 Graph Network Representation (Pre-processing and Pre-computation)

This problem relates to mapping WMS pick item location tags to node coordinates in
a 2-D space. Consideration of warehouse obstacles is required in order to i) forbid
generation of edges between nodes that are obstructed and ii) determine distances of
multi-edge paths that circumnavigate obstacles. Shortest paths between all nodes in the
network must be calculated and stored in order to generate pick-run instance distance
matrices.

© Louis Janse van Rensburg Uppsala University

Problem Specification 22

3.2.2 Extraction of Historic (Human Picker) Pick-Runs from the WMS Log
Data for Problem Instance Generation

This data-mining problem relates to processing large volumes of data produced by the
WMS to extract and store pick-runs historically carried out by human pickers. These
pick-run instances are used to experimentally assess the distance minimization granted
by Simulated Annealing and Concorde TSP Solver.

3.2.3 Experimentation and Evaluation

Comparing Historic Route Distances to Distances of Routes as Computed by

Simulated Annealing and Concorde TSP Solver for the same Instances

Experimentation is required in order to test the hypothesis that compute-optimized

routes have reduced distance when compared to distances of historic routes taken for
the same instances.

Determining the Upper-Bound Instance Size for Concorde TSP Solver to Compute
Solutions within the Specified Time Window

Given computation time-window, determining the upper-bound instance size for the
Concorde TSP Solver is required in order to assess the feasibility of determining exact
solutions in a live setting (assuming a license for commercial use is granted).

Solution Evaluation of Simulated Annealing across Increasing Instance Sizes

Given i) the time-window constraint and ii) Concorde TSP Solver’s commercial licensing
restriction, the performance of Simulated Annealing must be assessed across increasing
instance sizes in order to determine the meta-heuristic’s feasibility for live implementa-
tion.

© Louis Janse van Rensburg Uppsala University

Methodology 23

4 Methodology

4.1 Data
4.1.1 WMS Log Data

The raw log dump provided is characterized as follows:

• .exp format

• 7.5 million rows (2018, 2 month data log)

• 2 million rows (2015, 2 month dataset)

• 91 column attributes including:

- log time-stamp

- pick-item information (3-D location IDs, weight, volume and quantity)

- unique pick-run ID

- codified warehouse operation type

- unique user ID .

4.1.2 Architectural CAD Drawing

The Ahlsell Gardemoen warehouse floor (see 4.1 below) covers a rectangular area with
width 105.3 meters and length 256.5 meters. The warehouse is split by three main interior
walls into four sections and wide openings in these walls allow for crossing between
sections. Picking occurs in all sections. Racks (light blue) are labelled numerically
with red script (these labels correspond to rack IDs in the log data), cross aisles and
underpasses (red arrows). Incoming goods are received at the ’top’ side of section 1 and 3,
and outbound goods are shipped from the ’top’ side of section 2. The dark-blue polygon
represents the mezanin (second floor, where cart picking occurs - not studied in this
work). Underneath the mezanin on ground floor is where (stationary) conveyor picking
occurs and where orders are consolidated and checked prior to outbound shipping.
Pink racks in section 1 represent automated goods retrieval machinery (for smaller
sized goods), and the pink racks in section 4 represent the storage location of various
heavy duty cables. The multicolored rectangular polygon at the lower left of section 2

© Louis Janse van Rensburg Uppsala University

Methodology 24

represents a large automated picking system (used for smaller goods), and this connects
to conveyors both on the mezanin floor, and below the mezanin.
The CAD map provided by Ahlsell was not up to date (i.e. rack extensions
and removals were not accounted for in the CAD drawing) this required adjustments
(mapped during a site visit) in order to represent the warehouse floor correctly.

© Louis Janse van Rensburg Uppsala University

 Methodology

© Louis Janse van Rensburg

Figure 4.1: Warehouse Floor CAD Drawing of Ahlsell Gardemoen Site, Oslo.

Uppsala University
25
Methodology 26

4.2 Main Tools

• Python 2.7, 3.61 • Jupyter Notebook

• Matlab • NetworkX 2.2 Python Package 2

• Sony Mobile’s Sensory Behaviour
• Simulated Annealing Algorithm
Data Platform (SBDP)
Source Code 3
• Apache Spark 2.1.0
• Concorde TSP Solver 4
• Spark SQL
• Microsoft Excel
• Amazon Web Services for Cloud
Computing • Adobe Suite

4.3 Main Algorithms

4.3.1 Unobstructed Node Pairs Connectivity Algorithm for Adjacency
Matrix Generation

Figure 4.2: Illustration of how Graph Connectivity was Established. Here, the polygon
obstructing nodes i and j means the boolean values stored in the adjacency
matrix adjMat[i ][ j] 0 and adjMat[ j][i ] 0.

This algorithm requires two sets of data:

1. An N-by-2 array A of N x,y coordinates that map to the N graph vertices repre-
senting
• the picker depot,
1 Python packages used were Numpy, PANDAS, Matplotlib, SciPy, Shapely
2 Retrieved from [41].
3 Simulated Annealing Algorithm Source Code based on Kirkpatrick [36] retrieved from [42].
4 Retrieved from [43].

© Louis Janse van Rensburg Uppsala University

Methodology 27

• pick item locations (in two dimensions along the floor plane) and
• obstacle (racks, walls, machinery) corners.

2. A list of polygon shape objects, P (each polygon shape object is a 2D-array contain-
ing x and y coordinates representing polygon vertices), denoting both warehouse
obstacles, and dummy obstacles. In this work, ten dummy obstacle polygons are
generated (see Step 6 in 4.5.3) by visual inspection as a means to obstruct edge
generation between node pairs where the path width is too narrow (< 1.2 meters)
for a picker’s forklift to traverse.

The algorithm outputs a binary valued N-by-N adjacency matrix (adjMat). A

value of 1 at adjMat[i, j] indicates that there exists an unobstructed straight line between
the ith and jth vertices corresponding to the point coordinates in A[i, 0 : 1] and A[ j, 0 :
1], respectively (note, the description here maintains an inclusive [start : end] array
accessing convention). A value of 0 at adjMat[i, j] indicates that the edge is disallowed
as there exists at least one obstruction between the ith and jth vertices. Furthermore, a
function that determines whether a line-segment (l) intersects the bounds of any given
polygon p in the list of polygons P, is required. In this project implementation, Matlab’s
in-built intersect(l, P) function was used to determine whether a line segment intersects
with a given polygon. The algorithm to generate an adjacency matrix is given by:

Algorithm 1: Connect Unobstructed Node Pairs

input: N-by-2 array of vertex coordinates A and the list P of polygon vertex lists
output : N-by-N adjacency matrix adjMat
1 adjMat matrix ( N, N );
2 adjMat[i, j] 1, 8i, j 2 [0, N );
3 for i 0 to N 2 do
4 for j i + 1 to N 1 do
5 if i , j then
6 l lineSegment( A[i, 0 : 1], A[ j, 0 : 1]);
7 for k 0 to | P| 1 do
8 if intersect(l, P[k ]) == TRUE then
9 adjMat[i, j] 0;
10 adjMat[ j, i ] 0;
11 break
12 end
13 end
14 end
15 end
16 return adjMat;

© Louis Janse van Rensburg Uppsala University

Methodology 28

4.3.2 Weighted Adjacency Matrix Generation Algorithm

The output (adjMat) of Algorithm 1 then allows for direct L2-Norm (Euclidean distance)
calculation between connected ith and jth vertices, as it is known that no obstructions
lie between ith and jth vertices where adjMat[i, j] = 1. The weighted adjacency matrix
weightedAdjMat is thus generated as follows:

Algorithm 2: Generate Weighted Adjacency Matrix

input: N-by-2 array of vertex coordinates A, adjacency matrix adjMat
output : N-by-N Weighted adjacency matrix weightedAdjMat
1 weightedAdjMat adjMat;
2 for i 0 to N 2 do
3 for j i + 1 to N 1 do
4 if adjMat[i, j] == 1 then
p
5 weightedAdjMat[i, j] ( A[i, 0] A[ j, 0])2 + ( A[i, 1] A[ j, 1])2 ;
6 weightedAdjMat[ j, i ] weightedAdjMat[i, j];
7 else
8 if i , j and adjMat[i, j] == 0 then
9 weightedAdjMat[i, j] •;
10 weightedAdjMat[ j, i ] weightedAdjMat[i, j];
11 end
12 end
13 end
14 end
15 return weightedAdjMat;

Given N vertices, each vertex can be labelled according to the corresponding

row/column index in the N-by-N diagonally symmetric weighted adjacency matrix
weightedAdjMat. From this, a list of vertices V, edges E (represented as tuples of vertex
identifiers) and the corresponding edge weights W can be passed in as arguments
to NetowrkX’s Graph() Class constructor to generate an undirected, weighted graph
G = Graph(V, E, W ).

4.3.3 Floyd-Warshall All Node Pairs Shortest Path and Shortest Path
Distance Algorithm

In order to determine the shortest path and shortest path distance between any pair of
vertices in G, NetworkX’s shortest_path() implementation was used. This Floyd-Warshall
algorithm runs in O( N 3 ), requires O( N 3 ) memory and essentially performs Dijkstra’s
shortest path algorithm for all pairs of vertices. The algorithm i) computes and updates
distances in an N 3 matrix (where vertex index labels are mapped to matrix indices i, j, k

© Louis Janse van Rensburg Uppsala University

Methodology 29

2 [0, N )), and ii) computes and updates a N 3 pointer matrix. Both matrices are then
converted into a i) N 2 shortest path distance matrix shortestPathDists[i, j] and a nested
dictionary shortestPaths[i ][ j], that return the distance and shortest path vertex list (given
by vertex index IDs) for vertices i and j, respectively. The shortestPaths nested dictionary
has no further immediate use, other than visualizing optimal pick-run routes in a GUI
and performing route analysis.

Algorithm 3: Floyd-Warshall All Node Pairs Shortest Paths (NetworkX Implementa-

tion)
input: N 2 weighted adjacency matrix weightedAdjMat
output : Nested dictionary shortestPaths and N 2 matrix shortestPathDists
1 SD matrix ( N, N, N ); # Initializing empty N 3 distance matrix
2 SP matrix ( N, N, N ); # Initializing empty N 3 vertex pointer matrix
3 #Base Case
4 SD [0, :, :] weightedAdjMat;
5 for i 0 to N 1 do
6 for j 0 to N 1 do
7 if i , j and weightedAdjMat[i, j] < • then
8 SP[0, i, j] i;
9 end
10 end
11 end
12 #All Other Cases
13 for k 1 to N 1 do
14 for i 1 to N 1 do
15 for j 1 to N 1 do
16 if SD [k 1, i, j] > SD [k 1, i, k ] + SD [k 1, k, j] then
17 SD [k, i, j] SD [k 1, i, k ] + SD [k 1, k, j];
18 SP[k, i, j] SP[k 1, k, j];
19 else
20 SD [k, i, j] SD [k 1, i, j];
21 SP[k, i, j] SP[k 1, i, j];
22 end
23 end
24 end
25 end
26 shortestPaths pointerMatrixToShortestPathDictionary(SP); # A NetworkX
feature
27 shortestPathDists SD [k, :, :];
28 return shortestPaths, shortestPathDists;

© Louis Janse van Rensburg Uppsala University

Methodology 30

At this point the diagonally symmetric distance matrix shortestPathDist has been
generated such that the shortest path distance between any vertices i and j can be
accessed in constant time by querying shortestPathDist[i, j]. Given a list of index labelled
vertices V such that |V | = M and V ⇢ {0, ... , N 1} (i.e. a pick-run list) any M-by-M
problem instance distance matrix D can now be extracted from shortestPathDist matrix
in order to compute the optimal route (using Concorde), or approximate the optimal
route (using Simulated Annealing).

D [i, j] = shortestPathDists[V [i ], V [ j]], 8i, j 2 [0, M) (4.1)

4.3.4 Simulated Annealing

The Simulated Annealing algorithm takes in the following parameters:

• Starting temperature (StartTemp)

• A stopping temperature (StopTemp)

• Maximum number of iterations (MaxIter)

• Temperature cooling constant (a)

• Cooling schedule (ScheduleIter) denoting the number of iterations that must pass
before the temperature is updated.

Let the list of index labelled vertices to visit on a pick-run, V ⇢ {0, ... , N 1} and {0} 2 V
, where |V | = M, be denoted by V = [v0 , ..., vm 1] with depot (tour start and end) vertex
v0 . Furthermore, let the function distance(vi , v j ) map vertices in V to the indices of a
diagonally symmetric M-by-M pairwise distance matrix D with rows i = [0, M) and
columns j = [0, M ) such that the shortest path distance between vertices vi and v j can be
determined. An initial solution (InitSol) is generated using the greedy heuristic.

Algorithm 4: Greedy Heuristic

input: A list V of length M of index labeled vertices
output : A list InitSol of length M of (reordered) index labelled vertices
1 curPos V [0];
2 InitSol [curPos];
3 while | InitSol | < |V | do
4 nextPos v|min(distance(curPos, v), 8v|v 2 V and v < InitSol );
5 append( InitSol, nextPos);
6 curPos nextPos;
7 end
8 return InitSol;

© Louis Janse van Rensburg Uppsala University

Methodology 31

At every iteration of the Simulated Annealing algorithm, a candidate solution

(S0 ) is produced. In the Simulated Annealing source code, candidate generation occurs
by first randomly selecting a range of indices [s : e], such that s > 0, s < e and e < M,
(Note: the description here maintains an inclusive [start:end] list accessing convention).
The ordering of vertices located at these indices in the list of vertices specifying the
current solution (S), is then reversed. The new vertex list ordering denotes the candidate
solution.

Algorithm 5: Generate Candidate Solution

input: List S of length M, denoting the current solution
output : List S0 of length M, denoting a candidate solution
1 s randInt([1, M 2]);
2 e randInt([s + 1, M 1]);
3 S0 S;
4 S0 [s : e] reverse(S0 [s : e]);
5 return S0 ;

A given solution is evaluated for fitness, which in the case of the TSP is the total
tour distance. The smaller the distance, the fitter the solution. Given that the depot is
represented by the first vertex v0 in V, and is the first vertex in any current or candidate
solution, the return distance from the final vertex in a given solution to the depot must
be accounted for when determining the solution tour distance.

Algorithm 6: Compute Tour Distance

input: Any list solution S0 , of length M
output : Tour distance dist
1 dist 0
2 for i 0 to M 2 do
3 dist dist + distance(S0 [i ], S0 [i + 1])
4 end
5 dist dist + distance(S0 [ M 1], S0 [0]) #Add distance from last vertex back to the
depot vertex
6 return dist

Given the temperature T at the current iteration and the tour distance difference
between solutions ( tourDistance = tourDistance(S0 ) tourDistance(S)), the probabil-
ity P(S, S0 , T ) of transitioning from a current solution (S) to a newly generated solution
(S0 ) is given by

© Louis Janse van Rensburg Uppsala University

Methodology 32

8
<1, if tourDistance  0.
P(S, S0 , T ) = (4.2)
:exp( tourDistance/T ), otherwise.

In the latter case (when tourDistance(S)  tourDistance(S0 )), a comparison be-

tween i) P(S, S0 , T ), and ii) a real valued number (x |0  x  1) drawn from a random
continuous variable X uniformly distributed between 0 and 1, is made in order to accept
(x < P(S, S0 , T )) or deny (x P(S, S0 , T )) a solution transition. The best solution gener-
ated so far (bestSoFar) is always stored, and updated when a new best solution is found
(note, bestSoFar remains functionally distinct from the current solution (S)).

© Louis Janse van Rensburg Uppsala University

Methodology 33

Algorithm 7: Simulated Annealing

input: StartTemp, StopTemp, MaxIter, cooling constant a, ScheduleIter, pickrun
instance list V of length M
output : Vertex sequence list bestSoFar denoting the approximately optimal tour
1 T StartTemp;
2 iterCount 0;
3 schedCount 0;
4 S greedy(V );
5 bestSoFar S;
6 while iterCount < MaxIter and T > StopTemp do
7 schedCount schedCount + 1;
8 iterCount iterCount + 1;
9 if schedCount == ScheduleIter then
10 T aT;
11 schedCount 0;
12 end
13 S0 generateCandidate(S);
14 if tourDistance(S0 ) < tourDistance(S) then
15 S S0 ;
16 else
17 x random(0, 1);
18 p exp( (tourDistance(S0 ) tourDistance(S))/T );
19 if x < p then
20 S S0 ;
21 end
22 end
23 if tourDistance(bestSoFar ) > tourDistance(S) then
24 bestSo f ar S;
25 end
26 end
27 return bestSoFar;

4.3.5 Concorde TSP Solver

The Concorde TSP solver is considered the current state of the art for determining
optimal solutions to symmetric TSP problems. It extends the Branch and Bound (BAB)
algorithm employing Integer Linear Programming’s Branch and Cut procedure . The
software (freely available for academic use, and subject to licensing agreements for
commercial use) was obtained from [43].

© Louis Janse van Rensburg Uppsala University

Methodology 34

In the current work, Concorde was used in order to i) generate optimal solu-
tion benchmarks against which the performance of Simulated Annealing (for the same
problem instances) can be compared, and ii) determine the feasibility of implement-
ing Concorde in a live warehouse setting (given computation time windows, and the
distribution of instance sizes).

4.4 Main Data Structures

4.4.1 Arrays

The main arrays used in this work are listed as follows:

• An N-by-2 Numpy array A ( N = 6527) was generated following data processing

(see 4.5 below) to store the x,y coordinates (millimeter precision, integer valued)
corresponding to vertices in the graph network G. These vertices correspond
to picking locations (including the depot) and obstacle (walls, machinery, racks)
corners. This array was required as input to Algorithms 1 and 2 (see 4.3.1 and
4.3.2).

• Eight 156332-by-1 arrays5 (156332 = the number of discrete pick events that consti-
tute 20854 historic user-distinct pick-runs) were generated as a result of historic
pick-run extraction (see, 4.6). Row index ordering was imposed (in the same way
for all eight arrays) according to, first i) the concatenation of user ID and pick-run
ID (to demarcate user-distinct pick-runs), and secondly, ii) the event time-stamp
(within each user-distinct demarcated pick-run, so that historic item pick sequences
could be maintained). The arrays correspond to the following italicized attributes
(found in the log data) and data types (in square brackets):

- Concatenation of user ID (logguser) and pick-run ID (pickrno)-[String]

- Second resolution event time-stamp (datreg)-[Date-Time Object]

- Operation code (l16lcode)6 -[Integer]

- Picking zone/material handling area (fmha)-[String]

- Rack ID (frack)-[String]

- Horizontal rack location ID (fhorcoor)-[String]

- Travel-time to pick location (l49bptt)-[Float]

- Time spent picking (l49bppt)-[Float]

5 These arrays were stored in the list historicPickRuns, see 4.4.2 below. Evidently, a table representation
would have equally sufficed.
6 At this point, the operation code was no longer needed as all operation code values left over following

data cleaning and pick-run extraction corresponded to pick events (code 4) only.

© Louis Janse van Rensburg Uppsala University

Methodology 35

4.4.2 Lists

The following lists were generated during this implementation:

• A list P of 325 polygon shape representations of (315) warehouse environment

obstacles and (10) dummy obstacles (see 4.5 below) was generated where any pi
(8 i 2 [0, 325)) is itself a list of polygon vertex coordinate tuples. This list P was
required as input to Algorithm 1 (see 4.3.1).

• 20854 pick-run instance vertex lists, where any list V ⇢ [0, N ) and {0} 2 V (where
the vertex with label 0 corresponds to the depot). A given list was required in
order to produce any (historic) problem instance distance matrix D.

• A list historicPickRuns (produced following extraction and of historic pick runs)

containing the eight Numpy arrays mentioned in (second bullet point) section
4.4.1.

4.4.3 Matrices

The following matrices were generated in this implementation:

• The boolean valued matrix adjMat was generated using Algorithm 1. For any
vertices i and j, adjMat[i, j] specifies whether there exists an unobstructed direct
line of sight between locations i and j.

• Algorithm 2 generated a weighted adjacency matrix weightedAdjMat such that

the euclidean distance between all vertices i and j where adjMat[i, j] == 1 could
be determined and stored in weightedAdjMat[i, j]. Infinite distance (•) was stored
at weightedAdjMat[i, j], 8 i, j where adjMat[i, j] == 0.

• Algorithm 3 produced the distance matrix shortestPathDists. This distance matrix

stored shortest path distances between all vertices i, j 2 [0,N).

• When computing solutions to a given problem instance, an instance specific dis-

tance matrix D is first generated from pick-run vertex list V and the all-vertices
shortest path distance matrix shortestPathDists. The depot vertex is always repre-
sented at row/column 0 of D.

4.4.4 Python Dictionaries

Two dictionaries were generated:

• A dictionary keyDict (see 4.5) was created in-order to map the string concatenation
of distinct WMS pick location labels (concatenated data log attributes are: f mha 7 ,
7 The log attribute f mha is first checked to see whether it belongs to the set of mapped f mhas, and if so, it
is then converted into one of four section labels s1, s2, s3, s4. If it does not belong to the set of mapped
f mhas, then this pick location cannot be identified, hence, the pick-run list containing this pick location
cannot be subject to route optimization.

© Louis Janse van Rensburg Uppsala University

Methodology 36

f rack, f horcoor) to index labelled vertices in the Graph Network. For each historic
pick-run extracted from the log data, keyDict was used to convert a given pick-
run’s list of concatenated WMS location ID labels to a list of indices I denoting
vertices represented by x,y coordinates at A[i, :], 8 i 2 I. This dictionary is essential
for the live software implementation where pick lists (location ID labels) must be
converted into lists of index labeled vertices.

• Algorithm 3 produced the shortestPaths dictionary that returns the list of vertices
shortestPaths[i ][ j] that must be traversed in order to travel along the shortest path
between any two vertices i, j. This dictionary is useful for GUI visualization of
optimal tours in the warehouse space.

4.4.5 Graph Network

The un-directed, weighted graph G = (V, E, W ) was generated following computation

of the weightedAdjMat using the iGraph Graph Class. The graph consists of 6527 vertices
representing:

• 1 depot

• 5989 pick locations,

• 537 obstacle (racks/machinery/walls) corners

and 608980 edges, with associated weights calculated as the euclidean distance be-
tween adjacent vertices. G was used to calculate the shortest paths between all vertices,
allowing for population of the 6527-by-6527 distance matrix shortestPathDists.

4.5 Graph Network Representation

The main challenge of this project was to generate a spatial representation of the codified
WMS item location tagging logic. A given picking event occurs at a unique location
in two dimensional space and is associated with three main localisation log attributes:
Material Handling Area (MHA), Rack and Horizontal Rack Coordinate (a Vertical Rack
Coordinate additionally specifies a unique pick location in three dimensions). A given
MHA code (of type string) maps to multiple (integer valued) Rack codes, and a given
Rack code maps to multiple (integer valued) Horizontal Rack Coordinate codes. In order
to spatially represent the WMS tagging logic, a graph network was populated with
unique nodes corresponding to both permissible and unique combinations of MHA,
Rack and Horizontal Rack Coordinate codes.
A graph network representation can be used to produce an accurate distance
matrix, shortestPathDists, for all pairs of mapped warehouse pick points. This distance
matrix can then be accessed by way of mapping string-concatenated log location tags
(MHA + str(Rack)+ str(Horizontal Rack Coordinate)) to indices in shortestPathDists

© Louis Janse van Rensburg Uppsala University

Methodology 37

(this mapping is stored as the dictionary keyDict) such that instance-specific distance
matrices denoting pairwise distances for pairwise pick locations in a given pick-run can
be extracted and fed as input to TSP solver/optimization algorithms to determine the
optimal route.

Figure 4.3: CAD map racks drawn with labels corresponding to Rack attribute values in
the log data.

4.5.1 The Problem of Missing Data

The process of generating the Graph Network was detail-oriented and tricky given the
limited correspondence between the CAD map and the log data. The only markers in
the CAD drawing that corresponded to location tags in the log data were Rack labels
(see 4.3 above), and, even these were incompletely (and in some places, incorrectly)
labelled on the CAD map. Furthermore, the log data captured picking over a two month
period, however, not all locations in the warehouse were picked during this period and
so populating the graph network with the full set of relevant pick points of interest was
non-trivial.
Solving the problem of having incomplete map and log data therefore involved
cross validating information provided by the map to infer missing-data in the log. For
example:

• Observation 1: Racks 204 and 205 are of the same physical dimensions.

© Louis Janse van Rensburg Uppsala University

Methodology 38

• Observation 2: There is a greater number of unique pick points logged for Rack
204 compared to Rack 205.

• Conclusion: The number of unique pick points at Rack 205 must be at least equal
to the number of unique logged pick-points for Rack 204. If it can be shown that
the number of unique logged pick points at Rack 204 is maxmimal (given WMS
tagging logic and physical rack and rack segment dimensions) then rack 205 has
exactly the same number of unique pick points as the number of unique logged
pick points at Rack 204.

Likewise the log data also revealed errors or confusing/misrepresented spatial

information provided in the map. For instance, in section two of the warehouse (see
figure 4.1) the mezzanine (dark blue) covers the top rack segments of eight racks. The
existence of these rack segments was established by identifying a maximally numbered
pick point (given by the Horizontal Rack Coordinate attribute in the log) that belonged
to a covered up rack segment (this reasoning was validated during the site visit to the
warehouse). There were, however, a number of details that could simply not be deduced
by analyzing the map and the log data.

4.5.2 Data Gathering - Warehouse Site Visit

A site trip to the warehouse was carried out in order to gather additional information.
The additional information required was specified as follows:

• The list of relevant MHA codes (picking zone code) 8 .

- MHA codes of some log entries were not related to rack picking and had to
be excluded from further processing. Confusingly, these entries also contained
non-empty Rack and Horizontal Rack Coordinate values.

• Spatial identification of the depot (annotated on the updated CAD drawing).

• An up to date mapping of rack-modifications not specified in the CAD drawing.

- This required walking through the warehouse to identify where racks had been
modified, and if so, measuring the rack extensions/removals and mapping these
on the CAD drawing.

• Validating that the warehouse pallets (on top of which goods are stored) have
industry standard Euro-pallet dimensions.

- Each pallet occupies a pick point, and distinct rack segment types contain a
varying number of pallets/pick points.

8 These
were [’H1B1’, ’H1B2’, ’H1B3’, ’H1B4’, ’H1P1’, ’H1P2’, ’H1P3’, ’H1P55’, ’H1S1’, ’H2B1’, ’H2B2’,
’H2P1’, ’H2P2’, ’H2P3’, ’H2P4’, ’H3B1’, ’H3B2’, ’H3B3’, ’H3B6’, ’H3P1’, ’H3P2’, ’H3P3’, ’H3P4’, ’H3P55’,
’H3P6’, ’H4B1’, ’H4B2’, ’H4P1’, ’H4P2’, ’LA01’, ’LA02’, ’LA03’, ’LA04’, ’LA05’, ’LA06’]

© Louis Janse van Rensburg Uppsala University

Methodology 39

• Identifying distinct rack segment types, and the number of pick points (number of
Horizontal Rack Coordinate tags) contained within each rack-segment type.

Figure 4.4: Rack segment types with dimensions and Euro-pallet capacity.

• Identifying the Horizontal Rack Coordinate indexing origin and direction of incre-
mentation.

- In this warehouse, racks can have a minimum Horizontal Rack Coordinate.

I had to identify where the origin (minimum Horizontal Rack Coordinate) was
located, and in which direction the Horizontal Rack Coordinate value was incre-
mented lengthwise along the rack. It was determined that the minimum Horizontal
Rack Coordinates (001 and 002 for odd and even numbered Racks, respectively)
began at the bottom of the Warehouse Floor layout as depicted in figure 4.1, and that
the direction of Horizontal Rack Coordinate value incrementation was towards
the top of the warehouse floor space.

• Determining the Horizontal Rack Coordinate addressing convention.

- Analysis of the log data indicated that odd numbered Horizontal Rack Coor-
dinates were associated with odd numbered Rack values (and even numbered

© Louis Janse van Rensburg Uppsala University

Methodology 40

Horizontal Rack Coordinates were associated with even numbered Rack values).
Use of this odd/even addressing convention was confirmed during the site visit.

• Identification/Validation of wall openings/access-points that are used for picking.

- Walls separate warehouse sections, however, pickers can travel between sec-
tions via wall openings at cross-aisles. During the site visit it was observed that
one wall opening had been closed and was no longer used during picking.

Following the site visit, sufficient information was gathered in order to begin
Graph Network construction.

4.5.3 Data Processing for Graph Network Construction

For all CAD map processing and pick location generation, the lower left corner of the
Warehouse Floor Map was referenced as the x-y axis origin.

Step 1: Conversion of warehouse floor structures (Racks, Walls, Machinery and

Obstacles) to polygon shape-files.

For each structure (racks, walls, machinery and obstacles) on the main picking floor, one
or more9 polygon shape-files (where a polygon constitutes a list of (x,y) vertices) was
generated. The unit of measurement used for x and y values was 1 = 1mm. Software
used to included the Adobe Suite (for measuring x,y coordinate positions of corners of
structures), Microsoft Excel and Matlab (for recording coordinate values and storing
shape-files in the list P, which is used as input to algorithm 1).
Let R denote the full set10 of racks (or, rack labels), and P the current set of
polygons produced. By comparing figure 4.1 to the plotted polygons in figure 4.5, it
can be seen in figure 4.5 that cross aisles have broken up the continuous racks (and
walls) into distinct polygons. Hence, 8r 2 R a given rack r 7! Pr ⇢ P. Furthermore,
for all polygons representing racks Pracks where Pr ⇢ Pracks ⇢ P, most11 have a width
covering the width of two adjacent racks (each facing distinct picking aisles to the right
and left), and so a given rack polygon pracks 2 Pracks : pracks 7! R0 ⇢ R. For each rack r,
the following was stored as a data entry in an excel file: i) an index mapping to polygons
Pr ⇢ P as well as ii) a record of whether the rack’s numeric label was odd or even (for all
odd labeled racks, the picking aisle is situated to the right, for all even labelled racks,
the rack is facing a picking aisle situated to its left).

9 Most racks were split into several polygons to respect presence of cross aisles that pass through the
underpasses of a given rack
10 Four racks were physically discontinuous (i.e. a given rack label mapped to physically disconnected

but x-axis aligned racks with discontinuous Horizontal Rack Coordinate ranges) and were assigned
distinct rack labels. That is, for a given discontinuous rack, the rack label mapping to a distinct sub-rack
was concatenated with a,b,c etc. depending on the number of sub-racks. Hence | R| is greater than the
number WMS rack labels of interest.
11 Some polygons map to one rack only.

© Louis Janse van Rensburg Uppsala University

Methodology 41

Figure 4.5: Plotted Polygonal Representation of Warehouse Floor Structures.

Step 2: Establishing a node localization metric using i) rack position and

dimensions, ii) rack segment type, position and dimensions and iii) pallet
dimensions to generate a list of node coordinate tuples, where unique WMS
location tags are to be mapped to unique node coordinate list indices.

Figure 4.6: Illustration of the Problem of Mapping WMS Location Tags to Nodes.

It should be noted here that one automation ’rack’ r auto (see the pink rack in the upper
left region of section 1 in figure 4.1) has six (evenly spaced) pick points where pickers
carrying out pick-runs can pick items retrieved from an automated retrieval system.

© Louis Janse van Rensburg Uppsala University

Methodology 42

Also, the set of six MHAs12 referring to this rack map uniquely to six picking points
situated on the rack along the y-axis (unlike other racks where Horizontal Rack Coor-
dinate specifies the position of a picking point lengthwise along a rack, here the MHA
provides this information). Determining the pick-point coordinates for this rack was
trivial (following the site visit), and therefore is excluded from processing in steps 1-4
(that is, from here on R R \ {r auto }). Nonetheless, as the graphical network is popu-
lated with nodes representing pick points beloning to r auto , let the object autoRack
(nodesX, nodesY, MH AList) where |nodesX |, |nodesY |, | MH AList| = 6, nodesX contains
x coordinate values of these picking points, and nodesY contains y coordinate values
and MH AList[i ] 7! (nodesX [i ], nodesY [i ]) and 13 nodesY [i ] < nodesY [i + 1], 8i 2 [0, 5].
From step 1, each rack r 7! Pr ⇢ P. Since the x value of the vertices of any rack
polygon pracks 2 Pr takes, in most cases, two values (corresponding to the right-most and
left-most extent of the polygon), determining the x coordinate of all the picking points
belonging to rack r was trivial:
Let X denote the set of x coordinate values (where in most cases | X | = 2) that can
be taken by the vertices of polygons Pr , where a given rack r 7! Pr . Let V denote the full
set of pick nodes, and Vr denote the set of picking nodes associated with a given rack r
where Vr ⇢ V. 8r 2 R the x-coordinate value xr of all coordinate tuples vr , 8 vr 2 Vr was
determined as follows:
8 xr 2 vr 2 Vr
8
<min( X ), if picking aisle is situated on the left (numeric rack label is even).
xr =
:max ( X ), if picking aisle is situated on the right (numeric rack label is odd).
(4.3)
It should be noted that depending on the implementation of the line-polygon
intersection algorithm (called within algorithm 1), an offset (e.g. 1mm) needs to be
added/subtracted from xr for odd/even labelled racks, respectively. The reason for this
is that some line-polygon intersection algorithms (e.g. the Python Shapely package)
assert that a polygon is intersected by a line if the line falls on the boundary of a polygon,
whereas others (geometric functions in MATLAB) assert the polygon is intersected only
when the area enclosed by the boundary overlaps with a line segment.
In order to determine the y-coordinate values of vr 2 Vr ⇢ V, the y-axis dimensions
of rack segments, and the known number of picking locations that can be contained
within a rack segment type rseg was leveraged.
Given the set of unique rack segments RSeg with corresponding i) rack segment
length and ii) known number of pallets that can be contained in each rack segment),
an excel file was generated whereby for each rack r, each consecutive rack segment
type rseg was recorded in a list RSegsr according to the ordered bottom-up fashion
as they occurred in the CAD map (which had been updated following the site visit).
12 The MHAs directly mapping to pick points in this automated section are [’LA01’, ’LA02’, ’LA03’, ’LA04’,
’LA05’, ’LA06’]
13 To maintain a bottom-up ordering.

© Louis Janse van Rensburg Uppsala University

Methodology 43

Straightforward auxiliary functions and data structures required to extract recorded

excel file data are listed below.
For a given rack r:

• Let getX (r ) return the x coordinate value assigned to all picking points for this
rack (as calculated above in 4.3.

• Let startPoint(r ) return the minimum y coordinate value for all vertices in the set
of polygons Pr , where r 7! Pr .

• Let getRSegList(r ) return the (bottom-up) ordered list of rack segments RSegsr
corresponding to rack r.

• Let nPallets(rseg) return the number of pallets (individual pick points) known to
be contained in a rack segment of type rseg.

• Let length(rseg) return the length along the y-axis of a given rack segment of type
rseg.

• Let the dictionary rackPickCoordsDict[r ] store the computed list of i) (bottom-up)

ordered y coordinate values yr and ii) x coordinate values xr of pick points vr , for
yr , xr 2 vr , 8vr 2 Vr .

The following script was then employed to generate the y coordinate values of all
possible pick points, given the rack and rack segment dimensions and position on the
warehouse floor.

© Louis Janse van Rensburg Uppsala University

Methodology 44

Algorithm 8: Compute Pick-Point Coordinates

input: The list of rack labels R
output : The dictionary rackPickCoordsDict
1 rackPickCoordsDict {}
2 palLength 1200 # denotes the standard euro pallet length in mm along the y axis.
3 for r in R do
4 nodesY []
5 nodesX []
6 ystart startpoint(r )
7 RSegr getRSegList(r )
8 for rseg in RSegr do
9 L length(rseg)
10 numPallets nPallets(rseg)
( L numPallets · PalLength)
11 spaceBetPallets
numPallets
spaceBetPallets
12 spaceBetWall AndPal
2
13 for i 0 to numPallets 1 do
14 if i == 0 then
palLength
15 yCoord ystart + spaceBetWall AndPal + # y coord
2
represents the mid point of pallet’s position
16 else if i== numpallets 1 then
palLength
17 yCoord ystart + L (spaceBetWall AndPal + )
2
18 else
19 yCoord ystart + spaceBetWall AndPal + i · ( palLength +
palLength
spaceBetPallets) +
2
20 end
21 nodesY.append(yCoord)
22 nodesX.append( getX (r ))
23 ystart ystart + L
24 end
25 end
26 rackPickCoordsDict[r ] = (nodesX, nodesY )
27 end
28 return rackYCoordsDict

© Louis Janse van Rensburg Uppsala University

Methodology 45

Step 3: Determining minimum Horizontal Rack Coordinate correspondence for

Racks and Sub-Racks

Most racks in this warehouse have a minimal Horizontal Rack Coordinate, (which
increments by numeric steps of 2 along the y axis) beginning at either (00)1 (if the
numeric rack label is odd), or (00)2 (if even). There were seven racks, however, that i) did
not extend to the bottom wall, and four racks (as referred to in footnote 10 referenced in
step 1) that ii) were physically disconnected (e.g. such a given rack has discontinuous
ranges of Horizontal Rack Coordinate values, and during steps 1 and 2, each sub-rack
was treated as a unique rack r 2 R). For case i), in order to determine the minimum
Horizontal Rack Coordinate for fully connected racks not reaching the bottom wall, the
following procedure was applied:
For a given rack r that is connected but does not extend to the bottom wall:

I Identify the nearest (along the x-axis) rack r 0 that is both fully connected and
reaches the bottom wall.

II Determine the index i in nodesY returned by rackPickCoordsDict[r 0 ] where nodesY [i ]0

has minimal difference to nodesY [0] returned by rackPickCoordsDict[r ]

III Assign the expected Horizontal Rack Coordinate HRC 0 to the node represented by
the coordinate (nodesX [0], nodesY [0]) according to the following calculation:

8
<2i + 1, if r has odd valued rack label.
HRC 0 = (4.4)
:2i + 2, if r has even valued rack label.

IV IF r is a connected rack, compare HRC 0 to the minimum Horizontal Rack Coordi-

nate associated with rack r (which is in turn, allowed to be associated with any
MHA in the list of relevant MHAs) that can be identified in the historic log data.
IF a given rack has identical dimensions and y-axis starting position to other racks,
multiple racks of this type can be queried in the log data in-order to bootstrap
confidence in the identification of a minimal WMS Horizontal Rack Coordinate for
r.
IF the minimal Horizontal Rack Coordinate value found in the log data for this (or
multiple identical copies of this) rack is less than HRC 0 , then a mistake (somewhere
in steps 1 or 2) has been made 14 . ELSE, the value is greater than or equal to HRC 0
and the procedure for validating the range of Horizontal Rack Coordinates as
specified below in step 4 can be carried out for r.

14 Note:Although this step may determine if an error has been made, it does not guarantee that HRC 0 is in
fact minimal, as it is possible for a minimal Horizontal Rack Coordinate to simply not have been picked
and recorded in the log data. Step 4 below further strengthens confidence in the assignment of HRCs to
nodes.

© Louis Janse van Rensburg Uppsala University

Methodology 46

For case ii), in order to determine the minimum Horizontal Rack Coordinate for any
disconnected sub-rack 15 r, the set of disconnected sub-racks belonging to a super-rack
need to be considered together in the following procedure:

I Consider each set of sub-racks belonging to a given (disconnected) super-rack

separately in the bottom-up order starting with the sub-rack closest to the wall.
IF the sub-rack currently considered is the first (closest to the bottom wall) sub-rack
in the current set considered, AND does not extend to the bottom wall, THEN first
carry out I-IV from the previous case i) above, and secondly carry out step 4 below.
ELSE IF the sub-rack currently considered is the first (closest to the bottom wall)
sub-rack in the current set considered, AND the sub-rack does extend to the bottom
wall, carry out step 4 below for this sub-rack.

II For all remaining sub-racks in a super-rack, it must be ensured when considering

a given super-rack that I-IV from the previous case i) above has been applied to
all preceding sub-racks (in the bottom-up order) and that the ranges of assigned
Horizontal Rack Coordinates for preceding sub-racks have been validated in step
4 below.

Step 4: Validation of Pick Point Node Generation - Cross referencing the number of
item locations for each rack (and sub-rack) generated by the localization metric with
the range of item locations for each rack type as found in the log data

Given that step 3 above associates a minimum HRC 0 for each rack (and sub-rack) r,
and that each rack and sub-rack considered have a continuous (i.e. connected) range of
Horizontal Rack Coordinates that increment by steps of 2, the following procedure was
applied in-order to map HRCs for all nodes generated in step 2:
For each rack and sub-rack r, its expected minimum HRC 0 , and nodes Vr , returned
by rackPickCoordsDict[r ]:

I Using algorithm 9 below generate a list HRCList of expected HRCs where there is
index correspondence to the lists of x and y coordinates returned by rackPickCoordsDict[r ].

II For each rack or sub-rack r, identify the set of connected racks/sub-racks, including
rack r, that have the same start and end position along the y-axis as rack r. For all
these racks identify the maximal Horizontal Rack Coordinate (for sub-racks, the
maximal Horizontal Rack Coordinate is the maximal Horizontal Rack Coordinate
that occurs before sufficiently large discontinuity in the range of Horizontal Rack
Coordinates found in the log for the super-rack).

III It must be ensured that the maximal Horizontal Rack Coordinate found in the
log for this rack/sub-rack type does not exceed the maximal expected HRC 0 as
15 where, for instance, a rack 324 has disconnected sub-racks 324a and 324b, both of which are represented
as distinct racks r 2 R.

© Louis Janse van Rensburg Uppsala University

 Methodology 47

Algorithm 9: Associate WMS Horizontal Rack Coordinates with Nodes

input: The dictionary rackPickCoordsDict, rack label r, expected minimum HRC 0
output : Ordered list of HRCs for r as HRCList
1 HRCList [ HRC 0 ]
2 NumNodes |rackPickCoordsDict[r ][0]| # the length of the nodesY (or equivalently,
nodesX) list for r
3 for i 1 to NumNodes do
4 HRCList.append( HRCList[i 1] + 2) #the numeric value of the expected HRC at
this node/pickpoint.
5 end
6 return HRCList

returned in the list HRCList from algorithm 9, else an error in measurement has
occurred.

The procedures outlined in steps 3 and 4 can be seen together as a confidence-

bootstrapping method for mapping WMS Horizontal Rack Coordinates to pick-point
nodes for a given rack r. This process was time consuming, however, after a number of
iterations of matching ranges of Horizontal Rack Coordinates to racks and sub-racks,
there was only one case 16 where due to rack modification and insufficient picks in the
log data, a ghost-node was inserted at the top extent of the rack, and assigned a maximal
HRC.
Finally, after HRCLists were generated for all racks and sub-racks r:

• If r is a sub-rack, the nodesY and nodesX lists returned from rackPickCoordsDict[r ],

were joined to all other nodesY, and nodesX returned from sub-racks belonging to
the same super-rack (a bottom-up join ordering was maintained). A super-rack was
now represented as a single entity r and the set of rack and sub-rack labels R was
reduced such that rackPickCoordsDict returns nodesY and nodesX corresponding
to both racks and super-racks (as the union of disconnected sub-racks).

• A new dictionary rackIn f o was generated, where for a given rack label r, the
call to rackIn f o [r ] returns (nodesX, nodesY, HRCList) where an index mapping
is maintained for all nodes represented by an x,y coordinate tuple, and (WMS
Horizontal Rack Coordinate correspondence) HRC.

Step 5: Specifying the Depot Node Coordinate Tuple, Generation of the N-by-2
Array A, and Generation of keyDict (associating WMS location tags with indices in
A)

Array A is required along with the list of polygons P as input to algorithm 1. Array
A contains the x,y coordinates of the depot, all picking nodes, and importantly, all
non-dummy (see step 6) polygon vertex coordinates.
16 Rack 417, in section 4 of the warehouse, directly adjacent to the right-hand side wall. This rack is situated
furthest from the depot, and so-called ’slow-moving’ goods are stored here and are infrequently picked.

© Louis Janse van Rensburg Uppsala University

Methodology 48

Following the warehouse site visit, the picker depot had been marked on the up-
dated CAD map, and using Adobe Suite, its coordinates (xdepot , ydepot ) were determined.
Hence, in the final array A, and dictionary keyDict

• A[0, 0] xdepot

• A[0, 1] ydepot

• keyDict[0 depot0 ] 0

In order to build keys for keydict, corresponding to WMS tags (MHA, Rack, Hori-
zontal Rack Coordinate) that return indices of picking nodes stored in A, subsets of the
list of relevant MHAs were first required to be mapped to racks.
As has been mentioned, the relevant17 MHAs (Material Handling Areas) associated
with picking were identified following the site visit and consultation with the WMS
provider. Although the MHA spatial mapping is not defined (MHAs map to pick
points distributed across racks according to some WMS logic), processing of the log data
enabled many-to-one associations of subsets of MHAs to the physical sections (1,2,3,4)
on the warehouse floor. The following is the mapping of all relevant MHAs to spatially
defined sections on the floor space: section_1 = [’H1B1’, ’H1B2’, ’H1B3’, ’H1B4’, ’H1P1’,
’H1P2’, ’H1P3’, ’H1P55’, ’H1S1’], section_2 = [’H2B1’, ’H2B2’, ’H2P1’, ’H2P2’, ’H2P3’,
’H2P4’], section_3 = [’H3B1’, ’H3B2’, ’H3B3’, ’H3B6’, ’H3P1’, ’H3P2’, ’H3P3’, ’H3P4’,
’H3P55’, ’H3P6’], section_4 = [’H4B1’, ’H4B2’, ’H4P1’, ’H4P2’], LA_sections18 = [’LA01’,
’LA02’, ’LA03’, ’LA04’, ’LA05’, ’LA06’].
Given i) the section ’SX’ corresponding to an MHA (where X 2 {1, 2, 3, 4}), ii)
the Rack and iii) the Horizontal Rack Coordinate corresponding to a pick location, the
building (as well as live determination during pick-run route optimization) of keys for
unique nodes was thus carried out as follows:

8
>
> 1, if MHA 2 section_1.
>
>
>
>
<2, if MHA 2 section_2.
X (4.5)
>
> 3, if MHA 2 section_3.
>
>
>
>
:4, if MHA 2 section_4.

and,
key = ’S’+str(X)+’_R’+str(Rack)+’_H’+str(HRC)

17 There are many MHAs in the log data that are either not able to be mapped as they correspond to
moving/mobile racks, stationary conveyor picking, and automated picking areas.
18 LA_sections refers to the set of MHAs assigned to automated picking racks where pickers carrying out

pickruns can pick goods retrieved by automated racks. All LA sections are located in the top left region
of section 1, however, these had to be treated separately when building keys. Picks occurring in the
LA sections were assigned Rack labels, however, these labels were not indicative of any location in 2-D
space.Confusingly, it is the MHA that acts as the Horizontal Rack Coordinate for picking that occurs in
LA_sections.

© Louis Janse van Rensburg Uppsala University

Methodology 49

As LA_sections are located in section_1, keys for pick nodes with MHAs belonging
to LA_sections were treated differently and built as follows:

key = ’S1’+’_’+str(MHA)

In this way, unique keys were built for all picking nodes such that for a given node
v with key k, the corresponding row index i in A[i, :] storing coordinates [v x , vy ] could
be returned from keyDict[k].
In order to populate A with pick-point node coordinates, the dictionary rackIn f o
and the object autoRack19 are required. Furthermore let the auxiliary functions

• genRackNodeKey(Section, Rack, HRC )

• genAutoRackNodeKey( MH A)

return the key built for a specific picking node as specified above for nodes belong-
ing to non-automated (i.e. conventional racks) and automated picking racks, respectively.
For regular non-automated picking racks, the Section parameter in genRackNodeKey()
(such that Section 2 {1, 2, 3, 4}) can be determined simply by accessing the first character
RackString[0] of RackString = str ( Rack )20 , for a given node vr belonging to rack r.

19 Referred to at the beginning of step 2.

20 TheRack labeling convention is such that, for instance, Rack 112 is situated in section 1, and is the 12th
rack in section 1 rightward along the x-axis.

© Louis Janse van Rensburg Uppsala University

Methodology 50

Algorithm 10: Populate array A and generate keyDict

input: The list of rack labels R, dictionary rackIn f o, the object autoRack, list of
polygons P, depot coordinates ( xdepot , ydepot )
output : Array A, dictionary keyDict
1 Alist [[ xdepot , ydepot ]]
2 keyDict {}
3 keyDict[ depot0 ]
0 0
4 #Populating A with picking nodes belonging to non-automated racks
5 for i 0 to | R| 1 do
6 r R [i ]
7 xcoords rackIn f o [r ][0]
8 ycoords rackIn f o [r ][1]
9 HRC rackIn f o [r ][2]
10 for j 0 to | xcoords| 1 do
11 Alist .append([ xcoords[ j], ycoords[ j]])
12 nodeIndex | Alist [:, 0]| 1
13 section str (r )[0]
14 key genRackNodeKey(section, r, HRC [ j])
15 keyDict[key] nodeIndex
16 end
17 end
18 # Populating A with picking nodes at automated retrieval rack
19 xcoords autoRack[0]
20 ycoords autoRack[1]
21 MH A autoRack[2]
22 for i 0 to | xcoords| 1 do
23 Alist .append([ xcoords[i ], ycoords[i ]])
24 nodeIndex | Alist [:, 0]| 1
25 key genAutoRackNodeKey( MH A[i ])
26 keyDict[key] nodeIndex
27 end
28 # Populating A with coordinates of vertices of polygons in the list of polygons P
29 for i 0 to | P| 1 do
30 for j 0 to | P[i ]| 1 do
31 Alist .append([ P[i ][ j][0], P[i ][ j][1]])
32 end
33 end
34 return asArray( Alist ), keyDict

© Louis Janse van Rensburg Uppsala University

Methodology 51

Step 6: Addition of dummy obstacle polygons to Polygon list P

Algorithm 10 populated array A with the vertices of polygons in P. In the current step,
polygons representing dummy obstacles are appended to P. This is purposely done after
Step 5, as vertices of dummy obstacles are not to be included as nodes in the graphical
network G.
Dummy obstacle polygons must be appended to P prior to executing algorithm 1
(Connect Unobstructed Node Pairs) in order to eliminate edges passing through narrow
passageways between racks, walls and obstacles in the warehouse space. Otherwise,
impossible edges (e.g. paths too narrow for pickers to traverse) would be introduced. In
the current work, ten areas (see 4.8, for example) in the warehouse space were visually
identified as areas where impossible edges were to be eliminated. Ten small rectangular
dummy polygons were then generated and positioned in these areas, ensuring no
accidental deletion of valid edges.
It should be noted that Step 6 could be automated entirely using a minimum dis-
tance threshold parameter21 and geometric computation on distances between pairwise
(non-dummy) polygons. The dummy obstacles generated through visual inspection
sufficed and so an automated approach was not developed.

Figure 4.7: Plotted Nodes ’*’ (Depot Node, Pick-Point Nodes, and Non-dummy Polygon
Vertex Nodes) and Polygons (including Dummy Obstacle Polygons).

21 Theminimum, unobstructed path width (perpendicular to direction of travel) necessary for a forklift to
traverse between consecutive nodes: pick points/obstacle corners.

© Louis Janse van Rensburg Uppsala University

Methodology 52

Figure 4.8: Depot Node and Examples of Pick-Point Nodes, Obstacle Corner Nodes, and
Dummy Obstacles.

4.5.4 Graph Network Generation

By this stage, graph network generation is straightforward. Given array A and the list
of polygons (including dummy-polygons) P, the algorithms 1-3 outlined in section 4.3
can be executed:

1. Pass A and P as arguments to algorithm 1 to determine the adjacency matrix

adjMat.

2. Pass adjMat and A to algorithm 2 to produce the weighted adjacency matrix

weightedAdjMat.

3. Pass node labels (V, E, W) to NetworkX’s Graph() class to generate a graphical

network G.

4. Determine all node pair shortest paths (shortestPaths) and shortest path dis-
tances that populate the distance matrix shortestPathDists using NetworkX’s
shortest_path( G ), shown in algorithm 3.

© Louis Janse van Rensburg Uppsala University

Methodology 53

Figure 4.9: A Virtual Warehouse - Graph Network G

4.5.5 Mapping of WMS Location Tags to Nodes in G for Live Picker Route
Optimization

During live optimization, the WMS communicates with the picker route optimization
cloud application by triggering JSON (or XML) posts to a server containing the necessary
data structures and algorithms for route optimization.
Data contained in the JSON/XML posts include WMS location tags (MH A, Rack,
HRC) for M items that are to be picked on a pick run. Given this input data, a specific
problem instance’s list of nodes V can be determined. This is achieved by an auxiliary
function getNode( MH A, Rack, HRC, keyDict) that generates a key k (in the same way
as specified for the functions genRackNodeKey(), genAutoRackNodeKey(), see Step 5 of
section 4.5.3) where keyDict[k ] then returns the node identifier i (corresponding to the
node represented at index i in A). The depot node with index label i = 0 is then appended
to the start and end of V, which can now be passed to Simulated Annealing (algorithm
7) for route optimization. Furthermore, using the node identifiers listed in V as indices,
a problem instance distance matrix D can be extracted from shortestPathDists and i)
can be used for distance calculation of tours generated during execution of Simulated
Annealing and ii) can be passed as the single input source to the Concorde TSP Solver
for determining the optimal tour.

© Louis Janse van Rensburg Uppsala University

Methodology 54

Figure 4.10: Illustration of Problem Instance Distance Matrix Extraction.

4.6 Extraction of Historic Pick-Run Instance Data

The main tools used to process raw log dump data and extract historic pick-run instance
data were Apache Spark, Spark SQL, Amazon Web Service cloud instances and Jupyter
(iPython) Notebook. The following criteria were used when extracting historic pick run
data:

• A historic pick-run containing unique pick-run ID attribute (labelled pickrno) can

only be carried out by a single picker (identified by the user ID attribute labeled
loguser).

• For each row with operation code (l16lcode) 4 denoting a pick event, the location
tag attributes labeled fmha, frack, fhorcoor, and fvercoor 22 must not be Null.

• The time stamp (datreg) value for each entry with operation code 4 must not be
Null.

• A given pick-run must contain at least 3 row entries with operation code (l16lcode)
4 where at least three distinct locations are to be picked 23 .

Pick-runs that satisfied the above criteria were then extracted and for each pick run the
historic sequence in which items were picked was enforced according to the time stamp
(datreg) ordering. Historic pick-run instance data was then stored in eight 156332-by-1
arrays, described in dot-point two of section 4.4.1.

22 Fvercoor denotes a vertical pick point specifying pick location in the third dimension. Although this
attribute is not necessary for determining optimal routes in two dimensions, it was later integrated into
the cloud application in order to enforce a vertical top-down picking policy
23 There is no distance reduction to be gained from optimizing a pick-run containing less than 3 distinct

locations where there is only one (start and end) depot

© Louis Janse van Rensburg Uppsala University

Methodology 55

Figure 4.11: Distribution of Extracted Historic Pick-run Instance Problem Sizes. Note:
Y-Axis is Log Scaled to Show the Presence of Non-trivial Instances.

4.7 Experimentation and Evaluation

4.7.1 Total Tour Distance Comparison - Optimized (Simulated Annealing
and Concorde) vs Historic Pick-Run Tours (N = 20854)

It was hypothesized that optimization24 of pick-run tours would lead to reduced distance
travelled by pickers when compared to the distance travelled historically for the same
instances (as evidenced by the time stamped pick-runs extracted from the log data).

24 Usingthe Graph Representation, Concorde and Simulated Annealing algorithms to optimally order the
sequence of items to pick for a given pick-run, according to the objective of minimizing tour distance.

© Louis Janse van Rensburg Uppsala University

Methodology 56

4.7.2 Trial and Error Tuning and Evaluation of Simulated Annealing

The rationale for implementing a Simulated Annealing algorithm to solve TSP problems
is that the parameters MaxIter25 , SchedIter26 , StopTemp and hyper parameters T and a
can be tuned so that a solution sufficiently approximating the optimum (for a range of
problem instance sizes, n  n⇤ , where n⇤ is maximal), requires computation time tSA < t⇤
where the maximum allowed time for computation is t⇤ . The empirical evaluation of
this algorithm ought to therefore determine the upper bound of the problem instance
size n⇤ such that the percentage error in tour distance between the optimal solution’s
Opt
tour distance (dn ) 27 and the tour distance resulting from the Simulated Annealing
Opt
solution (dSA
n ), proportional to dn , is less than some threshold q.
In this evaluation, the threshold q = .05. The reason for choosing this bound is
based on the fact that the commonly used picker routing heuristic methods prescribed
for single-block standard warehouses ( inappropriately applied in industry to larger
non-standard warehouses) have been shown to result in reducing the proportional
Opt
relative difference Ddn µ dn to within 5 % - 20 % for increasing instance sizes n =
{5, 15, 25, 35, 45}[18]28 . Hence, in building a case for implementing Simulated Annealing,
i) the 5% benchmark is used and ii) computation times are logged and compared with
the allowed threshold t⇤ = 1 sec.

4.7.3 Evaluation of Concorde TSP Solver

Concorde TSP Solver’s suitability for live implementation is evaluated by comparing the
distribution of instance sizes N in the logged population of pick-runs and the maximal
instance size nConcorde where computation time tConcorde < t⇤ = 1sec. If it can be shown
that all instance sizes n 2 N |n < nConcorde , live determination of optimal routes for
pickers in this warehouse is deemed feasible.

25 Denoting the maximum number of iterations the algorithm is permitted to run, see 4.3.4.
26 Denoting the temperature update schedule, see 4.3.4.
27 As determined using the Concorde TSP Solver.
28 See section 2.4.2.

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 57

5 Results, Analysis and Discussion

All experiments were run on Mac OS X 10.14 (64 bit) on a (single processor, dual core)
Intel Core i5 5287U of 2.90GHz with two 256 KB L2 caches (one per core), a 3 MB L3
cache and 8 GB RAM.

5.1 Total Distance Comparisons: Optimum vs Optimized vs

Historic Routes
Figure 5.1 provides a comparison of the total distance of optimized routes generated by
Concorde TSP Solver (CTS), 5491.904 km; Simulated Annealing with Tuned Parameters
(SATP), 5495.671 km; Simulated Annealing with Default Parameters (SADP), 5513.491
km; and the total distance of historic routes (6437.223 km) travelled by warehouse pickers
for 20854 pick-run instances extracted from the WMS log. For each optimization, there
is a substantial reduction in total distance relative to total historic distance travelled by
pickers (14.685% (CTS); 14.627% (SATP); 14.342% (SADP)).

Figure 5.1: Total distance for 20854 pick-run instances: i) CTS (5491.904 km), ii) SADP
(5513.491 km), and iii) SATP (5495.671 km) and iv) routed historically
(6437.223 km).

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 58

Figure 5.2: Example Pick-Run: Historic (583 meters) vs Optimum (454 meters)

5.2 Random Sample Set Generation for Performance Analysis

Two sets of randomly generated problem instances were required for further testing
and analysis. Generating a sample with problem size n requires n random selections
(without replacement) from a set of integer labelled nodes in G.

1. For run-time and distance minimization analysis, 100 pick-run instances were
randomly generated for each of the 26 instance sizes (2600 samples in total) in
the range n = [5,30]. The reason for selecting an upper bound of n = 30 is that an
analysis of the distribution of instance sizes extracted from the historic log data
showed that 99.5% of all instances had instance size n  30. Figures 5.4, 5.5, 5.6,
5.7, 5.8, 5.10, 5.11, 5.3 all display results for tests carried out on this sample set.

2. A second set of randomly generated instances were used for time-out analysis on
CST time-outs for larger instances. For each instance size in the set of instance sizes
{100, 125, 150, 175, 200} 30 samples were generated. Figure 5.9 displays results for
tests carried out on this sample set.

5.3 Parameter Tuning - Simulated Annealing

Parameter tuning was carried out using trial and error. As per default source code
parameters, starting temperature T was initially set as the root of the instance size n.
However, after trialling different variations of T as a function of n, a large value for T
(high energy) was found to produce best results in terms of distance minimization. Even
better results were obtained during trial and error tuning by increasing a (decreasing
the rate of cooling).

Simulated Annealing Default Parameters (SADP):

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 59

p
• Start temperature: T = n, where n = instance size.

• a = 0.995

• Cooling schedule: Ti = aTi 1 , at iteration i.

• Maximum iterations (MaxIter) = 105

• Stopping temperature (StopTemp) = 10 9

• Number of iterations required before updating T (SchedIter) = 1

Simulated Annealing Tuned Parameters (SATP):

• Start temperature: T = 1.2 ⇥ 105

• a = 0.998

• Cooling schedule: Ti = aTi 1 , at iteration i.

• Maximum iterations (MaxIter) = 105

• Stopping temperature (StopTemp) = 10 9

• Number of iterations required before updating T (SchedIter) = 1

5.3.1 Energy and Exploration

Due to a high constant value for T, SATP terminates after completing 16194 iterations
when Ti is cooled to StopTemp. SADP terminates with fewer iterations (4295 iterations
p
where n = 5; 4475 iterations where n = 30, for variable start temperature T = n) when
Ti is cooled to StopTemp.
Higher starting temperature not only increases the number of iterations required
for algorithm termination, it also results in greater tendency for exploration. The reason
for this is that when a less fit candidate solution S0 is generated, the probability of
accepting S0 over S, given by exp( DtourDistance/Ti ), becomes greater with a greater
value for the denominator Ti . That is, with high T, SATP will initially tend to explore a
greater number of sub-optimal solutions compared to SADP. The benefit to this is that
higher T helps the algorithm to avoid getting stuck early at local minima and leads to
better approximation of the global optimum for the instances studied.
How energy (T) relates to exploration can be further observed in terms of the
exploration chance counts and the exploration counts for both SADP (figures 5.3 and 5.5)
and SATP (figures 5.4 and 5.6). An exploration chance occurs during an iteration of
Simulated Annealing if the candidate solution S0 being evaluated has a distance greater
than the current solution S. Exploration of a less optimal solution occurs when a randomly
generated real valued number between 0 and 1 is less than exp( DtourDistance/Ti ).

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 60

Figure 5.3: Number of iterations in SADP where the candidate solution S0 has a distance
greater than the current solution S.

Figure 5.4: Number of iterations in SATP where the candidate solution S0 has a distance
greater than the current solution S.

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 61

Figure 5.5: SADP Exploration Counts: Number of iterations where a sub-optimal

solution was selected.

Figure 5.6: SATP Exploration Counts: Number of iterations where a sub-optimal

solution was selected.

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 62

5.4 Run-time Comparisons

Figure 5.7 shows a run-time comparison of maximum allowed time (t* = 1 second)
and minimum, maximum and mean run-times for CTS and SADP. Figure 5.8 shows a
run-time comparison of maximum allowed time and minimum, maximum and mean
run-times for CTS and SATP. It can be seen that CTS is consistently faster (in some cases,
by an order of magnitude) when compared to both SADP and SATP. By contrasting
figures 5.7 and 5.8 it can be seen that following parameter tuning, run-times for Simulated
Annealing are somewhat impaired (there is an overall upward shift along the y-axis for
run-time in seconds for SATP when compared to SADP). Although run-time for SATP
in one instance is seen to exceed the maximum allowed time, this can be considered a
noise point1 as instance size (n = 6) is trivial and run-times for SATP otherwise remain
below the maximum allowed time.
Run-times were further studied for larger instances to determine the maximal
instance size, n⇤ , where CTS can consistently compute the optimum solution within the
maximum allowed time t⇤ . Figure 5.9 shows that for instances with instance size n 
150, CTS reliably produces the optimum solution within one second. The log data did
not contain an instance size n as great as 150. CTS computes optimum (as opposed to
approximately optimal) routes for all 20854 warehouse pick-runs extracted from the
two month log within a one second time limit, t⇤ . CTS is therefore found to be the
superior algorithm when compared to Simulated Annealing for live warehouse picker
route optimization.

1 Most likely due to background OS processes.

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 63

Figure 5.7: Minimum, maximum and mean run-times for CTS and SADP.

Figure 5.8: Minimum, maximum and mean run-times for CTS and SATP.

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 64

Figure 5.9: CTS for Larger Instances: CTS consistently computes the optimum route in
under one second for instances of up to N = 150.

5.5 Distance Reduction Comparisons: SATP and SADP relative

to Optimum (CTS)
Figures 5.10 and 5.11 show the percentage error in route distance computed by SADP
and SATP when compared to optimal route distances as computed by CTS, respectively.
It can be seen that the maximum allowable percentage error (5%)2 is exceeded by both
SADP and SATP. However, tuning (SATP) substantially reduces percentage error such
that only a few outliers exceed this maximum percentage error for larger instances.
Tuning Simulated Annealing seems therefore (by visual inspection) to provide better
results compared to both SADP and heuristic picker routing methods traditionally used
in industry.

2Abenchmark determined in the literature [18]. This benchmark is the performance limit of traditional
heuristic/hybrid approaches.

© Louis Janse van Rensburg Uppsala University

Results, Analysis and Discussion 65

Figure 5.10: SADP Distance Reduction: Percentage Error Deviation from Optimum
(CTS). Solutions for many instances have a percentage error > 5%.

Figure 5.11: SATP Distance Reduction: Percentage Error Deviation from Optimum
(CTS). Few outliers perform worse than the 5% error benchmark.

© Louis Janse van Rensburg Uppsala University

Future Work 66

6 Future Work

The current work provides a foundation for further warehouse optimizations including:

• Batch Optimization: Selecting an optimal subset of boxes from a set of currently

available boxes1 (each box containing item(s) located at nodes in G) to generate a
picking list for a picker. An objective here is to minimize meters per pick.

• Dynamic Slotting: Deciding where an incoming item should be stored in the

warehouse space using dynamic association rules and some forecast of orders.

1 Available boxes are boxes that currently need to be ’picked’ for outbound shipment.

© Louis Janse van Rensburg Uppsala University

Conclusions 67

7 Conclusions

This work describes how a warehouse CAD drawing and a warehouse management
system log dump can be processed to enable warehouse optimisation using AI methods.
This work also provides an experimental account of picker route optimization, contrast-
ing Simulated Annealing and Concorde TSP Solver. The main conclusions of this work
are:

1. Optimizing routes reduces aggregate route distance by almost 15% of total historic
route distance. It was found that warehouse forklift pickers drove 946 km further
than necessary over two months at the Ahlsell Gardemoen site.

2. Given the distribution of 20854 pick run instance sizes found in the Ahlsell ware-
house log dump, the Concorde TSP Solver is found to be the superior algorithm
for picker route optimization as it computes the optimum solution (for instance
sizes n  150) in under one second.

3. Simulated annealing can be tuned to perform consistently better than benchmarks

provided by industry-standard hybrid/heuristic picker routing strategies.

4. The data structures generated by this work provide a foundation for further
warehouse optimizations, such as batch optimization and dynamic slotting.

© Louis Janse van Rensburg Uppsala University

Literature 68

Literature

[1] B. Rouwenhorst, B. Reuter, V. Stockrahm, G. van Houtum, R. Mantel, and W. Zijm,

“Warehouse design and control: Framework and literature review”, European
Journal of Operational Research, vol. 122, no. 3, pp. 515–533, 2000.

[2] U. Pferschy and J. Schauer, “Order batching and routing in a non-standard

warehouse”, Electronic Notes in Discrete Mathematics, vol. 69, pp. 125–132, 2018,
Joint EURO/ALIO International Conference 2018 on Applied Combinatorial
Optimization (EURO/ALIO 2018).

[3] J. Karasek, “An overview of warehouse optimization”, International Journal of

Advances in Telecommunications, Electrotechnics, Signals and Systems, vol. 2, no. 3,
pp. 111–117, 2013.

[4] J. J. Bartholdi and S. T. Hackman, Warehouse & distribution science, Georgia

Institute of Technology, School of Industrial and Systems Engineering, The Supply
Chain and Logistics Institute, Atlanta, GA 30332-0205 USA, version 0.98,
August 28, 2017.

[5] C. W. Autry, S. E. Griffis, T. J. Goldsby, and L. M. Bobbitt, “Warehouse

management systems: Resource commitment, capabilities, and organizational
performance”, Journal of Business Logistics, vol. 26, no. 2, pp. 165–183, eprint:
https://onlinelibrary.wiley.com/doi/pdf/10.1002/j.2158-1592.2005.tb00210.x.

[6] J. Gu, M. Goetschalckx, and L. F. McGinnis, “Research on warehouse design and

performance evaluation: A comprehensive review”, European Journal of Operational
Research, vol. 203, no. 3, pp. 539–549, 2010.

[7] F. Caron, G. Marchet, and A. Perego, “Optimal layout in low-level picker-to-part

systems”, International Journal of Production Research, vol. 38, no. 1, pp. 101–117,
2000. eprint: https://doi.org/10.1080/002075400189608.

[8] K. Gue and R. Meller, “Aisle configurations for unit-load warehouses”, vol. 41,
pp. 171–182, March 2009.

[9] K. R. Gue, G. Ivanović, and R. D. Meller, “A unit-load warehouse with multiple

pickup and deposit points and non-traditional aisles”, Transportation Research Part
E: Logistics and Transportation Review, vol. 48, no. 4, pp. 795–806, 2012.

© Louis Janse van Rensburg Uppsala University

Literature 69

[10] K. J. Roodbergen and R. de Koster, “Routing order pickers in a warehouse with a

middle aisle”, European Journal of Operational Research, vol. 133, no. 1, pp. 32–43,
2001.

[11] R. de Koster, T. Le-Duc, and K. J. Roodbergen, “Design and control of warehouse

order picking: A literature review”, European Journal of Operational Research,
vol. 182, no. 2, pp. 481–501, 2007.

[12] C. Kallina and J. Lynn, “Application of the cube-per-order index rule for stock
location in a distribution warehouse”, Interfaces, vol. 7, pp. 37–46, November 1976.

[13] M.-K. Lee and E. A. Elsayed, “Optimization of warehouse storage capacity under
a dedicated storage policy”, International Journal of Production Research, vol. 43,
no. 9, pp. 1785–1805, 2005. eprint:
https://doi.org/10.1080/13528160412331326496.

[14] K.-W. Pang and H.-L. Chan, “Data mining-based algorithm for storage location
assignment in a randomised warehouse”, International Journal of Production
Research, vol. 55, no. 14, pp. 4035–4052, 2017. eprint:
https://doi.org/10.1080/00207543.2016.1244615.

[15] W. Zhou, S. Piramuthu, F. Chu, and C. Chu, “Rfid-enabled flexible warehousing”,

Decision Support Systems, vol. 98, pp. 99–112, 2017.

[16] M. B. M. D. Koster, E. V. der Poort, and M. Wolters, “Efficient orderbatching

methods in warehouses”, International Journal of Production Research, vol. 37, no. 7,
pp. 1479–1504, 1999. eprint: https://doi.org/10.1080/002075499191094.

[17] P. J. Parikh and R. D. Meller, “Selecting between batch and zone order picking
strategies in a distribution center”, Transportation Research Part E: Logistics and
Transportation Review, vol. 44, no. 5, pp. 696–719, 2008.

[18] C. Petersen, “An evaluation of order picking routing policies”, International Journal
of Operations & Production Management, vol. 17, pp. 1098–1111, January 1997.

[19] C. Petersen, “Routeing and storage policy interaction in order picking

operations”, in Decision Sciences Institute Proceedings, vol. 3, 1995, pp. 1614–1616.

[20] K. J. Roodbergen and R. Koster, “Routing methods for warehouses with multiple
cross aisles”, International Journal of Production Research, vol. 39, no. 9,
pp. 1865–1883, 2001. eprint: https://doi.org/10.1080/00207540110028128.

[21] H. D. Ratliff and A. S. Rosenthal, “Order-picking in a rectangular warehouse: A

solvable case of the traveling salesman problem”, Operations Research, vol. 31,
no. 3, pp. 507–521, 1983.

© Louis Janse van Rensburg Uppsala University

Literature 70

[22] L. Pansart, N. Catusse, and H. Cambazard, “Exact algorithms for the order
picking problem”, Computers & Operations Research, vol. 100, pp. 117–127, 2018.

[23] J. Zhu, H. Zhang, J. Guo, and L. Zhou, “Picking path optimization in dual zone
type warehouse based on genetic algorithms”, vol. 3, pp. 41–46, January 2015.

[24] E. Grosse, C. Glock, and R. Ballester-Ripoll, “A simulated annealing approach for

the joint order batching and order picker routing problem with weight
restrictions”, vol. 20, pp. 65–83, January 2014.

[25] T. Vaughan and C. Petersen, “The effect of warehouse cross aisles on order
picking efficiency”, International Journal of Production Research, vol. 37, pp. 881–897,
January 1999.

[26] C. Theys, O. Bräysy, W. Dullaert, and B. Raa, “Using a tsp heuristic for routing
order pickers in warehouses”, European Journal of Operational Research, vol. 200,
no. 3, pp. 755–763, 2010.

[27] J. D. C. Little, K. G. Murty, D. W. Sweeney, and C. Karel, “An algorithm for the
traveling salesman problem”, Operations Research, vol. 11, no. 6, pp. 972–989, 1963.
eprint: https://doi.org/10.1287/opre.11.6.972.

[28] D. Applegate, R. Bixby, W. Cook, and V. Chvatal, On the solution of traveling

salesman problems, 1998.

[29] G. Reinelt, “Tsplib—a traveling salesman problem library”, ORSA Journal on

Computing, vol. 3, no. 4, pp. 376–384, 1991. eprint:
https://doi.org/10.1287/ijoc.3.4.376.

[30] D. L. Applegate, R. E. Bixby, V. Chvatál, and W. J. Cook, The Traveling Salesman

Problem: A Computational Study. Princeton University Press, 2006.

[31] R. Key and A. Dasgupta, “Warehouse pick path optimization algorithm analysis”,
in 11 th International Conference on Foundations of Computer Science (FCS 2015), 2015.

[32] E. U. Rotterdam, “Routing strategies”, Erasmus Institute of Management, Tech.

Rep., 2018, Retrieved October 2018 from https://www.erim.eur.nl/material-
handling-forum/research-education/tools/calc-order-picking-time/what-to-
do/routing-strategies/LargestGap.

[33] R. W. HALL, “Distance approximations for routing manual pickers in a

warehouse”, IIE Transactions, vol. 25, no. 4, pp. 76–87, 1993. eprint:
https://doi.org/10.1080/07408179308964306.

[34] E. U. Rotterdam, “Warehouses”, Erasmus Institute of Management, Tech. Rep.,

2018, Retrieved October 2018 from

© Louis Janse van Rensburg Uppsala University

Literature 71

https://www.erim.eur.nl/material-handling-forum/research-
education/tools/calc-order-picking-time/what-to-do/warehouses/.

[35] M. Antosiewicz, G. Koloch, and B. Kamiński, “Choice of best possible

metaheuristic algorithm for the travelling salesman problem with limited
computational time: Quality, uncertainty and speed”, Journal of Theoretical and
Applied Computer Science, vol. 7, pp. 46–55, January 2013.

[36] S. Kirkpatrick, C. D. Gelatt, and M. P. Vecchi, “Optimization by simulated

annealing.”, Science, vol. 220 4598, pp. 671–80, 1983.

[37] Y. Li, A. Zhou, and G. Zhang, Simulated annealing with probabilistic neighborhood for
traveling salesman problems, Jul. 2011.

[38] S. Hong, A. L. Johnson, and B. A. Peters, “Batch picking in narrow-aisle order

picking systems with consideration for picker blocking”, European Journal of
Operational Research, vol. 221, no. 3, pp. 557–570, 2012.

[39] N. Metropolis, A. W. Rosenbluth, M. N. Rosenbluth, A. H. Teller, and E. Teller,

“Equation of State Calculations by Fast Computing Machines”,, vol. 21,
pp. 1087–1092, Jun. 1953.

[40] M. Locatelli, Convergence of a simulated annealing algorithm for continuous global

optimization, Kluwer Academic Publishers, 2000.

[41] M. Schult Hagberg, Networkx 2.2, Source code retrieved May 2018 from:
https://pypi.org/project/networkx/, 2018.

[42] C. Ceyhan, Simulated annealing algorithm to solve travelling salesman problem in

python, Source code retrieived May 2018 from:
https://github.com/chncyhn/simulated-annealing-tsp, 2017.

[43] D. L. Applegate, R. E. Bixby, V. Chvatál, W. J. Cook, and A. Rohe, Concorde tsp

solver version 03.12.19, Source code retrieved May 2018 from:
http://www.math.uwaterloo.ca/tsp/concorde/downloads/downloads.htm,
2003.

© Louis Janse van Rensburg Uppsala University