Papers
Topics
Authors
Recent
Search
2000 character limit reached

Autonomous Multi-Package Drone Delivery

Updated 9 July 2026
  • The paper demonstrates a proof-of-concept prototype combining graph-based route planning with a lightweight multi-level payload hanger to deliver multiple packages in a structured urban skyway network.
  • It employs a nearest-neighbor (NDF) heuristic that selects rooftop nodes along geofenced corridors, ensuring safe altitude margins and reduced return-to-depot cycles.
  • The approach integrates global routing with precise local control via external localization, addressing energy efficiency through dynamic payload reduction after each delivery.

Autonomous multi-package drone delivery in urban airspace is a last-mile aerial logistics problem in which a single drone departs from a depot, visits multiple delivery locations in one continuous trip, and returns to the source while remaining constrained to a structured “skyway network” of rooftop-to-rooftop aerial corridors. In "Autonomous Delivery of Multiple Packages Using Single Drone in Urban Airspace," the problem is instantiated as a proof-of-concept prototype that combines graph-based route planning, a lightweight multi-level payload hanger, external localization, and altitude-controlled contact release in an indoor 3D model of Sydney’s central business district (CBD) (Lee et al., 2022). The work is motivated by recent increases in drone payload capability and by the prospect of reducing cost per delivery, total air traffic, and return-to-depot cycles without abandoning urban constraints such as restricted zones, line-of-sight flight policies, and short battery ranges.

1. Urban skyway delivery as a constrained graph problem

The central abstraction is the “skyway network,” defined as a set of directed or undirected aerial segments connecting nodes that are safe take-off and landing stations, typically on building rooftops. The drone does not free-fly arbitrarily through urban space. Instead, it remains on predefined skyway segments, operates within altitude layers, and follows rooftop-to-rooftop routing shaped by geofenced corridors and urban separation requirements. In the prototype, the skyway network is treated as a graph over a 3D model of Sydney CBD, and the delivery route is realized as a sequence of edges within that graph (Lee et al., 2022).

This formulation is significant because it recasts urban aerial delivery as a structured routing problem rather than an unconstrained waypoint-following task. A common misconception is that the demonstration addresses generic point-to-point drone delivery in dense cities. It does not. The operative problem is narrower and more disciplined: a single vehicle, multiple packages, rooftop nodes, and flight constrained to vetted corridors. This suggests a closer affinity to graph-constrained vehicle routing than to unconstrained residential doorstep delivery.

The work also makes explicit the operational pressures that justify this problem variant. If a drone can carry multiple packages in one sortie, then the number of return-to-depot cycles can decrease. A plausible implication is that, in corridor-managed airspace, this may also reduce deconfliction burden relative to repeated single-package flights, provided the route remains feasible under payload and energy limits.

2. Physical system architecture and payload handling

The hardware platform is a Crazyflie 2.1 nano-quadcopter from Bitcraze, selected for indoor safety and robustness. Because the platform can carry only very light payloads, the demonstration uses three lightweight packages attached with a custom hanging mechanism rather than a heavier active gripper or electromagnetic release system. External absolute positioning is supplied by one HTC Vive base station (Lighthouse), while Crazyflie’s standard onboard flight controller and control stack execute high-level waypoint commands derived from the route planner (Lee et al., 2022).

The payload subsystem is a multi-level hanging string mechanism. A string forms a ring around the drone’s sides to preserve stability, and tape wraps at three vertical levels create a ladder-like hanger in which each level holds a hooked clip-style payload frame. The design directly addresses a small-drone payload constraint: it avoids the mass overhead of electromagnets while preserving a deterministic release order.

Release is achieved by a contact-release maneuver. During cruise, the drone stays above rooftop height by more than the total hanging length so that no payload touches the roof unintentionally. At a delivery node, it descends until the target package just touches the rooftop, and a slight rebound detaches the hook. The stacking order is intentionally reversed relative to visit order: the farthest destination’s package is hung at the top level so it is released last, while lower packages corresponding to nearer destinations are released first. This coupling between physical hanger geometry and route sequence is one of the paper’s most concrete system-level contributions.

