Low-altitude ground collaborative distribution method and system considering real-time traffic state of road

Abstract

The invention discloses a low-altitude ground collaborative distribution method and system considering a real-time traffic state of a road, and relates to the technical field, and the method comprises the steps: constructing a traffic speed function of a driving time function of a distribution vehicle along with the change of time and a road section in a segmented manner; constructing an energy consumption function for the unit time power consumption rate of the unmanned aerial vehicle; constructing a mixed integer programming model according to the passing speed function and the energy consumption function; generating an initial solution; performing variable neighborhood search of multi-thread parallel disturbance in the search space based on the initial solution, and performing iterative solution to obtain an optimal solution of the mixed integer programming model; resetting the optimal solution to obtain a primary optimal solution; and optimizing the primary optimal solution to obtain a final solution. According to the invention, through constructing the mixed integer programming model, the distribution efficiency can be improved in a scene of cooperative distribution of the distribution vehicle and the unmanned aerial vehicle.

Description

Technical Field

[0001] This application relates to the field of logistics and distribution technology, and in particular to a low-altitude ground collaborative distribution method and system that takes into account the real-time road traffic conditions. Background Technology

[0002] While drones offer advantages over trucks (delivery vehicles) such as lower transportation costs, higher speed, and less susceptibility to ground conditions, they also have significant drawbacks, including shorter flight time, limited payload capacity, and higher skill requirements for operators. Given these advantages and disadvantages, the current focus of technological development is on finding a complementary delivery method based on drones—namely, combined drone and truck delivery.

[0003] In terms of application scenarios, drone-truck collaborative delivery can be categorized as a vehicle routing problem (VRP) in urban logistics. Currently, due to the complexity of collaborative delivery models, most truck-drone joint delivery technologies often make unnecessary assumptions about the operational characteristics of both drones and trucks, particularly regarding how these characteristics interact and how different technological features affect actual operations. For example, current research and technologies on collaborative delivery often simplify the implementation on the truck side in an idealized way. In reality, in today's cities, supply is gradually becoming saturated, and truck speeds are increasingly affected by road congestion, which severely impacts the collaborative planning of trucks and drones. Furthermore, as weight-sensitive devices, drones currently lack models that consider the relationship between load capacity and power consumption, potentially leading to significant deviations in task planning and inaccurate energy consumption predictions in practical applications.

[0004] In terms of technical approaches, the problem of drone-truck collaborative delivery is typically solved in practice using heuristic algorithms such as Variable Neighborhood Search (VNS), Iterative Local Search (ILS), and Adaptive Large Neighborhood Search (ALNS). These intelligent optimization algorithms, which use insertion and exchange as their main search methods, are well-suited for solving problems like vehicle routing, where ranking is the primary optimization objective. However, existing methods generally suffer from instability and poor robustness when dealing with the complex and high-dimensional problem of truck-drone collaborative delivery (stable methods often indicate poor performance or long processing times). In other words, there is a severe shortage of efficient, stable, and high-quality heuristic optimization algorithms for this increasingly important problem of truck-drone collaborative delivery. Summary of the Invention

[0005] In view of this, embodiments of this application provide a low-altitude ground collaborative delivery method and system that takes into account the real-time road traffic conditions, so as to improve the collaborative delivery efficiency of delivery vehicles and drones.

[0006] One aspect of this application provides a low-altitude ground collaborative delivery method that takes into account real-time road traffic conditions, the method comprising the following steps:

[0007] The passage speed function is constructed in segments to represent the travel time function of delivery vehicles as a function of time and road segment.

[0008] An energy consumption function is constructed based on the power consumption rate of the drone per unit time; wherein, each of the delivery vehicles is equipped with the drone.

[0009] A mixed-integer programming model is constructed based on the traffic speed function and the energy consumption function; wherein, the objective of solving the mixed-integer programming model is to minimize the operating cost under the premise of completing delivery on time;

[0010] Generate an initial solution for the mixed integer programming model according to the stated solution objective;

[0011] Based on the initial solution, a variable neighborhood search with multi-threaded parallel perturbation is performed in the search space, and then the optimal solution of the mixed integer programming model is obtained by iterative solution.

[0012] When the maximum number of iterations is reached, if the optimal solution does not meet the preset conditions, the optimal solution is reset to obtain an optimized solution.

[0013] Based on the first-order optimization solution, a variable neighborhood search with multi-threaded parallel perturbation is performed in the search space, and then the second-order optimization solution of the mixed integer programming model is obtained iteratively as the final solution.

[0014] In some embodiments, the segmented construction of the travel speed function of the delivery vehicle as a function of travel time varying with time and road segment includes the following steps:

[0015] The delivery vehicle is defined at the delivery point. , The distance and time traveled between them are related as follows:

[0016] ;

[0017] The above expression indicates that when the delivery vehicle selects an arc... At that time, the sum of the lengths of the sub-segments traversed by the delivery vehicle during all time periods is equal to the length of the arc. Indicates whether the path is feasible. Indicates the number of delivery points;

[0018] Introducing decision variables To determine whether to choose Time period through arc and satisfy the following constraints:

[0019] ;

[0020] ;

[0021] ;

[0022] The above three constraints respectively indicate that only the delivery vehicle can select the arc. Only then will they further choose to go through the arc During the specified time period, the delivery vehicle selects an arc. At least one time period is required, during which the delivery vehicle is in the arc at any time. The distance traveled cannot exceed the arc. The total length, and cannot be driven during periods that have not been selected.

[0023] In some embodiments, constructing the energy consumption function based on the power consumption rate of the drone per unit time includes the following steps:

[0024] The power consumption rate of the UAV per unit time is expressed as a function related to its own weight, payload, gravitational acceleration, air fluid density, number of UAV blades, and number of UAV rotors, which is called the energy consumption function.

[0025] The energy consumption function is divided into a loaded outbound energy consumption function and an unloaded inbound energy consumption function.

[0026] In some embodiments, the operating costs include delivery vehicle operating costs, drone flight costs, and fixed costs; the delivery vehicle operating costs consist of unit distance costs under free-flow conditions and additional costs under traffic congestion conditions; the drone flight costs are related to the total distance to the destination and return to the rendezvous point; and the fixed costs are related to the number of delivery vehicles used.

[0027] The process of constructing a mixed-integer programming model based on the traffic speed function and the energy consumption function includes the following steps:

[0028] The mixed-integer programming model is constructed as follows:

[0029] .

[0030] In some embodiments, generating an initial solution to the mixed-integer programming model according to the solution objective includes the following steps:

[0031] First, based on the nearest neighbor pairs of delivery points that can only be served by the delivery vehicles, a greedy solution is generated to produce pure delivery vehicle paths.

[0032] Then, a variable neighborhood search algorithm is used to rapidly descent the greedy solution to improve the quality of the initial solution;

[0033] For the delivery points served by the drones, drones are then inserted in ascending order of proximity to existing delivery vehicle sub-paths; if insertion is not possible, a new sub-path is created.

[0034] In some embodiments, the step of performing a variable neighborhood search with multi-threaded parallel perturbation within the search space based on the initial solution, and then iteratively solving to obtain the optimal solution of the mixed integer programming model, includes the following steps:

[0035] For each thread, the perturbation operator is used to perturb it in increments, and the variable neighborhood descent improvement is called independently.

[0036] If any thread finds a better solution, the global optimum is updated and the perturbation magnitude is reset;

[0037] If the solution of all threads does not improve, then the number of perturbations for each thread is increased synchronously.

[0038] In some embodiments, resetting the optimal solution to obtain a first-order optimized solution includes the following steps:

[0039] The sum of the scores of each delivery point and its neighbors in the current optimal solution is obtained according to the scoring system.

[0040] Define the degree of destruction, and destroy the corresponding delivery points from the current optimal solution in order of increasing degree of destruction according to the score, and establish a set of destroyed delivery points;

[0041] Iterate through the set of damaged delivery points. For each damaged delivery point, sort all current sub-paths in ascending order of the average distance between the current delivery point and the damaged delivery point, and insert the damaged delivery point into the sub-path in turn.

[0042] Mark all target delivery points in the path that do not use drone services, and insert these target delivery points as drone service points in the location with the lowest cost.

[0043] Another aspect of this application embodiment provides a low-altitude ground collaborative delivery system that takes into account real-time road traffic conditions, the system comprising:

[0044] The vehicle modeling unit is used to construct, in segments, the travel time function and the travel speed function of delivery vehicles as they change with time and road segment.

[0045] The drone modeling unit is used to construct an energy consumption function for the power consumption rate of the drone per unit time; wherein, each of the delivery vehicles is equipped with a corresponding drone;

[0046] The planning model modeling unit is used to construct a mixed integer programming model based on the traffic speed function and the energy consumption function; wherein, the objective of solving the mixed integer programming model is to minimize the operating cost under the premise of completing delivery on time;

