Content uploaded by Ritwik Raj

Author content

All content in this area was uploaded by Ritwik Raj on Dec 07, 2020

Content may be subject to copyright.

The Multiple Flying Sidekicks Traveling Salesman Problem:

Parcel Delivery with Multiple Drones

Chase C. Murray Ritwik Raj

Department of Industrial & Systems Engineering,

University at Buﬀalo, Buﬀalo, New York, USA

October 28, 2019

Abstract: This paper considers a last-mile delivery system in which a delivery truck operates in coor-

dination with a ﬂeet of unmanned aerial vehicles (UAVs, or drones). Deploying UAVs from the truck

enables customers located further from the depot to receive drone-based deliveries. The problem is ﬁrst

formulated as a mixed integer linear program (MILP). However, owing to the computational complexity of

this problem, only trivially-sized problems may be solved directly via the MILP. Thus, a heuristic solution

approach that consists of solving a sequence of three subproblems is proposed. Extensive numerical testing

demonstrates that this approach eﬀectively solves problems of practical size within reasonable runtimes.

Additional analysis quantiﬁes the potential time savings associated with employing multiple UAVs. The

analysis also reveals that additional UAVs may have diminishing marginal returns. An analysis of ﬁve

diﬀerent endurance models demonstrates the eﬀects of these models on UAV assignments. The model and

heuristic also support anticipated future systems that feature automation for UAV launch and retrieval.

Keywords: Unmanned aerial vehicle; drone; vehicle routing problem; traveling salesman problem; logis-

tics; integer programming; heuristics

1 Introduction

This paper introduces the multiple ﬂying sidekicks traveling salesman problem (mFSTSP), in which

a delivery truck and a heterogeneous ﬂeet of unmanned aerial vehicles (UAVs, commonly called

drones) coordinate to deliver small parcels to geographically distributed customers. Each UAV may

be launched from the truck to deliver a single customer package, and then rendezvous (return) to

the truck to be loaded with a new parcel or transported to a new launch location. The objective of

the problem is to leverage the delivery truck and the ﬂeet of UAVs to complete the delivery process

and return to the depot in the minimum amount of time.

The problem of pairing UAVs with traditional delivery trucks was ﬁrst introduced by Murray

and Chu (2015). The paper provided a mathematical programming formulation and a simple

heuristic for the problem of coordinating a single traditional delivery truck with a single UAV,

dubbed the ﬂying sidekick traveling salesman problem (FSTSP). Nearly identical problems have

been described by other researchers under the name TSP with drone (e.g., Agatz et al. 2018,

Bouman et al. 2018, Ha et al. 2018).

A number of industry implementations have occurred since the original FSTSP paper appeared.

For example, Amazon made its ﬁrst delivery worldwide (Wells and Stevens 2016) and its ﬁrst U.S.

delivery a few months later (Rubin 2017). However, drone-maker Flirtey beat Amazon to several

milestones, including the ﬁrst Federal Aviation Administration (FAA) approved U.S. drone delivery

(Vanian 2016). Logistics solution provider UPS also entered the drone delivery race, teaming

with UAV manufacturers Zipline to deliver blood for lifesaving transfusions in Rwanda (Tilley

2016), CyPhy Works to deliver medical supplies in the U.S. (Carey 2016), and electric truck and

UAV manufacturer Workhorse to demonstrate a truck/drone tandem (Peterson and Dektas 2017).

Mercedes-Benz also revealed a concept for a drone delivery van that automatically loads UAVs with

parcels without the need for a driver (Etherington 2017). The 2016 Material Handling Industry

1

(MHI) Annual Industry Report (MHI 2016) notes that 59% of its survey respondents believe that

emerging technologies like drones are already having an impact on supply chains. The report also

claims that adoption rates for technologies like drones are expected to grow to 50% over the next

decade.

The present paper extends the original FSTSP, as well as other related studies on truck/UAV

routing, in several key respects. It features a more comprehensive treatment of the operating con-

ditions, to better reﬂect the realities associated with the complex nature of this coordinated vehicle

routing problem. Speciﬁcally, it contributes to the existing literature in the following ways. First,

the mFSTSP considers an arbitrary number of heterogeneous UAVs that may be deployed from the

depot or from the delivery truck. These UAVs may have diﬀerent travel speeds, payload capaci-

ties, service times, and ﬂight endurance limitations. Accounting for these diﬀerences accommodates

service providers who may expand their ﬂeet with a variety of drones over time. For example, Ama-

zon’s UAV designs have evolved from eight-rotor octocopters, to a multi-rotor/ﬁxed-wing hybrid,

to the latest four-rotor quadcopter in just a few years (Amazon 2019). Given the rapidly-changing

technology, it is reasonable to assume that companies will augment their ﬂeet over time with im-

proved drones. Thus, as companies change the composition of their ﬂeets (either via expansion or

via replacement of drones no longer ﬁt for service), it is expected that companies will increasingly

operate heterogeneous ﬂeets. Similarly, model variations for evolving automated UAV launch and

recovery systems (at the depot or within the truck) are also provided.

Second, because the delivery truck is typically too small to safely accommodate multiple drones

landing or launching simultaneously, the mFSTSP explicitly queues the aircraft in both the launch

and retrieval phases. This additional scheduling problem adds complexity to the problem, but

more accurately reﬂects the limitations associated with deploying multiple drones from a relatively

small space. Consideration of queuing of these activities is important because they may comprise

a signiﬁcant portion of the total operational time; disregarding this aspect may result in solutions

leading to UAVs running out of power before being safely retrieved.

Finally, this paper provides a comparative analysis of ﬁve endurance models, one of which (a

non-linear model that determines energy consumption as a function of velocity and parcel weight)

has not been applied to truck/UAV routing problems. The analysis highlights the potential risks

associated with constructing schedules based on overly-simpliﬁed endurance models. As with the

queue scheduling, the primary risk of using an optimistic endurance model is solutions resulting in

UAVs that fail to return to their recovery locations.

A small eight-customer example is provided to highlight the time savings that may be aﬀorded

by the mFSTSP. Figure 1 shows a comparison of vehicle routes for customers located in the Seattle

area. The route generated by solving a standard traveling salesman problem (TSP) demonstrates

the long travel distance that must be covered if a single truck makes all eight deliveries. With the

addition of one UAV, the truck visits only ﬁve of the customers and avoids the eastern half of the

region. When three UAVs are employed, the truck needs to visit only three customers. The Gantt

chart in Figure 2 highlights the coordination required. In particular, as more UAVs are utilized, the

truck driver must spend more time launching and retrieving the drones. Additionally, the drones

may spend more time waiting for the truck to arrive at the recovery location. Table 1 reveals the

signiﬁcant time savings for even trivially-sized problems.

The remainder of this paper is organized as follows. An overview of related academic literature

is provided in Section 2. A formal problem deﬁnition and mixed integer linear programming (MILP)

formulation are provided in Section 3. A three-phased heuristic solution approach is proposed in

Section 4, followed by a numerical analysis in Section 5 to highlight the beneﬁts, and limitations, of

deploying multiple drones from the delivery truck. Additional analysis explores the impacts of the

region size, potential automation improvements, and implications of diﬀerent endurance models.

2

(a) TSP Solution (no UAVs) (b) mFSTSP with 1 UAV (c) mFSTSP with 3 UAVs

Figure 1: A comparison of routes for a small eight-customer problem in the Seattle region

Delivery

Travel

Launch UAV

Retrieve UAV

Waiting

Truck 2 4 7 1 8 5 6 3

Truck 5 8 4 2 3

UAV 1 6 1 7

Truck 3 2 5

UAV 1 1 6

UAV 2 8

UAV 3 4 7

Time

TSP

mFSTSP (1 UAV)

mFSTSP (3 UAVs)

Figure 2: Detailed vehicle timing for the small Seattle example, using either a single truck (TSP),

a truck with one UAV, or a truck with three UAVs. Numbers on the bars identify each of the eight

customers.

Table 1: Comparison of time savings for the small Seattle example.

Makespan Time Savings Improvement

[hr:min:sec] [hr:min:sec] over TSP

3 UAVs 0:47:00 0:25:01 34.7%

1 UAV 0:59:29 0:12:32 17.4%

TSP 1:12:01 – –

3

Finally, conclusions and future research directions are provided in Section 6.

2 Related literature

This review focuses on problems involving the coordinated use of trucks and UAVs for parcel

delivery. While beyond this scope, we note another class of problems that consider the use of only

UAVs to make deliveries (i.e., without a truck). Variants of this problem include variable UAV

battery energy (Dorling et al. 2017, Venkatachalam et al. 2017, Cheng et al. 2018), multi-objective