Localization and navigation are correspondingly divided into a global and local layer. Global planning computes a route over the skyway graph; local control uses Vive-based position feedback to follow waypoints, maintain rooftop clearance, and execute the descent–touch–rebound release action. No live UTM service is integrated. Geofencing and separation are instead enforced implicitly by constraining motion to skyway segments in the indoor environment.

3. Nearest Destination First as routing and scheduling policy

Route planning is based on Nearest Destination First (NDF), a greedy nearest-neighbor heuristic. Starting at the depot, the drone iteratively selects the closest unserved destination along the skyway network, flies there, delivers the corresponding package, and repeats until all packages are served, after which it returns to the source (Lee et al., 2022). In graph terms, shortest-path distances are precomputed or evaluated between candidate nodes, and each step appends the shortest path from the current node to the selected next destination.

The associated planning logic can be summarized as follows. Let G=(V,E)G=(V,E) be the skyway graph, let sVs\in V be the depot, and let DVD\subseteq V be the delivery set. Beginning at ss, the planner repeatedly chooses

i=argminiUnvisitedsp(current,i),i^*=\arg\min_{i\in \text{Unvisited}} sp(\text{current},i),

where sp(u,v)sp(u,v) is the shortest-path distance over GG. The selected shortest path is appended to the route, the package for ii^* is scheduled for release on arrival, and the process continues until the route is closed by a return path to ss.

The method is computationally lightweight. If Dijkstra is run once per iteration from the current node, the time complexity is O(D(ElogV))O(|D|\cdot(|E|\log |V|)) for sparse graphs. If all-pairs shortest paths are precomputed over sVs\in V0, nearest-node selection becomes sVs\in V1 per step and total selection becomes sVs\in V2. The space cost depends on shortest-path storage and can reach sVs\in V3 if fully cached.

NDF is not presented as an optimal solver. The paper explicitly situates it as the standard nearest-neighbor heuristic from the traveling salesman problem and, in vehicle-routing terms, as a simple constructive policy for a single route with multiple deliveries. A common misunderstanding would be to read the work as establishing optimal urban multi-stop routing. It does not. The design choice is instead to demonstrate an end-to-end system with a fast, simple, and physically compatible heuristic. This simplicity is reinforced by the fact that NDF also determines the physical stacking order of packages through reversal of visit order.

4. Mathematical formulation, energy model, and feasibility constraints

The delivery problem is formalized on a skyway graph sVs\in V4 with depot sVs\in V5, delivery set sVs\in V6, edge distances sVs\in V7, travel speed sVs\in V8, service times sVs\in V9, payload weights DVD\subseteq V0, payload capacity DVD\subseteq V1, and battery/energy limit DVD\subseteq V2. A route is a sequence

DVD\subseteq V3

that visits all nodes in DVD\subseteq V4 exactly once, either directly as edges or through shortest-path concatenations on DVD\subseteq V5 (Lee et al., 2022).

Travel time on an edge is modeled by

DVD\subseteq V6

An example makespan objective is

DVD\subseteq V7

Payload feasibility at departure is

DVD\subseteq V8

After each delivery, the carried mass decreases, so if DVD\subseteq V9 is the carried mass on segment ss0, then delivering at node ss1 induces the update ss2 whenever ss3.

The paper further introduces a linear payload-dependent energy model consistent with the narrative that energy scales approximately linearly with payload weight:

ss4

with constraint

ss5

Here ss6 is the average mass carried on segment ss7, ss8 is the baseline per-distance energy coefficient, and ss9 scales the payload-dependent term. The associated state-of-charge recursion is

i=argminiUnvisitedsp(current,i),i^*=\arg\min_{i\in \text{Unvisited}} sp(\text{current},i),0

Path feasibility requires that consecutive route nodes lie on the skyway graph or on shortest paths within it, while respecting altitude limits and geofenced corridors.