[0047] An initial solution generation unit is used to generate an initial solution for the mixed integer programming model according to the solution objective.

[0048] An initial solution iteration unit is used to perform a variable neighborhood search with multi-threaded parallel perturbation in the search space based on the initial solution, and then iteratively solves the optimal solution of the mixed integer programming model.

[0049] The optimal solution optimization unit is used to reset the optimal solution and obtain an optimized solution if the optimal solution does not meet the preset conditions after the maximum number of iterations has been reached.

[0050] The secondary optimization unit is used to perform a variable neighborhood search with multi-threaded parallel perturbation in the search space based on the primary optimization solution, and then iteratively solves the secondary optimization solution of the mixed integer programming model as the final solution.

[0051] Another aspect of this application embodiment provides an electronic device, including a processor and a memory;

[0052] The memory is used to store programs;

[0053] The processor executes the program to implement any of the methods described above.

[0054] Another aspect of this application provides a computer-readable storage medium storing a program that is executed by a processor to implement the method described in any of the above embodiments.

[0055] This application includes at least the following beneficial effects:

[0056] The mixed-integer programming model constructed in this application can simultaneously characterize the road traffic status that changes over time and the impact of drone power consumption rate affected by load and time on the delivery plan in the scenario of collaborative delivery by delivery vehicles and drones. It is applicable to the real urban logistics delivery operation environment and can achieve more accurate and reasonable urban logistics delivery plan output, thereby improving delivery efficiency. Attached Figure Description

[0057] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0058] Figure 1 A flowchart illustrating the low-altitude ground collaborative delivery method that takes into account real-time road traffic conditions, as provided in an embodiment of this application.

[0059] Figure 2 A general flowchart of the collaborative delivery method provided in the embodiments of this application;

[0060] Figure 3 This application provides an example of drone-truck collaborative delivery in urban logistics.

[0061] Figure 4 This application provides a speed-based road traffic state simulation diagram for embodiments of the present application.

[0062] Figure 5 A flowchart of the VNS-PRS method provided in the embodiments of this application;

[0063] Figure 6 Visualization of the average algorithm performance under different parameter combinations provided in the embodiments of this application;

[0064] Figure 7 The algorithm robustness analysis diagram provided for the embodiments of this application;

[0065] Figure 8 A diagram illustrating the algorithm convergence process provided in the embodiments of this application;

[0066] Figure 9 This is a structural block diagram of a low-altitude ground collaborative delivery system that takes into account real-time road traffic conditions, as provided in an embodiment of this application. Detailed Implementation

[0067] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0068] Before providing a detailed description of the embodiments of this application, some related technologies involved in the embodiments of this application will be described first, as follows:

[0069] VNS-G: General Variable Neighborhood Search. VND: Variable Neighborhood Descent. VNS: Variable Neighborhood Search. VNS-A: Variable Neighborhood Search with Adaptive Selection of Perturbed Neighborhoods. VNS-R: Variable Neighborhood Search with Reduced Perturbing. VNS_PR: Variable Neighborhood Search with Multi-threaded Parallel Perturbing and Consideration of Restarting the Search Process After Getting into Local Optimum. VNS_PRS: Variable Neighborhood Search with Multi-threaded Parallel Perturbing, Consideration of Restarting the Search Process After Getting into Local Optimum, and Further Decomposition and Secondary Optimization of the Problem After the Algorithm Ends. ILS: Iterative Local Search. ALNS: Adaptive Large Neighborhood Search. VRP: Vehicle Path Problem.

[0070] Reference Figure 1 This application provides a low-altitude ground collaborative delivery method that takes into account the real-time road traffic conditions, specifically including the following steps S100~S160:

[0071] S100: Segmented construction of the travel time function and the traffic speed function of delivery vehicles as they change with time and road segment;

[0072] S110: Construct an energy consumption function for the power consumption rate of the drone per unit time; wherein, each of the delivery vehicles is equipped with the drone.

[0073] S120: Construct a mixed integer programming model based on the traffic speed function and the energy consumption function; wherein, the objective of solving the mixed integer programming model is to minimize the operating cost under the premise of completing delivery on time;

[0074] S130: Generate the initial solution of the mixed integer programming model according to the stated solution objective;

[0075] S140: Based on the initial solution, perform a variable neighborhood search with multi-threaded parallel perturbation in the search space, and then iteratively solve to obtain the optimal solution of the mixed integer programming model;

[0076] S150: When the iteration reaches the maximum number of times, if the optimal solution does not meet the preset conditions, the optimal solution is reset to obtain an optimized solution.

[0077] S160: Based on the first-order optimization solution, perform a variable neighborhood search with multi-threaded parallel perturbation in the search space, and then iteratively solve to obtain the second-order optimization solution of the mixed integer programming model as the final solution.

[0078] The following section will provide a detailed introduction and explanation of the solutions in the embodiments of this application, using specific application examples.

[0079] This embodiment utilizes mixed-integer mathematical modeling techniques to describe the parallel collaborative delivery problem between trucks (delivery vehicles) and drones. In addition to conventionally considered factors, the model also takes into account real-world issues encountered in actual operation, such as the impact of real-time changes in road conditions on truck speed and the impact of load variations on drone power consumption per unit time. Based on this, an intelligent optimization algorithm for urban logistics delivery suitable for low-altitude ground collaboration is developed using the variable-domain search approach.

[0080] I. Overall Approach.

[0081] Figure 2 This is the overall flowchart of this embodiment. Based on this flowchart, this embodiment consists of two aspects: mathematical modeling (steps 1-3) and solving using intelligent optimization algorithms (steps 4-6). Specifically, it includes the following steps:

[0082] Step 1: Linearize real-time road traffic status. Based on traffic congestion data of urban roads related to all delivery nodes, the continuous speed changes are discretized into segmented time periods; based on the relationship "congestion index = free-flow travel time / actual travel time", a traffic speed function that varies with time and road segment is obtained, which is used to evaluate the travel time of trucks through each arc segment at any departure time.

[0083] Step 2: Power Consumption Efficiency Assessment. The power consumption rate of the drone per unit time is expressed as a function related to its own weight, payload, gravitational acceleration, air fluid density, number of drone blades, and number of drone rotors, and the energy consumption and flight range are characterized in two segments: "outbound (loaded) / return (unloaded)".

[0084] Step 3: Constructing the Mixed Integer Programming Model. Jointly plan "truck routes + drone takeoffs and landings / services" on a directed graph. Each truck is equipped with one drone, which uses the truck as a takeoff and landing platform and can operate in parallel. All orders must be delivered before the deadline. Establish a mixed integer programming model with the objective of "minimizing operating costs while completing delivery on time." The results of Steps 1 and 2 are used as inputs to form relevant constraints such as path connectivity, capacity, time windows / delivery times, and takeoff / landing matching.

[0085] Step 4: Solve the initial value generation algorithm iteration. First, generate pure truck paths as greedy solutions based on the nearest neighbor pairs of nodes that can only be served by trucks; then, use VNS_R to quickly descent the greedy solutions to improve the quality of the initial structure; then, for nodes that can be served by drones, try to insert drones in ascending order of proximity to existing truck sub-paths. If insertion is not possible, start a new sub-path.

[0086] Step 5: Multi-threaded parallel perturbation. Each thread uses a perturbation operator to perturb at an increasing increment and independently calls Variable Neighborhood Descent (VND) to improve. If any thread finds a better solution, the global optimum is updated and the perturbation magnitude is reset. If there is no improvement, the number of perturbations for each thread is increased synchronously.

[0087] Step 6: When there is still no improvement after completing a round of perturbation amplitude from small to large, a customized restart based on the "destruction-repair" idea is triggered to try to escape the local optimum.

[0088] Step 7: After outputting the global optimum, sort the sub-paths from slowest to fastest according to their average vehicle speed; each time, select a slow sub-path and form a new sub-problem with several sub-paths that are close to its center of gravity, and call Steps 4-6 again for refinement until all sub-paths have completed secondary optimization, thereby focusing on optimizing the local structure that is more affected by congestion and outputting the final solution.

[0089] II. Model Preparation.

[0090] 1. Problem Description.