(San et al. 2016), multiple UAV replenishment locations (Song et al. 2018), and coordinated UAVs

(Oh et al. 2018). Additionally, numerous works have considered the beneﬁts of UAVs in a variety of

non-military applications. Recent examples include UAV logistics infrastructure (Shavarani et al.

2018, Hong et al. 2018, Kim and Awwad 2017, Chauhan et al. 2019), healthcare (Scott and Scott

2018, Kim et al. 2017), and disaster response (Rabta et al. 2018, Chowdhury 2018, Zhong et al.

2018). A survey of the literature on UAVs for civil applications is provided by Otto et al. (2018).

The problem of combining a drone with a traditional delivery truck for parcel delivery was ﬁrst

formally deﬁned by Murray and Chu (2015). That paper introduced an MILP formulation for the

FSTSP, and also deﬁned the parallel drone scheduling TSP (PDSTSP), where multiple drones are

launched from the depot to serve nearby customers, independent of the truck delivery. Greedy

construction heuristics for both problems were provided.

Numerous studies have since explored variations of the single-truck single-drone problem, often

called the TSP with drone (TSP-D). For example, Agatz et al. (2018) provided a new MILP model

for the TSP-D, as well as several route ﬁrst-cluster second heuristics. An improved formulation for

the FSTSP was presented by Dell’Amico et al. (2019a). Ponza (2016), Ha et al. (2018), Freitas and

Penna (2018), Daknama and Kraus (2017), and Schermer et al. (2018) explored neighborhood search

based heuristics, while Bouman et al. (2018) and Tang et al. (2019) present dynamic programming

and constraint programming approaches, respectively, for obtaining optimal solutions. A multi-

objective variant of the TSP-D, with a non-dominated sorting genetic algorithm, was proposed by

Wang et al. (2019b). Poikonen et al. (2019) provide four branch-and-bound-based heuristics for the

TSP-D. Jeong et al. (2019) modiﬁed the FSTSP to consider variable UAV energy consumption and

restricted ﬂying areas. Dukkanci et al. (2019) consider a variation of the FSTSP that minimizes

the operational cost and calculate UAV energy consumption as a function of speed.

In the case of single-truck multi-UAV problems, Ferrandez et al. (2016) and Chang and Lee

(2018) consider a system in which the truck deploys multiple drones from distributed launch sites

along the truck’s route. The drones return to the truck before the truck departs for its next

destination. Clustering heuristics have been developed, such that the truck is routed to each

cluster and nearby customers are served via UAV. Conversely, similar to the mFSTSP, Yoon (2018)

consider a single truck that may launch multiple UAVs, with the UAVs returning to the truck at

a diﬀerent location. An MILP formulation is provided, which is tested on instances with up to 10

customers. Tu et al. (2018) propose an adaptive large neighborhood search heuristic for a similar

problem, the TSP with multiple drones (TSP-mD).

The use of multiple trucks and multiple UAVs is considered by Kitjacharoenchai et al. (2019),

which is an extension of the FSTSP, but without endurance limitations and launch/delivery time

considerations. While UAVs can be launched from and retrieved at diﬀerent trucks, only one UAV

can be launched or retrieved at any customer location. They present an MILP formulation and

propose an insertion based heuristic to solve problems with up to 50 customers. Sacramento et al.

(2019) extend the FSTSP with multiple trucks, each carrying a single UAV. A solution approach

based on adaptive large neighborhood search is provided. Wang and Sheu (2019) consider a prob-

4

lem in which multiple UAVs may be launched from multiple trucks at customer locations, where

each UAV can serve multiple customers on a sortie. UAVs must be retrieved at separate docking

locations. A branch-and-price algorithm is demonstrated on problems with up to 15 customers.

Schermer et al. (2019b) address a multi-truck problem in which each truck may have multiple UAVs.

A matheuristic is proposed for larger-scale instances. Additionally, Schermer et al. (2019a) consider

a multi-truck, multi-UAV problem where UAV launches and retrievals may occur at non-customer

locations, termed en route operations. An MILP formulation for this problem is provided, along

with a variable neighborhood search heuristic.

Work related to the PDSTSP includes new heuristics proposed by Saleu et al. (2018) and

Dell’Amico et al. (2019b). A multi-truck variant of the PDSTSP, solved via constraint program-

ming, is provided by Ham (2018) in which UAVs can perform both delivery and pickup activities.

Kim and Moon (2019) consider a variation of the PDSTSP in which UAVs can be deployed from

the depot and several drone stations. Another variant, proposed by Wang et al. (2019a), considers

a ﬂeet of trucks, each carrying a UAV, operating simultaneously with additional independent UAVs

that are launched from the depot.

Another class of truck/UAV problems assume that only the UAVs may make deliveries, such as

the multi-visit drone routing problem (MVDRP) proposed by Poikonen (2018) and the truck/drone

tandems considered by Mathew et al. (2015), bin Othman et al. (2017), Peng et al. (2019), and

Wikarek et al. (2019). Although not a parcel delivery application, Luo et al. (2017) proposed a

two-echelon ground vehicle and UAV cooperative routing problem in which a truck carries one UAV

which is responsible for visiting one or more surveillance targets before returning to the truck.

Several theoretical studies have shown the beneﬁts of using a combined truck-UAV delivery

system. Wang et al. (2016) introduced the vehicle routing problem with drones (VRPD), and de-

termined bounds on the ratio of VRPD time savings versus traditional routing problems (e.g., VRP

and TSP). The analysis considered particular cases where trucks and drones follow the same dis-

tance metric and drone battery life is unlimited. Poikonen et al. (2017) relaxed these assumptions

to develop bounds on similar ratios, but with diﬀering distance metrics for trucks and drones and

limited drone endurance. Carlsson and Song (2017) consider a continuous approximation model

to replace computationally diﬃcult combinatorial approaches. Their horseﬂy routing problem con-

sists of one truck and one UAV. Unlike other models, the UAV launch/retrieval locations are not

restricted to customer nodes. Campbell et al. (2017) and Li et al. (2018) also used continuous

approximation methods, and developed cost models to study the economic impacts. Results by

Campbell et al. (2017) suggest that substantial cost savings can be achieved using the combined

truck-drone delivery system with multiple drones per truck, and highlight the beneﬁts associated

with automated loading and reduced delivery service times. Boysen et al. (2018) study the com-

plexity of problems involving a given set of UAV customers and a ﬁxed truck route.

In contrast to the above studies, Ulmer and Thomas (2018) introduce a problem in which

customer orders arrive dynamically. For each incoming order, the ﬁrm must decide whether a truck

or UAV will make the delivery (if at all). There is no interaction between trucks and UAVs.

3 Problem deﬁnition and mathematical programming formulation

This section provides a formal deﬁnition of the mFSTSP, as well as an MILP formulation of the

problem. A summary of the parameter notation is described in Table 2.

Let Crepresent the set of all customer parcels, such that C={1,2, . . . , c}. Each customer must

receive exactly one delivery by either the single delivery truck or by one of the heterogeneous UAVs

that are denoted by the set V. A particular customer i∈Cis said to be “droneable” by UAV

5

Table 2: Parameter notation

VSet of UAVs.

CSet of customers; C={1,2, . . . , c}.

ˆ

CvSet of customers that may be served by UAV v∈V;ˆ

Cv⊆Cfor all v∈V.

NSet of all nodes; N={0,1, . . . , c + 1}.

N0Set of nodes from which a vehicle may depart; N0={0,1, . . . , c}.

N+Set of nodes to which a vehicle may visit; N+={1,2, . . . , c + 1}.

τij Truck’s travel time from node i∈N0to node j∈N+.

τ0

vij Travel time for UAV v∈Vfrom node i∈N0to node j∈N+.

sL

v,i Launch time for UAV v∈Vfrom node i∈N0.

sR

v,k Recovery time for UAV v∈Vat node k∈N+.

σkService time by truck at node k∈N+, where σc+1 ≡0.

σ0

vk Service time by UAV v∈Vat node k∈N+, where σ0

v,c+1 ≡0.

PA set of tuples of the form hv, i, j, ki, specifying all possible three-node sorties that

may be ﬂown by UAV v∈V.

evijk Endurance, in units of time, for UAV v∈Vtraveling from nodes i∈N0to j∈ˆ

Cv

to k∈N+.

v∈V, and thus belongs to the set ˆ

Cv, if that customer’s parcel is eligible to be delivered by v. This

categorization may be a function of several factors, including the parcel’s weight or size, whether a

customer signature is required, whether the parcel contains hazardous material that should not be

ﬂown, or whether the customer’s location is conducive to accommodating a drone (e.g., apartments

or heavily-wooded areas may be inaccessible to a UAV).