These formulations matter for two reasons. First, they tie the physical act of dropping packages to route feasibility through decreasing carried mass. Second, they clarify that multi-package delivery is not just a path-planning problem but a coupled routing–payload–energy problem. The prototype itself does not report calibrated energy parameters, but it explicitly uses the qualitative fact that energy use decreases after each drop because the payload mass becomes smaller.

5. Indoor Sydney CBD testbed and demonstrated behavior

The demonstration is carried out in an indoor testbed equipped with one HTC Vive base station for precise 3D localization and a detailed 3D model of Sydney’s CBD representing rooftops and building volumes. Rooftops are used as graph nodes, and safe aerial corridors between rooftops are used as edges. Building heights matter operationally because the drone must maintain altitude above roof level plus the hanging string length to avoid incidental contact (Lee et al., 2022).

Execution proceeds as an end-to-end chain: map, graph, route, flight, and contact-release. The drone carries three packages, follows the NDF-selected sequence, descends at each destination for rooftop contact release, and returns to the source after the final drop. Collision avoidance is not implemented as free-flight obstacle negotiation; it is achieved by geofenced corridors in the skyway graph and altitude margins, so the vehicle adheres to predefined routes rather than navigating around obstacles ad hoc.

The evaluation is qualitative rather than benchmark-oriented. The paper does not report numerical values for total mission time, path length, localization accuracy, or comparative performance against alternative heuristics. What is demonstrated is feasibility: three packages can be transported and delivered in one trip over an urban-like rooftop network using a very small platform and a lightweight release mechanism. Another common misconception is therefore that the paper provides a quantitative routing comparison. It does not; the experimental contribution is a physical proof of concept.

This qualitative scope should not be mistaken for lack of technical content. The prototype validates several practical details that are often omitted in abstract routing models: altitude margins must account for the full hanging length; release order must be coordinated with mechanical stacking order; and external localization can simplify early-stage validation of graph-constrained multi-stop flight.

6. Limitations, research context, and directions for scale-up

The prototype is bounded by the payload capacity of the Crazyflie, which restricts both package weight and the number of packages; the demonstration uses three lightweight packages. Battery limits constrain total route length and the number of deliveries, and the system assumes return-to-base after deliveries rather than recharge or mid-route swaps. NDF is fast but suboptimal, and the paper explicitly notes that larger networks and stronger constraints would motivate more advanced heuristics such as Christofides, the savings heuristic, tabu search, or energy-aware planners (Lee et al., 2022).

The release mechanism is likewise specialized. Contact-release requires rooftop clearance and precise altitude control, and the paper notes sensitivity to turbulence and rooftop surface characteristics. Real urban conditions would also introduce wind, temporary no-fly zones, and dynamic requests, all of which would require online replanning and robustness mechanisms such as constraint-aware trajectory planning and load-dependent speed control.

Within the broader literature, this work sits at a specific intersection of aerial logistics and structured urban mobility. It differs from house-level autonomous drone delivery systems that navigate from a GPS waypoint above a house to a front door, front yard, back yard, or front paved area using semantic segmentation and visual routing (Kannan et al., 2021). It also differs from ground-robot last-mile systems that optimize cumulative latency under uncertain travel times and emphasize pedestrian safety, roughness-aware control, and contactless unloading (Shaklab et al., 2023). A plausible implication is that the skyway-network formulation is most naturally aligned with corridor-managed rooftop logistics rather than doorstep or sidewalk service.

At the system level, the paper lays groundwork for several extensions already identified in its own implementation guidance: energy-aware nearest-neighbor variants, hybrid heuristics with local improvement, hard geofences and altitude floors and ceilings, GNSS+RTK and visual-inertial odometry for outdoor localization, and eventual UTM integration through managed skyway segments. In that sense, the contribution is less an optimized final solution than a concrete prototype of single-drone, multi-stop, rooftop-constrained delivery that binds graph planning, payload ordering, and physical release into one reproducible pipeline.

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to DELIVER.