[0091] The drone-truck collaborative delivery problem considered in this embodiment can be defined in a directed graph. Above, among which, Orders placed on behalf of all customers. It is a set of arcs connecting customer points and warehouses. The urban logistics delivery problem discussed in this article references real-world operational processes. In reality, logistics companies often categorize packages according to the expected delivery time of orders before delivery begins (e.g., before 18:00 tomorrow), and then centrally plan delivery tasks within their jurisdiction based on the categorization results. Specifically, at the start time, a fleet of identical trucks is stationed at the warehouse, ready to deliver packages to customers. This batch of packages needs to be delivered before a corresponding deadline, denoted as _____. Each truck is equipped with a drone, which independently serves customers using the truck as a take-off and landing platform. This process can be carried out simultaneously with truck deliveries. See details. Figure 1 In the above process, the truck's speed is related to real-time changes in road congestion, while the drone's speed is constant. The drone's power consumption is related to its weight, and it operates on a battery-swapping model, with the battery being replaced immediately each time it returns to the truck. The logistics company needs to use both trucks and drones to complete all delivery tasks before the expected delivery time. Under these circumstances, the goal of this embodiment is to plan a delivery solution with the lowest operating cost, which jointly optimizes the truck's driving route, service targets, and the drone's service targets, take-off and landing locations, and times.

[0092] To simplify the model and ensure clarity, this embodiment makes the following assumptions:

[0093] (1) The drone can only be launched and recovered at service points via a truck paired with it.

[0094] (2) A drone can only serve one customer during a single flight.

[0095] (3) The drone must return before the truck leaves the rendezvous point.

[0096] (4) If the drone arrives at the rendezvous point ahead of time, it will need to hover at low altitude and wait, which will consume power continuously.

[0097] (5) The power consumption during the drone service process is negligible.

[0098] (6) The time for adjusting the settings of the drone on the truck and changing the battery is negligible.

[0099] (7) The truck will not stop while it is in motion.

[0100] (8) Once the drones and trucks arrive at the service point, they will begin service immediately.

[0101] 1.1 Truck and drone route construction.

[0102] The drone-truck collaborative delivery problem in this embodiment is a variant of the VRP problem, and the notation is detailed in Appendix Table 1. For simplicity, this embodiment references the modeling form of the multi-vehicle routing problem without vehicle indexes, with the following constraints:

[0103]

[0104] Among them, constraint (1) ensures that each customer can only be served by one delivery tool, either a truck or a drone, and each customer can only be served once. Constraints (2) and (3) indicate that customers assigned to trucks can only be served once by the truck's delivery route, and the same applies to drones. Constraint (4) is the flow balance formula for truck routes. Constraint (5) indicates that the total number of trucks departing from the warehouse cannot exceed the maximum number of trucks available. Constraint (6) indicates that the take-off and landing points of drones must be continuous waypoints on the truck route. Constraint (7) ensures that a drone can only visit one customer point in each flight. Constraint (8) indicates that the demand for each drone delivery cannot exceed the drone's maximum payload capacity. Constraint (9) is a combined representation of subloop elimination and capacity limitation constraints. express This constraint addresses the potential for sub-loops. In fact, regardless of whether drones or trucks are used for delivery, truck capacity is occupied when the delivery originates from the warehouse. Therefore, this constraint eliminates sub-loops while ensuring that the total demand for truck or truck-mounted drone delivery on each route does not exceed the truck's capacity limit.

[0105] By constraining (1) to (9), this embodiment can generate multiple routes for truck and drone collaborative delivery, and each route satisfies the capacity limit and the single-loop form of starting from the warehouse and finally returning to the warehouse.

[0106] 1.2 Real-time road direction status simulation.

[0107] Considering the increasingly saturated urban road traffic system, truck speeds are related to road congestion. In fact, road congestion is affected by time. For example, during weekday morning and evening rush hours, urban road congestion levels rise sharply, and truck speeds drop significantly; however, in the early morning, speeds can reach free-flow speeds. Furthermore, speeds differ between origin and destination due to different route segments, and due to tidal effects, even on the same route, speeds vary in different directions. In reality, truck speed changes are a continuous process; in this embodiment, this continuous change is simplified to a piecewise function, such as... Figure 3 As shown. This embodiment uses express The start and end times of the time period. This represents the total set of time periods. The end time of the last time period before reaching each service point is forcibly set to [the specified time]. ,as follows:

[0108] (10)

[0109] This equation ensures that customer points using the truck service will begin service before the latest expected delivery time for this batch of packages.

[0110] Based on the above settings, this embodiment uses Indicates the free-flow speed of the truck. Indicates the congestion index. Indicates the truck is in Time period from Location to drive to The actual average velocity at a given location, and the relationship between the three are as follows:

[0111] (11)

[0112] The congestion factor is calculated as the ratio of the average free-flow speed of trucks to their actual average speed. In fact, this method of assessing road congestion is widely used in the real world.

[0113] For example, Figure 4 This is a simulation diagram of road traffic conditions based on speed.

[0114] 1.3 Road driving efficiency as a function of time.

[0115] Considering the description of road congestion in the previous section, this embodiment needs to calculate the truck's travel time based on different departure times and different road segments, according to constraints (1) to (9), in order to determine whether the route is feasible. This means that each arc is composed of multiple sub-arc segments with different speeds. The truck is... , The distance and time traveled between them are related as follows:

[0116] (12)

[0117] Constraint (12) indicates that when the truck selects the arc At that time, the sum of the lengths of the sub-segments passing through that road segment over all time periods is equal to the length of the arc. Based on this, decision variables are introduced. To determine whether to choose Time period through arc :

[0118] (13)

[0119] (14)

[0120] (15)

[0121] Constraint (13) indicates that only truck selection arcs are allowed. Only then will they further choose to go through the arc During the time period, constraint (14) is to ensure the truck selection arc At least one time period must pass. Constraint (15) indicates that the truck is on the arc at any time period. The distance traveled cannot exceed the arc. The total length, and cannot be driven during periods that have not been selected.

[0122] This embodiment aims for a continuous selection of time periods. For example, a truck in... Departure time, passing through arc ,exist The arc was completed in a short time. 80% of the journey is covered, so the remaining 20% ​​must be covered from... The calculation begins at time [time]. To achieve this goal, the following series of constraints are introduced:

[0123]

[0124] Constraints (16) and (17) constrain the arrival and departure times of the trucks at the nodes. Specifically, the departure time... The point time must be earlier than the earliest time on the arc. The difference between the end time of the travel period and the travel time within that arc segment, and the arrival time. The time at the point must be later than the latest time at the arc. The sum of the start time of the travel period and the corresponding travel time. Constraints (18) and (19) ensure that when the arc... When selected, arrive The time of the point is equal to the time of departure. The time at the point is the sum of the time spent traveling during each time period. Constraint (20) states that the truck will leave immediately after serving the customer. Constraint (21) restricts the time at which all trucks depart from the warehouse to time 0.

[0125] Furthermore, due to the different routes, each truck's return time to the warehouse varies. Therefore, in the modeling form without a vehicle index, it is necessary to distinguish the return time from different customer points to the warehouse, denoted as . Therefore, for the arc returning to the warehouse, the following constraints are introduced:

[0126]

[0127] Among them, constraint (22) functions similarly to constraint (17), constraint (23) functions similarly to constraint (18), and constraint (24) functions similarly to constraint (19).

[0128] 1.4 Characteristics of the limitations of unmanned aerial vehicles (UAVs).

[0129] In urban logistics delivery, drones can deliver goods regardless of most terrain and road traffic conditions. However, drones are subject to strict management policies, tight capacity limits, and high power consumption. Firstly, due to payload limitations, drones must return to the truck after completing a delivery service, regardless of whether there is surplus power to serve other customers. In this embodiment, the interaction between the drone and the truck takes place at a service point, and the drone can take off and land at any time during the truck's service period. Given these considerations, whether the drone can arrive at the rendezvous point before the truck arrives will affect the arrangement of subsequent tasks; that is, it is necessary to decide the drone's arrival time at the rendezvous point. This embodiment uses... This indicates the time the drone was late when meeting at point i.

[0130]

[0131]

[0132] Constraint (25) indicates the distance from the drone to the destination. Starting from the designated time, if a drone is assigned to complete the task from... Click Click to return to The task at point necessitates ensuring the drone can leave after the truck departs. Return before the point. Constraints (26) and (27) determine the suitability of the UAV mission by calculating the difference between the time it takes for the UAV to return to point k after departing from point i and the time it takes for the truck to travel to point k. When the truck and drone meet at point k, does the drone arrive at point k later than the truck? And when a drone mission exists... Furthermore, when the drone arrives at point k later than the truck, constraints (28) and (29) are responsible for recording the time value of the drone's late arrival. Constraint (30) indicates that the drone's late arrival time must not exceed the truck's service time at that point, i.e., it must return before the truck leaves. In addition, this embodiment does not set time constraints for the case where the drone's landing point is in the warehouse, which is handled by set... Distinguishing between them. And because drone-related variables are not affected... Due to constraints, this embodiment requires the following constraints to ensure that the delivery service performed by the drone also begins before the expected latest delivery time of the batch of packages.

[0133] (31)

[0134] Constraint (31) means that if a drone service is the last task in a path, its service start time must be before the maximum time limit.