Each UAV is capable of carrying one droneable parcel at a time, although the weight or volume

capacity of each UAV may diﬀer. UAVs may be launched from the depot, or from the truck. While

a UAV can be launched multiple times, it cannot be launched from the same location more than

once. This assumption, consistent with the deﬁnition of the original FSTSP, is made primarily

for algorithmic convenience. A UAV can be retrieved at the depot, or by the truck at a customer

location, but it cannot be retrieved at the same customer location from which it was launched.

When a UAV returns to the truck, it may be loaded onto the truck or it can be launched from

the truck (at this location) with a new package. The truck can also make stops between UAV

launch and retrieval locations to serve other customers while UAVs are airborne. It is assumed

that the truck can transport all of the available UAVs at once, although the truck may only launch

or retrieve one UAV at a time.

For now, assume that the truck must be present at the depot when the UAVs are launched or

retrieved; in Section 3.7 we address a variant of the problem for cases where the depot features

automation or is suﬃciently staﬀed to prepare and receive UAVs without the driver. We also

initially assume that the driver must participate in the launch/recovery process when en route

(away from the depot). However, Section 3.8 describes model modiﬁcations that leverage UAV-

handling automation within the truck.

Because the truck may launch and retrieve (and re-launch) multiple UAVs at a particular

customer location, it is important to coordinate these activities carefully to avoid mid-air collisions.

Thus, the driver’s task of dropping oﬀ a customer’s parcel must also be scheduled with the UAV

launch and recovery activities. Figure 3 shows an example of ﬂow of the scheduled activities.

To characterize the underlying network structure of the mFSTSP, we deﬁne the set of all nodes

6

(a) UAV 1 ar-

rives

(b) Truck

arrives

(c) UAV 2 ar-

rives and is re-

trieved

(d) UAV 2 is

relaunched

(e) UAV 1 is

retrieved

(f) Driver serves

customer and

truck departs

Figure 3: A notional example depicting the scheduling activities required at truck customer loca-

tions.

in the network to be N={0,1, . . . , c + 1}, where nodes 0 and c+ 1 represent the depot from which

all vehicles must originate and return. This convention accommodates the case in which the origin

depot (0) and destination depot (c+ 1) have diﬀerent physical locations. The truck may only depart

from node 0, and must return to node c+ 1. The set of nodes from which a vehicle may depart

is represented by N0={0,1, . . . , c}, while N+={1,2, . . . , c + 1}describes the set of all nodes to

which a vehicle may visit.

The truck’s travel time along the road network from node i∈N0to j∈N+is given by τij.

Similarly, τ0

vij represents the time required for UAV v∈Vto ﬂy from node i∈N0to node j∈N+.

When UAV v∈Vis launched from node i∈N0, it requires sL

v,i units of time. This launch

time is indexed on vto incorporate diﬀerences in UAVs (some of which may be better designed to

load parcels or swap batteries). The launch time is also indexed on the launch location; launching

from the depot may require a diﬀerent amount of time (e.g., perhaps the drones are already loaded

with their ﬁrst parcel and already have a fresh battery, or perhaps there’s automation within the

depot). The recovery time, sR

v,k, is similarly deﬁned for UAV v∈Vretrieved at node k∈N+.

Truck deliveries require σkunits of time for service at node k∈N+, where σc+1 ≡0 as there is

no delivery at the depot. Similarly, UAV v∈Vrequires σ0

vk units of time to perform the delivery

service at node k∈N+, where σ0

v,c+1 ≡0. This service time is indexed on the UAV to reﬂect

diﬀerences in delivery mechanisms among UAVs in the ﬂeet. For example, some UAVs deliver

goods via a tether while the drone remains airborne (c.f., Google’s “egg” (Mogg 2015) and Flirtey’s

pizza delivery UAV (Boyle 2016)), others require the UAV to land to release the package (c.f., DHL’s

‘parcelcopter’ (Adams 2016) and UPS/Workhorse truck/UAV tandem (Adams 2017)), while other

designs drop goods via parachute (c.f., Amazon’s patent for a shipping label with built-in parachute

(Mogg 2017) and Zipline’s blood deliveries (Toor 2016)).

3.1 UAV endurance

Each UAV v∈Vhas a unique endurance, represented as evijk and measured in units of time,

for which it may remain operational as it travels from node i∈N0(launch) to j∈ˆ

Cv(delivery),

and then to k∈N+(rendezvous). The incorporation of the UAV’s endurance is critical, as UAV

operations are hampered by limited battery capacity.

7

To identify potential valid UAV sorties (i.e., the sequence of a launch, customer delivery, and

rendezvous), Pis deﬁned to be a set of four-tuples of the form hv, i, j, kifor v∈V,i∈N0,j∈ˆ

Cv,

and k∈N+. This set has the following properties:

•The launch node, i, must not be the ending depot node (i.e., iis restricted to N0);

•The delivery node, j, must be an eligible customer for UAV v(i.e., j∈ { ˆ

Cv:j6=i});

•The rendezvous point, k, may be either a customer or the ending depot (but it must not be

either node ior j); and

•The UAV’s travel time from i→j→kmust not exceed the endurance of the UAV (i.e.,

τ0

vij +σ0

vj +τ0

vjk ≤ev ijk for k∈ {N+:k6=j, k 6=i}).

3.2 Objective and decision variables

The objective of the mFSTSP is to minimize the time required to deliver all parcels and return

to the depot (i.e., to minimize the makespan). This is accomplished via determination of decision

variable values across six main classes, a summary of which is provided in Table 3. First, binary

decision variable xij = 1 if the truck travels from node i∈N0immediately to node j∈ {N+:j6=i}.

This decision variable determines the route of the delivery truck. Similarly, in the second class,

binary decision variable pij = 1 if the truck visits node i∈N0at some time prior to visiting node

j∈ {C:j6=i}. We deﬁne p0j≡1 for all j∈Cto indicate that the truck must leave the depot

(node 0). This decision variable is employed to ensure that a UAV’s launch and recovery nodes are

consistent with the truck’s route (i.e., if a UAV is launched from a truck, it cannot return to the

truck at a location that was earlier in the truck’s route).

In the third class, binary decision variable yvijk = 1 if UAV v∈Vtravels from node i∈N0to

customer j∈ { ˆ

Cv:j6=i}, re-joining the truck at node k∈ {N+:hv, i, j, ki ∈ P}. This decision

variable identiﬁes UAV sorties.

The fourth class involves ﬁve continuous decision variables to determine the time at which key

events for the truck and UAVs occur. Speciﬁcally, ˇ

ti≥0 captures the truck’s arrival time to node

i∈N, where ˇ

t0≡0 to indicate that the truck is available to begin operations at time zero. The

truck’s service time completion at node i∈N+is given by ¯

ti≥0, where ¯

t0≡0 to reﬂect the fact

that there is no customer associated with the depot. This decision variable indicates the time at

which customer i’s parcel has been delivered. Next, ˆ

ti≥0 identiﬁes the truck’s completion time

at node i∈N(e.g., the earliest departure time from this node if i∈N0). In the problem variant

where the truck is not required to be at the depot when UAVs launch, then ˆ

t0≡0. Similarly,

timing for the UAVs is determined by ˇ

t0vi ≥0, which denotes the arrival time for UAV v∈Vto

node i∈N, and ˆ

t0vi ≥0, which identiﬁes the completion time for UAV v∈Vat node i∈N.

Next, numerous binary decision variables (all identiﬁed by the letter zwith sub- and super-

scripts) are employed to determine the coordination between the driver and each UAV, and to

establish the sequencing of UAV launches and retrievals at each node. Details on each of these

variables are provided in Table 3.

Finally, 1 ≤ui≤c+ 2 are standard truck subtour elimination variables, deﬁned for all i∈N+,

that indicate the relative ordering of visits to node i.

Details of the MILP formulation are provided in the remainder of this section. Due to the

length of the model, constraints are grouped according to functionality.

3.3 Core model components from the FSTSP

The mFSTSP leverages core components of the FSTSP model provided by Murray and Chu (2015),

with modiﬁcations to accommodate multiple UAVs. This model employs several “big-M” con-

8

Table 3: Decision variables

xij ∈ {0,1}xij = 1 if the truck travels from node i∈N0immediately to node

j∈ {N+:j6=i}.

pij ∈ {0,1}pij = 1 if node i∈N0appears in the truck’s route before node j∈ {C:

j6=i}.p0j≡1 for all j∈C.

yvijk ∈ {0,1}yv ijk = 1 if UAV v∈Vtravels from node i∈N0to customer j∈ { ˆ

Cv:

j6=i}, re-joining the truck at node k∈ {N+:hv, i, j, ki ∈ P}.

