303, or transmit the image stream to a wireless device or package delivery system 105 via a wireless transceiver 304.

In one embodiment, upon drones 101 receiving instructions from package delivery system 105 as to the order and manner in delivering packages to the destination, such drones 101 communicate amongst each other via wireless transceiver 304. Such communication may involve the order of delivering packages (e.g., drone 101A delivers package A followed by drone 101C delivering package B followed by drone 101B delivering packages C and E), the success or failure in delivering such packages as well as visual images (discussed further below) of the pile of packages that resides at the destination after delivering the package.

In one embodiment, drones 101 communicate amongst each other using multi-channel collaboration with package delivery system 105 to ensure that the sequencing of the delivery of packages as well as piling information, including both captured images of the piled packages or instructions, can be shared with drones 101 that are responsible for delivering the packages at the destination.

Drone 101 may further include a visual recognition system 305 connected to image processing system 302. Visual recognition system 305 may include one or more processors configured to analyze captured images, such as the captured image of the package in cargo holder 204, and identify the dimensions and shape of the package in cargo holder 204 from the analyzed image. In one embodiment, visual recognition system 305 utilizes a function (e.g., cv2.findContours( ) function of OpenCV) to identify the dimensions and shape of the package in cargo holder 204 from the captured image of the package in cargo holder 204. In one embodiment, visual recognition system 305 utilizes various software tools to determine the dimensions and shape of the package in cargo holder 204 from the analyzed image, including, but not limited to, ImageJ, JMicro Vision, IC Measure, Digimizer, CMEIAS Image Tool, Image-Pro Plus 7, etc.

Furthermore, drone 101 includes a processor 306 connected to memory 303 for executing software instructions. Processor 306 may be any custom made or commercially available processor, a central processing unit, an auxiliary processor among several processors, a semiconductor-based microprocessor (in the form of a microchip or chip set) or generally any device for executing software instructions.

Additionally, drone 101 includes a data store 307 connected to processor 306 to store data. Data store 307 may include any volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, and the like)), nonvolatile memory elements (e.g., ROM, hard drive, tape, CDROM, and the like), and combinations thereof. Moreover, data store 307 may incorporate electronic, magnetic, optical, and/or other types of storage media.

Memory 303 may include any volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)), nonvolatile memory elements (e.g., ROM, hard drive, etc.), and combinations thereof. Moreover, memory 303 may incorporate electronic, magnetic, optical, and/or other types of storage media. It is noted that memory 303 may have a distributed architecture, where various components are situated remotely from one another but can be accessed by processor 306. The software in memory 303 may include one or more software programs, each of which includes an ordered listing of executable instructions for implementing logical functions. In the example of FIG. 3, the software in memory 303 includes a suitable operating system (O/S) 308 and programs 309. Operating system 308 essentially controls the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. Program 309 may include various applications, add-ons, etc. configured to assist package delivery system 105 in ensuring that packages are placed at the destination in a manner that prevents the collapse of such piled packages as discussed herein, including performing various aspects of the methods described herein.

In one embodiment, programs 309 include a program for calculating the center of gravity position of each package placed in cargo holder 204. In one embodiment, the center of gravity position of a package is determined by taking the sum of the average value of the weight/volume times the distance times the volume segment divided by the weight. As previously discussed, the weight is obtained from scale 206. In one embodiment, the volume is obtained from the dimensions (length, width and height) of the package, which are obtained from visual recognition system 305.

In one embodiment, the dimensions, shape, weight, and center of gravity position of a package (collectively referred to as the “package information”) is acquired by drone 101 from analyzing the package as discussed above. Such package information may be transmitted to package delivery system 105, such as via wireless transceiver 304.