[0135] Drones have relatively small battery capacities and are considered weight-sensitive vehicles, so their power consumption rate varies with weight. Simply put, the heavier the payload, the higher the drone's power consumption rate. The next step is to quantify the drone's power consumption. The following methods can be used to estimate the drone's power consumption per unit weight and per unit time:

[0136] (32)

[0137] in, It is the weight of the drone itself (including the battery and the fuselage frame). It is gravitational acceleration. It is the fluid density of air ( ), It is the area of ​​the drone's rotating blades ( ), It refers to the number of rotors.

[0138] Now, the constraints related to the drone's battery power in this embodiment can be written as follows:

[0139]

[0140]

[0141] Constraints (33) and (34) are the drone's power constraints. Power consumption is related to the drone's actual payload, and the drone needs to return to the truck to replace the battery before the power is depleted. The power consumption rate calculated in (32) is the weight of the drone during its journey to the destination to deliver goods. With the weight of the goods The sum of the total weight of the drone and its return trip after the service is completed; however, the drone's weight is only its own weight. Because the power consumption rates of these two processes are different, this embodiment needs to calculate the time it takes for the drone to travel to its destination and the time it takes for the drone to return to the truck. For the former, it can be directly used... The latter needs to be determined based on whether the total service time of the drone exceeds the travel time of the truck between the take-off and landing points. If it does, the drone's idle time is the return flight time; once the drone reaches the rendezvous point, it can directly interact with the already arrived truck. Conversely, if the drone's idle time is less than the truck's travel time between the take-off and landing points, the drone's idle time is the same as the truck's travel time between the take-off and landing points. This is because if the drone arrives at the rendezvous point early, it is not allowed to land directly but must hover in the air, a process that continuously consumes power.

[0142] To achieve the above judgment, auxiliary judgment constraints (30), (31), and (32) are introduced. When A value of 0 indicates that the total service time of the drone exceeds the travel time of the truck between the take-off and landing points, and vice versa. Furthermore, for drone trips where the landing point is a warehouse, the waiting time for the truck is not considered; that is, all... It was set to 0.

[0143] 1.5 Model Construction.

[0144] The objective of this embodiment is to minimize operating costs while ensuring timely delivery. Operating costs consist of three parts: truck travel costs, drone flight costs, and fixed costs. Truck travel costs comprise the unit distance cost under free-flow conditions and additional costs due to traffic congestion. Drone flight costs are related to the total distance to the destination and return to the rendezvous point. Fixed costs are related to the number of vehicles used. Based on this, a mixed-integer programming model is constructed as follows:

[0145] (33)

[0146] The model is constrained by equations (1)-(9), (12)-(31), (33)-(37), and the following equations (34)-(41):

[0147]

[0148]

[0149] 2. Intelligent optimization algorithm design.

[0150] In the previous section, this embodiment considered unavoidable factors in actual operation, such as real-time traffic congestion on urban roads and the relationship between drone power consumption efficiency and weight, and constructed a mixed-integer mathematical model for collaborative delivery between drones and trucks. However, the inclusion of these real-world factors leads to high model solution complexity and a tendency to get trapped in local optima. This difficulty is further amplified when the granularity of the road congestion simulation is fine.

[0151] In fact, this type of problem has been proven to be NP-hard, meaning that in practical engineering applications, it is difficult to solve the problem accurately within an acceptable timeframe. To balance solution efficiency and quality, this section and embodiment propose a metaheuristic algorithm framework based on variable neighborhood search.

[0152] 2.1 Variable Domain Search (VNS).

[0153] Variable Neighborhood Search (VNS) is a metaheuristic framework renowned for its flexibility and simplicity in building efficient heuristic algorithms. Over time, numerous VNS variants have been proposed, such as Partial Variable Neighborhood Search (SVNS), Variable Neighborhood Descent Search (VNDS), and Nested Variable Neighborhood Search (NVNS). In essence, all improvements in VNS-based heuristics essentially revolve around the following three steps:

[0154] (1) Vibration process: Map the current solution to a neighborhood structure in order to escape the local optimum.

[0155] (2) Improvement process: Select a neighborhood and perform a local search on the perturbed solution. The goal is to find a better feasible solution around the current solution.

[0156] (3) Neighborhood transformation: Based on certain rules, different neighborhoods are used to implement operations (1) and (2) in order to enrich the exploration results of the solution space.

[0157] Table 1. General Variable Neighborhood Search Framework (VNS_G)

[0158]

[0159] Table 1 illustrates the General Variable Neighborhood Search (VNS-G), which, as its name suggests, has been widely used and studied. Its main feature is the iterative application of various local search operators in the improvement process (also known as the neighborhood descent stage) to further improve the quality of the solution, as shown in rows 8-13 of Table 1. Specifically, to implement a VNS process, this embodiment requires an initial solution, a set of predefined vibrational neighborhood structures, and a set of predefined improved neighborhood structures as inputs. In fact, the final result of the algorithm is strongly correlated with these three inputs. To achieve a high-quality VNS algorithm framework, it is necessary to address the following issues:

[0160] 1) Similar to most heuristic algorithms, a good initial value can greatly improve the search speed of VNS. So how should the initial value acquisition algorithm be designed in this embodiment?

[0161] 2) Since the iteration process of VNS often lacks a clear search direction, how can we define the neighborhood and the rules for neighborhood changes and update strategies to improve search efficiency?

[0162] 3) According to the neighborhood distance rule in VNS, if no better solution is found, the magnitude of the perturbation will become increasingly larger. However, when a high-quality solution has already been found, large, undirected perturbations are like finding a needle in a haystack. So how can we prevent the algorithm from getting trapped in local optima and enhance its robustness after a high-quality solution has been obtained?

[0163] Table 2 Initial Solution Generation Pseudocode

[0164]

[0165] 2.2 Design of VNS scheme.

[0166] 2.2.1 Initial solution generation.

[0167] To address the characteristics of the drone-truck collaboration problem, this embodiment constructs an interconnected two-dimensional vector to store path planning information and vehicle information for accessing relevant nodes. Specifically, the path layer of the vector is constructed based on the number of nodes and the determined number of trucks used, while the tool layer has the same length as the path layer and records which tool is used to access nodes at corresponding positions in the path layer (trucks are denoted as 0, drones as 1). For example, {{0, 1, 2, 3, 0, 4, 5, 6, 0}, {0, 1, 0, 1, 0, 0, 1, 0, 0}} indicates that two trucks depart from and return to the warehouse. One truck (and its equipped drone) is responsible for delivering to nodes 1, 2, and 3, where nodes 1 and 3 are delivered by drone, and node 2 is delivered by truck. The other truck is responsible for delivering to nodes 4, 5, and 6, where nodes 4 and 6 are delivered by truck, and node 5 is delivered by drone.

[0168] Based on this, this embodiment directly introduces the objective function (Equation 33): As the fitness function, and The constraints are transformed and encapsulated into a feasibility assessment function, thereby enabling the evaluation of solution quality within the feasible region. In particular, due to the decomposability of the multi-vehicle routing problem, the fitness function and the feasibility assessment function are extremely efficient in actual algorithm operation, and their time complexity per call is basically unaffected by the problem size.