ˇ

ti≥0 Truck’s arrival time to node i∈N, where ˇ

t0≡0.

¯

ti≥0 Truck’s service time completion at node i∈N+, where ¯

t0≡0.

ˆ

ti≥0 Truck’s completion time at node i∈N(e.g., the earliest departure time

from this node if i∈N0). If the truck is not required to be at the depot

when UAVs launch, then ˆ

t0≡0

ˇ

t0vi ≥0 Arrival time for UAV v∈Vto node i∈N.

ˆ

t0vi ≥0 Completion time for UAV v∈Vat node i∈N.

zR

v1,v2,k ∈ {0,1}zR

v1,v2,k = 1 if v1∈Vand v2∈ {V:v26=v1}are recovered at node

k∈N+, such that v1is recovered before v2.

zR

0,v,k ∈ {0,1}zR

0,v,k = 1 if the truck completes its service activities at node k∈N+

before UAV v∈Vis retrieved at node k.

zR

v,0,k ∈ {0,1}zR

v,0,k = 1 if UAV v∈Vis retrieved at node k∈N+before the truck

completes its service activities at node k. We deﬁne zR

v,0,c+1 ≡0 for all

v∈V(since the truck has no service activities at the depot node, the

order does not matter).

zL

v1,v2,i ∈ {0,1}zL

v1,v2,i = 1 if UAV v1∈Vis launched from node i∈N0before v2∈

{V:v26=v1}is launched from i.

zL

0,v,i ∈ {0,1}zL

0,v,i = 1 if the truck completes its service activities at node i∈N0

before UAV v∈Vis launched from i.

zL

v,0,i ∈ {0,1}zL

v,0,i = 1 if UAV v∈Vis launched from node i∈N0before the truck

completes its service activities at node i. If the truck is not required to

be present when UAVs launch from the depot, we may deﬁne zL

v,0,0= 0

for all v∈V(since the truck has no service activities at the depot node,

the order does not matter).

z0

v1,v2,i ∈ {0,1}z0

v1,v2,i = 1 if UAV v1∈Vlaunches from node i∈Cbefore UAV

v2∈ {V:v26=v1}lands at i.

z00

v1,v2,i ∈ {0,1}z00

v1,v2,i = 1 if UAV v1∈Vlands at node i∈Cbefore UAV v2∈ {V:

v26=v1}launches from i.

1≤ui≤c+ 2 Truck subtour elimination variables, deﬁned for all i∈N+, which indi-

cate the relative ordering of visits to node i.

9

straints, where the value of Mrepresents a suﬃciently large number. One valid value of Mis the

length of a TSP tour such that the truck visits each customer, plus the sum of truck service times

over all customers.

The objective function and the general constraints related to guaranteeing customer deliveries

and eliminating truck subtours are as follows:

Min ˆ

tc+1 (1)

s.t. X

i∈N0

i6=j

xij +X

v∈VX

i∈N0

i6=jX

k∈N+

hv,i,j,ki∈P

yvijk = 1 ∀j∈C, (2)

X

j∈N+

x0j= 1,(3)

X

i∈N0

xi,c+1 = 1,(4)

X

i∈N0

i6=j

xij =X

k∈N+

k6=j

xjk ∀j∈C, (5)

X

j∈C

j6=iX

k∈N+

hv,i,j,ki∈P

yvijk ≤1∀i∈N0,∀v∈V, (6)

X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk ≤1∀k∈N+,∀v∈V, (7)

2yvijk ≤X

h∈N0

h6=i

xhi +X

l∈C

l6=k

xlk

∀v∈V, i ∈C, j ∈ {C:j6=i}, k ∈ {N+:hv, i, j, ki ∈ P},(8)

yv0jk ≤X

h∈N0

h6=k

xhk ∀v∈V, j ∈C, k ∈ {N+:hv, 0, j, ki ∈ P},(9)

uk−ui≥1−(c+ 2)

1−X

j∈C

hv,i,j,ki∈P

yvijk

∀i∈C, k ∈ {N+:k6=i},∀v∈V, (10)

ui−uj+ 1 ≤(c+ 2)(1 −xij )∀i∈C, j ∈ {N+:j6=i},(11)

ui−uj≥1−(c+ 2)pij ∀i∈C, j ∈ {C:j6=i},(12)

ui−uj≤ −1+(c+ 2)(1 −pij)∀i∈C, j ∈ {C:j6=i},(13)

pij +pji = 1 ∀i∈C, j ∈ {C:j6=i}.(14)

The objective function (1) seeks to minimize the latest time at which either the truck or a UAV

return to the depot. Although ˆ

tc+1 is explicitly deﬁned for only the truck’s return time to the

depot, constraints in Sections 3.4 and 3.5 serve to link the UAVs’ and truck’s return time to the

depot. Thus, the objective function is equivalent to min{max

v∈V{ˆ

tc+1,ˆ

t0v,c+1}}.

Constraint (2) requires each customer to be visited exactly once. Constraint (3) ensures that

the truck departs from the depot exactly once, while Constraint (4) requires the truck to return to

10

the depot exactly once.

Constraint (5) provides ﬂow balance for the truck, which must depart from each node that it

visits (except the ending depot node), while Constraint (6) states that each UAV may launch at

most once from any particular node, including the depot. Similarly, Constraint (7) indicates that

each UAV may rendezvous at any particular node (including customers and the ending depot) at

most once.

If a UAV is launched from customer iand is collected by the truck at node k, then Constraint

(8) states that the truck must be assigned to both nodes iand k. Furthermore, Constraint (9)

ensures that if a UAV launches from the starting depot 0 and is collected at node k, then the truck

must be assigned to node k. Similarly, Constraint (10) ensures that the truck must visit ibefore k

if a UAV launches from customer iand is collected at node k. Subtour elimination constraints for

the truck are provided by (11).

Constraints (12)–(14) determine the proper values of pij. Because uiand pij describe the

ordering of nodes visited by the truck only, values of these decision variables are inconsequential

for any iand jthat are visited only by a UAV.

3.4 UAV timing constraints

The following constraints establish the times at which each UAV launches from either the depot

or the truck, arrives at a customer location, and returns to either the truck or the depot. These

constraints also address UAV ﬂight endurance limitations.

ˆ

t0vl ≥ˇ

t0vk −M

3−X

j∈C

hv,i,j,ki∈P

j6=l

yvijk −X

m∈C

m6=i

m6=k

m6=l

X

n∈N+

hv,l,m,ni∈P

n6=i

n6=k

yvlmn −pil

∀i∈N0, k ∈ {N+:k6=i}, l ∈ {C:l6=i, l 6=k},∀v∈V(15)

ˆ

t0vi ≥ˇ

t0vi +sL

v,i −M

1−X

j∈C

j6=iX

k∈N+

hv,i,j,ki∈P

yvijk

∀v∈V, i ∈N0,(16)

ˆ

t0vi ≥ˇ

ti+sL

v,i −M1−zL

v0i∀v∈V, i ∈N0,(17)

ˆ

t0vi ≥¯

ti+sL

v,i −M1−zL

0vi∀v∈V, i ∈N0,(18)

ˆ

t0vi ≥ˆ

t0v2,i +sL

v,i −M1−zL

v2,v,i∀v∈V, v2∈ {V:v26=v}, i ∈N0,(19)

ˆ

t0v2,i ≥ˇ

t0vi +sL

v2,i −M1−z00

v,v2,i∀v∈V, v2∈ {V:v26=v}, i ∈C, (20)

ˇ

t0vj ≥ˆ

t0vi +τ0

vij −M

1−X

k∈N+

hv,i,j,ki∈P

yvijk

∀v∈V, j ∈C, i ∈ {N0:i6=j},(21)

11

ˇ

t0vj ≤ˆ

t0vi +τ0

vij +M

1−X

k∈N+

hv,i,j,ki∈P

yvijk

∀v∈V, j ∈C, i ∈ {N0:i6=j},(22)

ˆ

t0vj ≥ˇ

t0vj +σ0

vj X

i∈N0

i6=jX

k∈N+

hv,i,j,ki∈P

yvijk ∀v∈V , j ∈C, (23)

ˆ

t0vj ≤ˇ

t0vj +σ0

vj +M

1−X

i∈N0

i6=jX

k∈N+

hv,i,j,ki∈P

yvijk

∀v∈V, j ∈C, (24)

ˇ

t0vk ≥ˇ

tk+sR

v,k −M1−zR

v0k∀v∈V, k ∈N+,(25)

ˇ

t0vk ≥¯

tk+sR

v,k −M1−zR

0vk∀v∈V, k ∈N+,(26)

ˇ

t0vk ≥ˇ

t0v2,k +sR

