Smart Warehouse Optimization with Clingo
With the growth in customer demand and market competition, it has become increasingly important to improve the speed and accuracy of all interconnected functions in the supply chain. In every domain involving supply chain management, effective storage and retrieval of products in a warehouse is critical to the overall success of the supply chain. Effective warehouse automation not only improves overall supply chain efficacy but also reduces various costs, including warehouse operations, inventory holding, and product damage.
As technology has advanced, we have seen warehouse operations evolve from manual handling to the use of multiple sophisticated robots working simultaneously to complete tasks. Despite these advancements, the basic requirements for automation remains the same. This project presents a basic warehouse automation model that addresses fundamental requirements such as safe product handling and quick order fulfillment. This model serves as a foundation upon which more sophisticated systems can be built.
Please Note : This was an academic project done as part of my Master of Computer Science program at Arizona State University
I. Automated Order Fulfillment System for High-Value Goods
Designing an automated system for order fulfillment involves addressing challenges like speed, accuracy, volume, and avoiding conflicting actions that could cause damage or safety issues. The goal of the project was to create an efficient material handling system for a finished goods warehouse, ensuring rapid and reliable order processing without causing harm to products or the system.
Key points include:
Avoiding movements under shelves while loaded.
Preventing placement of shelves on highways.
Ensuring robots do not swap positions simultaneously.
II. Description of Solution
This section has two parts : the approach to the solution and the actual solution.
A. Approach to Solving the Problem
The approach to developing the final working model started with building the movements and actions, then adding constraints as needed. The idea was to have a working model that could fulfill orders without any constraints and then add individual constraints.
Actions are categorized into three main categories:
Moving the robot to the instructed final grid: This focused on the ‘move’ action, getting the robot to move from the initial position to the picking stations.
Moving the robot loaded with a shelf containing the product from the initial position to the picking station: This focused on the ‘pickup’ and ‘putdown’ actions of the robot.
Delivering the product from the shelf to fulfill the order at the picking station: This ensured the quantity decrements from the shelf and the outstanding quantity on order is reduced as deliveries are made.
Once the robot could perform all the actions listed above for all provided instances without any constraints, constraints were built for each action. Below are some of the constraints that were modeled:
For the ‘move’ action:
Robots cannot move outside the grid.
Robots cannot swap places.
A loaded robot cannot move underneath a shelf.
Robots cannot enter the picking stations when not loaded.
For the ‘pickup’ and ‘drop’ actions:
A robot cannot carry two shelves.
A robot can pick up a shelf only when at the location of the shelf.
Robots cannot drop the shelves on the highway.
Robots cannot enter the picking stations when not loaded.
For the ‘deliver’ action:
A robot can deliver only at the picking station.
A robot cannot deliver more than required.
A robot cannot deliver more than available.
A robot cannot deliver the wrong product.
A robot can deliver only from the shelf it is carrying.
In addition to this, state constraints and some constraints on combinations of actions were modeled. Here are a few:
A shelf cannot be on the highway.
Two robots cannot be at the same location.
Two shelves cannot be at the same location.
The constraints were logically segregated as mandatory and flexible based on the impacts of violating them. Flexible constraints can be tweaked or relaxed based on other changes. More details on this are provided in the results and analysis section.
Once all these were determined , the approach was structured based on general principles of Answer Set Programming (ASP):
Sort and object declaration.
State constraints.
Effect and preconditions of actions.
Action constraints.
Domain-independent axioms.
These constraints were enabled iteratively and Asprilo visualizer was used to ensure the actions and movements made logical sense and did not cause any violations. Finally, when a working model was achieved for all test cases, some constraints were tweaked to simulate real-world scenarios. More details on this are provided in the following section.
B. Main Results and Analysis
Below section presents the analysis for one of the simpler test cases, including the interpretation of results and simulation done by tweaking the constraints. How the model's response to changes in constraints plays into the real-world decision process is also discussed in this section.
Below are two simulated cases resulting from relaxing the constraints based on improvements made to the working environment. This case needs the fulfillment of just one order with a mix of different products required.
Illustrations from the Asprilo visualizer will demonstrate the model. Below are a few legends helpful in visualizing the model.
The figure shows the initial state of the warehouse, including the position of robots, shelves, and the location of the picking station. The grids are numbered from R1 through R4 for rows and C1 through C4 for columns. At any given time, robots can move one grid up or down on the same vertical axis or move one grid right or left on the same horizontal axis. Robots can move only one step at a time and can perform only one action at a time. A loaded robot cannot navigate through a grid occupied by a shelf.
Initial State and Legend
Case-1 is to simulate a scenario where the firm has made investments in improving the working environment. The firm has built a sophisticated picking station which can accommodate multiple robots to make deliveries at the same time. This simulation was achieved by relaxing the state constraint which was restricting more than 1 robot at the picking station.
Simulation-1 for Scenario-5
Case-2 is to simulate a scenario where the firm has made investments in improving the technology and installing a more sophisticated robot which can carry 2 shelves at a time. This simulation was achieved by relaxing the constraint which was restricting robot from carrying more than 1 shelf at a time.
Simulation-2 for Scenario-5
II. Results
The results show that the total number of moves and time increase with the number of orders to be fulfilled. The mix of products for each model also impacts the total duration to fulfill the order, with the mix of products having a more significant effect on the duration and number of steps.
Results
Final thoughts…
Declarative KRR frameworks [6] have shown their great utility in practice, especially for search-problems such as design, configuration, planning, classification, and diagnosis. ASP is one of the most attractive KRR frameworks because of its rich representation language. Therefore, ASP is used in academia and in industry for the encoding and solving of problems. ASP has captured the title of most sought-after approach to solve complex problems and the adoption is increasing with increase in need to solve complex problems. There are lot of opportunities for growth for the language and approach as a whole. The growth in technology and availability of more sophisticated and efficient computing machines will increase the pace at which this is adopted.
REFERENCES
[1] Falkner, A., Friedrich, G., Schekotihin, K. et al. Industrial Applications of Answer Set Programming. K ̈unstl Intell 32, 165–176 (2018). https://doi.org/10.1007/s13218-018-0548-6.
[2] Erik T. Mueller,Chapter 15 - Commonsense Reasoning Using Answer Set Programming, Editor(s): Erik T. Mueller,Commonsense Reasoning (Second Edition),Morgan Kaufmann,2015,Pages 249-269,ISBN 9780128014165,
[3] Baral, Chitta (2003). Knowledge Representation, Reasoning and Declarative Problem Solving. Cambridge University Press. ISBN 978-0-521-81802-5.
[4] Subrahmanian, V.S.; Zaniolo, C. (1995). ”Relating stable models and AI planning domains”. In Sterling, Leon (ed.). Logic Programming: Proceedings of the Twelfth International Conference on Logic Programming. MIT Press. pp. 233–247. ISBN 978-0-262-69177-2
[5] Gebser, M., Obermeier, P., Otto, T., Schaub, T., Sabuncu, O., Nguyen, V.,Son, T. C. (2018). Experimenting with robotic intra-logistics domains.CoRR, abs/1804.10247.
[6] Andres, B. Kaufmann, O. Matheis, and T. Schaub. Unsatisfiability-based optimization in clasp. In A. Dovier and V. Santos Costa, editors, Technical Communications of the Twenty-eighth International Conference on Logic Pro- gramming (ICLP’12), volume 17, pages 212–221. Leibniz International Pro- ceedings in Informatics (LIPIcs), 2012. 75, 94.
[7] Banbara, B. Kaufmann, M. Ostrowski, and T. Schaub. Clingcon: The next generation. Theory and Practice of Logic Programming, 17(4):408–461, 2017. 58
[8] Biere, M. Heule, H. van Maaren, and T. Walsh, editors. Handbook of Sat- isfiability, volume 185 of Frontiers in Artificial Intelligence and Applications. IOS Press, 2009. 9, 60
Sample Code Snippets for few conditions/constraints:
No shelves on 2 robots
:- 2 {holds(object(shelf,S),value(at,pair(X,Y)),T) : robot(R)}, shelf(S), T=0..m.
Explanation of the elements in the code:
The line :- 2 {holds(object(shelf,S),value(at,pair(X,Y)),T) : robot(R)}, shelf(S), T=0..m. is a constraint that states that it is not allowed to have more than one shelf being held by two robots at any given time.
The 2{...} part specifies a cardinality constraint, indicating that the enclosed atoms should not be true more than 2 times.
The term holds(object(shelf,S),value(at,pair(X,Y)),T) : robot(R) specifies the conditions under which the constraint applies, where S is a shelf, X and Y are coordinates, T is a time step, and R is a robot.
The shelf(S) predicate identifies the shelves.
The T=0..m part indicates that the constraint applies for all time steps from 0 to m.
shelf stays on robot unless put down by robot
{holds(object(shelf,S),object(robot,R),T+1)} :- holds(object(shelf,S),object(robot,R),T), not occurs(object(robot,R),putdown,T), R=1..nr, T=0..m-1.
Explanation of the elements in the code:
The line {holds(object(shelf,S),object(robot,R),T+1)} :- holds(object(shelf,S),object(robot,R),T), not occurs(object(robot,R),putdown,T), R=1..nr, T=0..m-1. specifies that a shelf S held by a robot R at time T can continue to be held by the robot at time T+1 unless the robot puts it down.
The {holds(object(shelf,S),object(robot,R),T+1)} part represents a choice rule allowing the holds predicate to be true at the next time step T+1.
The holds(object(shelf,S),object(robot,R),T) condition ensures the shelf is being held by the robot at time T.
The not occurs(object(robot,R),putdown,T) condition ensures that the robot does not put down the shelf at time T.
The R=1..nr part ensures this rule applies to all robots from 1 to nr.
The T=0..m-1 part ensures this rule applies to all time steps from 0 to m-1.