[0169] The pseudocode for the initial solution generation is detailed in Table 2, where, and These represent the path layer and tool layer of a two-dimensional vector, respectively. and These are two customer sets: one accessible only by truck and the other accessible by drone (determined by whether the order weight exceeds the drone's maximum payload). The specific algorithm flow is as follows:

[0170] Nearest Neighbor Search: Greedy construction based on node distance only includes... A centralized path layer vector is generated. Simultaneously, truck capacity and delivery timeliness are used as criteria to determine whether additional trucks are needed, ultimately forming a basic path for pure truck service. It's worth noting that when generating truck paths, this embodiment only considers customers who can only access the service via trucks (rather than the common practice of processing all nodes uniformly first and then converting some nodes to drones). This approach can minimize the number of trucks (i.e., the number of zeros) during initial solution generation; the related advantages will be further explained in subsequent sections.

[0171] Table 3. Variable Neighborhood Search Framework for Reducing Perturbation Elements (VNS-R)

[0172]

[0173] Variable Neighborhood Search (VNS-R) to Reduce Disturbance: Since this embodiment involves road congestion, node distance is not the sole criterion for evaluating path quality. Therefore, paths generated solely through greedy methods often suffer from poor quality. To address this issue, this embodiment introduces VNS-R (details in Table 3) to rapidly improve the greedy solution and obtain a higher-quality initial solution structure.

[0174] Drone-friendly node insertion: Finally, for the remaining nodes that can provide drone services, insert them into the optimized system following the process outlined in rows 9-18 of Table 2. In the middle. Among them, for the currently inserted node , according to Each node in the current path is sorted by its distance to any adjacent node from nearest to farthest. The insertion point. Based on this, for each First, attempt to insert it as a drone service node, then attempt to insert it as a truck node. If insertion is not possible at any point along the current path, then schedule a truck to serve the node.

[0175] 2.2.2 Design of neighborhood operators.

[0176] Neighborhood operators are a crucial factor in determining the efficiency and upper limit of an algorithm. Considering that VNS itself is not suitable for using overly complex heuristic rules to characterize operators, and that the optimization in this embodiment is essentially a sorting problem, this embodiment develops neighborhood operators based on operations such as swapping and insertion.

[0177] (1) Service Switching: Randomly select a customer location and switch its delivery method; that is, if drones are currently being used, switch to trucks, and vice versa. Furthermore, this operator may lead to... This addresses the situation where two consecutive index locations use drone services (a drone cannot simultaneously carry goods from two customer points for continuous autonomous delivery). To handle this, this embodiment defines a rule that only the first drone service after a truck service is considered a drone service point. For example, for... In the case of {0, 1, 1, 1, 0}, the 1 in the third position will be treated as 0. With this setting, each call to the operator can flexibly change the delivery service mode of each node in the current sub-path.

[0178] (2) Adjust the number of trucks: In Randomly select a location. If the current location is a customer node, add warehouse node 0 at the current location, thus adding a truck route (synchronous update). If the current location is already a warehouse node, then that warehouse node is removed, and two adjacent sub-paths are merged, thereby reducing one truck path. In fact, with industrial development and rising labor costs, how to complete delivery tasks with as few trucks as possible is an important decision-making objective. Therefore, this operator is introduced to adjust the number of trucks. However, due to the non-directional nature of the operator search, its actual performance exhibits some instability. Therefore, this embodiment minimizes the number of trucks before the start of the iteration in the nearest neighbor search part of the initial value generation.

[0179] (3) Customer migration: In A customer is randomly selected and moved to another available insertion position. Based on this, the algorithm first attempts to insert the customer as a drone service node, and then attempts to insert it as a truck service node. The migration operation is one of the key operators for the efficiency of the algorithm's iteration. In a migration operation, a customer node may change its access order in the current truck sub-path, or it may be assigned to the access plan of other trucks.

[0180] (4) Customer exchange: in Two customers are randomly selected and their positions are swapped. Similarly, in the migration process, the algorithm first attempts to swap them to a drone service node, then to a truck service node. As a key operator for algorithm iteration efficiency, a single swap operation may change the access order of two customer nodes within the current truck sub-path, or swap two customer nodes between different truck sub-paths.

[0181] (5) Path reversal: in Randomly select two positions, then reverse the nodes corresponding to these two positions and all intermediate positions (synchronously update). For example, for {0, 1, 2, 0, 3, 4, 0}, if the 2nd and 5th positions are selected, it changes to {0, 3, 0, 2, 1, 4, 0}. In fact, considering road congestion over time, this embodiment often presents situations where some node combinations are very close, but the effect is poor due to excessive road congestion at the current access time. In such cases, reversing a portion of the path can change the node access time without altering the node adjacency relationships.

[0182] (6) Optimal Combination Migration: In fact, the size of the path reversal neighborhood is very large, and most operations significantly disrupt the path. Therefore, this operator is not suitable for the Variable Neighborhood Descent (VND) stage. To address this issue, this embodiment first scores the distance between each node and the other nodes based on relative distance (relying only on the ranking of distances between nodes). For example, for node 1, the node closest to it will receive... The highest score will be awarded to the node that is second closest to him. This process is repeated for each node, and so on. This avoids isolating geographically remote nodes.

[0183] Based on this, if a pair middle right The score is the highest score or right If the score is the highest, then the combination is called the optimal combination. This process can be repeated to form a pattern like... The link. In the ideal case, this link can be expanded into an entire sub-path. Once all the current optimal combinations are obtained, the following process is used to traverse all combinations: 1. Attempt to reverse the relevant combinations and place them in their original positions; 2. Extract the combination from the original path and attempt to insert it into the remaining positions in the path in both ascending and descending order. Thus, the effect of attempting to change the node access time is achieved without changing the adjacency relationship of high-quality node combinations.

[0184] In summary, this embodiment incorporates service switching, truck quantity adjustment, customer migration, customer exchange, and path reversal into the vibration neighborhood set. Furthermore, by replacing path reversal with optimal combination migration, an improved neighborhood set required for the VND is constructed. In fact, determining the rules governing exploration and traversal between different neighborhoods within the VND is a crucial issue.

[0185] Table 4 Variable Domain Descent (VND) Update Strategy

[0186]

[0187] Specifically, this embodiment first attempts to significantly update the solution structure by adjusting the number of trucks to change the number of current sub-paths. Based on this, it continuously uses three operators related to swapping and insertion to optimize the node access order under the current number of trucks. Once a better solution is found, it returns to adjusting the number of trucks to try to optimize the number of trucks again. If no better solution is found, it switches neighborhoods sequentially. Since this embodiment aims to call the best combination migration when it is more likely to get trapped in local optima, it is placed last. Finally, when the switching service is reached, it means that the current solution is difficult to improve by updating the number of trucks or changing the node access order. Therefore, in this stage, the switching service is continuously called to optimize the delivery method under the given path arrangement. Except for the switching service, all other operators adopt the first-improvement rule. The pseudocode of this algorithm process is shown in Table 4.

[0188] 2.3 Enhancements to the VNS framework.

[0189] 2.3.1 Multi-threaded parallel search.

[0190] According to the process of the General Variable Neighborhood Search (VNS-G), the order in which the perturbed neighbors are visited is currently undecided. Generally, this step requires defining the number of neighbors and the specific operations for each neighbor based on prior experience. However, this process not only requires extensive testing and experimentation but also lacks theoretical support. For example, assuming that the 7th neighbor in the neighborhood structure involves calling customer swaps 3 times followed by customer migrations 4 times, this embodiment often struggles to clearly explain the reasoning behind this setting (why not 4 customer swaps followed by 3 customer migrations? And what quantitative impact do different settings have on the algorithm's performance and robustness?).

[0191] Another approach is to predefine the possible neighborhoods to be selected for each perturbation in the set, and then randomly select a neighborhood during the perturbation. The number of times the selected neighborhood is repeatedly operated on increases with the magnitude of the perturbation. Increase synchronously. For example, At that time, the selected neighborhood is operated on once. In this approach, the selected neighborhood is processed 10 times, and so on. However, due to the randomness involved, the robustness of VNS under this method is significantly poor. Therefore, based on this, a variable neighborhood search (VNS-A) algorithm with perturbation-adaptive neighborhood selection is introduced.

[0192] Based on the above, the approach of this embodiment is to avoid the large amount of prior knowledge required to define the neighborhood space while maintaining the stability of the algorithm. Therefore, this embodiment introduces multi-threaded search, where each thread represents a perturbation operation on the neighborhood. A total of 5 threads are involved in the algorithm of this embodiment. Each thread uses an operator to perform perturbation and independently calls the VND to improve the solution based on the perturbation result. Finally, if a thread finds a better solution, the best solution among all threads is selected to update the global optimum, and the perturbation magnitude is adjusted. Reset to 1; if no better solution can be found for any of the lines, increase the perturbation amplitude. (That is, the number of repeated operations in the neighborhood of each thread increases year-on-year), see details for specific process. Figure 5 .

[0193] 2.3.2 Restart Mechanism (RM).

[0194] The third problem mentioned in Section 2.1 remains unsolved. Simply put, besides significant perturbations, this embodiment requires more targeted strategies to enhance the algorithm's ability to escape local optima after obtaining high-quality solutions. In fact, this problem has received considerable attention. However, incorporating relevant strategies into the neighborhood structure significantly weakens the algorithm's ability to escape local optima. Based on this, this embodiment draws on the destruction-repairing idea of ​​adaptive large neighborhood search algorithms and designs a separate set of heuristic rules. When a complete iteration (i.e....) arrive After the process ends, this method is called to reset the current solution; this is also known as the restart mechanism.

[0195] Specifically, this embodiment needs to clarify the reasons why the path planning scheme gets stuck in a local optimum. Simply put, some nodes may be difficult to directly replace with better locations during VND optimization due to service modes or congestion. For example, a customer point may have many neighbors far away, but since the current solution uses drones to serve this node, and there are no better locations to insert it for drone service, this node is unchangeable. However, in reality, if it were placed as a truck service point in another location (even though this step would be a negative benefit), it could provide more optimization space for other nodes, thus escaping the local optimum.

[0196] Based on the above considerations, this embodiment first obtains the sum of the scores of each client node and its preceding and following neighbors in the current solution, according to the scoring system mentioned in the optimal combination migration. Definition The degree of damage (0%-100%) is determined by the score. The process involves sequentially destroying points from the current solution in ascending order of cost, creating a set of destroyed points. Then, iterating through this set, for each point, sorting all sub-paths by the average distance between nodes within the path and the destroyed nodes in ascending order, and attempting to insert the destroyed nodes into the sub-paths sequentially (first inserting customer nodes that can only use truck services, then inserting drone-friendly nodes). Finally, marking all drone-friendly nodes in the path that do not use drone services, and attempting to insert these points as drone service points in the lowest-cost location.

[0197] 2.3.3 Secondary optimization.

[0198] To further enhance the algorithm's ability to escape local optima and improve its robustness, this embodiment designs a secondary optimization process based on the decomposable nature of the multi-vehicle routing problem. The idea behind this embodiment is that optimizing a single NP-hard problem of size 100 is far more difficult than optimizing two NP-hard problems of size 50, and the key lies in how to decompose the problem.

[0199] Specifically, when the algorithm outputs the final solution and Next, first calculate the average speed of each sub-path and sort them in ascending order. Then, iterate through the sorted sub-paths. Each time, a sub-path and other sub-paths with high similarity to that sub-path are selected to form a new combination of paths to be optimized, and VNS_PR is called again to attempt to further optimize the current solution, until all sub-paths have been optimized twice. The similarity of sub-paths can be determined by the centroid distance between each sub-path. This embodiment aims to use this problem decomposition method to more focusedly reorganize the truck service plans of nearby customers, thereby optimizing service paths that are more affected by road congestion as much as possible.

[0200] One possible specific embodiment is as follows:

[0201] I. Algorithm Parameter Settings

[0202] In this section, this embodiment evaluates and tests the proposed model and algorithm from multiple dimensions, including solution quality, solution efficiency, algorithm necessity, and robustness, under a unified experimental setup. Regarding parameter settings, the truck's fixed cost is 100, capacity is 200, truck speed in free-flow mode is 48 km / h, and basic fuel cost per kilometer is 1. The drone's capacity is set to 20, flight speed to 72 km / h, electricity cost per kilometer to 0.75, drone weight to 15 kg, and drone payload / power consumption to 0.5. The time-varying congestion granularity is discretized at 10-minute intervals (specific values ​​are randomly generated based on the experimental congestion index range), and the delivery task time limit is set to 6 hours. Furthermore, this section uses the Solomon Islands public dataset for experiments, where truck travel distance is calculated using Manhattan distance based on coordinates provided in the dataset, while drone flight distance is calculated using Euclidean distance. For the algorithm VNS_PRS, this embodiment sets its maximum number of perturbations. The algorithm terminates when the value is 15 and there is no improvement after ten consecutive complete iterations.

[0203] 2.2.1. Small-scale examples

[0204] In this section, this embodiment simulates three congestion index ranges on the Solomon datasets C101, R101, and RC101, where [1.0, 1.5) represents a relatively smooth road condition, [1.0, 2.0) represents a randomly congested condition, and [1.5, 2.0) represents a relatively congested condition. Table 5 compares the performance of CPLEX and the proposed VNS_PRS on small-scale problems (10 and 15 clients) across a total of nine instances. Due to the inherent randomness in the performance of heuristic algorithms, columns seven and eight show the average results and running time (in seconds) for 10 runs of VNS_PRS, respectively.

[0205] Table 5 Performance of VNS_PRS in small-scale instances (based on the commercial solver CPLEX)

[0206]

[0207] First, fine-grained time-varying modeling drastically reduces the efficiency of accurate solutions, with timeouts commonly occurring at a problem size of 15. Because this embodiment discretizes time-varying congestion with fine granularity, the operations research model introduces a large number of time-dependent binary variables and linkage constraints, leading to a rapid expansion of the branch and bound tree. Results show that when the problem size is 15, CPLEX triggers the 3600-second time limit on most combinations and fails to prove optimality. More importantly, its final feasible solution often differs significantly from VNS_PRS; for example, in the RC101, 15, [1.0, 2.0) instance, VNS_PRS reduces efficiency by 66.69% compared to CPLEX.

[0208] Secondly, VNS_PRS is insensitive to congestion granularity and can stably reach the optimal / near-optimal state within seconds. Unlike the tree search of MILP, VNS_PRS performs neighborhood iteration based on path sorting, and its time complexity is mainly affected by the customer size, while being relatively insensitive to congestion granularity. With a problem size of 10, VNS_PRS converges in approximately 0.7–1.7 seconds. Even with a problem size of 15, VNS_PRS maintains an average convergence time of approximately 2–6 seconds.

[0209] Furthermore, when CPLEX achieves its optimal solution on a scale of 10 instances, VNS_PRS matches its solution, verifying the consistency and correctness of the model and cost assessment. However, as the scale increases to 15, the solution cost and uncertainty of CPLEX rise rapidly, while VNS_PRS consistently obtains the optimal or better feasible solution within seconds (the results in columns six and seven are almost identical, indicating that the variance of VNS_PRS in 10 independent runs is extremely low), demonstrating both efficiency and robustness. Such phenomena sufficiently illustrate the necessity and effectiveness of developing an efficient heuristic algorithm for this research.

[0210] 2.2.2. Parameter tuning.

[0211] In the algorithm of this embodiment, customer migration and customer exchange are key neighborhoods for achieving improvements. However, since the time required to fully explore them increases dramatically with the problem size, it is necessary to decide the proportion of the VND exploration neighborhood in large-scale problems, denoted as . Meanwhile, the extent of damage in the restart mechanism. This directly determines the time required for a complete iteration after restarting. The greater the disruption, the further the solution after restarting is from the current optimal solution, and the longer the time required for the next iteration is likely to be. It's not hard to see that... and The impact on solution time is joint. When using heuristics to solve large-scale optimization problems, it is necessary to make a choice between solution time and solution quality, and find a parameter combination with a high "cost-effectiveness". In Table 6, this embodiment uses the Solomon C101 dataset as a blueprint to test different combinations for a problem size of 100 and congestion indices of [1.0, 1.5), [1.0, 2.0), and [1.5, 2.0). (0.1-0.4) and (0.1-0.5) The average result and average running time (seconds) of ten independent runs. Based on this, to further visualize the impact of parameters on algorithm performance, this embodiment linearly normalizes the average performance of different parameter combinations in different instances, and sums and averages the linearly normalized values ​​of the same parameter combinations under different congestion scenarios, thus obtaining... Figure 6 The smaller the "average performance" value, the better the algorithm generally performs under this parameter combination.

[0212] In terms of algorithm performance, the proportion of neighborhood exploration in VND is continuously increased. This can lead to continuous improvement in the quality of the solution; however, observation... Figure 6 The trend along the y-axis clearly shows that the improvement brought about by increasing the depth of neighborhood exploration first increases and then decreases (when...). After reaching 0.25, it was increased again. The potential improvements are significantly reduced. And regarding the destructive power of the restart mechanism... ,exist Before reaching 0.4, the solution quality continuously improved. However, when... When the value is 0.5, the solution quality deteriorates significantly. This is because excessive disruption approaches a "random restart," excessively weakening the local optimum information from previous iterations. In summary, if... If the depth is too low, even with strong destructive power, a local search will struggle to fully exploit the new space; if If the strength is too low, even a high neighborhood search strength may cause the search to linger around the current solution.

[0213] Regarding runtime, as shown in Table 6, as expected, increasing either parameter leads to a monotonically increasing average runtime. Especially when both parameters are simultaneously high, the time cost has a cumulative effect, resulting in the slowest combination in the entire table. =0.4, =0.5). With Increasing the value from 0.05 to 0.25 resulted in a 46.8-60.1% improvement in average runtime. Further increasing to 0.40, the increase expanded to 100.7-110.1% (nearly doubling). However, the overall improvement in algorithm performance was... The time cost is significantly reduced when the value is between 0.25 and 0.4. This indicates that even when the improvement in solution quality has reached a saturation point, the time cost continues to increase substantially without showing any signs of slowing down.

[0214] Therefore, this embodiment, after comprehensively balancing quality and time, ultimately selected ( =0.25, The parameter combination is 0.4. First, observing the graph, we can see that this combination is close to optimal in terms of normalized weighted scores, while its running time is significantly lower than all parameter combinations that outperform it. For example, ( =0.3, The combination of (=0.4) only improves the overall performance by 1.04%, but requires an additional 9.16%-22.25% of runtime. Furthermore, for traditional ALNS algorithms, under typical large-scale problems... Often, a smaller value will yield better results. However, in the RM of VNS_PRS, the optimal destruction rate is as high as 40%, an anomaly that will be explained in the next subsection (comparative analysis).

[0215] Table 6. Average algorithm performance under different parameter combinations

[0216]

[0217] 2.2.3. Comparative analysis.

[0218] This section compares the performance of the algorithm proposed in this embodiment (VNS-PRS) with other algorithms, with the main objectives being: 1) to prove that the new VNS framework proposed in this embodiment is superior to other traditional VNS frameworks; and 2) to prove that the algorithm proposed in this embodiment is better than the methods currently used in research related to drone-truck collaborative delivery. Based on the above, this embodiment implements six algorithms: VNS-G (a general version of VNS), VNS-A (a perturbation neighborhood adaptive selection VNS), VNS-PR, VNS-PRS, ILS, and ALNS. The operator settings for VNS-G and VNS-A are completely identical to those for VNS-PRS. VNS-PR is a version of VNS-PRS with reduced secondary optimization. This version was introduced because this embodiment aims to observe whether allocating some time to secondary optimization can truly improve performance under the same runtime conditions. Table 7 shows the best and average performance of six algorithms in ten independent runs, based on the Solomon dataset C101, with congestion indices following the intervals [1.0, 1.5), [1.0, 2.0), and [1.5, 2.0). The problem size is 60-100. Since the time complexity of each iteration varies among the different algorithms, this embodiment uses the VNS-PRS runtime as a benchmark for fair comparison, ensuring consistent runtime for all algorithms and using the same initial values ​​for each iteration.

[0219] Specifically, according to Table 7, the cost calculated by each algorithm increases with increasing road congestion. Overall, the VNS-type algorithms based on the operators in this embodiment and the customized VND descent rules generally outperform ILS and ALNS. VNS-G and VNS-A perform similarly, with VNS-G exhibiting higher stability (better average performance), VNS-A having a higher upper limit (slightly better optimal performance), while VNS-PR / PRS significantly outperforms the VNS algorithms under the traditional framework. In scenarios with low congestion coefficients, the overall solution cost of the six algorithms is low, and the performance of each algorithm is relatively similar (even so, VNS-PRS still achieves the best results across all scales). In scenarios with high congestion coefficients, the performance gap between different algorithms widens further, and the advantage of VNS-PRS becomes more prominent. In all instances, the average performance of VNS-PRS is significantly better than other algorithms. Compared to traditional VNS frameworks (VNS-G and VNS-A), ILS, and ALNS, VNS-PRS offers performance improvements of 0.1-10.94%, 2.25-14.58%, and 2.03-6.97%, respectively. The advantage of VNS-PRS increases with worsening road congestion. For VNS-PR, VNS-PRS achieves stable improvements through secondary optimization, with only one set of instances showing slightly lower performance than VNS-PR (<0.05%). On average, VNS-PRS maintains a significant lead (0.5-2.55% improvement).

[0220] Table 7 Algorithm Performance Comparison

[0221]

[0222] It is worth noting that the average cost of VNS-PRS is very close to the optimal cost across all scenarios, meaning that the algorithm can find high-quality solutions with similar results in each run. While other algorithms may occasionally find excellent solutions similar to VNS-PRS, they struggle to maintain the same level of performance consistently. To further explore the robustness of different algorithms, Figure 7 This section presents the distribution of results from multiple independent runs of each algorithm across all instances. The upper and lower bins represent the maximum / minimum values, the box portions represent the 25%-75% data range, and the dividing lines within the boxes represent the median. When the congestion index is in the ranges of [1.0, 1.5) and [1.0, 2.0), VNS-PR / PRS, benefiting from multi-threaded search and a restart mechanism, exhibits extremely high robustness despite using the exact same neighborhood operator and VND rules as VNS-G / A. VNS-PRS, in particular, maintains relative optimality, with almost identical results across 10 runs.

[0223] When the congestion index is in the range [1.5, 2.0), due to increased congestion, various algorithms are more prone to getting trapped in local optima. Taking a problem size of 60 as an example, the bins of VNS-A / G and ILS are basically stuck at 1700, while the bins of VNS-PR / PRS and ALNS can reach around 1600. This indicates that VNS-PR / PRS and ALNS have a stronger ability to escape local optima. However, observing all instances, it can be found that ALNS's ability to escape local optima is limited and unstable. VNS-PRS, due to its embedded quadratic optimization, can significantly improve the solution quality in difficult problem situations. In all instances, the bin and median position of VNS-PRS are lower than those of VNS_PR. For example, when the problem size is 80, although the optimal solution that VNS-PR can achieve (2130.56) is slightly better than VNS-PRS (2131.53), the better situation of VNS-PR is only short-lived (the boxes are concentrated at the tail), while VNS-PRS can approach the relatively optimal solution multiple times through secondary optimization.

[0224] Since this section compares algorithms based on runtime, it's not possible to directly determine the convergence speed of each algorithm. Therefore, in Figure 8 This embodiment demonstrates the iterative convergence of VNS-PRS, the best-performing VNS-type algorithm among ILS, ALNS, and VNS-like algorithms, under three congestion scenarios (scale 100). Intuitively, VNS-PRS converges much faster than ILS and ALNS. Thanks to the efficient exploration of the solution space by multi-threaded search, VNS-PRS achieves higher convergence speeds. In the case of [1.0, 1.5), fast convergence was achieved in less than 20% of the time. And... as well as In this case, VNS-PRS gets trapped in a local optimum (i.e., in... Figure 7 (A long plateau occurred). At this point, through continuous restarts, VNS-PRS successfully escaped the local optimum (i.e., the curve declined again after the plateau). Furthermore, VNS-PRS's rapid convergence makes its restart mechanism more suitable for large destruction ratios. Specifically, VNS-PRS can quickly explore the local solution space through multi-threaded search. When trapped in a local optimum, a large destruction restart will bring the current solution to a more distant solution space for thorough exploration. If the destruction ratio is too small, it will cause the multi-threaded search to overlap with historical iterations, resulting in wasted computational resources and decreased search efficiency.

[0225] In summary, by comparing the algorithm's solution quality, operational robustness, and convergence speed, this embodiment demonstrates that VNS-PRS maintains a leading solution performance regardless of whether the problem is in low or high congestion, or whether it is a small or large-scale problem. Furthermore, VNS-PRS exhibits the most robust and efficient performance in challenging scenarios involving high congestion and large-scale combinations.

[0226] The embodiments of this application achieve: 1) forming a processable mathematical model for real-time dynamic constraints in urban logistics distribution (such as road congestion and drone power consumption); 2) developing a more efficient, stable, and high-quality heuristic intelligent optimization solution algorithm framework based on this model, which is expected to be applied to optimization in other fields.