Additionally, drone 101 further includes an attitude control system 310 connected to processor 306. In one embodiment, attitude control system 310 executes any necessary changes in heading, position, or velocity by varying the rotational speed of one or more rotors 311 of drone 101. Such changes may correspond to enabling drone 101 to place packages at the destination in a certain manner (e.g., place package #5 on the left-hand corner of package #2). Furthermore, such changes may enable drone 101 to rearrange the pile of packages to correspond to a particular arrangement as determined by package delivery system 105. In such an embodiment, drone 101 includes robotic arms 207 for rearranging the pile of packages to correspond to a particular arrangement as determined by package delivery system 105.

In one embodiment, the rotor speeds of each rotor 311 may be directly controlled by one or more motors 312 connected to attitude control system 310. For example, a multi-rotor drone 101 may include four, six, eight, or any other appropriate number of rotors 311. Adjusting the speed of one or more rotors 311 may control the height of drone 101, rotate drone 101 along multiple rotational axes or degrees of freedom, or propel drone 101 in any desired direction at variable speeds.

These and other features will be discussed in greater detail further below.

Referring now to FIG. 4, FIG. 4 is a diagram of the software components of package delivery system 105 used to ensure the stability in the arrangement of a pile of packages delivered by drones 101 in accordance with an embodiment of the present disclosure.

As shown in FIG. 4, package delivery system 105 includes a package identifier 401 configured to identify the package information for each package to be delivered by a drone 101 at a particular destination.

As previously discussed, drones 101 are configured to analyze each package to be delivered to a destination (e.g., home residence) to obtain package information, including the dimensions, shape, weight, and center of gravity position of the package. Such package information is transmitted to package identifier 401 of package delivery system 105. In one embodiment, such package information further includes the destination (e.g., location in warehouse, home residence) for the package to be delivered. In one embodiment, such a destination is associated with an identifier, which is used by package identifier 401 to determine which packages are to be delivered to which destination, including an expected day (and possibly time) of delivery. In one embodiment, such an identifier is provided to drone 101 by the service provider, who is responsible for sending the package to a customer location. In one embodiment, such delivery information is stored in a data structure (e.g., table). As a result, package identifier 401 is able to determine which packages are to be delivered at the same destination, including on the same day, by searching through such a data structure. In one embodiment, such a data structure is stored in the storage device of package delivery system 105.

In one embodiment, upon receipt of such information, package identifier 401 associates such package information to each package to be delivered to a particular destination within a certain period of time (e.g., same day). As a result, package identifier 401 determines the set of packages (e.g., five packages) to be delivered to the same destination (e.g., particular home residence) within a period of time (e.g., same day). In one embodiment, package identifier 401 stores such information, such as the package information for each package to be delivered at the same destination within a period of time (e.g., same day), in a data structure (e.g., table). In one embodiment, such a data structure is stored in a storage device of package delivery system 105.

Package delivery system 105 further includes a simulator 402 configured to perform different simulations of stacking the packages to be delivered at the same particular destination (e.g., particular home residence) by drones 101 within a duration of time, which may be user-designated, based on package information received from drones 101. Such simulations may involve various approaches to stacking the packages. For example, simulator 402 may perform simulations of piling the packages to be delivered at the same destination in a different order (e.g., package #4 is placed on the pile of packages prior to stacking package #5 on the pile of packages versus placing package #5 on the pile of packages prior to stacking package #4 on the pile of packages) and in a different manner (e.g., stacking package #2 on the left-hand corner of package #1 versus stacking package #2 on the right-hand corner of package #1, etc.). In one embodiment, simulator 402 utilizes various software tools, including, but not limited to, Simio®, FlexSim®, aPrirori®, SIMUL8®, Vensim®, ExtendSim®, etc.

Based on simulating the various approaches of stacking the packages to be delivered at the same destination, optimizing engine 403 (discussed further below) of package delivery system 105 determines the optimal arrangement of stacking the packages at the destination in a particular order and in particular manner (e.g., place package #6 on the top center of package #4) by drones 101 within a duration of time (e.g., within five hours) that maximizes the stability in the pile of packages (i.e., prevents the collapse of such piled packages). In one embodiment, the stability of the pile of packages is determined using progressive collapse analysis. In one embodiment, progressive collapse analysis is performed by simulator 402 using various software tools, including, but not limited to, Extreme Loading®. In one embodiment, such analysis involves basing a “collapse” on lateral displacement analysis, which involves engineering judgement-based predefined limits. For example, there are various predefined limits as to how far a first package placed on a second package can extend beyond the border of the second package without collapsing (falling down) based on the width of such first and second packages. In one embodiment, the particular way of stacking the packages that results in the highest score for stability (i.e., preventing the collapse of such piled packages within the predefined limits) corresponds to the optimal arrangement for the pile of packages.

In one embodiment, simulator 402 utilizes the finite element method to enforce equilibrium on each point of a pile of packages, where the dimensions and shapes of the simulated pile of packages correspond to the dimensions and shapes as provided in the package information for such packages. Particles of each of the piled packages are free to separate from one another, which is advantageous in the simulation of collapsing the piled packages. In one embodiment, the finite element method is performed using a three-dimensional finite particle model using Matlab®.

In one embodiment, in connection with simulating the various approaches of stacking the packages to be delivered at the same destination, simulator 402 determines how close the center of gravity position for each package is to the center of each package(s) upon which it resides (except for those residing on the ground). As previously discussed, the center of gravity position of a package is the point at which the weight of the package is concentrated. This is the center point from which the weight is evenly dispersed on all the sides. As a result, the center of gravity position determines exactly when the package will reach its tipping point and fall over.

In one embodiment, in each of the simulations performed by simulator 402, a line is drawn straight down from the center of gravity position of the package. The package is tilted while keeping the line pointed vertically down from the center of gravity position at all times. The line will allow simulator 402 to determine the moment the center of gravity passes past the base (bottom-center) of the package. This is the point at which the package has reached its tipping point and will fall over.

In one embodiment, optimizing engine 403 assigns a score to each simulated arrangement based on the stability of each arrangement. That is, optimizing engine 403 assigns a score to each simulated arrangement based on how far the center of gravity position for each package in the piled set of packages is to passing the base (bottom-center) of the package. The further away that the center of gravity position is from passing the base of the package, the less likely that package will fall over. The greater the number of packages where it is not likely for its center of gravity to pass the base of the package, the higher the score thereby indicating a greater stability in such an arrangement.

In one embodiment, the arrangement that has been assigned the highest score is selected as corresponding to the optimal arrangement (i.e., the arrangement of the pile of packages to occur when the packages are delivered at the destination). In order to implement such an arrangement of the pile of packages, such packages need to be delivered in a particular order (e.g., package #2 is to be delivered prior to package #3) and in particular manner (e.g., package #5 placed on the top middle of package #3). Such an order and manner is determined based on the simulation of the identified optimal arrangement. For example, the simulation of the optimal arrangement that was performed by simulator 402 may include the order in which the packages are delivered, including the manner in stacking such packages. For instance, the simulation may indicate that the largest package should be first delivered and form the base of the pile of packages. The simulation may further indicate the next package to be delivered and in what manner (e.g., placed on the center-right of the first package) it should be placed on the previously placed package and so forth. In such a manner, the optimal arrangement of the pile of packages may be perfected.

Package delivery system 105 further includes an instructing engine 404 configured to instruct drones 101 that are to deliver packages to the same destination within the duration of time, which may be user-designated, to deliver such packages in a particular order and in particular manner based on the optimal arrangement of stacking the packages as identified by optimizing engine 403. As previously discussed, in order to implement such an arrangement of the pile of packages, such packages need to be delivered in a particular order and in particular manner (e.g., package #5 placed on the top middle of package #3). In one embodiment, instructing engine 404 instructs drones 101 to deliver packages to the same destination within a duration of time in such a particular order and in such a particular manner in order to implement such an arrangement.

In one embodiment, for each of the drones 101 (with the exception of the first drone 101 to deliver a package to the destination) that is being utilized to deliver the packages to the destination, instructing engine 404 provides an image of the arrangement of the pile of packages that should exist at the destination prior to delivering the package(s) at the destination. Such an image is based on the simulation of the optimal arrangement of the pile of packages, in which such a simulation indicates the arrangement of the packages as each drone 101 drops off its package(s).

In one embodiment, for each of the drones 101 (with the exception of the first drone 101 to deliver a package to the destination) that is being utilized to deliver the packages to the destination, drone 101 captures an image of the current arrangement of the pile of packages, such as via camera 301, at the destination prior to delivering the package(s) at the destination. In one embodiment, such images are provided from drone 101 that previously dropped off a package at the destination.

In one embodiment, instructing engine 404 determines if the current arrangement of the pile of packages differs from the arrangement of the packages to be present at the time of delivering the package(s) at the destination. If there is a difference, then, in one embodiment, instructing engine 404 instructs drone 101 to rearrange the pile of packages, such as via robotic arms 207, to correspond to the arrangement of the packages to be present at the time of delivering the package(s) at the destination. In one embodiment, such rearrangement may include removing obstacles, keeping an uneven space empty, utilizing smaller packages to fill-in gaps between packages, utilizing large and bulky packages on the lower or bottom level of the stack of packages, changing an orientation of a package, etc.

As discussed above, in one embodiment, drones 101 are configured to capture images of the arrangement of the pile of packages at the destination after delivering the package(s) at the destination. Such information may be provided to instructing engine 404, which may later be transferred to the computing device 104 of the customer, such as the customer who received such packages at the destination. Such information may be provided to computing device 104 via various electronic means, including e-mail or text message. In one embodiment, the information provided to computing device 104 may include instructions for picking up which packages and in what order in order to prevent the collapse of the pile of packages. In one embodiment, such instructions may be augmented reality based guidance in which computer generated information enables the simulation of picking up the packages in a particular order and in a particular manner in order to prevent the collapse of the pile of packages. In one embodiment, such augmented reality based guidance is based on the simulation corresponding to the identified optimal arrangement for stacking the packages at the destination in which the order and manner for picking up the packages is in the opposite sequence of the order and manner in stacking the packages.

A further description of these and other features is provided below in connection with the discussion of the method for ensuring the stability in the arrangement of a pile of packages delivered by drones 101 at a destination.

Prior to the discussion of the method for ensuring the stability in the arrangement of a pile of packages delivered by drones 101 at a destination (e.g., location in a warehouse, location at a residence), a description of the hardware configuration of package delivery system 105 (FIG. 1) is provided below in connection with FIG. 5.

Referring now to FIG. 5, in conjunction with FIG. 1, FIG. 5 illustrates an embodiment of the present disclosure of the hardware configuration of package delivery system 105 which is representative of a hardware environment for practicing the present disclosure.

Various aspects of the present disclosure are described by narrative text, flowcharts, block diagrams of computer systems and/or block diagrams of the machine logic included in computer program product (CPP) embodiments. With respect to any flowcharts, depending upon the technology involved, the operations can be performed in a different order than what is shown in a given flowchart. For example, again depending upon the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, concurrently, or in a manner at least partially overlapping in time.

A computer program product embodiment (“CPP embodiment” or “CPP”) is a term used in the present disclosure to describe any set of one, or more, storage media (also called “mediums”) collectively included in a set of one, or more, storage devices that collectively include machine readable code corresponding to instructions and/or data for performing computer operations specified in a given CPP claim. A “storage device” is any tangible device that can retain and store instructions for use by a computer processor. Without limitation, the computer readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these mediums include: diskette, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as punch cards or pits/lands formed in a major surface of a disc) or any suitable combination of the foregoing. A computer readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through a wire, and/or other transmission media. As will be understood by those of skill in the art, data is typically moved at some occasional points in time during normal operations of a storage device, such as during access, de-fragmentation or garbage collection, but this does not render the storage device as transitory because the data is not transitory while it is stored.

Computing environment 500 contains an example of an environment for the execution of at least some of the computer code (stored in block 501) involved in performing the inventive methods, such as ensuring the stability in the arrangement of a pile of packages delivered by drones 101 at a destination. In addition to block 501, computing environment 500 includes, for example, package delivery system 105, network 103, such as a wide area network (WAN), end user device (EUD) 502, remote server 503, public cloud 504, and private cloud 505. In this embodiment, package delivery system 105 includes processor set 506 (including processing circuitry 507 and cache 508), communication fabric 509, volatile memory 510, persistent storage 511 (including operating system 512 and block 501, as identified above), peripheral device set 513 (including user interface (UI) device set 514, storage 515, and Internet of Things (IOT) sensor set 516), and network module 517. Remote server 503 includes remote database 518. Public cloud 504 includes gateway 519, cloud orchestration module 520, host physical machine set 521, virtual machine set 522, and container set 523.

Package delivery system 105 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer or any other form of computer or mobile device now known or to be developed in the future that is capable of running a program, accessing a network or querying a database, such as remote database 518. As is well understood in the art of computer technology, and depending upon the technology, performance of a computer-implemented method may be distributed among multiple computers and/or between multiple locations. On the other hand, in this presentation of computing environment 500, detailed discussion is focused on a single computer, specifically package delivery system 105, to keep the presentation as simple as possible. Package delivery system 105 may be located in a cloud, even though it is not shown in a cloud in FIG. 5. On the other hand, package delivery system 105 is not required to be in a cloud except to any extent as may be affirmatively indicated.

Processor set 506 includes one, or more, computer processors of any type now known or to be developed in the future. Processing circuitry 507 may be distributed over multiple packages, for example, multiple, coordinated integrated circuit chips. Processing circuitry 507 may implement multiple processor threads and/or multiple processor cores. Cache 508 is memory that is located in the processor chip package(s) and is typically used for data or code that should be available for rapid access by the threads or cores running on processor set 506. Cache memories are typically organized into multiple levels depending upon relative proximity to the processing circuitry. Alternatively, some, or all, of the cache for the processor set may be located “off chip.” In some computing environments, processor set 506 may be designed for working with qubits and performing quantum computing.

Computer readable program instructions are typically loaded onto package delivery system 105 to cause a series of operational steps to be performed by processor set 506 of package delivery system 105 and thereby effect a computer-implemented method, such that the instructions thus executed will instantiate the methods specified in flowcharts and/or narrative descriptions of computer-implemented methods included in this document (collectively referred to as “the inventive methods”). These computer readable program instructions are stored in various types of computer readable storage media, such as cache 508 and the other storage media discussed below. The program instructions, and associated data, are accessed by processor set 506 to control and direct performance of the inventive methods. In computing environment 500, at least some of the instructions for performing the inventive methods may be stored in block 501 in persistent storage 511.

Communication fabric 509 is the signal conduction paths that allow the various components of package delivery system 105 to communicate with each other. Typically, this fabric is made of switches and electrically conductive paths, such as the switches and electrically conductive paths that make up busses, bridges, physical input/output ports and the like. Other types of signal communication paths may be used, such as fiber optic communication paths and/or wireless communication paths.

Volatile memory 510 is any type of volatile memory now known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, the volatile memory is characterized by random access, but this is not required unless affirmatively indicated. In package delivery system 105, the volatile memory 510 is located in a single package and is internal to package delivery system 105, but, alternatively or additionally, the volatile memory may be distributed over multiple packages and/or located externally with respect to package delivery system 105.

Persistent Storage 511 is any form of non-volatile storage for computers that is now known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is being supplied to package delivery system 105 and/or directly to persistent storage 511. Persistent storage 511 may be a read only memory (ROM), but typically at least a portion of the persistent storage allows writing of data, deletion of data and re-writing of data. Some familiar forms of persistent storage include magnetic disks and solid state storage devices. Operating system 512 may take several forms, such as various known proprietary operating systems or open source Portable Operating System Interface type operating systems that employ a kernel. The code included in block 501 typically includes at least some of the computer code involved in performing the inventive methods.

Peripheral device set 513 includes the set of peripheral devices of package delivery system 105. Data communication connections between the peripheral devices and the other components of package delivery system 105 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insertion type connections (for example, secure digital (SD) card), connections made though local area communication networks and even connections made through wide area networks such as the internet. In various embodiments, UI device set 514 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smart watches), keyboard, mouse, printer, touchpad, game controllers, and haptic devices. Storage 515 is external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 515 may be persistent and/or volatile. In some embodiments, storage 515 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where package delivery system 105 is required to have a large amount of storage (for example, where package delivery system 105 locally stores and manages a large database) then this storage may be provided by peripheral storage devices designed for storing very large amounts of data, such as a storage area network (SAN) that is shared by multiple, geographically distributed computers. IoT sensor set 516 is made up of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

Network module 517 is the collection of computer software, hardware, and firmware that allows package delivery system 105 to communicate with other computers through WAN 103. Network module 517 may include hardware, such as modems or Wi-Fi signal transceivers, software for packetizing and/or de-packetizing data for communication network transmission, and/or web browser software for communicating data over the internet. In some embodiments, network control functions and network forwarding functions of network module 517 are performed on the same physical hardware device. In other embodiments (for example, embodiments that utilize software-defined networking (SDN)), the control functions and the forwarding functions of network module 517 are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer readable program instructions for performing the inventive methods can typically be downloaded to package delivery system 105 from an external computer or external storage device through a network adapter card or network interface included in network module 517.

WAN 103 is any wide area network (for example, the internet) capable of communicating computer data over non-local distances by any technology for communicating computer data, now known or to be developed in the future. In some embodiments, the WAN may be replaced and/or supplemented by local area networks (LANs) designed to communicate data between devices located in a local area, such as a Wi-Fi network. The WAN and/or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and edge servers.

End user device (EUD) 502 is any computer system that is used and controlled by an end user (for example, a customer of an enterprise that operates package delivery system 105), and may take any of the forms discussed above in connection with package delivery system 105. EUD 502 typically receives helpful and useful data from the operations of package delivery system 105. For example, in a hypothetical case where package delivery system 105 is designed to provide a recommendation to an end user, this recommendation would typically be communicated from network module 517 of package delivery system 105 through WAN 103 to EUD 502. In this way, EUD 502 can display, or otherwise present, the recommendation to an end user. In some embodiments, EUD 502 may be a client device, such as thin client, heavy client, mainframe computer, desktop computer and so on.

Remote server 503 is any computer system that serves at least some data and/or functionality to package delivery system 105. Remote server 503 may be controlled and used by the same entity that operates package delivery system 105. Remote server 503 represents the machine(s) that collect and store helpful and useful data for use by other computers, such as package delivery system 105. For example, in a hypothetical case where package delivery system 105 is designed and programmed to provide a recommendation based on historical data, then this historical data may be provided to package delivery system 105 from remote database 518 of remote server 503.

Public cloud 504 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and/or other computer capabilities, especially data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages sharing of resources to achieve coherence and economies of scale. The direct and active management of the computing resources of public cloud 504 is performed by the computer hardware and/or software of cloud orchestration module 520. The computing resources provided by public cloud 504 are typically implemented by virtual computing environments that run on various computers making up the computers of host physical machine set 521, which is the universe of physical computers in and/or available to public cloud 504. The virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 522 and/or containers from container set 523. It is understood that these VCEs may be stored as images and may be transferred among and between the various physical machine hosts, either as images or after instantiation of the VCE. Cloud orchestration module 520 manages the transfer and storage of images, deploys new instantiations of VCEs and manages active instantiations of VCE deployments. Gateway 519 is the collection of computer software, hardware, and firmware that allows public cloud 504 to communicate through WAN 103.

Some further explanation of virtualized computing environments (VCEs) will now be provided. VCEs can be stored as “images.” A new active instance of the VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating-system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances, called containers. These isolated user-space instances typically behave as real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can utilize all resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and devices assigned to the container, a feature which is known as containerization.

Private cloud 505 is similar to public cloud 504, except that the computing resources are only available for use by a single enterprise. While private cloud 505 is depicted as being in communication with WAN 103 in other embodiments a private cloud may be disconnected from the internet entirely and only accessible through a local/private network. A hybrid cloud is a composition of multiple clouds of different types (for example, private, community or public cloud types), often respectively implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technology that enables orchestration, management, and/or data/application portability between the multiple constituent clouds. In this embodiment, public cloud 504 and private cloud 505 are both part of a larger hybrid cloud.

Block 501 further includes the software components discussed above in connection with FIGS. 2-4 to ensure the stability in the arrangement of a pile of packages delivered by drones 101 at a destination. In one embodiment, such components may be implemented in hardware. The functions discussed above performed by such components are not generic computer functions. As a result, package delivery system 105 is a particular machine that is the result of implementing specific, non-generic computer functions.

In one embodiment, the functionality of such software components of package delivery system 105, including the functionality for ensuring the stability in the arrangement of a pile of packages delivered by drones 101 at a destination may be embodied in an application specific integrated circuit.

As stated above, drones can be used to transport medicinal products, such as blood products, vaccines, pharmaceuticals, and medical samples. For example, drones may be used to transport medicinal products into remote or otherwise inaccessible regions. Furthermore, drones have been proposed as a solution for rapidly delivering prepared foods, such as pizzas, tacos, and frozen beverages. Additionally, drones are starting to be used to deliver packages. As the use of drones for delivering packages to consumers from online stores, brick & mortar stores, restaurants, etc. becomes more ubiquitous, the issue of having packages stacked in an unstable manner may become an issue. For example, if multiple drones are piling the packages at a particular destination (e.g., porch of a customer), such drones should ensure the stability of the piled or stacked packages. If the packages are not stacked in a stable manner, then the piled packages may collapse resulting in damage to the contents (e.g., products) of such packages. Furthermore, when the piled packages collapse, such collapsed packages run the risk of being mishandled by the customer. Unfortunately, there is not currently a means for ensuring that such packages delivered by the drones are piled in a manner that prevents the collapse of such piled packages.

The embodiments of the present disclosure provide a means for enabling drones to deliver and stack/pile packages in a stable manner whereby the collapse of such piled packages is prevented as discussed below in connection with FIGS. 6-7. FIG. 6 is a flowchart of a method for ensuring the stability in the arrangement of a pile of packages delivered by drones (e.g., drones 101) at a destination. FIG. 7 is a flowchart of a method for having each drone ensure the stability in the arrangement of the piled packages at the destination.

As stated above, FIG. 6 is a flowchart of a method 600 for ensuring the stability in the arrangement of a pile of packages delivered by drones (e.g., drones 101) at a destination in accordance with an embodiment of the present disclosure.

Referring to FIG. 6, in conjunction with FIGS. 1-5, in operation 601, drones 101 analyze each package to be delivered to a destination to obtain package information, including the dimensions, shape, weight, and center of gravity position of the package.

As discussed above, drone 101 includes a visual recognition system 305, which analyzes the captured images, such as the captured image of the package in cargo holder 204, and identifies the dimensions and shape of the package in cargo holder 204 from the analyzed image. In one embodiment, visual recognition system 305 utilizes a function (e.g., cv2.findContours( ) function of OpenCV) to identify the dimensions and shape of the package in cargo holder 204 from the captured image of the package in cargo holder 204. In one embodiment, visual recognition system 305 utilizes various software tools to determine the dimensions and shape of the package in cargo holder 204 from the analyzed image, including, but not limited to, ImageJ, JMicroVision, IC Measure, Digimizer, CMEIAS Image Tool, Image-Pro Plus 7, etc.

Furthermore, in one embodiment, cargo holder 204 of drone 101 utilizes a scale 206 integrated with cargo holder 204 that is used to determine the weight of a package(s) placed in cargo holder 204. For example, scale 206 may correspond to a portable mini digital scale (e.g., Superior I-2000 portable digital scale, Wewdigi® digital scale, TOP2KG, etc.). In one embodiment, the weight is obtained for each package as each package is placed on cargo holder 204. In situations in which a package is already placed on cargo holder 204, when a new package is placed on cargo holder 204, the weight of the pre-existing packages on cargo holder 204 is then subtracted from the total weight of the packages on cargo holder 204 in order to obtain the weight of the newly added package on cargo holder 204. In one embodiment, the weight obtained from scale 206 for each package placed on cargo holder 204 may be transmitted to package delivery system 105.

Additionally, in one embodiment, programs 309 of drone 101 include a program for calculating the center of gravity position of each package placed in cargo holder 204. In one embodiment, the center of gravity position of a package is determined by taking the sum of the average value of the weight/volume times the distance times the volume segment divided by the weight. As previously discussed, the weight is obtained from scale 206. In one embodiment, the volume is obtained from the dimensions (length, width and height) of the package, which are obtained from visual recognition system 305.

In one embodiment, the dimensions, shape, weight, and center of gravity position of a package (collectively referred to as the “package information”) is acquired by drone 101 from analyzing the package as discussed above. Such package information may be transmitted to package delivery system 105, such as via wireless transceiver 304.

In operation 602, package identifier 401 of package delivery system 105 receives the package information from multiple drones 101 delivering packages to a same destination (e.g., same residence location) within a duration of time, which may be user-designated.

As previously discussed, drones 101 are configured to analyze each package to be delivered to a destination (e.g., home residence) to obtain package information, including the dimensions, shape, weight, and center of gravity position of the package. Such package information is transmitted to package identifier 401 of package delivery system 105. In one embodiment, such package information further includes the destination (e.g., location in warehouse, home residence) for the package to be delivered. In one embodiment, such a destination is associated with an identifier, which is used by package identifier 401 to determine which packages are to be delivered to which destination, including an expected day (and possibly time) of delivery. In one embodiment, such an identifier is provided to drone 101 by the service provider, who is responsible for sending the package to a customer location. In one embodiment, such delivery information is stored in a data structure (e.g., table). As a result, package identifier 401 is able to determine which packages are to be delivered at the same destination, including on the same day, by searching through such a data structure. In one embodiment, such a data structure is stored in the storage device (e.g., storage device 511, 515) of package delivery system 105.

In one embodiment, upon receipt of such information, package identifier 401 associates such package information to each package to be delivered to a particular destination within a certain period of time (e.g., same day). As a result, package identifier 401 determines the set of packages (e.g., five packages) to be delivered to the same destination (e.g., particular home residence) within a period of time (e.g., same day). In one embodiment, package identifier 401 stores such information, such as the package information for each package to be delivered at the same destination within a period of time (e.g., same day), in a data structure (e.g., table). In one embodiment, such a data structure is stored in a storage device (e.g., storage device 511, 515) of package delivery system 105.

In operation 603, simulator 402 of package delivery system 105 performs simulations of stacking packages using different approaches based on the received package information.

As discussed above, in one embodiment, simulator 402 performs different simulations of stacking the packages to be delivered at the same particular destination (e.g., particular home residence) by drones 101 within a duration of time, which may be user-designated, based on package information received from drones 101. Such simulations may involve various approaches to stacking the packages. For example, simulator 402 may perform simulations of piling the packages to be delivered at the same destination in a different order (e.g., package #4 is placed on the pile of packages prior to stacking package #5 on the pile of packages versus placing package #5 on the pile of packages prior to stacking package #4 on the pile of packages) and in a different manner (e.g., stacking package #2 on the left-hand corner of package #1 versus stacking package #2 on the right-hand corner of package #1, etc.). In one embodiment, simulator 402 utilizes various software tools, including, but not limited to, Simio®, FlexSim®, aPriori®, SIMUL8®, Vensim®, ExtendSim®, etc.

Based on simulating the various approaches of stacking the packages to be delivered at the same destination, optimizing engine 403 of package delivery system 105 determines the optimal arrangement of stacking the packages at the destination in a particular order and in particular manner (e.g., place package #6 on the top center of package #4) by drones 101 within a duration of time (e.g., within five hours) that maximizes the stability in the pile of packages (i.e., prevents the collapse of such piled packages). In one embodiment, the stability of the pile of packages is determined using progressive collapse analysis. In one embodiment, progressive collapse analysis is performed by simulator 402 using various software tools, including, but not limited to, Extreme Loading®. In one embodiment, such analysis involves basing a “collapse” on lateral displacement analysis, which involves engineering judgement-based predefined limits. For example, there are various predefined limits as to how far a first package placed on a second package can extend beyond the border of the second package without collapsing (falling down) based on the width of such first and second packages. In one embodiment, the particular way of stacking the packages that results in the highest score for stability (i.e., preventing the collapse of such piled packages within the predefined limits) corresponds to the optimal arrangement for the pile of packages.

In one embodiment, simulator 402 utilizes the finite element method to enforce equilibrium on each point of a pile of packages, where the dimensions and shapes of the simulated pile of packages correspond to the dimensions and shapes as provided in the package information for such packages. Particles of each of the piled packages are free to separate from one another, which is advantageous in the simulation of collapsing the piled packages. In one embodiment, the finite element method is performed using a three-dimensional finite particle model using Matlab®.

In one embodiment, in connection with simulating the various approaches of stacking the packages to be delivered at the same destination, simulator 402 determines how close the center of gravity position for each package is to the center of each package(s) upon which it resides (except for those residing on the ground). As previously discussed, the center of gravity position of a package is the point at which the weight of the package is concentrated. This is the center point from which the weight is evenly dispersed on all the sides. As a result, the center of gravity position determines exactly when the package will reach its tipping point and fall over.

In one embodiment, in each of the simulations performed by simulator 402, a line is drawn straight down from the center of gravity position of the package. The package is tilted while keeping the line pointed vertically down from the center of gravity position at all times. The line will allow simulator 402 to determine the moment the center of gravity passes past the base of the package. This is the point at which the package has reached its tipping point and will fall over.

In operation 604, optimizing engine 403 of package delivery system 105 identifies the optimal arrangement of stacking the packages in a particular order and in a particular manner by drones 101 within the duration of time that maximizes the stability in the resulting arrangement of the pile of packages based on the simulations of operation 603.

As discussed above, in one embodiment, optimizing engine 403 assigns a score to each simulated arrangement based on the stability of each arrangement. That is, optimizing engine 403 assigns a score to each simulated arrangement based on how far the center of gravity position for each package in the piled set of packages is to passing the base (bottom-center) of the package. The further away that the center of gravity position is from passing the base of the package, the less likely that package will fall over. The greater the number of packages where it is not likely for its center of gravity to pass the base of the package, the higher the score thereby indicating a greater stability in such an arrangement.

In one embodiment, the arrangement that has been assigned the highest score is selected as corresponding to the optimal arrangement (i.e., the arrangement of the pile of packages to occur when the packages are delivered at the destination). In order to implement such an arrangement of the pile of packages, such packages need to be delivered in a particular order (e.g., package #2 is to be delivered prior to package #3) and in particular manner (e.g., package #5 placed on the top middle of package #3). Such an order and manner is determined based on the simulation of the identified optimal arrangement. For example, the simulation of the optimal arrangement that was performed by simulator 402 may include the order in which the packages are delivered, including the manner in stacking such packages. For instance, the simulation may indicate that the largest package should be first delivered and form the base of the pile of packages. The simulation may further indicate the next package to be delivered and in what manner (e.g., placed on the center-right of the first package) it should be placed on the previously placed package and so forth. In such a manner, the optimal arrangement of the pile of packages may be perfected.

In operation 605, instructing engine 404 of package delivery system 105 instructs drones 101 to deliver packages to the same destination within the duration of time (e.g., five hours) in a particular order and in a particular manner based on the identified optimal arrangement of stacking the packages.

As previously discussed, in order to implement such an arrangement of the pile of packages, such packages need to be delivered in a particular order and in particular manner (e.g., package #5 placed on the top middle of package #3). In one embodiment, instructing engine 404 instructs drones 101 to deliver packages to the same destination within a duration of time in such a particular order and in such a particular manner in order to implement such an arrangement.

A further discussion regarding drones