Multi-Drone Orchestration for Warehouse Stocktaking

By Aravind Nair, Kumar Shailendra

Stocktaking is an integral and routine process carried out at every warehouse facility to reconcile the inventory. The counting activity is carried out on the behest of a WMS (Warehouse Management Solution) user. The counting process is usually carried out by personnel with handheld scanning devices or by counting the boxes on a pallet or bay area. The frequency of performing this operation varies within the industry and is time-consuming. Currently, even with the use of digital handheld devices, the required human effort is high, as a person must physically locate the shelf, identify the pallet to carry out the counting for, and then perform the scan or count the boxes present. Once the counting is completed, the data is captured and then reconciled with a WMS and/or an ERP system.

This operation will lead to downtimes at the warehouse, which, in turn, affects the business, causing delays in servicing orders. The manual process is error-prone and cannot be audited later.

A drone-based automated stocktaking solution addresses this problem. The use of robotic systems, like drones and AMRs (autonomous mobile robots), collectively called agents, with onboard imaging and processing capabilities, allows us to that automate routine processes like stocktaking. Images taken during stocktake are stored in a central database. These images can be used to audit the process later.

Solution architecture

The key components that constitute the stocktaking solutions are:

1. A client application (a standalone UI/UX web app to create user requests)
2. A Process orchestration layer
3. The Application server to process the solution specific algorithm
4. The agent system (Edge computation on the agent).

Each of these components has a wide range of functionality and challenges to address.

Solution Architecture

User process flowchart

The flow of the solution is as follows:

• The application is used by a warehouse manager, for example, to create a stocktaking request in the system. The user then chooses the location or aisle at which the stocktaking operation will occur and then schedules it. The in-built task scheduler will trigger the task request before the scheduled time.
• The triggered task is passed to the process orchestration layer, which parses the data and invokes specific sub-modules to fetch additional information, like location information, optimal paths for navigation, drone identification, task-related information, etc. The updated information bundle is then packaged and passed on to the identified drone/agent system.
• The agent uses the provided information like local map, localization measures to carry out navigation autonomously to reach the target aisle location. The agent will employ its own capabilities, like obstacle detection and collision avoidance measures, to address any dynamic obstacles. At the target aisle, the drone enters the aisle, identifies the pallet to scan, and collects the data. The process is repeated until all the specified pallets are scanned. On completion of the scanning and image capturing operation, the drone initiates data transfer from its onboard storage to a remote file server.

The application server receives a notification on newly available data and subsequently processes the captured data. After processing is complete (including the product information and stock count on each pallet) a report is generated based on a fiducial format, and passed back to the user application, where it is formatted and made available to the user.

Orchestration using microservices

The process orchestration component must fulfill a wide variety of functional requirements and thus is a culmination of several individual sub-components. We need this system to be modular, efficient, scalable, and decentralized (to ease development cycles and avoid dependencies on specific standards/technology stacks).

When we identify the key functionalities that the process orchestration component carries out and divide them into individual sub-services, we can design it as a set of microservices. Let’s have a look at the requirements and functionalities expected of this system.

• Handling versatility in user applications: The user input can vary depending on whether the user application is a custom web application, which we have developed as part of the solution, or a Warehouse Management system (WMS) solution provided by the likes of SAP or Blue Yonder. The system should be capable enough to handle such versatility, utilizing smart endpoints, which can easily be exposed for efficient external API use.
• Need for Evolutionary Design: Indoor navigations rely on custom maps for navigation (unlike outdoor maps, which use GPS-based navigation systems). These maps are of several types and can be generated using different techniques. This field is highly evolving; hence, it is imperative to use the most optimal one suitable for our use case. Future upgrades can be in the form of algorithms used, the approach used to store the maps, the implementation methodologies, or the technical stack used for its implementation.
• Optimized agent selection: One of the key roles to be performed by this orchestrator is the identification of a suitable drone/agent from the registry (list of registered drones). Factors that influence this decision are the availability status, battery health, proximity of the drone to the target location, etc. So, we need to identify an optimal agent upon considering all these factors.
• Status Monitoring: System monitoring allows us to log, track, change status, and use the data for further analytics. In our scenario, we need to actively monitor the health and hardware parameters of the drone, in close to real-time. The monitored parameters of the drone can be used to keep track of the drone's health, its performance and to carry out any control actions based on them. Apart from the drone parameter, the system also needs to monitor the task-related information to keep track of the task progress. This information can be used to provide close to real-time updates to the end-user via the UI application.
• Control Action System: The responsibility of this module is to carry out certain pre-defined control actions when one or more monitored parameters cross thresholds or meet certain criteria. The drone itself has an onboard, autopilot firmware, which can handle emergency scenarios. But it is equally important for the solution to be capable enough to handle these scenarios through efficient contingency plans. For example, consider a drone that is in flight and carrying out a data-capturing operation in an aisle. If the drone is low on battery (or reaches a pre-defined threshold voltage), it should update the server about task-related information (like last known location, the last pallet scanned, etc.) and then carry out the ‘battery low’ contingency plan — flying to the nearest charging station, or home location or landing at a safe spot. The server then carries out the process of identifying a new drone to ‘resume’ the task from the last scanned location, using the details shared from the last flight. Another example is that of monitoring the air traffic of drones within a warehouse. This is useful when you have many drones deployed at the same time to carry out different tasks simultaneously and as complicated as it requires active monitoring and path planning to ensure safe navigation of the drones.
• Data Management: The upload of solution data must be managed from an edge device and ensure its validity. The drone has onboard capabilities to store the captured data while it is in operation. Upon completion of the task, it must transfer the data to a remote file server. This process should be monitored and verified to ensure that all data has been transferred successfully. It is also important to inform the next participant about the availability of a new batch of data for further processing.

