AMPL Project

AMPL Project
Background
Hollyboba is an e-commerce business. To balance the urgent need to meet growing demands while maintaining high-quality logistics services, the company built intelligent warehouses that employ storage-moving-robots, referred to as automatic guided vehicles (AGVs), that are dispatched when a batch of orders arrives. One of the major challenges in operating an intelligent warehouse is the management and dispatching of AGVs. The purpose of this project is to design an optimal dispatching system.
1 Problem description
In an intelligent warehouse, stock-keeping units1 (SKUs) are initially stored on storage racks in the picking area (see Figure 1). The warehouse has a number of workstations where the SKUs are picked from the racks by robot arms and placed into the packages to be shipped. A large number of AGVs, which pick up racks from the picking area and transport them to the workstations, surround the storage racks. The figure on the cover shows typical racks being carried by AGVs (the small robots at the bottom). Each rack has 10 storage grids, each storing only one type of SKU 2.
A typical order consists of certain quantities of various types of SKUs. When an order arrives, it is distributed among the workstations. (Note that distributing the orders to the workstations is itself an important problem; we initially assume that this is given to us as part of our input). Each workstation contains several berths for the AGVs. After receiving an order, the dispatch centre examines the types and the number of SKUs in that order and sends commands to one or multiple AGVs to pick up and transport racks to the workstation. The candidate racks include the ones in the picking area and the ones already being carried by AGVs.
If a rack has been assigned to a workstation, it needs to be transported by an AGV. In particular, if a rack is currently not moving, an idle AGV will be assigned to pick it up and deliver it to the target workstation. If instead a rack is currently moving and it is not assigned to a workstation, then the AGV that is currently transporting the rack will carry it from the current location to a workstation3. When an AGV carrying a rack arrives at the workstation, it will park in a berth near the workstation. If the workstation has no empty berth at the moment, no rack is assigned to this workstation.
A typical objective is to minimise the total distance travelled by the AGVs over a typical day. However, doing this would require to include a time dimension (i.e. orders arrive over time, hence one will need to re-optimise many times over a time period) as a well as a forecasting component (i.e. dispatching decisions need to be taken at regular time intervals, without knowing the future orders). To keep things simple, we consider a time-snapshot of the warehouse operation, where we know the positions of the racks, AGVs, current orders to be fulfilled and berths available. Given that typically we will not have sucient available berths and AGVs to fulfill all current orders, our objective function will be some weighted combination of the total distance and the number of orders left unfulfilled.
1A stock keeping unit is a specific type of product, e.g. an SKU could be iPhone 14 in blue, another SKU could be iPhone 14 in purple.
2In other words, every rack can hold up to 10 di↵erent types of SKUs and di↵erent racks can hold a di↵erent selection of SKUs.
3For simplicity, in our data all racks that are moving have not yet been assigned to a workstation, although this situation would be easy to model
Code Help, Add WeChat: cstutorcs
2 Data descrition
The warehouse is a 50m⇥50m square with four workstations located at each corner. There are 40 SKUs, 20 AGVs, and 80 racks.
Figure 1: Schematic representation of the warehouse with the current positions of the racks (grey rectangles) and AGVs (red circles). Grey rectangles with a red circle represent racks currently being transported by an AGV. Stationary racks are deposited in rows in the picking area (the area within the dashed rectangle). The four workstations are represented by the blue corners.
The data is provided in the file Project_data.xlsx. Below is a summary of the data contained in each tab of the file.
“Coordinates and status”: this contains the “x,y” coordinates of the racks, workstations, and AGVs. For the racks, numbered 1 through 80, the “status” columns indicates whether the rack is stationary or moving. If the rack is moving, then the “x,y” coordinates are not provided but we indicate, in the column “AGV assigned”, which AGV is currently transporting the rack (e.g., rack 13 is currently being transported by AGV number 7).
“Inventory matrix”: here we show the stock level of each SKU in each rack (note that, since 3

each rack has 10 storage grids, each rack carries at most 10 distinct types of SKU). For example, rack 1 carries SKUs of type from 1 to 10, where there are 7 items of SKU 1, 5 of SKU 2, 19 of SKU 3, and so forth.
“Demands”: this tab provides the number of orders of each SKU to be dispatched to each workstation.
“Berths”: number of open berths for each workstation.
3 Project aim
Since the AGVs move only along the x,y-axes, the distance between two locations in the warehouses is given by the “Manhattan distance”, i.e. the `1 norm, where the distance between two points (x(1), y(1)) and (x(2), y(2)) is defined as k(x(1), y(1)) (x(2), y(2))k1 = |x(1) x(2)| + |y(1) y(2)|.
Our objective, which we intend to minimise, is a weighted combination of the total distance of the rack from their assigned AGV (with weight ↵1 = 1), the total distance of the rack from their assigned workstation (with weight ↵1 = 1.3), and the total number of orders that will be left unfulfilled (with weight ↵1 = 3). (Note that it makes sense to assign larger weight in the objective to the distance the AGV travel when carrying a rack, since they will be slower and consume more energy.)
4 Building an integrated order-dispatching system
Currently Hollybobba has a legacy system to assign orders to workstations. They would like to explore the benefit of integrating the order-dispatching decision into the AGV-dispatching model. In this second part of the project, the task is to include the assignment of orders to workstations in the optimisation model. How does the integrated model compare to the previous one? What is the di↵erence in cost? How many more orders are fulfilled?
Programming Help, Add QQ: 749389476
Deliverables and Report Contents
The Espresso Company wants you to develop optimisation models for their problems. Use AMPL to implement and solve these models It is expected that you will then analyse and discuss your findings on the basis of the questions outlined in the previous sections. You must deliver a Project Report containing your analysis and suggestions but also detailing the modeling that you have undertaken. The Project report should consist of the following (explained below in more detail):
(a) A brief Executive Summary, discussing your main findings. It should be completely free of any mathematical terms and discussion of modeling technicalities. It should describe the main characteristics of the solutions obtained and answer all the questions.
(b) A concise Management Report discussing all of your findings. The Management Report should be independent of the Executive Summary (i.e., self-contained). Ideally, the Management Report will avoid the use of unnecessary modeling technicalities.
(c) A number of Technical Appendices. The technical appendices will give a complete account of the modeling development. In particular, an appendix detailing the development of the optimisa- tion models, where all entities of your models are defined and their meaning is explained in detail, together with the models clearly stated.
(d) An electronic copy, of all of the model files that you develop as well as any additional computer files used (if any).

Marking scheme
Modeling 30 Implementation 20 Analysis 30 Organisation/Presentation 20 Total 100
Modeling. The basic ingredients of the model are appropriately and meaningfully defined. The essential decision variables for the model are introduced with suitable types. Constraints are formulated correctly.
Implementation. All scenarios and the extension are implemented in a sound manner. Data is provided in an appropriate form and separated from the model. Further, demonstrating sucient capacity to developing “good” models: avoiding unnecessary variables and constraints, compactness of data representation as well as the use of more advanced features for defining model entities.
Analysis. The report should suciently demonstrate the ability to recognise and report all key results of the models and relate these to the real-world problem as well as demonstrating sucient understanding of these results with a discussion of requisite insight. Discussing limitations of the model, the possible sources of these and how they may impact on the problem decision.
Organisation/Presentation. A main report and technical appendices which are clear, concise, well organised, well formatted and well presented with appropriate use of figures and tables, well commented and easy to navigate files.
CS Help, Email: tutorcs@163.com