Intelligent Control and Optimization of Cooperative Transportation Between a Single Drone and an Autonomous Vehicle Under Dynamic Weather Conditions

Abstract

To address the challenges of reduced delivery efficiency, complex routing decisions, and limited system robustness in cooperative transportation involving a single drone and an autonomous vehicle under dynamic weather conditions, this study investigates the optimization of drone–autonomous vehicle collaborative delivery in complex and uncertain environments. The objective is to improve task execution efficiency while enhancing the adaptability of the transportation system to dynamic disturbances. To this end, an optimization model is developed by incorporating weather variations, drone–vehicle coordination constraints, and the spatiotemporal characteristics of delivery tasks. Based on this model, a dedicated solution algorithm is proposed to achieve efficient joint optimization of route planning and task allocation in complex environments. Numerical results demonstrate that, for the same randomly generated instance, the drone–truck collaborative delivery strategy reduces the delivery time from 414.55 to 385.10 compared with the truck-only scheme, corresponding to an improvement of 7.1%, thereby confirming the effectiveness of the collaborative transportation strategy. Furthermore, when weather factors are taken into account and drone–truck cooperation is allowed, the proposed algorithm reduces the delivery time from 392.84, obtained by a conventional algorithm, to 338.39, yielding a performance improvement of 13.8%. These results verify the effectiveness and superiority of the proposed algorithm in dynamic weather environments. Overall, the proposed method significantly improves the efficiency of the cooperative transportation system and provides theoretical support and methodological guidance for drone–autonomous vehicle collaborative delivery in complex environments.

1. Introduction

1.1. Problem Taxonomy and Core Formulations for Truck–Drone Collaboration

The investigation into truck–drone collaborative routing has been extensive, with the objective being the enhancement of last-mile logistics through the joint optimisation of truck routes and drone sorties (launch–serve–recover) under synchronisation constraints (e.g., rendezvous and waiting). The fundamental taxonomy can be traced back to the so-called Flying Sidekick Traveling Salesman Problem (FSTSP) and the Parallel Drone Scheduling Traveling Salesman Problem (PDSTSP), which were proposed by Murray and Chu. The FSTSP emphasises the insertion of drone sorties into a truck route, characterised by tight temporal coupling. In contrast, the PDSTSP reflects a parallel division of labour, with trucks serving customers located farther from the depot, while drones cover nearby customers within flight range [1].

Building on these early structures, Agatz et al. proposed the Traveling Salesman Problem with Drone (TSPD), which differs from FSTSP in its operational assumptions and notably allows multiple drone launches from the same location, increasing routing flexibility and offering a more general abstraction for cooperative last-mile operations [2]. Collectively, these formulations established the canonical decision components: The primary focus of this study is the customer assignment to truck versus drone, in addition to the launch and recovery node selection, and the time synchronisation policies.

At the systems level, Macrina et al. provided a structured survey that consolidates this taxonomy by separating drone routing studies into drone-only operations and truck–drone cooperative operations [3]. The cooperative class is further divided into TSPD-type and VRPD-type problems, and the TSPD family is subdivided into FSTSP and PDSTSP. This taxonomy provides a clearer understanding of the modelling landscape and demonstrates how the introduction of increased realism typically results in the addition of coupling constraints and elevated computational complexity.

1.2. Model Extensions Toward Scale, Uncertainty, and Dynamic Operations

Following the pioneering development of one-truck-one-drone models, research progressed towards the creation of larger-scale systems. Tu et al. [4] extended the setting to one vehicle with multiple drones, termed TSPmD, and proposed a greedy adaptive search to cope with the enlarged solution space. Wang, Poikonen and Golden further introduced the Vehicle Routing Problem with Drones (VRPD) for multiple vehicles and multiple drones, and provided worst-case analyses showing that extreme-case performance is influenced by the number of drones carried and the drone-to-truck speed ratio [5]. The present studies illustrate how altering the fleet structure affects both the performance potential and the theoretical and computational properties.

Recent research has seen an increasing incorporation of uncertainty and operational dynamics, albeit typically via demand or time variability. Wang, Li and Xiong’s research focused on the analysis of stochastic demand in the context of truck–drone delivery systems, with a particular emphasis on the exploration of collaborative replenishment strategies [6]. In their seminal work, Liu et al. pioneered a novel approach to modelling stochastic travel time as a Markov decision process, employing reinforcement learning to facilitate a paradigm shift from static planning to sequential decision-making under uncertainty [7]. Otto et al. examined incomplete information in disaster relief contexts and analysed delivery and online re-optimisation policies with a worst-case perspective, which is relevant to high-uncertainty and safety-critical operations [8]. Gu, Liu, and Poon proposed a dynamic truck–drone routing framework that can accommodate both scheduled deliveries and on-demand pickups, thereby facilitating dynamic assignment and replanning [9].

Despite the fact that these works considerably extend the applicability of truck–drone routing, the “dynamic” factors are principally demand- or travel-time-driven. In comparison, dynamic weather and no-fly zones alter aerial feasibility and flight cost structures more fundamentally, as they reshape reachable airspace and may require detours or temporary grounding—elements that are still not systematically integrated into the most common single-truck–single-drone cooperative formulations.

1.3. Solution Methodologies and the Research Gap Toward Dynamic Weather and No-Fly Zones

Methodologically, solution approaches have evolved from exact optimization to scalable heuristics/metaheuristics and learning-based methods. Boccia et al. advanced exact and mathematical capabilities for a one-truck-one-drone problem. This problem allows a drone to serve multiple nodes in a single flight. The work used valid inequalities and a branch-and-cut framework. This was to strengthen solution quality and optimality guarantees [10]. Heuristic and hybrid strategies continue to be prominent for practical instance sizes: De Freitas and Penna proposed a hybrid scheme for FSTSP, combining an exact initialisation (for a baseline TSP tour) with a heuristic insertion mechanism for drone sorties. This was supported by structured encodings of customer orders and truck/drone travel times [11].

Metaheuristics, and more specifically, genetic algorithms, have been refined through problem-aware encodings and decoding/repair procedures. Ha et al. [12] proposed an adaptive hybrid genetic algorithm for TSPD with new crossover and multiple local searches. In contrast, Mahmoudinazlou and Kwon [13] introduced type-aware chromosomes that explicitly distinguish truck-served vs. drone-served nodes and use dynamic programming for decoding and fitness evaluation. Concurrently, learning-based approaches have gained traction: In their seminal study, Bogyrbayeva et al. [14] proposed a deep reinforcement learning framework (attention-based encoder + LSTM decoder) for TSPD, reporting results that were comparable to operations-research baselines. Survey evidence also supports the continuing relevance of local search, multi-stage frameworks, and hybrid algorithms as key directions for improving truck–drone routing solutions [15]. Future research will focus on real-time decision-making [16] and the consumption of electrical energy [17].

Across these streams, three limitations emerge for realistic deployment in the single-truck–single-drone setting: (1) Dynamic weather is rarely modelled explicitly as a time-dependent factor affecting drone speed, energy consumption, and safety feasibility windows; most uncertainty modelling focuses on demand or travel-time randomness. (2) It is evident that no-fly zones are not sufficiently integrated, particularly in cases where they are time-varying (e.g., temporary restrictions). This is due to the fact that they have the capacity to reshape feasible aerial paths and can invalidate planned launch–recovery pairings. Dynamic weather is rarely modelled explicitly as a time-dependent factor affecting drone speed, energy consumption, and safety feasibility windows; most uncertainty modelling focuses on demand or travel-time randomness. (3) As indicated in point, the development of a deployable dynamic collaboration framework that considers the joint aspects of truck routes, drone launch–recovery coupling, and rolling replanning under dynamic weather and no-fly constraints is still in its infancy.

Motivated by these discrepancies, the present study focuses on single-drone–single-vehicle cooperative transport under dynamic weather and no-fly zones. The objective of this study is to develop a model that incorporates the dynamics of weather and restricted airspace, transforming them into time-dependent feasibility and flight-cost functions. The model aims to optimise truck routing and drone sortie synchronisation under the evolving constraints. Additionally, it seeks to facilitate online and rolling-horizon replanning, ensuring the maintenance of feasibility and efficiency in the face of changing conditions.

2. Materials and Methods

Based on the above problem description, the emergency relief distribution problem with coordinated truck–drone transportation can be decomposed into two subproblems: (i) transportation mode selection for the truck and the drone, and (ii) route selection for both vehicles. As shown in Figure 1, a schematic diagram of collaborative transport between a single drone and a single truck.

In the mode selection subproblem, we consider the following factors: (1) certain nodes cannot be served by the drone due to operational restrictions (e.g., no-fly zones); (2) real-time weather conditions may preclude drone service at some nodes; (3) temporal synchronization between the drone and the truck is required, including coordination of drone launch, service, and recovery with the truck’s schedule; and (4) the goal is to determine a mode assignment that minimises the overall completion time.

In the route selection subproblem, the key decisions are to: (1) identify truck and drone routes that minimise the total delivery time, and (2) account for weather-induced variations in drone flight time when determining the optimal routes.

We adopt the following assumptions:

• A single distribution center is considered, equipped with one truck and one drone.
• The truck and the drone can perform deliveries independently.
• At a rendezvous location, either vehicle may wait for the other.
• Each demand node is served exactly once, either by the truck or by the drone.
• In each sortie, the drone serves at most one demand node.
• The speed ratio between the drone and the truck is assumed to be constant but can be adjusted; different parameters can be set for different scenarios.
• Vehicle capacity constraints are ignored. The truck is assumed to carry sufficient supplies to satisfy the demands of all nodes assigned to it, and the drone is assumed to carry sufficient supplies to satisfy the demand of the single node served in a sortie.
• The effect of payload weight on the drone’s battery consumption is neglected.
• Delivery service time, charging time, and other service-related times are not considered.

Based on the above assumptions, the key issues in solving the cooperative transportation routing problem between the drone and the truck can be summarised as follows: the endurance of the drone; the determination of whether the drone is able to take off; the determination of the drone’s launch and landing nodes; the determination of whether the drone is able to land; and the travel time of both the drone and the truck.

Schematic Diagram of Cooperative Transport Between a Single Truck and a Single Drone.

This paper provides definitions and explanations of the parameters and variables required for this model, as shown in

Table 1. Set definition and symbols.

Symbol	Definition
$N$	$\mathrm{Set}\mathrm{of}\mathrm{nodes},N=\left\{0\right\}\cup C\cup \left\{n+1\right\}$
$C$	$\mathrm{Set}\mathrm{of}\mathrm{demand}\left(\mathrm{customer}\right)\mathrm{nodes},C=\left\{1,2,\dots ,n\right\}$
$S$	$\mathrm{Set}\mathrm{of}\mathrm{truck}\mathrm{nodes}\mathrm{where}\mathrm{UAV}\mathrm{takeoff}\mathrm{and}\mathrm{landing}\mathrm{are}\mathrm{permitted},S\subseteq N$
A	$\mathrm{Set}\mathrm{of}\mathrm{vehicle}\left(\mathrm{truck}\right)\mathrm{arcs}A=\left\{(i,k)\left|i,k\in N,i\ne k\right.\right\}$
U	$\mathrm{Set}\mathrm{of}\mathrm{UAV}\mathrm{arcs}/\mathrm{sorties}{A}^u=\left\{\left.(i,k)\in A\right|i\in S,k\in S\right\}$
$U$	$\mathrm{Ternary}\mathrm{Arc}\mathrm{Set}\mathrm{of}\mathrm{Drones},U=\left\{(i,j,k)\left|i\in S,k\in S,j\in C,i\ne j,j\ne k,i\ne k\right.\right\}$
$G$	Set of weather time windows.
$H$	Set of weather categories (types).

,

Table 2. Parameter symbols and definitions.

Symbol	Definition
$t_{ij}^v$	Travel (driving) time of vehicle $v$ from node $i$ to node $j$
$t_{ab}^f$	Baseline flight time of the UAV from node $a$ to node $b$ under normal weather
$W_i(t)$	Weather Risk Index at Node $i$ at Time $t$
$W_{i,g}$	The weather risk index at node $i$ within the time window $g$ satisfies the condition $W_{i,g}\in \left[0,1\right]$, and $W_i(t)$ is obtained by $\left[T{S}_g,T{E}_g\right]$ discretizing over the time window.
$e_j$	The drone service indicator for the client node $j$, if $e_j=1$ the node $j$ permits drone services; if $e_j=0$ the node $j$ is located in a no-fly zone.
${\theta }_i$	Upper Limit Threshold for Flight Risk at Node $i$, ${\theta }_i\in \left[0,1\right]$
$f_D$	UAV flight endurance (maximum flyable duration)
$d_{ij}$	Distance between node $i$ and node $j$
$\Delta$	Length (duration) of the time interval, $T{E}_g-T{S}_g=\Delta$
${\varphi }_{i,g}$	Node $i$ Time-of-Flight Multiplier in Time Window $g$
${\tau }_{ij}^u$	Drone Mission $(i,j,k)$ Take off Segment $(i,j)$ Flight Duration
${\tau }_{jk}^u$	Drone Mission $(i,j,k)$ Take off Segment $(j,k)$ Flight Duration
$\left[S_g,E_g\right]$	Endpoint of the weather system time window $g$

and

Table 3. Variable symbols and definitions.

Symbol	Definition
$x_{ij}$	Binary variable indicating whether the vehicle $v$ visits the node $i$ and then travels to the node $j$
$y_{ijk}$	Binary variable indicating whether the UAV takes off from node, $i$ visits node, $j$ and lands (is recovered) at node $k$
$z_j$	Binary variable indicating whether the customer $j$ is served by the truck.
$o_i$	Truck Arrival at Node $i$ Time
$t_i$	Time at which the truck arrives at the node $i$
$u_i$	Sequencing (ordering) variable
${\alpha }_{ijkg}\in \left\{0,1\right\}$	Takeoff time-window selection indicator.
${\beta }_{ijkg}\in \left\{0,1\right\}$	Service time-window selection indicator.
${\gamma }_{ijkg}\in \left\{0,1\right\}$	Recovery (retrieval) time-window selection indicator.
$C_{\max }$	Total completion time (makespan).

.

A single UAV mission (sortie) is represented by a ternary arc $(i,j,k)\in U$: the UAV takes off from a permitted truck node $i\in S$, serves customer $j\in C$, and is recovered at a permitted recovery node $k\in S$. The binary variable $y_{ijk}$ indicates whether sortie $(i,j,k)$ is executed. To map the takeoff–service–recovery events to weather time windows, three types of time-window selection indicator variables are introduced:

$${\alpha }_{ijkg},{\beta }_{ijkg},{\gamma }_{ijkg}\in \left\{0,1\right\}$$

which indicate that the takeoff, service, and recovery events of sortie $(i,j,k)$, respectively, occur in weather window $g$.

If a sortie is executed, each of the three events must select exactly one weather window:

$${\displaystyle \sum _{g\in G}{\alpha }_{ijkg}}=y_{ijk},{\displaystyle \sum _{g\in G}{\beta }_{ijkg}}=y_{ijk},{\displaystyle \sum _{g\in G}{\gamma }_{ijkg}}=y_{ijk},\forall (i,j,k)\in U$$

In addition, Big-M constraints are used to bind the event time variables to the selected weather-window interval. Taking the takeoff event as an example (if takeoff occurs at node $i$ and its time is denoted by $t_i$), we have

$$t_i\ge T{S}_g-M(1-{\alpha }_{ijkg}),t_i\le T{E}_g+M(1-{\alpha }_{ijkg}),\forall (i,j,k)\in U,\forall g\in G$$

The service and recovery events can be similarly bound to $\left[T{S}_g,T{E}_g\right]$ using ${\beta }_{ijkg}$ and ${\gamma }_{ijkg}$ together with their corresponding time variables.

Weather feasibility constraints and linear flight-time reformulation

(i)

Feasibility (no-fly) constraints

When the takeoff/service/recovery event of sortie $(i,j,k)$ is assigned to window $g$, the corresponding node must satisfy the flyability requirement:

$${\alpha }_{ijkg}\le F_{i,g},{\beta }_{ijkg}\le F_{j,g},{\gamma }_{ijkg}\le F_{k,g},\forall (i,j,k)\in U,\forall g\in G$$

Meanwhile, whether customer node $j$ permits UAV service is indicated by $e_j$; thus, it must hold that

$$y_{ijk}\le e_j,\forall (i,j,k)\in U$$

(ii)

Linearization of flight time

Let the baseline UAV flight time from node $a$ to node $b$ under normal weather be $t_{ab}^f$. This paper incorporates the weather impact into the two flight segments ${\tau }_{ij}^u$ and ${\tau }_{jk}^u$ in a linear manner using an “event-window multiplier correction”:

$${\tau }_{ij}^u={\displaystyle \sum _{g\in G}{\varphi }_{i,g}}{t}_{ij}^f{\alpha }_{ijkg},{\tau }_{jk}^u={\displaystyle \sum _{g\in G}{\varphi }_{i,g}}{t}_{jk}^f{\beta }_{ijkg},\forall (i,j,k)\in U$$

On this basis, the UAV endurance constraint is written as

$${\tau }_{ij}^u+{\tau }_{jk}^u\le f_D{y}_{ijk},\forall (i,j,k)\in U$$

The objective function aims to minimise the total time, specifically the shortest time for the drone-equipped truck to return to the distribution center, or the shortest time for the drone and truck to arrive at the distribution center at a later time.

$$\min C_{\max }$$

(1)

Risk indicators $W_{i,g}\in \left[0,1\right]$ are divided into 5 intervals, each corresponding to different flight time multipliers. The flight time multiplier function is as follows:

$${\varphi }_{i,g}=\Phi (W_{i,g})=\left\{\begin{array}{l}{\varphi }^{sun},W_{i,g}<0.3\\ {\varphi }^{cloud},0.3\le W_{i,g}<0.5\\ {\varphi }^{lightrain},0.5\le W_{i,g}<0.65\\ {\varphi }^{heavyrain},0.65\le W_{i,g}<0.75\\ {\varphi }^{storm},0.75\le W_{i,g}\le 1\end{array}\right.$$

(1)

After completing deliveries, trucks must return to the distribution center.

$${\displaystyle \sum _{k\in N}{x}_{0k}}=1$$

(2)

$${\displaystyle \sum _{i\in N}{x}_{i,n+1}}=1$$

(3)

(2)

Trucks are prohibited from returning to the starting point or departing again from the destination.

$${\displaystyle \sum _{i\in N}{x}_{i0}}=1$$

(4)

$${\displaystyle \sum _{k\in N}{x}_{n+1,k}}=0$$

(5)

(3)

Truck flow balancing at customer points ensures each truck visits a customer exactly once.

$${\displaystyle \sum _{i\in N}{x}_{ij}}=z_j,\forall j\in C$$

(6)

$${\displaystyle \sum _{k\in N}{x}_{jk}}=z_j,j\in C$$

(7)

(4)

Customers can only choose either drone or truck delivery; orders cannot be fulfilled simultaneously by both drones and trucks, nor can they be delivered repeatedly by either drones or trucks.

$$z_j+{\displaystyle \sum _{(i,j,k)\in U}{y}_{ijk}}=1,\forall j\in C$$

(8)

(5)

Only when the truck follows the actual curve can the drone perform its mission during this period, and the drone must be recovered from its departure point.

$${\displaystyle \sum _{j\in C}{y}_{ijk}}\le x_{ik},\forall (i,k)\in A$$

(9)

$${\displaystyle \sum _{j\in C}{y}_{ijk}}\le 1,\forall (i,k)\in A$$

(10)

(6)

When the target point is a no-fly zone, the drone cannot directly access it.

$$y_{ijk}\le e_j,\forall (i,j,k)\in U$$

(11)

(7)

Truck travel sequence: If the truck travels along the arc, the time the truck reaches point A is no earlier than time B.

$$o_k\ge t_i+t_{ik}^v-M(1-x_{ik}),\forall (i,k)\in A$$

(12)

(8)

Waiting within the node, the departure time is used no earlier than the arrival time.

$$t_i\ge o_i,\forall i\in N$$

(13)

(9)

Flight time during the takeoff phase of drone operations.

$${\tau }_{ij}^u={\displaystyle \sum _{g\in G}{\alpha }_{ijkg}}{\varphi }_{i,g}{t}_{ij}^f$$

(14)

(10)

Flight time during the landing phase of drone operations.

$${\tau }_{jk}^u={\displaystyle \sum _{g\in G}{\beta }_{ijkg}}{\varphi }_{j,g}{t}_{jk}^f$$

(15)

(11)

The truck must wait at the drop-off point until the drone has completed its landing, allowing both the drone and the truck to wait for each other.

$$t_k\ge t_i+{\tau }_{ij}^u+{\tau }_{jk}^u-M(1-y_{ijk}),\forall (i,j,k)\in U$$

(16)

(12)

Drone endurance constraints.

$${\tau }_{ij}^u+{\tau }_{jk}^u\le f_D+M(1-y_{ijk}),\forall (i,j,k)\in U$$

(17)

(13)

MTZ subring elimination.

$$u_i-u_k+(n+1)x_{ik}\le n,\forall i\ne k,i,k\in C$$

(18)

$$1\le u_i\le n,\forall i\in C$$

(19)

(14)

If the drone performs a mission, select one time window each for takeoff, delivery, and landing; if the mission is not performed, all time windows are 0.

$${\displaystyle \sum _{g\in G}{\alpha }_{ijkg}}=y_{ijk},\forall (i,j,k)\in U$$

(20)

$${\displaystyle \sum _{g\in G}{\beta }_{ijkg}}=y_{ijk},\forall (i,j,k)\in U$$

(21)

$${\displaystyle \sum _{g\in G}{\gamma }_{ijkg}}=y_{ijk},\forall (i,j,k)\in U$$

(22)

(15)

The takeoff time must fall within the selected time window.

$$T{S}_g-M(1-{\alpha }_{ijkg})\le t_i\le T{E}_g+M(1-{\alpha }_{ijkg}),\forall (i,j,k)\in U,g\in G$$

(23)

(16)

The service time must fall within the selected time window.

$$T{S}_g-M(1-{\beta }_{ijkg})\le t_i+{\tau }_{ij}^u\le T{E}_g+M(1-{\beta }_{ijkg}),\forall (i,j,k)\in U,g\in G$$

(24)

(17)

The landing time must fall within the selected time window.

$$T{S}_g-M(1-{\gamma }_{ijkg})\le t_i+{\tau }_{ij}^u+{\tau }_{jk}^u\le T{E}_g+M(1-{\gamma }_{ijkg}),\forall (i,j,k)\in U,g\in G$$

(25)

(18)

Ensure weather conditions at the departure point are suitable for flight.

$$W_{i,g}\le {\theta }_i+M(1-{\alpha }_{ijkg}),\forall (i,j,k)\in U,g\in G$$

(26)

(19)

Guarantee that the weather at the service location is suitable for flying.

$$W_{j,g}\le {\theta }_j+M(1-{\beta }_{ijkg}),\forall (i,j,k)\in U,g\in G$$

(27)

(20)

Guarantee the weather will be flyable at the recovery point.

$$W_{k,g}\le {\theta }_k+M(1-{\gamma }_{ijkg}),\forall (i,j,k)\in U,g\in G$$

(28)

(21)

The completion time shall not be earlier than the time of return to the distribution center.

$$C_{\max }\ge t_{n+1}$$

(29)

Variable domains.

$$\begin{gathered} o_i\ge 0,t_i\ge 0,C_{\max }\ge 0 \\ {\alpha }_{ijkg},{\beta }_{ijkg},{\gamma }_{ijkg}\in \left\{0,1\right\} \\ {x}_{ik}\in \left\{0,1\right\},y_{ijk}\in \left\{0,1\right\},z_j\in \left\{0,1\right\} \end{gathered}$$

This paper constructs a MILP model to describe the constraints of truck–drone collaborative delivery under no-fly zones and dynamic weather conditions. Given that this problem is NP-hard and direct computation is costly, a hybrid genetic algorithm combined with local search is employed during the solution phase. To avoid secondary uncertainties caused by real-time weather changes during the solution process, dynamic weather is treated as an exogenous time-varying input and processed in two stages:

(1)

During the case generation phase of dynamic weather simulation, a continuous-time weather risk sequence $W_i(t)$ is generated for each node on a unified system timeline, which is then discretised into time windows to obtain $W_{i,g}$. Based on $W_{i,g}$, the flight time multiplier ${\varphi }_{i,g}$ and flyable indication $F_{i,g}$ for each node within each time window are precomputed.

(2)

Path optimization during the solution phase treats $W_{i,g}$, ${\varphi }_{i,g}$, and $F_{i,g}$ as known input parameters, disregarding replanning caused by weather updates during execution.

Therefore, during the solution phase, there is no need to generate weather conditions on-site. Instead, by querying the pre-generated ${\varphi }_{i,g}$ and $F_{i,g}$ based on the time window index corresponding to the current time, the feasibility verification under weather conditions and flight time calculation can be completed.

To incorporate continuously varying weather conditions into a mixed-integer programming model, the time dimension is discretised. Continuous time $W_i(t)$ is divided into time windows $g$, resulting in $W_{i,g}$. The system timeline is a continuous variable $t\ge 0$. The system operation timeline is partitioned into multiple time windows of equal length, denoted as the set $G$. Each time window has a duration of $\Delta$, and the $g$th time window corresponds to the interval $\left[T{S}_g,T{E}_g\right]$.

$$T{S}_g=(g-1)\Delta$$

(30)

$$T{E}_g=T{S}_g+\Delta$$

(31)

The correspondence between continuous time $t$ and time window index $g$ is as follows:

$$g=\left[{\displaystyle \frac{t}{\Delta }}\right]+1$$

(32)

To embed the decision-making process of continuous system timeline $t\ge 0$ into MILP and incorporate dynamic weather effects, this paper discretises the real-time weather process into a set of weather time windows $G$ of fixed length $\Delta$. For any $g\in G$, its start and end points are defined as: (30) and (31). In the example, Δ = 30 (unit time) is selected. The choice of Δ reflects a trade-off between precision and scale: a smaller Δ captures weather variations more finely, but the binary choice variables related to weather windows (such as ${\alpha }_{ijkg},{\beta }_{ijkg},{\gamma }_{ijkg}$) and their corresponding Big-M constraints will grow approximately linearly with |G|, significantly increasing the difficulty of solving the MILP.

Within each time window, assuming the weather conditions at node $W_{i,g}$ remain approximately constant, the weather risk level at node $i$ during time window $g$ is denoted by weather risk indicator A. The timing of drone takeoff, delivery, and landing events can be mapped to corresponding time windows to enable “window-based lookup” for weather constraint verification and flight time calculation. This discretization method ensures the model’s linearizability for solubility while approximating the impact of time-varying weather on drone flight feasibility and duration. In the example, $\Delta =30$ is selected. Weather risk indicator $W_i(t)$ is discretized into $W_{i,g}\in \left[0,1\right]$ by time window.

The dynamic weather system is constructed independently from the drone–truck collaborative transportation system, accounting for the impact of weather conditions on drone flight operations. The development of this weather system must address the following critical issues:

(1)

Configuration between real-time weather data and algorithm-generated weather data.

(2)

Short-term stability of the weather system, ensuring consistent weather queries at the same time and location.

(3)

Randomness within the weather system, guaranteeing unpredictable weather patterns across different locations and time periods.

To address the discrepancy between real-world weather time and algorithmic weather time, the system employs cumulative time. This cumulative time represents the elapsed period since the start of the drone–truck collaborative transport system, specifically from when the truck carrying the drone departs the distribution center. This cumulative time serves as the algorithmic time, which is then converted to real-world time at a fixed ratio. The calculation formula is shown in Equation (33).

$$t_{real}=0.1t_{system}\mathrm{mod}24$$

(33)

where $t_{\mathrm{real}}$ represents the actual weather time, and $t_{\mathrm{system}}$ represents the system cumulative time.

To ensure short-term stability of the weather system, it is necessary to guarantee that multiple queries at the same time and node return identical weather conditions. A fully randomised weather system cannot meet this requirement. Therefore, a time window with a fixed interval based on system time is established, ensuring identical weather queries within the same time window. In this system, the time interval is set to 30 system cumulative time units, forming a time window. Starting from the system cumulative time, the first 30 system cumulative time units constitute Time Window 1, the next 30 system cumulative time units form Time Window 2, and so on. A diagram illustrating the specific time window is shown in Figure 2.

To account for the randomness of weather systems, it is necessary to ensure that weather conditions exhibit randomness across different locations and times, thereby establishing varying weather risks. The original weather risk comprises three components: base risk, actual time weather risk, and disturbance impact. The base weather risk is randomly assigned, while the actual weather risk is derived by substituting the actual time into the function.

$${\tilde{W}}_i(t)=\left({\mu }_i+\xi \sin \left({\displaystyle \frac{2\pi (t_{\mathrm{real}}-6)}{24}}\right)+{\epsilon }_{i,t}\right)$$

(34)

$$W_i(t)=\min \left\{1,\max \left\{0,{\tilde{W}}_i(t)\right\}\right\}\in \left[0,1\right]$$

(35)

Among these, ${\tilde{W}}_i(t)$ represents the original weather risk indicator for node $i$ at time $t$, ${\mu }_i$ denotes the baseline risk level for node $\xi$, ${\epsilon }_{i,t}$ signifies the daily cycle fluctuation amplitude, and G indicates the disturbance factor.

Multiple sampling points are taken along a continuous time axis. For each time window $g$, the set of all sampling points within that window is aggregated according to the following Formula (36) to obtain the complete weather trajectory.

$$W_{i,g}=\max W_i(t)$$

(36)

Let node $i$ have a weather risk indicator $W_i(t)\in \left[0,1\right]$ at continuous time $t$. For any $g\in G$, the risk process over the interval $\left[T{S}_g,T{E}_g\right]$ is discretely aggregated into an in-window risk level $W_i(t)\in \left[0,1\right]$. To ensure reproducibility, this paper adopts a conservative aggregation method of “taking the maximum value within the time window”: (36)

Based on node risk threshold ${\theta }_i\in \left[0,1\right]$, define flight feasibility indicator $F_{i,g}\in \left\{0,1\right\}$. Simultaneously, to characterise the increase in flight duration caused by risks, introduce the flight time multiplier A for node $i$ within time window $g$. This paper precomputes ${\varphi }_{i,j}\in \left[1.0,2.0\right]$. ${\varphi }_{i,j}$ from $W_{i,g}$ (either using piecewise constant or piecewise linear forms; to maintain MILP linearity, piecewise constant mapping is adopted here). Consequently, $\left\{W_{i,g},F_{i,g},{\varphi }_{i,g}\right\}$ is precomputed for all nodes $i$ and time windows $g$ prior to modeling and serves as a known parameter input for the MILP.

For easy reference, a parameter summary table has been created, as shown in

Table 4. Parameter summary table.

Parameter	Meaning	Unit	Range
${\tilde{W}}_i(t)$	Original Weather Risk Value at Time $t$ for Node $i$	-	$\left[0,1\right]$
$W_i(t)$	Risk Indicator at Node $i$ at Time $t$	-	$\left[0,1\right]$
$W_{i,g}$	Risk Level of Node $i$ in Time Window $t$	-	$\left[0,1\right]$
${\varphi }_{i,g}$	Node $i$, Time Window $g$ Flight Time Multiplier	-	$1.0\sim 2.0$
$F_{i,g}$	Flight Feasibility Indicator for Node $i$, Time Window $g$	-	0 or 1
$g$	Time Window Index	-	$g=\left[{\displaystyle \frac{t}{\Delta }}\right]+1$
$T{S}_g$	Starting Point of the $g$th Time Window	Unit time	$T{S}_g=(g-1)\Delta$
$T{E}_g$	End of the $g$th Time Window	Unit time	$T{E}_g=T{S}_g+\Delta$
$t$	Continuous System Timeline	Unit time	$t\ge 0$
$G$	Time Window Set	-	$g\in G$
$\Delta$	Time Window Length	Unit time	Example calculation $\Delta =30$
$t_r$	Real-time Weather	hour	$t_r\ge 0$
$\omega$	System Time to Real Event Mapping Factor	hour/Unit time	0.1
$t_s$	System Cumulative Time	Unit time	$t_s\ge 0$
${\mu }_i$	Basic Risk Level of Node $i$	-	dimensionless, $\left[0,1\right]$
$\xi$	Daily Cycle Fluctuation Range	-	dimensionless
${\epsilon }_{i,t}$	Disturbance Term	-	dimensionless

:

Typical MILP scale under time discretization (number of binary variables and constraints).

The additional binary variables introduced by time-window discretization are mainly ${\alpha }_{ijkg},{\beta }_{ijkg},{\gamma }_{ijkg}$. For each $(i,j,k)\in U$, each type corresponds to $\left|G\right|$ variables. Therefore, the total number of newly introduced binary variables is $3\left|U\right|\left|G\right|$. Correspondingly, the number of unique time-window selection constraints is $3\left|U\right|$; the number of time-window interval binding constraints (upper and lower bounds) is approximately $6\left|U\right|\left|G\right|$; and the number of weather feasibility constraints is approximately $3\left|U\right|\left|G\right|$. Hence, the scale of variables and constraints introduced by discretization grows approximately linearly with $\left|G\right|$.

Since branch-and-bound solvers are sensitive to binary variables and Big-M constraints, when $\Delta$ decreases and consequently $\left|G\right|$ increases, the MILP solving time increases significantly. Therefore, heuristic methods are adopted as the primary solution strategy for medium- and large-scale instances in this study, while MILP solvers are applied to small-scale instances to verify feasibility and modeling correctness (with the solving time and optimality gap reported).

The overall workflow of the weather system is illustrated in Figure 3. First, node and system cumulative time are input into the weather system to generate initial weather probabilities for each node, with an appropriate time interval (time window) set. Next, the system processes the cumulative time to derive the actual time. Then, the actual time is fed into the actual weather calculation function. Finally, the weather conditions for each node at different times are obtained.

The pseudocode for the weather system is as follows (Algorithm 1):

Algorithm 1: Dynamic Weather Simulator (offline generation with time-window stability)

Input: node set $N$, time windows $G$, window length $\Delta$, sampling step $S$, mapping factor $\omega$, parameters ${\left\{{\mu }_i\right\}}_{i\in N}$, $\xi$, disturbance scale $\sigma$ threshold ${\left\{{\theta }_i\right\}}_{i\in N}$, random seed $seed$ (and optional spatial correlation $\rho$). Output: $W_{i,g}$, ${\varphi }_{i,g}$, $F_{i,g}$ for all $i\in N$, $g\in G$. 1. Initialise RNG with $seed$. Initialise cache Cache $\left[(i,g)\right]=None$ for all $i\in N,g\in G$. 2. For each time window $g\in G$: 2.1 Compute window endpoints $T{S}_g=(g-1)\Delta ,T{E}_g=T{S}_g+\Delta$ 2.2 Construct sampling time set $T_g=\left\{T{S}_g,T{S}_g+s,\dots ,T{E}_g\right\}$ 2.3 (Optional spatial correlation) Draw a global disturbance ${\eta }_g\sim N(0,{\sigma }^2)$ 2.4 For each node $i\in N$ If $Cache\left[\left(i,g\right)\right]$ exists, set $W_{i,g}=Cache\left[\left(i,g\right)\right]$ and continue. Else, for each sampling time $t\in T_g$: (a) Convert to real time $t_r=\omega t_s\mathrm{mod}24$. (b) Draw local disturbance ${\varsigma }_{i,t}\sim N(0, {\sigma }^2)$. (c) Set disturbance ${\epsilon }_{i,t}=\left\{\begin{array}{l}\rho {\eta }_g+\sqrt{1-{\rho }^2}{\varsigma }_{i,t}\\ {\varsigma }_{i,t}\end{array}\right.$ (d) Compute original risk ${\tilde{W}}_i(t)=\left({\mu }_i+\xi \sin \left({\displaystyle \frac{2\pi (t_{\mathrm{real}}-6)}{24}}\right)+{\epsilon }_{i,t}\right)$ (e) Clip to obtain $W_i(t)=\min \left\{1,\max \left\{0,{\tilde{W}}_i\right\}\right\}\in \left[0,1\right]$ Aggregate within window $W_{i,g}=\max W_i(t)$ store $Cache\left[\left(i,g\right)\right]=w\left\{i,g\right\}$ 3. For each $i\in N,g\in G$: 3.1 Compute flyability indicator $F_{i,g}=(W_{i,g}\le {\theta }_i)$ 3.2 Compute flight-time multiplier ${\varphi }_{i,g}$ from $W_{i,g}$ using a predefined mapping (e.g., piecewise-constant or piecewise-linear). 4. Return $W_{i,g},F_{i,g},{\varphi }_{i,g}$

A two-part encoding scheme is adopted for the UAV–truck system. The front segment is indicative of the truck route, whereas the rear segment encodes UAV sorties as triplets, with each triplet consisting of a launch node, a service (delivery) node, and a recovery (landing) node. As demonstrated in the accompanying figure, the sequence from 0 to 9 in the front segment signifies that the truck visits all demand nodes, while the trailing “2–3–4” denotes the UAV’s launch node, serviced node, and recovery node, respectively. Consequently, (2, 3, 4) constitutes a UAV sortie triplet.

The front segment exhibits a fixed length across chromosomes, as it enumerates the complete set of nodes in the truck tour. In contradistinction, the number of customers served by the UAV is not known a priori. This results in a variable-length rear segment, and consequently, chromosomes with different overall lengths. For instance, Chromosome 1 contains a single UAV-served customer, whereas Chromosome 2 contains two UAV-served customers, resulting in different chromosome lengths. As illustrated in the accompanying figure, the UAV serves one node in Chromosome 1, with the remaining nodes being served by the truck. In Chromosome 2, the UAV serves two nodes, while the remaining nodes are served by the truck. As shown in Figure 4, the yellow nodes represent truck delivery points, and the purple nodes represent drone delivery points.

The initialization scheme is shown in Figure 5. The initial population is generated using four chromosome-construction strategies: a truck-only solution, an aggressive solution, a conservative solution, and a random solution. In the truck-only solution, all customers are served by the truck. In the aggressive solution, the allocation of customers to either the truck or the UAV is determined by the feasibility of assigning them to the UAV, with priority given to the UAV. In the conservative solution, customers may also be assigned to either mode, and the UAV remains the preferred option. However, the number of UAV deployments is capped to limit UAV utilisation. In the random solution, customers are assigned to either the truck or the UAV without any deployment cap or preference bias.

Following the construction of the chromosome, a feasibility check is conducted. In the event of any customers being absent, they are to be inserted into the truck route. Conversely, in the event of duplicate customers being present, they are to be removed. As demonstrated in the accompanying figure, nodes serviced by trucks are highlighted in yellow, whereas those serviced by UAVs are highlighted in purple. It is important to note that different service assignments correspond to different initialization outcomes.

The fitness value is defined as the reciprocal of the total completion time; therefore, a longer travel time yields a lower fitness value. The process of fitness evaluation is conducted in accordance with the following sequence of steps:

The primary objective of this study is to verify customer coverage. Prior to the computation of fitness, it is imperative to ascertain that the solution encompasses all demand nodes.

The second element to be considered is that of feasibility (constraint) checking. The designed algorithm is integrated with the mathematical model to determine whether a solution satisfies all constraints, such as the constraint that the truck must depart from the depot and return to the depot after completing deliveries, and each customer can be served exactly once by either the truck or the UAV.

Thirdly, consideration must be given to meteorological conditions and restrictions pertaining to air travel. The system is utilised to ascertain the meteorological conditions experienced during UAV flight, thereby evaluating the viability of take-off and the projected duration of the flight.

The fourth method is that of fitness mapping. The calculation of fitness is dependent on the total duration of the route. The critical aspects of total-time evaluation include the calculation of (i) the synchronization time at truck–UAV rendezvous nodes and (ii) the truck arrival times at nodes. In the Figure 6, yellow circles represent truck-served nodes and purple circles represent UAV-served nodes. The total time is defined as the time required for the truck to depart from node 0, complete all deliveries, and return to node 0, while accounting for customers serviced by the UAV. During the interval between nodes 1 and 3, the truck and the UAV operate in parallel: the UAV serves node 5 while the truck serves nodes 1, 2, and 3. Consequently, the time at which the system can proceed beyond node 3 is determined by the maximum of the truck’s and the UAV’s arrival times at node 3. In the given example, the UAV requires 13 min whereas the truck requires 5 min; therefore, the UAV time governs. Consequently, when computing the overall completion time, particular attention must be paid to the truck arrival times and to synchronization at truck–UAV rendezvous nodes.

(1)

Elite Preservation Strategy

The elite preservation strategy is defined as the process of maintaining a subset of high-fitness individuals following evolutionary operations such as crossover and mutation. In this particular paradigm, individuals are evaluated according to their level of fitness, and a subset of the most effective solutions is replicated directly into the subsequent generation. This mechanism has the capacity to accelerate convergence, improve algorithmic stability, and prevent the loss of high-quality individuals due to stochastic genetic operations.

In this study, the implementation of elite preservation is articulated as such. Firstly, in each generation, a fixed proportion of high-fitness individuals is retained. Secondly, the globally best individuals identified to date are documented, thereby ensuring that, in the event of the algorithm displaying aberrant behaviour in a specific generation, these elite solutions can be retrieved to resume the search from reliable incumbents. Thirdly, the number of elite individuals is subject to dynamic adjustment. Proportional retention is congruent with the fundamental principle of elitism, thereby facilitating accelerated convergence through the consolidation of the search within the high-quality regions of the solution space. The global recording of the most accomplished individuals serves as a safeguard against the occasional occurrence of performance degradation during the course of evolution. Finally, the dynamic adaptation of the elite size has been shown to facilitate a balance between exploitation and exploration. In instances where the population exhibits limited improvement over multiple generations, the elite set is reduced and the proportion of non-elite individuals is increased. This, in turn, leads to an expansion in search diversity and, by extension, the explored region of the solution space is effectively enlarged.

(2)

Adaptive Parameters

Adaptive parameters are adjusted dynamically according to functional rules, rather than being treated as fixed constants. In the proposed algorithm, adaptivity is incorporated in two distinct aspects: firstly, in the mutation rate, and secondly, in the number of elite individuals. The iterative generation of offspring in a genetic algorithm can be interpreted as a search process over the solution space. In order to alleviate premature convergence and reduce the likelihood of becoming trapped in local optima, an adaptive mutation rate is employed. The precise formulation of the adaptive mutation rate is as follows:

$${\mu }_a(k)=\left\{\begin{array}{l}{\mu }_0,k\le 5,\\ \min (0.4,1.5{\mu }_0),5<k\le 15,\\ \min (0.5,2{\mu }_0),k>15.\end{array}\right.$$

In the formula, ${\mu }_0$ denotes the baseline mutation rate, $k$ denotes the number of stagnation generations, and ${\mu }_a(k)$ denotes the adaptive mutation rate. As the value increases, the mutation rate is increased accordingly, which promotes broader exploration of the solution space and helps the algorithm escape local optima. The number of elite solutions is adjusted in a similar manner: based on the stagnation generations, the corresponding parameter is increased or decreased to expand or contract the search scope.

(3)

Tournament Selection

Tournament selection is a process of random sampling, whereby a predetermined number of individuals are selected from a given population. The individual with the highest level of fitness is then chosen as the parent. The strategy under discussion has been shown to be effective in preserving population diversity, as evidenced by its implementation in the sampling process. This is achieved by permitting individuals with a lower level of fitness to participate. When combined with elitism, tournament selection achieves a balance between randomness (exploration) and determinism (exploitation).

In the proposed algorithm, tournament selection is used to determine parent individuals. Subsequent to the initialisation of the population, a predetermined number of individuals is randomly selected to constitute a tournament. The candidates are then evaluated based on their level of fitness, and the individual who demonstrates the highest level of aptitude is selected as a parent. It is imperative to note that the identical procedure is applied in every generation subsequent to the population update. As demonstrated in the accompanying figure, the nodes in yellow are representative of customers serviced by trucks, while those in purple correspond to customers serviced by UAVs. In the context of a tournament comprising three events, the initial tournament (hereafter referred to as ‘Tournament 1’) employs a fitness ranking system to select Parent 1. Subsequent tournaments are structured in a similar manner. As shown in Figure 7, a diagram of the tournament.

(4)

Crossover and Mutation

In consideration of the two-part encoding, which comprises a truck route and UAV triplets, it is acknowledged that individual lengths may vary due to the variable number of UAV sorties. Consequently, crossover and mutation are performed separately for the UAV segment and the truck segment. In the context of the truck segment, three distinct crossover operators are employed: order crossover (OX), partially mapped crossover (PMX), and edge recombination crossover (ERX).

The order crossover (OX) is illustrated in the Figure 8 below. The upper chromosome is designated as Parent 1, while the lower chromosome is labelled Parent 2. Each individual is indexed from 0 to 4, and the crossover segment is selected from index 1 to index 3 (highlighted in green in Parent 1). The offspring inherits the genes at indices 1–3 from Parent 1. The remaining positions are then filled by scanning Parent 2, starting from index 4, yielding the visiting order 4, 5, 3, 1, 24, 5, 3, 1, 2. Following the removal of the nodes already contained within the inherited segment (i.e., 2, 3, and 4), the remaining nodes are then inserted sequentially (i.e., 5 and 1), thus completing Offspring 1.

The concept of partially mapped crossover (PMX) is illustrated in the accompanying Figure 9. The crossover segment is selected from indices 2 to 3; the green segment taken from Parent 1 is {3, 4}. A mapping is then constructed between the two parents over this segment, namely 3 versus 1 and 4 versus 2. The remaining positions of the offspring are initially filled using the corresponding genes from Parent 2.

Specifically, the first position in Parent 2 is 5, which is inserted directly. The second position in Parent 2 is 3, but this value is a duplication of a gene already present in the inherited segment. Therefore, it is replaced according to the mapping, yielding 1. In a similar manner, the fifth position in Parent 2 is 4, which is also a duplicate. This is replaced by its mapped counterpart, 2. Consequently, the resulting offspring is [5, 1, 3, 4, 2].

The concept of edge recombination crossover (ERX) is illustrated in the accompanying figure. ERX places significant emphasis on the preservation of adjacency information, that is to say, the connections between neighbouring nodes (edges). In the provided example, Parent 1 is represented by the colour yellow, and Parent 2 by green. Initially, the adjacency relationships among nodes are identified separately for both parents (as illustrated in Step 2), and an adjacency list is subsequently constructed by merging the neighbour sets from the two parents (Step 3). In conclusion, the offspring is generated in accordance with a predetermined selection rule.

The procedure delineated in the Figure 10 can be summarised as follows:

The initial point of departure is designated as node 1. Its candidate neighbors are {2, 3, 5}. For each candidate, the number of remaining neighbours is to be counted after the removal of node 1 from its adjacency list. The subsequent node is selected as the candidate with the minimal neighbour count. In this instance, nodes 2 and 5 have the lowest counts, and either can be selected.

Following the selection of node 2, the adjacent nodes are determined to be 1, 3 and 4. With the previously selected node 1 excluded from the analysis, a comparison of the neighbour counts of nodes 3 and 4 is warranted. Given the equal counts, either 3 or 4 can be selected.

Following the selection of node 3, the adjacent nodes are determined to be 4 and 5. With the already selected nodes {1, 2} excluded from the analysis, a comparison of the neighbour counts of 4 and 5 is warranted. It is evident that the counts are equal on this occasion, and therefore it can be concluded that either node may be selected.

Following the selection of node 5, it is observed that only node 4 remains. Consequently, the offspring has been completed.

The implementation of UAV crossover is primarily achieved through three distinct operations: the regeneration of UAV triplets, the direct inheritance of UAV triplets, and the deletion of UAV triplets. As demonstrated in the accompanying Figure 11, yellow nodes are indicative of customers who are served by trucks, while purple nodes denote those served by UAVs. The initial panel corresponds to UAV-triplet regeneration, the subsequent panel to UAV-triplet inheritance, and the final panel to UAV-triplet deletion. It is evident that the UAV crossover performs recombination primarily within the set of triplets that have been presented in the parents. Additionally, the UAV crossover has the capacity to insert UAV triplets that are compatible with the newly generated truck route.

The term “mutation” is comprised of three constituent components: firstly, the specification of an adaptive mutation rate; secondly, truck-route mutation; and thirdly, UAV-node mutation. The adaptive variability rate is demonstrated in the formula and can be instantiated via different functional forms to emulate different evolutionary dynamics across iterations.

The implementation of truck-route mutation is achieved through the utilisation of three distinct operators: namely, swap mutation, in-version mutation, and insertion mutation. The random selection of two nodes on the truck route and subsequent exchange of their positions is known as swap mutation. Inversion mutation is a process that involves the selection of a specific sequence of nodes on a given graph. In this context, the two boundary nodes are kept fixed, while all intermediate nodes are reversed. This process is referred to as “inversion mutation” because it involves the inversion of a specific sequence of nodes. Insertion mutation involves the random selection of a node and its subsequent relocation to a different position in the route. As demonstrated in the accompanying figure, the initial panel illustrates the process of swap mutation, whereby nodes 2 and 4 are exchanged. The subsequent panel delineates the inversion mutation, characterised by the reversal of the segment between nodes 2 and 5. The final panel illustrates the insertion mutation, which involves the insertion of node 2 immediately following node 4. As shown in Figure 12, a diagram illustrating changes in the truck’s path.

The implementation of UAV-related mutation is achieved through the utilisation of three operators: The following procedures are to be followed:

(i)

The conversion of a UAV-served node into a truck-served node;

(ii)

The conversion of a truck-served node into a UAV-served node;

(iii)

The modification of the UAV launch and recovery nodes. As illustrated in the Figure 13, yellow nodes are used to denote truck-served customers, purple nodes are used to denote UAV-served customers, and blue nodes are used to denote UAV launch and recovery points. The initial panel provides a visual representation of the conversion of a UAV-served node to a truck-served node. The subsequent panel offers a visual depiction of the conversion of a truck-served node to a UAV-served node. Finally, the third panel illustrates the modification of the UAV recovery node from node 3 to node 4.

The proposed UAV-truck solution algorithm is designed as follows:

The initialization of parameters and the generation of instances are prerequisites for the subsequent steps in the process. The initial steps in the sequence of events comprise the initialisation of algorithmic parameters, the generation of benchmark instances, and the initialisation of the weather system.

The subsequent stage of the process is population initialisation and preprocessing. The initialisation of the population and subsequent classification of individuals into four distinct groups is imperative: namely, truck-only solutions, aggressive solutions, conservative solutions, and random solutions. Subsequently, the coverage checking procedure should be performed, followed by the application of local search in order to refine the solutions.

The third component of the study is the fitness evaluation. The feasibility of the solution is evaluated by checking compliance with the model constraints, and the total delivery time is computed, which is subsequently converted into the fitness value.

The termination check is the fourth step in the process. In the event that the maximum number of iterations is reached, the results should be visualised; otherwise, the process should be moved on to the next iteration.

The fifth point for consideration is that of evolutionary iteration. The population should be evolved according to the prescribed elite preservation strategy, adaptive-parameter scheme, and tournament-selection setting.

Sixthly, there is the concept of crossover and mutation with local improvement. With specified probabilities, perform crossover and mutation operations; subsequent to these operations, apply local search to further improve the offspring solutions.

The process of re-evaluation and subsequent ranking is a key component of the methodology. The subsequent steps involve the re-computation of fitness, the comparison of individuals, and the ranking of the population according to their level of fitness.

In this section, the eighth point to consider is the handling of duplicates and the completion of populations. Following two rounds of fitness evaluation, it is imperative to verify the absence of duplicate individuals. In the event of duplicates existing, these should be removed; otherwise, newly generated individuals should be added to form the updated population.

The ninth issue pertains to the identification of stagnation and the subsequent initiation of a restart or update process. It is imperative to monitor whether the population is stagnating, that is to say, whether the best (or overall) fitness remains unchanged across iterations. In the event of stagnation being detected, the population should be restarted; otherwise, the global best solution should be updated.

The final termination and visualisation process is the concluding stage of the procedure. It is imperative to verify whether the iteration limit has been attained. In the event that this is the case, the final results should be output and visualised; if not, the iteration process should be continued. The algorithm flowchart is shown in Figure 14.

3. Results

To validate the effectiveness of the proposed algorithm, benchmark instances are typically required. However, due to the incorporation of the dynamic weather system, relevant public instances are unavailable. Therefore, randomly generated instances are adopted for verification. Specifically, within a 100 × 100 square region, 12 demand nodes and one fixed depot are generated at random; the Cartesian coordinates of all nodes are reported in the table. The following assumptions are imposed:

(1)

The travel distance of both the UAV and the truck is measured using the Euclidean metric.

(2)

At the initial stage, the UAV cannot reach certain nodes; moreover, when the weather system produces thunderstorm conditions, the UAV is unable to serve some nodes.

(3)

Both the UAV and the truck carry emergency supplies, while the type and weight of the supplies are not differentiated.

(4)

The effect of carrying emergency supplies on the UAV’s battery consumption is ignored.

(5)

The truck can carry sufficient cargo to serve all demand nodes, whereas the UAV can carry cargo for only one demand node per sortie.

The coordinates of the demand nodes and related parameters are shown in

Table 5. Demand node coordinates.

Node	X	Y
0	50	50
1	63.94	2.50
2	27.50	22.32
3	73.64	67.67
4	89.22	8.69
5	42.19	2.98
6	21.86	50.54
7	2.65	19.88
8	64.99	54.49
9	22.04	58.93
10	80.94	0.65
11	80.58	69.81
12	34.03	15.55
13	95.72	33.66
14	9.27	9.67
15	84.75	60.37
16	80.71	72.97
17	53.62	97.31
18	37.85	55.20
19	82.94	61.85
20	86.17	57.74
21	70.46	4.58

,

Table 6. Basic parameter settings for the example.

Parameter Name	Parameter Value
Truck speed	1
Drone speed	2
Weather time step	10
Total weather time horizon	120
Number of weather states	5
Range of weather impact coefficient	1.0–2.0
Weather time window	30
Probability that the drone can perform delivery	0.8

and

Table 7. Basic parameter settings for genetic algorithms.

Parameter Name	Parameter Value
Population size	80
Maximum number of iterations	150
Mutation probability	0.9
Crossover probability	0.2
Elite retention ratio	0.1

.

When dynamic constraints (weather/no-fly zones) render landscapes more non-convex and fragmented, higher variability maintains diversity, while adaptive mechanisms further enhance escape capacity during stagnation.

The above data are then input into the proposed algorithm. After 150 iterations, the evolution of the objective value (iteration cost) with respect to the iteration count is shown in the figure. The iteration cost decreases from an initial value of 394.95 time units to a final value of 338.39 time units, corresponding to a performance improvement of 14.3%. Figure 15 shows the graph of the iterative changes in the total algorithm cost.

The final solution produced by the algorithm yields the cooperative routing plan of the truck and UAV, as illustrated in the figure. The corresponding weather conditions at each node at the time of truck arrival are reported in the

Table 8. Weather conditions at the truck arrival node.

Demand Node Index	Weather Condition	Weather Impact Factor
1	Clear	1.0
2	Clear	1.0
3	Cloudy	1.1
4	Clear	1.0
5	Cloudy	1.1
6	Cloudy	1.1
7	Cloudy	1.1
8	Clear	1.0
9	Clear	1.0
10	Clear	1.0
11	Light rain	1.2
12	Cloudy	1.1
13	Clear	1.0
14	Cloudy	1.1
15	Clear	1.0
16	Cloudy	1.1
17	Clear	1.0
18	Clear	1.0
19	Cloudy	1.1
20	Cloudy	1.1
21	Cloudy	1.1

.

The detailed routing map generated by the algorithm is shown in the Figure 16. In the plot, triangles indicate UAV-served customer nodes, whereas circles denote truck-served customer nodes. Different colors represent different weather conditions: yellow corresponds to sunny weather, gray to cloudy weather, light blue to light rain, dark blue to heavy rain, and brown to torrential rain. For the tested instance, neither torrential rain nor heavy rain is observed; only one light-rain event occurs, while the remaining conditions are primarily sunny or cloudy. The UAV serves nodes 2 and 10, and all other nodes are delivered by the truck. In the final solution, nodes 2 and 10 are assigned to the UAV, while the remaining nodes are served by the truck. This assignment is not predetermined; rather, it is the outcome of joint optimization. Specifically, these nodes are selected for UAV service because, under the realised weather windows and synchronization schedule, assigning them to the UAV yields a more favorable overall makespan. The main drivers include: (i) their compatibility with the initial UAV-service eligibility setting; (ii) feasible weather windows for takeoff, service, and recovery; (iii) acceptable synchronization with the truck at launch and rendezvous nodes; and (iv) the potential to avoid longer truck-side detours.

To validate the effectiveness of the collaborative strategy and weather-considering hybrid genetic algorithm, two sets of control experiments were conducted based on different algorithms: one comparing single-truck transportation without weather consideration to collaborative truck–drone transportation, and another comparing standard algorithms with hybrid genetic algorithms within the same case study for weather-considering collaborative truck–drone transportation. Iteration cost variation charts were plotted accordingly.

For the same randomly generated case study, the truck-only delivery time is 414.55 min on the left, while the collaborative drone–truck delivery time is 385.10 min on the right—a 7.1% improvement, demonstrating the effectiveness of the collaborative transportation strategy. Comparison chart, as shown in Figure 17.

For the same randomly generated case study, considering weather conditions and enabling coordinated transportation between drones and trucks, the standard algorithm achieved a delivery time of 392.84 min (left side), while the designed algorithm achieved 338.39 min (right side). The designed algorithm demonstrated a 13.8% performance improvement over the standard algorithm, proving its effectiveness. Comparison chart, as shown in Figure 18.

Run multiple instances (different node sets, multiple random seeds, varying densities) and display distribution statistics (mean/confidence intervals). Fixed configuration × 10 random seeds—verify stability of results across different random instances. Different node scales (12/17/22) × 10 seeds—testing algorithm performance across varying problem sizes. Different drone-achievable densities (50%/75%/100%) × 10 seeds—testing the impact of node density on results. The resulting plot is shown in Figure 19, Figure 20, Figure 21 and Figure 22.

4. Discussion

(1)

The impact of the ratio of the speed of the drone to that of the truck on the solution results.

In studying the UAV–truck cooperative delivery problem, the speed ratio between the UAV and the truck is assumed to be 2.0. To investigate the effect of the speed ratio on solution quality, four experiments are conducted. The UAV-to-truck speed ratio is set to 1.0 in Experiment 1, 1.5 in Experiment 2, 2.0 in Experiment 3, and 3.0 in Experiment 4. The coordinates of the depot and demand nodes are fixed across all experiments, and all other parameters remain identical.

For each speed ratio, the convergence curve over iterations and the final delivery routes are plotted. The convergence curves indicate that the best performance is achieved when the UAV-to-truck speed ratio equals 2.0, as this setting converges the fastest and yields the shortest completion time. When the speed ratio is 1.0 or 3.0, the final delivery time is the same as that obtained with a ratio of 2.0, but more iterations are required to reach convergence. The final routing plots further show that the truck route is identical for speed ratios of 1.0, 2.0, and 3.0; however, the UAV route obtained at a ratio of 2.0 is superior to those at ratios of 1.0 and 3.0. This observation is consistent with the convergence-curve results, where the speed ratio of 2.0 produces the best overall outcome. The iteration costs and final path results are shown in Figure 23 and Figure 24.

(2)

Impact of Weather Conditions on the Delivery Time in UAV–Truck Cooperative Routing

To investigate how weather conditions affect the delivery time of the UAV–truck cooperative transportation system, this study focuses on the setting of the baseline probability of adverse weather. Four experimental groups are designed by assigning the baseline adverse-weather probability to 0.1, 0.35, 0.5, and 0.7, respectively. To illustrate the influence of different baseline probabilities, both the convergence curves (objective value versus iteration) and the final UAV–truck routing maps are plotted.

From the convergence curves, the following observations can be made:

(1)

Baseline adverse-weather probability = 0.1.

The initial solution time is 355.95, and the final solution time is 338.39, corresponding to an improvement of 4.9%. Because weather conditions are generally favorable, the initial solutions are of relatively high quality, leaving limited room for further improvement.

(2)

Baseline adverse-weather probability = 0.35.

The initial solution time is 394.95, and the final solution time is 338.39, yielding a 14.3% improvement. As weather begins to deteriorate, the quality of the initial solution decreases, while the final solution remains unchanged; consequently, the relative improvement becomes larger.

(3)

Baseline adverse-weather probability = 0.5.

The initial solution time is 373.83, and the final solution time is 338.39, resulting in a 9.5% improvement. Although weather conditions further worsen, the initial solution in this case is better than that under the baseline probability of 0.35. However, more iterations are required to reach the best value than in the 0.35 case. This suggests that the algorithm may occasionally generate a high-quality initial solution even under more adverse conditions; nevertheless, as the frequency of adverse weather increases, optimization becomes more difficult, and more iterations (and hence more computational effort) are needed to converge to the final solution.

(4)

Baseline adverse-weather probability = 0.7.

The initial solution time is 430.61, and the final solution time is 398.58, corresponding to a 7.4% improvement. Under highly frequent adverse weather, the initial solution quality is poor and the algorithm requires substantially more optimization iterations to reach the best solution, in the order of approximately 100 generations.

From the final UAV–truck routing maps, consistent patterns can be observed across different baseline adverse-weather probabilities. When the baseline probability is 0.1, almost all nodes experience sunny conditions, which aligns with the convergence curve showing a high-quality initial solution. When the baseline probability increases to 0.35, one light-rain event appears and cloudy conditions occur at 10 nodes; consequently, the initial solution quality deteriorates due to weather impacts, and the initial completion time increases to 394.95. When the baseline probability is 0.5, the instance contains two heavy-rain events, five light-rain events, and 10 cloudy events, and multiple iterations are required before the algorithm converges to the optimal solution. When the baseline probability further increases to 0.7, thunderstorms occur as many as eight times, heavy rain occurs seven times, and light rain occurs four times. The frequent occurrence of thunderstorms substantially restricts UAV utilization, while heavy rain increases UAV flight times. These observations are consistent with the convergence results: the initial solutions are of low quality, the optimization process requires longer convergence, and the final solution quality is also reduced. The iteration costs and final path results are shown in Figure 25 and Figure 26.

(3)

Impact of the UAV’s Reachability of Customer Nodes on Delivery Time

Before the truck and UAV depart from the depot, some customer nodes are not serviceable by the UAV. To examine how the UAV’s initial reachability affects delivery performance, four experiments are conducted with the initial UAV-reachability probability set to 0.5, 0.6, 0.8, and 0.9, respectively. For each setting, convergence curves (objective value versus iteration) and the final UAV–truck routing maps are generated to demonstrate the impact of different reachability levels. This parameter is used only for random instance generation of customer-node accessibility to UAV service.

From the convergence curves, the following results are observed:

(1)

Initial reachability probability = 0.5.

The initial solution is 406.01 and the final solution is 381.60, corresponding to a 6.0% improvement. When the UAV can serve only about half of the nodes, the initial completion time is high and the final solution quality is relatively poor.

(2)

Initial reachability probability = 0.6.

The initial solution is 397.87 and the final solution is 383.55, yielding a 3.6% improvement. With a 10% increase in reachable nodes relative to the 0.5 case, the initial solution improves, whereas the final solution remains broadly similar.

(3)

Initial reachability probability = 0.8.

The initial solution is 394.95 and the final solution is 338.39, resulting in a 14.3% improvement. When the UAV can serve 80% of the nodes, both the initial and final solution qualities improve.

(4)

Initial reachability probability = 0.9.

The initial solution is 373.83 and the final solution is 338.39, corresponding to a 9.5% improvement. In general, the initial solution quality increases as the proportion of UAV-reachable nodes increases.

The final routing maps further indicate that, as the initial UAV reachability probability increases, UAV utilization tends to increase overall and its deployment becomes more reasonable within the cooperative routing plan. The iteration costs and final path results are shown in Figure 27 and Figure 28.

(4)

Impact of UAV Flight Range on Delivery Time

To examine the effect of UAV flight range on the overall delivery time, four settings are considered, with the UAV flight range set to 30, 50, 100, and 200, respectively. For each setting, convergence curves (objective value versus iteration) and the final UAV–truck routing maps are plotted to illustrate the impact of different flight-range limits.

(1)

Flight range = 30.

The initial solution is 403.25 and the final solution is 372.77, corresponding to a 7.6% improvement. With a limited flight range, the initial solution quality is low and the final solution remains worse than those obtained under larger ranges.

(2)

Flight range = 50.

The initial solution is 378.46 and the final solution is 338.39, yielding a 10.6% improvement. As the flight range increases, solution quality improves, and the final objective value matches that obtained under other (larger) range settings.

(3)

Flight range = 100.

The initial solution is 401.66 and the final solution is 338.39, corresponding to a 15.8% improvement. Although the flight range is larger, the initial solution quality is lower than that in the 50-range case; nevertheless, the final solution achieves the same value as those under ranges of 50 and 200.

(4)

Flight range = 200.

The initial solution quality further decreases relative to the 100-range case, although it still does not improve to the level achieved when the range is 50. The final solution remains identical to those obtained under ranges of 50 and 100.

Overall, increasing the UAV flight range tends to facilitate better final solutions up to a point, while the quality of the initial solutions does not necessarily improve monotonically with the range, reflecting the stochasticity of initialization and the nonconvex nature of the search landscape. The iteration costs and final path results are shown in Figure 29 and Figure 30.

The results of the parameter-sensitivity experiments on delivery time in the UAV–truck cooperative transportation setting are summarised in

Table 9. Table of different parameters and their effects.

Parameter	Initial Delivery Time	Improvement Ratio	Number of Iterations to Reach the Optimum	Number of Iterations to Reach the Optimum Section Headings:
Drone-to-truck speed ratio
1	376.87	338.39	10.2%	103
1.5	394.83	382.54	3.1%	82
2	394.95	338.39	14.3%	21
3	376.87	338.39	10.2%	52
Baseline probability of severe weather
0.1	355.95	338.39	4.9%	15
0.35	394.95	338.39	14.3%	21
0.5	373.83	338.39	9.5%	72
0.7	430.61	398.58	7.4%	98
Initial drone accessibility
0.5	406.01	381.60	6.0%	45
0.6	397.87	383.55	3.6%	59
0.8	394.95	338.39	14.3%	23
0.9	373.83	338.39	9.5%	80
Impact of drone flight range on results
30	403.25	372.77	7.6%	34
50	378.46	338.39	10.6%	34
100	401.66	338.39	15.8%	23
200	384.81	338.39	12.1%	20

. It is observed that the best delivery time of 338.39 repeatedly appears across multiple parameter configurations, which may be attributable to limitations of the randomly generated test instance.

To mitigate the potential bias induced by the instance design, the number of iterations required to reach the best objective value is additionally computed and compared. The UAV-to-truck speed ratio has a pronounced impact on optimization performance, and there exists an optimal ratio at which the cooperative delivery efficiency is maximised. When the baseline adverse-weather probability is at a low to moderate level (0.1–0.5), the algorithm can effectively avoid weather-related risks and maintain relatively favorable delivery times. However, once this probability exceeds 0.7, the delivery time deteriorates substantially. The UAV’s initial availability (reachability) has a decisive effect on the best achievable delivery time: only when availability is sufficiently high can the system attain the strongest cooperative benefits and the shortest delivery time. With respect to UAV flight range, an effective threshold is observed. Below this threshold, limited endurance restricts UAV deployment and results in longer delivery times. Once the threshold is exceeded, further increases in flight range yield diminishing returns in terms of delivery-time reduction, although they can enlarge the feasible search space and improve routing flexibility.

The near-identical final makespans obtained at UAV-to-truck speed ratios of 1.0, 2.0, and 3.0 suggest that the benefit of increasing UAV speed is subject to a structural saturation effect in the tested instance. This is because the objective is the system-level completion time rather than the UAV flight time alone. Under truck–UAV synchronization constraints, the completion of a cooperative segment is determined by the slower side at the rendezvous node. Therefore, once the UAV becomes sufficiently fast, the active bottleneck shifts to truck travel, waiting, and synchronization feasibility, so further speed increases yield only limited marginal improvement. In addition, weather-window feasibility and endurance constraints may prevent faster UAV motion from being fully translated into additional effective sorties. Hence, the convergence of different speed settings to the same final completion time is mainly attributable to synchronization bottlenecks, route-structure saturation, and instance-specific feasibility limitations.

Overall, the findings of this study are not only of theoretical interest, but also of considerable practical relevance. First, in emergency logistics and disaster-relief operations, road accessibility, local weather variations, and temporary no-fly restrictions are often highly uncertain, making static delivery plans difficult to implement effectively. The proposed truck–UAV cooperative framework explicitly incorporates dynamic weather and no-fly constraints into a unified optimization process, thereby providing more feasible and time-efficient decision support for emergency supply distribution, post-disaster replenishment, and rapid medical delivery. Second, in urban last-mile logistics, the results regarding the UAV-to-truck speed ratio, initial UAV accessibility, and UAV flight-range threshold suggest that the performance of a cooperative delivery system depends not simply on increasing UAV speed, but more importantly on appropriate system configuration and coordination design. This insight can help logistics operators make better decisions on UAV fleet configuration, rendezvous-point planning, task allocation, and dynamic replanning strategies. Finally, the results show that delivery performance deteriorates substantially when the probability of adverse weather becomes high, indicating that real-world deployment should place particular emphasis on weather-aware risk monitoring, early warning, and online route adjustment. Therefore, the proposed method has strong application potential in emergency logistics, disaster response, and intelligent last-mile delivery under uncertain environmental conditions.

5. Conclusions

In order to mitigate any potential bias arising from the instance design, the number of iterations required to reach the best objective value is additionally computed and compared. The speed ratio between the UAV and the truck has been shown to have a significant impact on the performance of optimisation, with the optimal ratio being one at which the efficiency of cooperative delivery is maximised. When the baseline adverse-weather probability is low to moderate (0.1–0.5), the algorithm has been shown to be capable of managing weather-related risks and maintaining relatively favourable delivery times. However, once this probability exceeds 0.7, the delivery time deteriorates substantially.

The initial availability of the UAV (reachability) exerts a substantial influence on the optimal delivery time. It is only when availability is sufficiently high that the system can achieve the strongest cooperative gains and attain the shortest delivery time. With regard to the flight range of UAVs, an effective threshold is evident. It is evident that when the threshold is not met, the endurance of the UAV is restricted, which consequently results in protracted delivery times. Beyond the threshold, further increases in flight range yield diminishing returns in terms of reducing delivery time, although they can expand the feasible search space and enhance routing flexibility.

Assuming that the drone’s battery capacity is independent of the actual cargo weight carried, the drone’s battery capacity remains a critical limiting factor for drone-truck collaborative transportation. Achieving real-time linkage between drone battery capacity and cargo weight would better align with practical requirements. Weather handling for drone-truck collaborative transport: On one hand, transitioning from continuous-time discretization simulation to online replanning; on the other hand, studying weather’s impact on delivery energy consumption by quantifying the nonlinear effects of wind direction and speed on drone power usage, thereby constructing models that more closely reflect real-world.

Future research could be extended in several directions. First, the current single-UAV–single-vehicle framework may be generalised to multi-UAV and multi-vehicle collaborative operations to better reflect large-scale delivery scenarios. Second, stochastic weather forecasts and forecast errors could be incorporated to improve the robustness of decision-making under uncertain environmental evolution. Third, real-time adaptive routing and rolling-horizon replanning deserve further study in order to enhance the responsiveness of the system to dynamic disturbances. In addition, practical factors such as UAV energy consumption, battery degradation, payload limitations, and service times may also be included to further improve the realism and applicability of the proposed approach.