v,k −M1−zR

v2,v,k ∀v∈V, v2∈ {V:v26=v}, k ∈N+,(27)

ˇ

t0vk ≥ˆ

t0v2,k +sR

v,k −M1−z0

v2,v,k ∀v∈V, v2∈ {V:v26=v}, k ∈C, (28)

ˇ

t0vk ≥ˆ

t0vj +τ0

vjk +sR

v,k −M

1−X

i∈N0

hv,i,j,ki∈P

yvijk

∀v∈V, k ∈N+, j ∈ {C:j6=k},(29)

ˇ

t0vk −SR

v,k −ˆ

t0vi ≤evij k +M(1 −yvijk)

∀v∈V, i ∈N0, j ∈ { ˆ

Cv:j6=i}, k ∈ {N+:hv, i, j, ki ∈ P}.(30)

Constraint (15) prohibits individual UAV sorties from overlapping. For example, suppose that

UAV vlaunches from iand returns to k. Further, suppose that the UAV later launches from l

(thus, pil = 1). This constraint prevents the launch time from l,ˆ

t0

vl, from preceding the return time

to k,ˇ

t0

vk. If the UAV does not return to k, the UAV does not launch from l, or idoes not precede

l, then this constraint will not be binding. This constraint requires the deﬁnition of p0l= 1 for all

l∈C.

Constraints (16)–(20) address launching of UAVs. The launch service (preparation) time, sL

v,i,

is included in these constraints to be consistent with the deﬁnition of ˆ

t0vi (the time at which UAV v

is launched from node i). Constraint (16) states that vcannot launch from i(to jand k) until after

vhas arrived at node i; if vwere transported on the truck to node i,ˇ

t0vi would be a meaningless

value. Per Constraint (17), UAV vcannot launch from iuntil after the truck has arrived to node iif

the truck customer is served after vis launched (i.e., if zL

v0i= 1). Conversely, Constraint (18) states

that UAV vcannot launch from iuntil after the truck has served this customer if the truck serves

the customer before vis launched (i.e., if zL

0vi = 1). In Constraint (19), UAV vcannot launch from i

until UAV v2has launched if v2launches before v(i.e., if zL

v2,v,i = 1), while Constraint (20) ensures

that v2does not launch until after vhas landed, if vlands before v2launches (i.e., if zL

v,v2,i = 1).

Note that, in Constraint (20), node iis restricted to being a customer node since no other node

type permits both launching and landing.

Constraints (21) and (22) govern the arrival timing for a UAV serving some customer j; Con-

straints (23) and (24) perform the same function for the departure timing. These four constraints

ensure that a UAV will travel directly to the customer location, and will depart immediately after

completing service. Any required loitering while waiting to be retrieved by the truck will occur at

the truck’s location. Constraints (25)–(29) address the landing of UAVs at retrieval locations (i.e.,

12

not at a drone delivery customer). The recovery service time (e.g., sR

v,k) is included to be consistent

with the deﬁnition of ˇ

t0vk (the time at which vis deemed to have arrived at node k). In particular,

Constraint (25) states that vcan land at node kas soon as the truck has arrived if the truck serves

customer kafter retrieving v(i.e., if zR

v0k= 1). However, if the truck serves customer kﬁrst (i.e.,

if zR

0vk = 1), then UAV vcannot land at kuntil the truck completed this service.

If UAV v2is recovered at node kbefore UAV v(i.e., if zR

v2,v,k = 1), Constraint (27) ensures that

the arrival time for vis after the arrival time for v2. Similarly, if v2is launched from node kbefore

vis recovered (i.e., if z0

v2,v,k = 1), Constraint (28) requires the arrival time for vto be after the

launch time for v2. In this constraint, kis restricted to the set of customers because UAVs cannot

launch and land from any other nodes. In Constraint (29), UAV vcannot land at kuntil it has

launched from customer jand travels from jto k.

UAV endurance limitations are addressed by Constraint (30). If vtravels from ito jto k, then

the diﬀerence between the arrival time at k(less the recovery time, which is incorporated in ˇ

t0vk )

and the departure time from imust not exceed the endurance limit.

3.5 Truck timing constraints

The following constraints govern the arrival, service, and departure activities for the truck.

ˇ

tj≥ˆ

ti+τij −M(1 −xij)∀i∈N0, j ∈ {N+:j6=i},(31)

¯

tk≥ˇ

tk+σkX

j∈N0

j6=k

xjk ∀k∈N+,(32)

¯

tk≥ˇ

t0vk +σk−M1−zR

v0k∀k∈N+, v ∈V, (33)

¯

tk≥ˆ

t0vk +σk−M1−zL

v0k∀k∈C, v ∈V, (34)

ˆ

tk≥¯

tk∀k∈N+,(35)

ˆ

tk≥ˇ

t0vk −M

1−X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk

∀k∈N+, v ∈V, (36)

ˆ

tk≥ˆ

t0vk −M

1−X

l∈C

l6=kX

m∈N+

hv,k,l,mi∈P

yvklm

∀k∈N0, v ∈V. (37)

The truck’s travel time is incorporated in Constraint (31), which states that the truck cannot

arrive at juntil after it has left iand traveled from ito j.

Constraints (32), (33), and (34) establish the truck’s service time completion at a customer.

Note that there is no customer service time at the depot (i.e., σc+1 ≡0). Thus, the service

completion time for the truck when visiting the depot does not have a service time component,

although it does also depend on the arrival of any UAVs to the depot in the event that we require

the truck to be present when UAVs arrive. In Constraint (32), the truck’s service time completion

at node kmust not be prior to arriving at the node and ﬁnishing service. If the truck does not serve

k, then ˇ

tkwill be a meaningless value (probably zero). Constraint (33) states that the truck cannot

complete service to customer kuntil UAV vhas arrived, if vis recovered at node kbefore the truck

service begins (i.e., if zR

v0k= 1). Similarly, the truck cannot complete its service of customer kuntil

UAV vhas launched, if vis launched from kbefore the truck begins service (i.e., if zL

vok = 1), as

13

in Constraint (34). Note that k∈C(rather than in N+) because UAVs cannot be launched from

node c+ 1.

Constraints (35), (36), and (37) establish the truck’s earliest departure from a node. Constraint

(35) prevents the truck from departing a node until it has completed serving the customer. If the

truck does not serve k, then ˇ

tkwill be a meaningless value. In Constraint (36), if a UAV is retrieved

at node k, then the truck cannot depart until that UAV has arrived. Similarly, the truck cannot

depart from a node until after all UAVs have launched from that node, as per Constraint (37).

3.6 Sequencing of retrievals, launches, and truck service

In this section, constraints are provided to establish proper values of the binary decision variables

used to sequence the activities at each node. We begin with constraints for setting the zR

·,·,·values:

zR

0vk +zR

v0k=X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk ∀v∈V , k ∈N+,(38)

zR

v,v2,k ≤X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk ∀v∈V , v2∈ {V:v26=v}, k ∈N+,(39)

zR

v,v2,k ≤X

i∈N0

i6=kX

j∈C

hv2,i,j,ki∈P

yv2ijk ∀v∈V , v2∈ {V:v26=v}, k ∈N+,(40)

zR

v,v2,k +zR

v2,v,k ≤1∀v∈V, v2∈ {V:v26=v}, k ∈N+,(41)

zR

v,v2,k +zR

v2,v,k + 1 ≥X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk +X

i∈N0

i6=kX

j∈C

hv2,i,j,ki∈P

yv2ijk

∀v∈V, v2∈ {V:v26=v}, k ∈N+.(42)

In Constraint (38), if vis retrieved at node k, then the truck must serve keither before or after

varrives. Conversely, zR

v,v2,k cannot equal one if neither vnor v2are retrieved at node k, as per

Constraints (39) and (40). Constraint (41) states that either vis retrieved before v2,v2is retrieved

before v, or at least one of these UAVs is not retrieved at k. Finally, if vand v2are both retrieved

at k, then either vis retrieved before v2, or v2is retrieved before v, as in Constraint (42).

Constraints (43)–(47), below, are the launch analogues to Constraints (38)–(42). These con-

straints are used to set the zL

·,·,·decision variable values:

zL

0vi +zL

v0i=X

j∈C

j6=iX

k∈N+

hv,i,j,ki∈P

yvijk ∀v∈V , i ∈N0,(43)

zL

v,v2,i ≤X

j∈C

j6=iX

k∈N+

hv,i,j,ki∈P

yvijk ∀v∈V , v2∈ {V:v26=v}, i ∈N0,(44)

zL

v,v2,i ≤X

j∈C

j6=iX

k∈N+

hv2,i,j,ki∈P