[0227] Some key technical solutions include:

[0228] (1) The congestion characteristics of urban roads over time (such as the decrease in speed during morning and evening rush hours) and the relationship between the power consumption and load of drones are simultaneously incorporated into the drone-truck collaborative delivery optimization model, providing a more refined modeling option for real drone-truck collaborative delivery operations.

[0229] (2) A novel variable neighborhood search algorithm framework (VNS-PRS) was developed, and several original sub-modules were introduced, including multi-threaded parallel perturbation, restarting the search process after getting stuck in a local optimum, and decomposing the problem based on road congestion and performing secondary optimization.

[0230] Other key technical solutions include:

[0231] (1) Modeling method: The characteristics of urban road traffic status changing over time and the power consumption rate of UAV affected by load are incorporated into the optimization of UAV-truck collaborative delivery to ensure that the solution is feasible in a real and dynamic traffic environment.

[0232] (2) Solution algorithm: A novel variable neighborhood search algorithm framework (VNS-PRS) was created, which combines multi-threaded parallel search, considers the restart mechanism after getting stuck in local optima, and achieves secondary optimization by decomposing the problem. This method has not only achieved excellent results in the current invention, but the general design ideas of each sub-module have made the framework highly extensible, that is, it can be applied to different optimization problems by adjusting the details of the algorithm.