An architecture that addresses all these functionalities and requirements is shown below (Figure — Process Orchestration Layer / AOS Architecture). The system is named ‘Agent Operation System’ (AOS), which was created using microservice design patterns. Each functionality is a microservice that follows the core attributes of the microservice architecture so as to enable:

1. Independent components that can be easily upgraded and replaced to implement each function. This also allows us to ensure CI/CD on these components. For example, if a customer wants us to build another imaging solution like crowd detection inside of a warehouse, this structure allows us to simply plugin that new module and its related dependencies to the existing architecture.
2. Smart endpoints to ensure plug-and-play to build customizable solutions depending on customer requirements. In this solution, we use standard protocols, like REST APIs, for carrying out communication between different modules through a message broker.
3. Efficient resource utilization through optimal agent recruitment, best-path calculation, based on traffic monitoring, proper task and agent tracking, and efficient management of workflow.
4. Ease of configuration in terms of adding more drones/agents, making changes to warehouse layouts, generation, and mapping of predefined markers, etc.
5. A reusable architecture, which can handle any form of agents — drones, AMRs, AGVs, etc., and still carry out the process with as few changes as possible.

Process Orchestration Layer / AOS Architecture

This architecture is a lot closer to what the solution needs and captures all the key expectations that we discussed before. The boundaries of these services are derived from the expectations & organized around the business requirements.

Technical Challenges

Communication mechanisms are mostly asynchronous in nature and use message brokers to carry out the message transmission. We use both synchronous communication (request-response) as well as asynchronous communication (notifications, event alerts, etc.) mechanisms. The mechanisms used by each microservice are heavily dependent on the workflow. For example, communications between an existing web application and one of the microservice would be a REST API call which is synchronous in nature. At the same time, communications between services can be event notifications that use message brokers like RabbitMQ and are carried out using JSON files. It is important to identify the trade-offs between efficiency in terms of resource utilization and time.

Another challenge to address is in handling multiple drones. Recruiting a suitable drone/agent for the job is imperative to successfully execute the task. We already talked about a few factors influencing this decision. Optimization techniques, based on the status messages, must be used to recruit the agent. If the time to complete the job is greater than the expected flight time of the drone, then multiple drones may be recruited. The task at hand needs to be efficiently divided and optimum paths charted so that ’n’ identified drones can carry it out efficiently. Of course, additional factors will need to be considered according to the priority level of the task, number of pending tasks, availability of drones, etc.

Key factors that are required for every robotic system to carry out navigation successfully are maps/layouts, positioning, and localization. In the solution, it’s the job of the AOS system to provide the drone with the first two: layout and positioning information. We achieved this by efficiently storing the warehouse layout and using fiducial markers as positioning elements within the layout. The relationship established between these markers is used to compute an optimal path for navigation. When the user creates a task for a specific location (a zone or an aisle), the microservice responsible for path calculation takes the starting position of the identified drone and computes an efficient path to the target location, while considering additional factors like air traffic. The ability of the AOS system to keep track of drones in-flight while assigning new tasks (with paths) to drones is one of the standout features of this system.

The key differentiator in this system is that each of these services can be operated, updated, upgraded, scaled, and deployed individually, without really affecting the working of the overall workflow. The workflow is orchestrated and enables each of these services to contribute efficiently to carry out the solution. Microservice-based architecture makes this possible.

Conclusion

Adoption of a microservice-based architecture for our robotics system offers many benefits — especially when we constantly adapt and improve the components in the solution. The ability to keep these components loosely coupled and technology-independent while, at the same time, making them work together in an orchestrated manner outweighs the challenges that come along with this system. It also allows us to make the solution more adaptable to new technology frameworks, and incorporate changes required to implement new use cases.