yv2ijk ∀v∈V , v2∈ {V:v26=v}, i ∈N0,(45)

zL

v,v2,i +zL

v2,v,i ≤1∀v∈V, v2∈ {V:v26=v}, i ∈N0,(46)

14

zL

v,v2,i +zL

v2,v,i + 1 ≥X

j∈C

j6=iX

k∈N+

hv,i,j,ki∈P

yvijk +X

j∈C

j6=iX

k∈N+

hv2,i,j,ki∈P

yv2ijk

∀v∈V, v2∈ {V:v26=v}, i ∈N0.(47)

Next, constraints are required for nodes at which one UAV launches and another UAV lands.

Binary decision variable z0

v1,v2,i = 1 if UAV v1∈Vlaunches from node i∈Cbefore UAV v2∈

{V:v26=v1}lands at i, while z00

v1,v2,i = 1 if UAV v1∈Vlands at node i∈Cbefore UAV

v2∈ {V:v26=v1}launches from i.

z0

v2,v,k ≤X

l∈C

l6=kX

m∈N+

hv2,k,l,mi∈P

yv2,k,l,m ∀v2∈V, v ∈ {V:v6=v2}, k ∈C, (48)

z00

v2,v,k ≤X

l∈C

l6=kX

m∈N+

hv,k,l,mi∈P

yv,k,l,m ∀v∈V , v2∈ {V:v26=v}, k ∈C, (49)

z0

v2,v,k ≤X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk ∀v∈V , v2∈ {V:v26=v}, k ∈C, (50)

z00

v2,v,k ≤X

i∈N0

i6=kX

j∈C

hv2,i,j,ki∈P

yv2,i,j,k ∀v2∈V, v ∈ {V:v6=v2}, k ∈C, (51)

z0

v2,v,k +z00

v,v2,k + 1 ≥X

i∈N0

i6=kX

j∈C

hv,i,j,ki∈P

yvijk +X

l∈C

l6=kX

m∈N+

hv2,k,l,mi∈P

yv2klm

∀v∈V, v2∈ {V:v26=v}, k ∈C, (52)

z0

v2,v,k +z00

v,v2,k ≤1∀v∈V, v2∈ {V:v26=v}, k ∈C, (53)

z0

v2,v,k +z0

v,v2,k ≤1∀v∈V, v2∈ {V:v26=v}, k ∈C, (54)

z00

v2,v,k +z00

v,v2,k ≤1∀v∈V, v2∈ {V:v26=v}, k ∈C. (55)

Constraint (48) states that z0

v2,v,k = 0 if v2does not launch from k, while Constraint (49) sets

z00

v2,v,k = 0 if vdoes not launch from k. Similarly, Constraint (50) requires z0

v2,v,k = 0 if vis not

retrieved at kand Constraint (51) sets z00

v2,v,k = 0 if v2is not retrieved at k. If vis retrieved at

customer kand v2is launched from customer k, then either v2is launched before vlands, or v

lands before v2launches, per Constraint (52).

Constraint (53) states that it is impossible for v2to be launched before vlands and for vto

land before v2launches. Similarly, Constraint (54) indicates that v2cannot launch before vlands,

if vlaunches before v2lands; while Constraint (55) states that it is impossible for v2to land before

vlaunches and for vto land before v2launches.

3.7 Variant 1: Truck not required at depot

The model above assumes that the truck must be present at the depot when UAVs are launched, and

must also be at the depot when UAVs return. This reﬂects the case that the driver is responsible

for manually performing these activities. However, the model may be relaxed to allow the UAVs

to launch from, and return to, the depot independent of the driver.

We begin by modifying the deﬁnitions of two decision variables. First, we deﬁne ˆ

t0≡0 to

15

allow the truck to immediately depart from the depot (without waiting for UAVs to be launched).

Second, we deﬁne zL

v,0,0≡0 for all v∈V; since the truck has no service activities at the depot

node, it does not need to be considered in the UAV launch sequencing.

Next, Constraints (25), (26) and (33) need not be satisﬁed at depot node c+ 1, since vcan land

at the depot independent of the truck’s arrival and service time completion. Thus, those constraints

should be replaced by

ˇ

t0vk ≥ˇ

tk+sR

v,k −M1−zR

v0k∀v∈V, k ∈C, (56)

ˇ

t0vk ≥¯

tk+sR

v,k −M1−zR

0vk∀v∈V, k ∈C, (57)

¯

tk≥ˇ

t0vk +σk−M1−zR

v0k∀v∈V, k ∈C. (58)

If the objective of the model is to minimize the time at which the last vehicle returns to the

depot, then Constraint (36) remains as is. Otherwise, if the objective is to minimize the time at

which the truck returns to the depot, then (36) should be modiﬁed to exclude depot node k=c+1.

Finally, Constraint (37) should be relaxed for node k= 0 since the departure of UAV vfrom

the depot is now independent of the truck’s departure. Thus, (37) should be replaced by

ˆ

tk≥ˆ

t0vk −M

1−X

l∈C

l6=kX

m∈N+

hv,k,l,mi∈P

yvklm

∀k∈C, v ∈V. (59)

3.8 Variant 2: Automated launch and recovery systems

The default mFSTSP model assumes that the truck driver must be engaged in the UAV launch

and recovery process at customer locations. However, concept vehicles have been proposed (c.f.,

(Etherington 2017)) that automate these activities. The obvious beneﬁt of such automation is that

the truck driver can make a delivery at a customer location independent of the UAV launches and

retrievals. Note, however, that the truck still has to be present for the launch and recovery at a

customer location; the diﬀerence is that the driver is not required.

To accommodate automated launch and recovery systems, the following modiﬁcations to the

baseline mFSTSP model are required. First, the UAV launch timing is no longer a function of the

driver’s service at the customer. Thus, Constraint (17) should be replaced by

ˆ

t0vi ≥ˇ

ti+sL

v,i −M

1−X

j∈{C:j6=i}X

k∈{N+:hv,i,j,ki∈P}

yv,i,j,k

∀v∈V, i ∈N0,(60)

and Constraint (18) should be removed. Similarly, the UAV recovery timing constraints should be

modiﬁed such that Constraint (25) is replaced by

ˇ

t0vk ≥ˇ

tk+sR

v,k −M

1−X

i∈N0X

j∈{C:hv,i,j,ki∈P}

yv,i,j,k

∀v∈V, k ∈N+,(61)

and Constraint (26) is removed.

The truck service constraints in (33) and (34) should be removed, as the start of the truck

driver’s service at a customer is no longer dependent upon the UAV arrivals or departures. Similarly,

Constraints (38) and (43), which require sequencing for driver service with recovery and launch

16

operations, respectively, should be removed.

Finally, the decision variables zL

v,0,i,zL

0,v,i,zR

v,0,k, and zR

0,v,k are no longer required. Although

the UAVs still require queueing, driver service at a customer may start immediately (i.e., the UAV

queueing is now independent of the driver’s service at a truck customer).

4 A three-phased heuristic solution approach

Due to the NP-hard nature of the mFSTSP, heuristic approaches are required for problems of

practical size. A three-phased iterative heuristic, depicted in Figure 4, is proposed.

In Phase I, customers are partitioned into two sets – those that will be served via truck and

those served via UAVs. The minimum number of customers in the truck set is given by an input

parameter called the lower truck limit (LTL). The LTL is initialized to

LTL0=|C|−|V|

|V|+ 1 ,

where LTL0represents the minimum number of truck customers required for a feasible solution. For

example, consider a 50-customer problem. If only 1 UAV is available, LTL0= 25, indicating that

at least 25 customers must be assigned to the truck route. If 4 UAVs are available, then at least 10

customers must be assigned to the truck. The value of the LTL is increased over the course of the

iterative procedure. In addition to partitioning the customer base into truck- and UAV-assigned

customers, Phase I also produces a unique TSP-like truck tour.

In Phase II, sorties for the UAV-assigned customers (as determined in Phase I) are generated.

These sorties deﬁne the launch and recovery locations associated with each UAV customer, as well

as the UAV assigned to each sortie. At the conclusion of Phase II, all truck and UAV routes are

identiﬁed, but the timing of the activities is determined in Phase III.

In Phase III, an MILP is solved to determine the exact timing of the launch, recovery, and

service activities for the truck and the UAVs. Phase III also determines the queueing sequences for

the UAVs.

After Phase III is completed, a local search procedure is executed to reﬁne the solution. The

value of LTL is then incremented to add diversity to the search space, and the procedure returns

to Phase I. The iterative procedure is repeated until the LTL equals the number of customers (i.e.,

until the problem becomes simply solving a TSP tour to visit all customers via truck). Details of

each phase are described in the remainder of this section.