[0233] Beneficial effects:

[0234] (1) The mathematical model constructed in this application embodiment can simultaneously depict the road traffic status that changes over time and the impact of the drone power consumption rate affected by load and time on the delivery plan in the scenario of truck-drone collaborative delivery. It is applicable to the real urban logistics delivery operation environment and can achieve more accurate and reasonable urban logistics delivery plan output.

[0235] (2) The intelligent optimization algorithm proposed in this application can significantly improve the ability to escape local optima during the solution process, with extremely fast convergence speed and good performance, solving the problem of low search efficiency of traditional algorithms in high-dimensional solution spaces. Relevant experimental data shows that the average performance of VNS-PRS is significantly better than other algorithms. Compared with traditional VNS frameworks (VNS-G and VNS-A), ILS, and ALNS, VNS-PRS can bring improvements of 0.1-10.94%, 2.25-14.58%, and 2.03-6.97%, respectively. The results of the embodiments show that the overall performance of this algorithm framework is significantly better than most existing related technologies on the market.

[0236] In addition, other methods can be used to solve the problem (such as ALNS, ILS and other methods mentioned in 2.2.3).

[0237] The following (Tables 8, 9, and 10) provide a description of the parameters that may be involved in this embodiment:

[0238] Table 8

[0239]

[0240] Table 9

