a rectangular grid of square conveyor modules with the capability to move items in the four cardinal directions. The modules can communicate with their neighboring modules as well as with the item they carry. At the south side of the grid, the retrieval conveyor moves products away from the grid. At the north, a replenishment conveyor moves products that need to be stored in the grid.
“GridStore Building on the puzzle-based storage system concept, Gue et al. (2014) propose a high-density storage system for physical goods called GridStore. The system consists of a rectangular grid of square conveyor modules with the capability to move items in the four cardinal directions. The modules can communicate with their neighboring modules as well as with the item they carry. At the south side of the grid, the retrieval conveyor moves products away from the grid. At the north, a replenishment conveyor moves products that need to be stored in the grid. Figure 12 illustrates the movement of the items toward the retrieval conveyor.”
— Robotized and Automated Warehouse Systems: Review and Recent Developments (Azadeh et al. 2019, 929).
GridStore—a Grid-Based Storage and Retrieval System
![]()
After many years of development and testing, we finally have a completed and accepted paper on GridStore: A Puzzle-Based Storage System with Decentralized Control. The paper, which will appear in IEEE Transactions on Automation Science and Engineering, was written with my colleague and friend Kai Furmans from Karlsruhe Institute of Technology and with two of our students, Zäzilia Seibold and Onur Uludağ.
For those familiar with this work from presentations gone by, you will notice that the name of the system has changed from GridFlow to GridStore. We are beginning to use the term GridFlow to refer to the class of systems that uses a grid-based movement architecture, rather than to a specific instance. GridFlow, GridPick, and GridSequence are all instances of the GridFlow way of thinking.
Below is an example of GridStore at work. Gray cells contain an item, such as a tote or pallet. Black cells represent requested totes trying to make their way to the southern boundary, where they are removed from the system by a conveyor or other means. Gray cells with a black circle represent totes returning to their “home rows.” When a replenishing totes reaches its home row, it turns gray until requested, after which it turns black. White cells are empty.
At each iteration conveyor cells determine their current state and then engage their neighbors in two rounds of “negotiations,” in which cells with competing interests try to reconcile. After negotiations are complete, cells convey in the appropriate direction. Voilà—GridStore!
The main feature of this paper is a detailed description of the decentralized controls rules that effect the nice global behavior of GridStore. Describing these rules was no easy task, so feel free to contact us if the paper doesn’t make sense.
GridStore
Our early research on high-density storage system suggested a natural tradeoff between storage density and throughput—the higher the density, the lower the throughput. Is there a way to get both?
The GridStore system combines puzzle-based movement and decentralized control to produce a high-density storage system that conforms to the plug-and-play paradigm. The system is built on the same hardware model as the Flexconveyor—a unit-sized conveyor segment that conveys in the four cardinal directions, has communications ports on all four sides, and has its own controller. Each conveyor is capable of talking to its four neighbors, and no others.
Control of the GridStore system is completely decentralized. At each time step, conveyors assess their current state (Unoccupied? Occupied? Occupied with moving item?), then enter a round of electronic negotiations with their neighbors to determine which direction each conveyor will convey. The result is the global behavior you see here:
Black items in the video have been requested by an external source, such as an order picking workstation or a shipping schedule. Blue items are returning to replenish the system. Each blue item has a target row, to which it travels and then awaits a request. Target rows match the home rows of departing items, thereby maintaining system balance.
Throughput in the GridStore system can be controlled by the number of rows and columns in the grid, by the number of empty cells k, and by the number of requested items (WIP), which we keep constant in a sort of “constant work-in-process” (CONWIP) system. Throughput goes up as the number of empty cells increases, and it also goes up as WIP increases. In ordinary storage systems subject to congestion, the marginal increase in throughput goes down as WIP increases; the opposite is true in GridStore, for low to medium levels of WIP.
![GridFlow throughput]()
As the number of active requests (WIP) increase, throughput increases non-linearly because (1) additional WIP tends to empty out the lower rows, clearing them for requested items and (2) requested items are more likely to form “slugs” which move together very efficiently. For very high levels of WIP (60+ in the plot), most items are requested and the system becomes “river-like.”
If you would like to learn more about the algorithms behind GridStore, please email me with the form below.