4.1 Phase I – Initial Customer Assignments

The goal of Phase I is to establish a unique truck tour containing at least LTL customers, which is

analogous to ﬁnding the xij decision variables in the mFSTSP formulation. Any customer not on

the truck’s route will be allocated (if possible) in Phase II to the UAVs. Pseudocode for Phase I is

provided in Algorithms 1, 2, and 3.

This phase begins by creating a TSP tour of only those customers that are not UAV-eligible

(lines 1–4 of Algorithm 1). The getTSP() function solves an MIP using the “lazy constraints”

method detailed in Gurobi Optimization (2018).

Next, customers are added or removed from the truck tour (lines 6–27 of Algorithm 1) according

to a savings metric, with the aim of reducing the makespan. The savings metric captures trade-

oﬀs between truck travel times, truck service time, and UAV launch and recovery times. This

17

Check for Termination

Is LTL ≤Number

of customers?

Report Solution

STOP.

Report incumbent solution

(OFV∗,TSPtour∗,

UAVsorties∗,

ActivityTimings∗)

Partition Customers

Divide customers be-

tween truck and UAVs,

and generate a truck tour

Initialize

Set OFV∗=∞,

Set LTL =LTL0,

Set TSPtour∗=∅,

Set UAVsorties∗=∅,

Set ActivityTimings∗=∅

Modify TSP Tour

Perform swap/subtour re-

versal/entire TSP reversal,

if needed, to ensure unique

TSP tour. Is it possible?

Increment LTL

Set LTL =LTL + 1,

set prevPhase3 = False

Check Phase I Bound

Generate a lower bound.

Is it smaller than OFV∗?

Create UAV Sorties

Assign a pair of feasible

launch-recovery point, and a

UAV to each UAV customer

Check Phase II Bound

Calculate optimistic

lower bound, λ. Is it

smaller than OFV∗?

Check Phase II Feasibility

Is Phase II feasible? Do

all UAV customers have

feasible assignments?

Check Previous Phase

Is prevPhase3 =True?

Solve (P3)

Set prevPhase3 =True. De-

termine the schedule of diﬀerent

activities. Is Phase III feasible?

Update Incumbent

If P3ObjVal is smaller

than OFV∗, update OFV∗,

TSPtour∗,UAVsorties∗

and ActivityTimings∗

Modify Assignment

Insert a UAV customer with

the cheapest cost in the

truck route, ensuring unique

TSP tour. Is it possible?

Improvement Step

Try to reduce make-span

by moving a truck customer

to a UAV, ensuring unique

TSP tour. Is it possible?

Local Search

For customers where truck

waits for retrieval, try shift-

ing retrieval points for corre-

sponding UAVs to the next

location. Is a shift possible?

Solve (P3)

Determine the schedule

of diﬀerent activities.

Is Phase III feasible?

Increment LTL

Set LTL =LTL + 1,

set prevPhase3 = False

Yes

No

Yes

Yes

Yes

Yes

No

No

No

No

Yes

No

Yes

Yes

No

Yes

No

No

Yes Yes

No

No

Phase I

Phase II

Phase III

Figure 4: Heuristic ﬂowchart

18

process is repeated until either no further improvements are found, or the savings metric suggests

a cycle (i.e., inﬁnite loop) of moving the same customers between the truck and UAVs.

The third step (lines 28-66 of Algorithm 2) ensures that at least LTL customers are served. This

step also attempts to evaluate the feasibility of the UAV assignments that will be made in Phase

II. Feasibility is ﬁrst determined by identifying UAV customers jfor any UAV vthat do not have a

corresponding valid sortie hv, i, j, ki ∈ P(line 31) for customers iand kthat are currently assigned

to the truck’s route.

Feasibility is further assessed via the checkP2Feasibility() function, which solves the following

objective-free integer linear program:

X

j∈Hi

rij ≤ |V| ∀ i∈TruckCustomers ∪ {0},(62)

X

i∈Gj

rij = 1 ∀j∈UAVCustomers,(63)

rij ∈ {0,1} ∀i∈TruckCustomers ∪ {0}, j ∈UAVCustomers.(64)

The set Gjcontains all customers i∈TruckCustomers ∪ {0}that can act as a UAV launch point

for customer j∈UAVCustomers, such that the retrieval point k∈N+is immediately after iin the

TSPtour and hv, i, j, ki ∈ P. Similarly, Hiis the set of customers j∈UAVCustomers that can be

served by launching from customer i∈TruckCustomers ∪{0}, such that the retrieval point k∈N+

is immediately before iin the TSPtour and hv, i, j, ki ∈ P. Binary decision variable rij equals 1

if j∈UAVCustomers is assigned to i∈TruckCustomers ∪ {0}as the launch point. Constraint

(62) ensures that only a maximum of |V|UAVs can be launched from any launch location, while

Constraint (63) requires each UAV customer to have exactly one launch point. If a feasible solution

to these constraints exists, the function checkP2Feasibility() returns an empty set; otherwise,

the function returns a set of UAV customers that do not have feasible assignments.

If any infeasible UAV customers are identiﬁed, or if the number of truck customers is less than

the LTL, one customer at a time will be added to the truck’s tour. costjk represents the change

in the truck’s makespan that would result from inserting UAV customer jimmediately before

customer kin the truck tour. coverjk is the set of customers in infeasCust whose assignment

would become feasible by inserting jin the truck tour immediately before k.

In the event that inserting jinto the truck’s route leads to a reduction in the makespan (i.e.,

a negative cost), the scorejk metric is calculated by multiplying costjk by the number of UAV

customers supported by the insertion. This indicates that the beneﬁt is shared among numerous

UAV customers. Conversely, if the makespan increases by inserting j,scorejk is calculated as

the cost per infeasible UAV customer that is being supported. Thus, if two insertions have the

same cost, the one that may eliminate a larger number of infeasibilities would be preferable. In

lines 52 and 53, the UAV customers j∗

1and j∗

2with minimum costjk and scorejk , respectively,

are identiﬁed. If there are no infeasible UAV customers but the number of truck customers is

less than LTL, we choose to move the customer with the cheapest cost to the truck (and re-solve

the TSP). However, if infeasible UAV customers have been identiﬁed and a suﬃcient number of

truck customers have already been added, we choose to insert the customer with the cheapest score

immediately before customer k. Otherwise (i.e., if there are infeasible UAV customers and the

length of the truck route is less than LTL), the customer with the cheapest score is added to the

truck route and a new TSP tour is generated. This process of moving customers to the truck route

is continued until there are no more UAV customers with infeasible assignments and there are at

least LTL truck customers.

19

Phase I continues in Line 67 of Algorithm 3, where the truck tour is perturbed if it has been

previously evaluated. If such a modiﬁcation is necessary, the procedure attempts to (1) swap a

truck customer and a UAV customer, (2) perform a subtour reversal (i.e., i→j→k→lbecomes

i→k→j→l), and (3) reverse the entire TSP tour. The modiﬁcation that produces a unique

truck route with the minimum associated cost is selected. If no unique tour is found, the value of

LTL is increased by one and the procedure returns to Phase I. Otherwise, a lower bound is generated

by using the TSP duration (including truck customer service times) and adding launch and retrieval

times for the UAV customers. If the lower bound exceeds the current incumbent (OFV∗), the LTL is

updated and the procedure repeats Phase I. If the bound is less than the current incumbent, the

procedure continues to Phase II.

Algorithm 1 Pseudocode for Phase I – Part 1 of 3

1: # Initialize:

2: TruckCust = all j∈ {C:j /∈ˆ

Cv∀v∈V}

3: UAVCust =C\TruckCust

4: TSPtour =getTSP(TruckCust)

5:

6: # Reduce TSP tour cost by adding/removing truck customers:

7: while (improvements are possible and no cycles occur) do

8: # Try to move customers from UAV to truck:

9: for j∈UAVCust do

10: savings = max

v∈V,hi,ki∈TSPtour

(τik +sL

vj +sR

vj −τij −τjk −σj)

11: if (savings >0) then

12: TruckCust ←TruckCust ∪ {j}

13: end if

14: end for

15: UAVCust ←UAVCust \TruckCust

16: TSPtour ←getTSP(TruckCust)

17:

18: # Try to move customers from truck to UAV:

19: for j∈ {TruckCust :j∈ˆ

Cvfor any v∈V}do

20: savings ←max

hv,i,j,ki∈P(τij +τjk +σj−τik −sL

vj −sR

vj )

21: if (savings >0) then

22: UAVCust ←UAVCust ∪ {j}

23: end if

24: end for

25: TruckCust ←TruckCust \UAVCust

26: TSPtour ←getTSP(TruckCust)

27: end while

4.2 Phase II – Create UAV sorties