[0241]

[0242] Table 10

[0243]

[0244] Reference Figure 9 This application provides a low-altitude ground collaborative delivery system that takes into account real-time road traffic conditions, including:

[0245] The vehicle modeling unit is used to construct, in segments, the travel time function and the travel speed function of delivery vehicles as they change with time and road segment.

[0246] The drone modeling unit is used to construct an energy consumption function for the power consumption rate of the drone per unit time; wherein, each of the delivery vehicles is equipped with a corresponding drone;

[0247] The planning model modeling unit is used to construct a mixed integer programming model based on the traffic speed function and the energy consumption function; wherein, the objective of solving the mixed integer programming model is to minimize the operating cost under the premise of completing delivery on time;

[0248] An initial solution generation unit is used to generate an initial solution for the mixed integer programming model according to the solution objective.

[0249] An initial solution iteration unit is used to perform a variable neighborhood search with multi-threaded parallel perturbation in the search space based on the initial solution, and then iteratively solves the optimal solution of the mixed integer programming model.

[0250] The optimal solution optimization unit is used to reset the optimal solution and obtain an optimized solution if the optimal solution does not meet the preset conditions after the maximum number of iterations has been reached.

[0251] The secondary optimization unit is used to perform a variable neighborhood search with multi-threaded parallel perturbation in the search space based on the primary optimization solution, and then iteratively solves the secondary optimization solution of the mixed integer programming model as the final solution.

[0252] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0253] In some alternative embodiments, the functions / operations mentioned in the block diagrams may not occur in the order shown in the operation diagrams. For example, depending on the functions / operations involved, two consecutively shown blocks may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order. Furthermore, the embodiments presented and described in the flowcharts of this application are provided by way of example to provide a more comprehensive understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of various operations is changed and sub-operations described as part of a larger operation are executed independently.

[0254] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0255] Although embodiments of this application have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of this application, the scope of which is defined by the claims and their equivalents.

[0256] The above is a detailed description of the preferred embodiments of this application, but this application is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A low-altitude ground-based collaborative delivery method considering real-time road traffic conditions, characterized in that, The method includes the following steps: The passage speed function is constructed in segments to represent the travel time function of delivery vehicles as a function of time and road segment. An energy consumption function is constructed based on the power consumption rate of the drone per unit time; wherein, each of the delivery vehicles is equipped with the drone. A mixed-integer programming model is constructed based on the traffic speed function and the energy consumption function; wherein, the objective of solving the mixed-integer programming model is to minimize the operating cost under the premise of completing delivery on time; Generate an initial solution for the mixed integer programming model according to the stated solution objective; Based on the initial solution, a variable neighborhood search with multi-threaded parallel perturbation is performed in the search space, and then the optimal solution of the mixed integer programming model is obtained by iterative solution. When the maximum number of iterations is reached, if the optimal solution does not meet the preset conditions, the optimal solution is reset to obtain an optimized solution. Based on the first-order optimization solution, a variable neighborhood search with multi-threaded parallel perturbation is performed in the search space, and then the second-order optimization solution of the mixed integer programming model is obtained iteratively as the final solution.

2. The low-altitude ground collaborative delivery method considering real-time road traffic conditions according to claim 1, characterized in that, The segmented construction of the delivery vehicle's travel time function as a function of time and road segment variation includes the following steps: The delivery vehicle is defined at the delivery point. , The distance and time traveled between them are related as follows: ； The above expression indicates that when the delivery vehicle selects an arc... At that time, the sum of the lengths of the sub-segments traversed by the delivery vehicle during all time periods is equal to the length of the arc. Indicates whether the path is feasible. Indicates the number of delivery points; Introducing decision variables To determine whether to choose Time period through arc and satisfy the following constraints: ； ； ； The above three constraints respectively indicate that only the delivery vehicle can select the arc. Only then will they further choose to go through the arc During the specified time period, the delivery vehicle selects an arc. At least one time period is required, during which the delivery vehicle is in the arc at any time. The distance traveled cannot exceed the arc. The total length, and cannot be driven during periods that have not been selected.

3. The low-altitude ground collaborative delivery method considering real-time road traffic conditions according to claim 1, characterized in that, The process of constructing the energy consumption function based on the unit time power consumption rate of the drone includes the following steps: The power consumption rate of the UAV per unit time is expressed as a function related to its own weight, payload, gravitational acceleration, air fluid density, number of UAV blades, and number of UAV rotors, and is referred to as the energy consumption function. The energy consumption function is divided into a loaded outbound energy consumption function and an unloaded inbound energy consumption function.

4. The low-altitude ground collaborative delivery method considering real-time road traffic conditions according to claim 1, characterized in that, The operating costs include delivery vehicle operating costs, drone flight costs, and fixed costs; the delivery vehicle operating costs consist of unit distance costs under free-flow conditions and additional costs under traffic congestion conditions; the drone flight costs are related to the total distance to the destination and return to the rendezvous point; and the fixed costs are related to the number of delivery vehicles used. The process of constructing a mixed-integer programming model based on the traffic speed function and the energy consumption function includes the following steps: The mixed-integer programming model is constructed as follows: 。 5. The low-altitude ground collaborative delivery method considering real-time road traffic conditions according to claim 1, characterized in that, The process of generating an initial solution to the mixed-integer programming model according to the objective includes the following steps: First, based on the nearest neighbor pairs of delivery points that can only be served by the delivery vehicles, a greedy solution is generated to produce pure delivery vehicle paths. Then, a variable neighborhood search algorithm is used to rapidly descent the greedy solution to improve the quality of the initial solution; For the delivery points served by the drones, drones are then inserted in ascending order of proximity to existing delivery vehicle sub-paths; if insertion is not possible, a new sub-path is created.

6. The low-altitude ground collaborative delivery method considering real-time road traffic conditions according to claim 1, characterized in that, The process of performing a multi-threaded parallel perturbation-based variable neighborhood search within the search space based on the initial solution, and then iteratively solving to obtain the optimal solution of the mixed integer programming model, includes the following steps: For each thread, the perturbation operator is used to perturb it in increments, and the variable neighborhood descent improvement is called independently. If any thread finds a better solution, the global optimum is updated and the perturbation magnitude is reset; If the solution of all threads does not improve, then the number of perturbations for each thread is increased synchronously.

7. The low-altitude ground collaborative delivery method considering real-time road traffic conditions according to claim 1, characterized in that, The process of resetting the optimal solution to obtain a first-order optimized solution includes the following steps: The sum of the scores of each delivery point and its neighbors in the current optimal solution is obtained according to the scoring system. Define the degree of destruction, and destroy the corresponding delivery points from the current optimal solution in order of increasing degree of destruction according to the score, and establish a set of destroyed delivery points; Iterate through the set of damaged delivery points. For each damaged delivery point, sort all current sub-paths in ascending order of the average distance between the current delivery point and the damaged delivery point, and insert the damaged delivery point into the sub-path in turn. Mark all target delivery points in the path that do not use drone services, and insert these target delivery points as drone service points in the location with the lowest cost.

8. A low-altitude ground-based collaborative delivery system considering real-time road traffic conditions, characterized in that: The system includes: The vehicle modeling unit is used to construct, in segments, the travel time function and the travel speed function of delivery vehicles as they change with time and road segment. The drone modeling unit is used to construct an energy consumption function for the power consumption rate of the drone per unit time; wherein, each of the delivery vehicles is equipped with a corresponding drone; The planning model modeling unit is used to construct a mixed integer programming model based on the traffic speed function and the energy consumption function; wherein, the objective of solving the mixed integer programming model is to minimize the operating cost under the premise of completing delivery on time; An initial solution generation unit is used to generate an initial solution for the mixed integer programming model according to the solution objective. An initial solution iteration unit is used to perform a variable neighborhood search with multi-threaded parallel perturbation in the search space based on the initial solution, and then iteratively solves the optimal solution of the mixed integer programming model. The optimal solution optimization unit is used to reset the optimal solution and obtain an optimized solution if the optimal solution does not meet the preset conditions after the maximum number of iterations has been reached. The secondary optimization unit is used to perform a variable neighborhood search with multi-threaded parallel perturbation in the search space based on the primary optimization solution, and then iteratively solves the secondary optimization solution of the mixed integer programming model as the final solution.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory; The memory is used to store programs; The processor executes the program to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a program that is executed by a processor to implement the method as described in any one of claims 1 to 7.

Images