The goal of Phase II is to determine the individual sorties hv, i, j, kifor each UAV v, where iis

the launch location, jis the customer that is being served by the UAV, and kis the retrieval

location. This is analogous to determining the yvijk decision variables in the mFSTSP formulation.

Pseudocode for Phase II is provided in Algorithms 4 and 5.

20

Algorithm 2 Pseudocode for Phase I – Part 2 of 3

28: # Move customers to truck for feasibility (and to satisfy LTL requirement):

29: feasible =False # Assume infeasible by default

30: while (not feasible)do

31: infeasCust = all j∈ {UAVCust :hv, i, j, ki/∈P∀v∈V, i ∈TruckCust, k ∈TruckCust}

32: if (infeasCust == ∅)then

33: infeasCust ←checkP2Feasibility(UAVCustomers,TSPtour)

34: end if

35: if ((infeasCust == ∅)and (len(TruckCust)≥LTL)) then

36: feasible ←True

37: else

38: for j∈UAVCust do

39: for k∈TruckCust ∪ {c+ 1}do

40: costjk = min

hi,ki∈TSPtour,hv,i,j,ki∈P(τij +τj k +σj−τik −sL

vj −sR

vj )

41: coverjk = all l∈ {infeasCust : (hv, m, l, jior hv, j, l, mi)∈P∀v∈V , m ∈

TruckCust}

42: if (j∈infeasCust)then

43: coverjk ←coverjk ∪ {j}

44: end if

45: if (costjk <0) then

46: scorejk =costjk ∗len(coverjk )

47: else

48: scorejk =costjk /len(coverjk )

49: end if

50: end for

51: end for

52: hj∗

1, k∗

1i= arg min

j∈UAVCust,k∈TruckCust∪{c+1}

(costjk )

53: hj∗

2, k∗

2i= arg min

j∈UAVCust,k∈TruckCust∪{c+1}

(scorejk )

54: if ((infeasCust == ∅)and (len(TruckCust)<LTL)) then

55: TruckCust ←TruckCust ∪ {j∗

1}

56: TSPtour ←getTSP(TruckCust)

57: else if ((infeasCust 6=∅)and (len(TruckCust)≥LTL)) then

58: TruckCust ←TruckCust ∪ {j∗

2}

59: TSPtour ←insert j∗

2in current TSPtour immediately before k∗

2

60: else

61: TruckCustomers ←TruckCustomers ∪ {j∗

2}

62: TSPtour ←getTSP(TruckCustomers)

63: end if

64: UAVCust ←UAVCust \TruckCust

65: end if

66: end while

21

Algorithm 3 Pseudocode for Phase I – Part 3 of 3

67: Modify TSP tour if not unique. If no unique tour is found, increase LTL and repeat Phase I.

68:

69: # Evaluate lower bound:

70: lowBound =TSPcost + min

v∈V

X

j∈UAVCust sL

vj +sR

vj

71: if (lowBound >OFV∗)then

72: increaseLTL() # See function below

73: else

74: Continue to Phase II.

75: end if

76:

77: procedure increaseLTL( )

78: LTL ←LTL + 1

79: prevPhase3 =False

80: if (LTL ≤ |C|)then

81: Return to Phase I with new LTL value.

82: else

83: Stop. Report OFV∗,TSPtour∗,UAVsorties∗,ActivityTimings∗.

84: end if

85: end procedure

Inputs to this phase include the set of customers to be assigned to UAVs (UAVcust) and the

truck route found in Phase I (TSPtour). Additionally, the earliest time at which the truck can

arrive at each location on the route, denoted as tjfor all j∈TSPtour, is calculated. While tj

incorporates truck customer service times, UAV launch and retrieval times are ignored. Thus, tj

is sum of the arrival time at jaccording to TSPtour and the service times at all previous truck

customer locations.

This phase begins in lines 3–6 by initializing the lists of UAV sorties (UAVsorties), customers

with no feasible assignments (infeasCust), UAVs available at each launch location (availUAVsj),

and unassigned UAV customers (UnasgnCust).

Next, in lines 8–12, the number of potential UAV sorties (numOptionsj) is determined for

each UAV customer j. We deﬁne P0⊆Psuch that hv, i, j, ki ∈ P0represents only valid i, j, k

combinations where iand kare consecutive stops on the truck’s tour. Thus, in Phase II, there

are no truck customers between the launch and recovery points in the UAV sorties. A local search

procedure is applied in Phase III to relax this restriction (i.e., to allow the truck to make multiple

stops while a UAV is en route).

In lines 14–32, UAV sorties are generated. Customers with the minimum numOptions are

prioritized, as they possess the fewest number of feasible candidate sorties. For each chosen UAV

customer, j, the assignment hv, i, j, ki ∈ P0is selected based on its impact on the waiting time for

both the truck and the UAV. Variable w(line 20) captures the time diﬀerence between the UAV’s

activities (travel from launch point ito customer j, serve customer j, and travel to retrieval point

k) and the truck’s activities (travel from launch point ito retrieval point k). A positive value of

windicates that the truck must wait for the UAV. If (WaitTime ≥0) and (w<WaitTime), the

current truck assignment incurred a waiting time that can be reduced by assigning this UAV sortie.

Conversely, if WaitTime <w<0, this UAV assignment would lead to a reduction in the time

22

that a UAV would wait for the truck. Thus, the aim is to ﬁnd an assignment that results in zero

truck waiting and minimum UAV waiting, or minimum truck waiting (if zero truck waiting is not

possible). If no feasible assignment is found (line 26), the customer is added to the infeasCust list;

otherwise (line 28), the assignment is stored in the UAVsorties list and the corresponding UAV

becomes unavailable at the corresponding launch location i∗.

If any UAV customers remain without an assigned sortie, it is necessary to move a UAV customer

to the truck route. In lines 34–37 of Algorithm 5 we calculate cheapestInsCost, which is the

minimum cost associated with inserting a UAV customer into the current TSP tour which might

make Phase II feasible. The following costs comprise cheapestInsCost, and are associated with

the insertion of UAV customer iinto position pof the truck route:

cins

i,p = Additional time associated with inserting customer i∈UAVCust into position pof

the truck’s route.

=τh,i +σi+τi,k −τh,k,

where node his at position p−1 and node kis at position pin TSPtour.

cwait,launch

i,p,j = Truck waiting time if a UAV were launched from customer i∈UAVCust inserted

into position p∈ {TSPtour positons}to serve customer j∈infeasCust \i.

= min

v∈V

k∈{TSPtour positions after p}τ0

v,i,j +σ0

v,j +τ0

v,j,k −(tk−ti−σi),

cwait,retrieve

i,p,j = Truck waiting time if a UAV were retrieved at customer i∈UAVCust inserted

into position p∈ {TSPtour positons}after serving customer j∈infeasCust \i.

= min

v∈V

k∈{TSPtour positions before p}τ0

v,k,j +σ0

v,j +τ0

v,j,i −(ti−tk−σk),

cwait

i,p,j = Minimum time the truck would spend waiting for a UAV, if the UAV is

launched or retrieved at customer i∈UAVCust inserted into position

p∈ {TSPtour positions}to serve customer j∈infeasCust \i.

= min{cwait,launch

i,p,j , cwait,retrieve

i,p,j }.

cfail

i,p,j = Cost of inserting j∈infeasCust into the truck’s route, if inserting customer

i∈UAVCust \jinto position p∈ {TSPtour positions}cannot make the assignment

of customer jfeasible.

= min

hi,ki∈TSPtour

τi,j +σj+τj,k −τi,k.

Thus, we may calculate

cheapestInsCost = min

i∈UAVCust, p∈{TSPtour positions}

cins

i,p +X

j∈infeasCust cwait

i,p,j +cfail

i,p,j

.(65)

The indices resulting in cheapestInsCost are saved as imin and pmin.

The lower bound, λ(line 40), reﬂects the truck tour duration (including truck service time),

launch and retrieval times for UAV customers, and cheapestInsCost (in the event that there

are UAV customers with no feasible assignments). If the lower bound is not promising (line 42),

23

increase the LTL and return to Phase I.

If no infeasible UAV assignments have been identiﬁed (line 44), the procedure continues to

Phase III. Otherwise, if Phase II infeasibility occurred as a result of trying to improve upon the

Phase III solution (line 47), stop the trial for improvement and return to Phase I with a new (or the

same) LTL. In lines 50–57, insert customer imin into position pmin in the truck’s route and update

the truck tour. If this tour is unique, repeat Phase II. Otherwise, return to Phase I with a new (or

the same) LTL value.

Algorithm 4 Pseudocode for Phase II – Part 1 of 2

1: Inputs: TSPtour,