Multi-AGV path planning method based on Petri network and mixed integer linear programming cooperation

Abstract

The invention discloses a multi-AGV path planning method based on cooperation of a Petri network and mixed integer linear programming, and the method comprises the steps: introducing the Petri network for modeling, and carrying out the modeling of corresponding places, tokens and transitions for three resources, namely AGVs, tasks and orbits; an MILP model is constructed; the Petri network triggers a path planning request change in an AGV resource module, and converts resource conflicts, path feasibility, cargo width change and task time limit in the Petri network into decision variables and logic constraints in MILP; each AGV calls an MILP model according to the current position and the starting points and the ending points of all the distributed tasks, and the analyzed optimal path and moment data are written into an AGV token in an AGV resource module; petri scheduling execution processes path conflicts among multiple AGVs, and a solving result of the MILP model is put into a Petri network for operation verification. Extensible, dynamic and intelligent multi-AGV path scheduling can be realized.

Description

Technical Field

[0001] The present invention relates to the field of intelligent manufacturing and logistics scheduling, and in particular to a multi-AGV path planning method based on the collaboration of Petri nets and mixed integer linear programming, which is used for path planning of multiple automatic guided vehicles (AGVs) in a complex track network. Background Art

[0002] An automated guided vehicle (AGV) is a robot capable of autonomous navigation and cargo handling. Through automation, AGVs accomplish tasks such as material handling and transportation, gradually replacing manual operations in fields such as manufacturing, logistics distribution, and firefighting. This significantly reduces labor costs while significantly improving the efficiency and accuracy of task execution. Compared to a single AGV, the simultaneous operation of multiple AGVs greatly increases work efficiency. Currently, multi-AGV systems are being applied in numerous fields, such as material handling in production workshops. In these workshops, the timely and safe completion of tasks by AGVs is crucial for ensuring production efficiency. Therefore, it is crucial for multiple AGVs to complete path planning in complex environments.

[0003] In actual industrial scenarios, AGVs not only need to complete point-to-point transportation tasks in complex track networks, but also have to deal with multiple dynamic and structural constraints, including but not limited to: changes in loading status: the width of the AGV is different when empty and fully loaded, resulting in changes in the set of accessible paths; spatial conflicts and interference: there are narrow sections or merging sections in the track network, and AGVs need to avoid physical collisions and mutual blockages; task timeliness requirements: each transportation task usually has a latest completion time, requiring the scheduling strategy to be both efficient and have timing constraints; resource sharing and mutual exclusion: multiple AGVs may request to enter the same track or area at the same time, and their access order must be coordinated to avoid conflicts and deadlocks.

[0004] Currently, mainstream multi-AGV path planning methods mostly use graph search algorithms (such as A*) or reinforcement learning algorithms. While graph search algorithms perform well in small-scale scenarios with simple constraints, they lack the ability to model complex constraints such as AGV width and cargo width, track width, and collisions with tracks. While reinforcement learning algorithms perform well in complex scenarios, they lack scalability, are expensive to train, and struggle to adapt to the frequent real-time changes in industrial scenarios.

[0005] Petri net is a model that can represent the flow of resources. It has the characteristics of concurrency, asynchrony, distribution, and deadlock detection, and can adapt well to complex scenarios. For example, Chinese patent application number 202010096155.5 discloses a vehicle path optimization method based on Petri nets and integer linear programming. This method adopts a hybrid modeling method based on Petri nets and mixed integer linear programming (MLIP) for urban logistics distribution path planning. However, its Petri net is only used for the model structure generator and does not participate in resource scheduling and conflict judgment during the path execution process. Petri nets are used to describe state transition structures, but are not used for path execution, resource conflict detection, and deadlock processing. Once the path is solved, it is fixed for execution. There is a lack of feedback adjustment mechanism, and it cannot adapt to sudden conflicts or resource changes during the operation of AGV. Chinese patent application number 202210196612.7 discloses a multi-AGV path planning and obstacle avoidance method based on a Petri net model. This method establishes an obstacle avoidance model based on Petri nets, implements path avoidance through static conflict classification (such as three types of opposite conflicts) and combines it with a state trigger mechanism. It is suitable for two-vehicle conflict scenarios, but has limited capabilities in task scheduling, global path optimization, and resource conflict control in multi-AGV systems. Its Petri net structure only expresses the occupancy status of AGVs between path nodes, lacks modeling of task attributes, AGV load changes, and track resource width, and has poor system scalability. It is difficult to support common industrial constraints such as task switching, loading and unloading processes, and track merging conflicts.

[0006] Therefore, the present invention provides an AGV path scheduling algorithm framework that collaborates with Petri nets and MILP to achieve multi-AGV dynamic path planning with the goal of minimizing the completion time of all AGVs, considering multiple constraints such as task attributes, vehicle size, track interference, etc., and with high scalability. Summary of the Invention

[0007] This paper addresses the problem of efficient path planning and scheduling for automated guided vehicles (AGVs) in complex industrial workshop environments under multiple constraints, including width changes after loading, track interference, resource conflicts, and task deadlines. A multi-AGV path planning method based on the collaborative power of Petri nets and mixed integer linear programming (MILP) is proposed. This method uses Petri nets to model the dynamic resource state of the entire production workshop. AGVs, tasks, and tracks are considered three types of resources, and corresponding places, tokens, and transitions are modeled for each of these three modules. This method accurately captures the concurrency, mutual exclusion, and resource state evolution of the entire multi-AGV system. The AGV data, task data, and track diagram data in the Petri net are then converted into decision variables and logical constraints in the MILP. When the Petri net plans a path for each AGV, transitions are triggered and the MILP is invoked to obtain an optimal solution. Finally, the optimized solution obtained by the MILP is fed back into the Petri net to trigger subsequent state evolution. The Petri net is then used to address congestion and deadlock issues encountered during AGV operation until all AGVs complete their assigned tasks. The path and schedule for each AGV are recorded and output as the final solution. Compared with traditional methods, this paper uses Petri nets to solve deadlocks and congestion caused by resource competition, and combines MILP to add multiple complex constraints for refined optimization, realizing a scalable, dynamic and intelligent multi-AGV path scheduling solution.

[0008] The technical solution adopted by the present invention to solve the technical problem is as follows:

[0009] In a first aspect, the present invention provides a multi-AGV path planning method based on the collaboration of Petri nets and mixed integer linear programming, the method comprising the following contents:

[0010] Step 1: Introduce Petri nets to model the dynamic state of resources in the entire production workshop. AGVs, tasks, and tracks are considered as three types of resources. The corresponding places, tokens, and transitions are modeled for each of these three resources, forming an AGV resource module, a task module, and a track resource module. The three modules are independent of each other.

[0011] Step 2: Construct a MILP model to solve the path planning of a single AGV;

[0012] Step 3: The Petri net triggers the path planning request transition in the AGV resource module, converting the resource conflicts, path feasibility, load width changes, and task deadlines in the Petri net into decision variables and logical constraints in the MILP. Each AGV root uses the current location and the start and end points of all assigned tasks to plan a feasible path in the track network. The parsed optimal path and time data are written to the AGV token in the AGV resource module.

[0013] Step 4: Petri scheduling is executed to handle the path conflicts between multiple AGVs.

[0014] The solution of the MILP model is put into the Petri net for verification, and the transition guard conditions in the Petri net are used to deal with resource conflicts and track interference problems. When each AGV completes all tasks in sequence according to the path output by the MILP model, the system outputs the complete path and corresponding schedule of each AGV as the final solution.

[0015] Furthermore, the specific process of step one is:

[0016] Conduct modular modeling of the production workshop and initialize input data, including task data, AGV data, and track map, where the track map is represented by a graph model;

[0017] Build the task module: Generate corresponding task attribute tokens from all task information. Each task information includes the starting point, end point, latest completion time, and cargo width attributes. Create three corresponding places to store tokens for tasks that have not yet started, tasks that are being executed, and tasks that have been completed. Create task start and task end transitions to start and complete a task, respectively.

[0018] Constructing the AGV resource module: For each AGV, a corresponding AGV token is generated based on its inherent properties (size, speed, etc.) and the bound task. A corresponding library is created for each AGV to store the AGV status and its assigned task information. Path planning request transitions, loading transitions, unloading transitions, and AGV movement transitions are created. These four transitions are used to trigger the call of the MILP model to generate a path, the AGV arrives at the task point to load, the AGV arrives at the task point to unload, and the AGV moves on the track.

[0019] Constructing a track resource module: Each track segment in the track graph is an edge in the graph model, and the two endpoints of the track segment are nodes in the graph model. For the workshop track network, each track segment is modeled as a track place, and a corresponding track token is generated for each track segment. The track token contains the occupant information of the track segment. Entering track transitions and leaving track transitions are created. These two transitions are used for AGVs to enter and leave the current track. At the same time, according to the actual layout of the workshop, track pairs that may physically interfere with each other are marked to enable conflict detection and width calculation during Petri net execution. Guard functions are embedded in the entering track transition to perform multi-layer conditional judgment:

[0020] 1) If the target track does not belong to the conflict group, determine whether the current track is occupied;

[0021] 2) If the target track belongs to a conflicting group, calculate the total width occupied by the tracks in the same group in real time;

[0022] 3) Based on a preset threshold and the current AGV width, determine whether the remaining space meets the safe coexistence condition. The safe coexistence condition is: when multiple AGVs pass through adjacent parallel track segments at the same time, the system must meet the spatial layout constraints to avoid physical interference between parallel vehicles.

[0023] Furthermore, in step 2, the MILP model includes the following key parts:

[0024] 1) Construct decision variables and objective functions

[0025] Define two decision variables, namely binary variables x i,j,t and the continuous-time variable y i,t , binary variable x i,h,t Indicates whether the AGV moves from node i to node j at time t; the continuous time variable y i,t Used to describe the time it takes for AGV to arrive at node i;

[0026] Set the objective function to minimize the total path;

[0027] 2) Add various constraints

[0028] Path continuity constraint: ensures that the inflow and outflow of each node satisfy the conservation relationship;

[0029] Time consistency constraint: If an edge is selected, the arrival time of the next node must be no less than the time of the current node plus the travel time;

[0030] Cargo width and track constraints: Ensure that the effective passage width of the AGV under the current loading state does not exceed the allowed width of the track;

[0031] Task constraints: ensure that each task does not exceed the deadline and is completed;

[0032] Task order constraint: ensures that tasks are executed in the order of the queue;

[0033] 3) MILP model solution

[0034] The MILP solver searches for the optimal solution based on the constraints and outputs the optimal value of each decision variable, i.e., the edge selection and node arrival time of the AGV at each moment.

[0035] Furthermore, the specific process of step 4 is as follows: the AGV moves sequentially according to the updated optimal path and time data. Before entering each track segment, the Petri net triggers the track resource module's entry track transition, executes the Guard check for resource mutual exclusion and track merging conflicts, and if the current track is occupied, enters the waiting queue. If the current track is idle, check whether the track is a marked parallel track. If it is a parallel track, query the occupancy status of all tracks in the same group, calculate the total occupied width and the remaining safety width, and if the safety width is greater than the current AGV's actual width, allow the AGV to obtain the current track. The safety width refers to the minimum effective space width required for a certain track section to avoid interference with other AGVs on the parallel track when allowing an AGV to pass.

[0036] When the Petri net plans a path for each AGV, a path planning request transition is triggered, and MILP is called to obtain an optimal solution. Finally, the optimized solution obtained by MILP is fed back to the Petri net to trigger subsequent state evolution. The Petri net is used to handle congestion and deadlock problems encountered during AGV operation until all AGVs complete their assigned tasks. The path and schedule of each AGV are recorded as the final solution output.

[0037] Furthermore, when the AGV completes the current track segment, it triggers the departure track transition in the track resource module to release resources, and updates the position in the AGV token to the end node of the current departure track segment, and records the time information of arriving at the node;

[0038] At the same time, the loading and unloading transitions of the AGV resource module control the loading / unloading operations at each key node. The loading and unloading transitions will update the loading status and actual width of the AGV. The actual width takes the maximum value of the cargo width and the AGV width.

[0039] In a second aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, which can implement the steps of the method when executed by a processor.

[0040] Compared with the prior art, the present invention has the following beneficial effects:

[0041] (1) The existing technology uses Petri nets to solve path planning problems in a relatively simple way. Its network model can only represent the "path occupancy" and "motion transfer" of AGVs, and lacks modeling of task attributes, AGV load changes, track resource width and direction status. In addition, the model structure is integrated and cannot be expanded. The present invention models the entire multi-AGV system based on Petri nets, creates three parts: task module, AGV resource module and track resource module, and uses independent libraries and transitions to model the task life cycle, AGV state changes and track segment state control. Each module is independent and loosely coupled, with good modularity and scalability. When the system task type or track topology structure changes, only some libraries and transitions need to be inserted or adjusted in the Petri net model, without the need to rebuild the model as a whole. This is significantly better than the reconstruction overhead of traditional scheduling models when facing topology changes or task dynamics.

[0042] (2) Compared with the existing methods that only rely on Petri nets to model path selection or conflict avoidance, the present invention embeds MILP path planning request transitions in the Petri net transition structure. Each time the AGV needs to trigger path planning, the MILP model solver is flexibly adjusted through this transition, and multiple constraints such as path continuity, time consistency, task deadline, and cargo width are explicitly modeled. In particular, in the practical problem of how cargo loading behavior affects the size of the AGV, the AGV width that changes with the pickup and unloading behavior is modeled as a variable in the MILP, making the path planning more in line with physical limitations and real scenarios, improving feasibility and path accuracy. Task-driven optimal path generation is achieved in real time. By encapsulating the path planning process within the MILP model, the Petri net not only has system modeling and execution control capabilities, but can also dynamically schedule external optimizers to complete path calculations, accurately responding to critical conditions such as task changes and conflicts, and greatly improving the flexibility, intelligence, and scheduling quality of the system.

[0043] (3) The present invention uses the MILP solution path as the initial scheduling strategy, and then uses the Petri net's operating mechanism to perform execution verification. The detailed transition guard conditions set in the track library in the Petri net are used to detect resource conflicts, track conflicts, width interference and other problems. For example, when an AGV applies for a section of track resources, the Petri net dynamically grants the right to use it based on whether there is an occupied AGV on the current track; when encountering a track conflict, the system detects the occupied width of the parallel track to decide whether to wait or pass. This structure that combines offline optimization with online judgment not only ensures the rationality of the overall system scheduling, but also effectively avoids deadlock and congestion, and improves operational robustness. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1This is a framework diagram of a multi-AGV path planning method based on Petri nets and mixed integer linear programming (MILP) in the present invention. DETAILED DESCRIPTION

[0045] The technical solution of the present invention is further described in detail below with reference to the accompanying drawings and specific embodiments, but is not intended to limit the scope of protection of the present application.

[0046] Example 1

[0047] This embodiment uses a multi-AGV path planning method based on the collaboration of Petri nets and mixed integer linear programming, including the following steps:

[0048] Step 1: Use Petri nets to modularize the production workshop

[0049] Initialize the input data, including task data, AGV data, and track graph. The track graph is represented by a graph model, track segments are represented by edges in the graph, and the two ends of a track segment are represented by nodes in the graph.

[0050] Modular modeling of the production workshop is carried out. First, the task module is modeled, and all task information (each task includes the starting point, end point, latest completion time, and cargo width) is converted into corresponding task attribute tokens; three corresponding warehouses are created to store task tokens that have not yet started, task tokens that are being executed, and task tokens that have been completed. Task start transitions and task end transitions are created to start and complete a task respectively.

[0051] The AGV resource module is modeled. For each AGV, a corresponding AGV token is generated based on its inherent properties (size, speed, etc.) and the bound tasks. A corresponding library is created for each AGV to store the AGV status and its assigned task information. Path planning request transitions, loading transitions, unloading transitions, and AGV movement transitions are created. These four transitions are used to trigger the call of the MILP model to generate a path, the AGV arrives at the task point to load, the AGV arrives at the task point to unload, and the AGV moves on the track.

[0052] The track resource module is modeled. For the workshop track network, each track segment (such as the edge (i, j) in the track graph, where i and j are nodes in the track graph) is modeled as a track place. A corresponding track token is generated for each track, and the token contains the occupant information of the track; the entry track transition and the exit track transition are used for the AGV to enter and exit the current track; at the same time, according to the actual layout of the workshop, for the physically side-by-side track pairs that may interfere with each other, set marks and safety width thresholds. The safety width refers to the minimum effective space width required for a certain track segment to allow an AGV to pass through in order to avoid interference with other AGVs on the parallel track. The safety width threshold refers to the minimum lateral safety distance that must be reserved when the AGV passes through a certain track segment to avoid interference with other AGVs on the parallel track. The Guard function is embedded in the entry track transition to perform multi-layer conditional judgment:

[0053] 1. If the target track does not belong to the conflict group, determine whether the current track is occupied;

[0054] 2. If the target track belongs to a conflicting group, the total width occupied by the tracks in the same group is calculated in real time;

[0055] 3. Based on the preset threshold and the current AGV width, determine whether the remaining space meets the safe coexistence conditions;

[0056] Step 2: Construct MILP model

[0057] The MILP model is constructed to solve the path planning of a single AGV. The MILP model includes the following key parts:

[0058] 1. Construct decision variables and objective functions

[0059] Define two decision variables, namely binary variables x ij,t , indicates whether the AGV travels from node i to node j at time t;

[0060] Continuous time variable y i,t , used to describe the time it takes for AGV to arrive at node i;

[0061] Set the objective function to minimize the total path.

[0062] 2. Add various constraints

[0063] Path continuity constraint: ensures that the inflow and outflow of each node satisfy the conservation relationship.

[0064] Time consistency constraint: If an edge is selected, the arrival time of the next node must be no less than the time of the current node plus the travel time.

[0065] Cargo width and track constraints: Ensure that the effective passage width of the AGV in the current loading state does not exceed the allowed width of the track.

[0066] Task constraints: Ensure that each task does not exceed the deadline and is completed.

[0067] Task order constraint: ensures that tasks are executed in the order of the queue.

[0068] 3. MILP model solution

[0069] The model is submitted to the MILP solver. The MILP solver searches for the optimal solution based on the constraints and outputs the optimal value of each decision variable, namely the edge selection and node arrival time of the AGV at each moment.

[0070] Step 3: Petri net scheduling execution and triggering the call of MILP for path planning

[0071] All task tokens are placed in the task library that has not yet started, and tasks are assigned to each AGV token according to the pre-allocation rules. The AGV token contains the task sequence information; each AGV token is placed in its own AGV library, the position is the current starting node, and all track libraries are initialized to idle.

[0072] The scheduling controller selects the first task token in the task queue from each AGV token and triggers the task transition of the task module, transferring the task token from the waiting state to the executing library (storing the executing task token), and updating the state to executing.

[0073] The corresponding AGV token updates the current task information in the corresponding AGV library and simultaneously updates the status of the AGV token to "working." When the AGV token status is "working" and the current task is activated, the Petri net triggers the path planning request transition of the AGV resource module. Each AGV uses the MILP model to plan a feasible path in the track network based on its current location and the start and end points of all assigned tasks. The resolved optimal path and time data are then written to the AGV token.

[0074] Step 4: Petri scheduling executes to handle path conflicts between multiple AGVs

[0075] The AGV moves sequentially according to the updated path data. Before entering each track segment, the Petri net triggers the track resource module's entry track transition and executes the Guard check for resource mutual exclusion and track merging conflicts. If the current track is occupied, the AGV enters the waiting queue. If the current track is idle, the AGV checks whether the track is a marked parallel track. If it is a parallel track, the occupancy status of all tracks in the same group is queried, the total occupied width and the remaining safety width are calculated, and if the safety width is greater than the current AGV actual width, the AGV is allowed to obtain the current track segment.

[0076] When the AGV completes its current track segment, it triggers the Track Resource module's Leave Track transition to release resources, updates the AGV token's location to that node, and records the time it arrived at that node. Loading and unloading operations are performed at each key node (controlled by the AGV Resource module's Loading and Unloading transitions). These transitions update the AGV's loading status and actual width (the maximum of the cargo width and the AGV width). After the AGV unloads, it triggers the Task module's Task End transition, placing the completed task token in the Completed Place and selecting the next task from the task queue in the AGV token to begin execution.

[0077] When each AGV completes all tasks sequentially according to the MILP output path, all task tokens are transferred to the completed library, and the system outputs the complete path and corresponding schedule of each AGV as the final solution.

[0078] Example 1

[0079] This embodiment is based on a multi-AGV path planning method that combines Petri nets with mixed integer linear programming (MILP), and includes the following steps:

[0080] Step 1: Modular modeling of the production workshop using Petri nets

[0081] The Petri net is mainly composed of three independent modules: task module, AGV resource module and track resource module.

[0082] The following describes the places, tokens, and transitions in each module, as well as the guard conditions for key transitions.

[0083] The task module creates three places, namely waiting place, executing place and completed place. Tokens for storing all unstarted tasks; executing libraries Tokens for tasks being executed, completed locations A token used to store completed tasks.

[0084] The structure of the task token Token_Task is:

[0085]

[0086] Among them, S x and E x is the starting point and end point of task x, D x is the latest completion time of task x, is the width of the goods, order specifies the order of the tasks in the queue; status indicates the task status, unstarted means not started, in_progress means being executed, done means completed; task_id indicates task information; Token_Taskx indicates the task token of task x.

[0087] The task module creates two transitions, namely the task end transition and the task start transition. StartTask Used to start the library from waiting Extract the task token, update its status to "in_progress", and write the task information into the corresponding AGV token; the task ends with transition T FinishTask After the task is completed, the task token is transferred to the completed library And update the task status to "done".

[0088] The AGV resource module includes AGV token, AGV library and four transitions (path planning request transition, loading transition, unloading transition and AGV movement transition)

[0089] Create an AGV library for each AGVn The AGV token Token_AGVn of the nth AGV is represented as:

[0090]

[0091]

[0092] Among them, agv_id represents the number of AGV, position represents the position of AGV, v n Indicates the speed of AGVn, Indicates the width of AGVn in the empty state. represents the actual width of AGVn, task_queue represents the task sequence, T m Represents the mth task in the task queue, m indicates that there are m tasks assigned in total, current_task_index indicates the current task index, path[] indicates the path function, and time_table[] indicates the timetable.

[0093] When AGVn starts to execute a task, Updated to Where T n,1 Indicates the first task in the task queue of the nth AGV. Indicates T n,1 The width of the cargo under the task.

[0094] Path planning request transition When the AGV starts to execute the first task, it triggers a path planning request, calls the MILP model to solve the complete path, and writes the solution result to the AGV token.

[0095] AGV Mobile Transformation move Used to execute AGV path movement, update the position and time in the AGV token, and trigger the resource occupancy update of the target track segment.

[0096] Loading Transition T ArriveStart and unloading transition T ArriveEnd It is used to load cargo at the mission start point, update the loading status and actual width, unload cargo at the mission end point, and update the status to mission completion.

[0097] Track resource module creates track library Track token Token_Track used to store track segment (i, j) ij , i and j represent the endpoints of the track segment, and i and j represent nodes in the track graph. Initial track token Token_Track ij The status is:

[0098] Token_Track ij ={occupied=False,occupier_id=null,W ij ,direction}

[0099] Among them, occupied indicates whether the track is occupied, occupier_id indicates the AGV id occupying the track, W ij Indicates the maximum allowed width of the track, and direction indicates the direction of the track. Based on the actual layout of the workshop, for track pairs where physical interference may occur, a parallel track group tag is given, a group identifier is assigned to the parallel track group G, and a safety width threshold δ is set. Multiple AGVs in the parallel track group can travel side by side. Create an entry track transition Used to control the AGV to enter the track and set the guard condition for the transition:

[0100] 1. Check the track segment status to determine whether the track segment is occupied by other AGVs. If so, stop and wait.

[0101] 2. If track segment (i, j) belongs to the parallel track group G, perform the following judgment: query the occupancy status of all track segments in the same group and calculate the total occupied width W other , calculate the remaining safety width W remain =δ-W other , when the remaining safety width W remain Not less than the current actual width of AGVn Right now , AGVn is allowed to occupy the track.

[0102] After the AGV enters the track, the track status is updated to "occupied" and the occupant is recorded.

[0103] Creating an Off-Track Transition It is used to clear the track occupancy information after the AGV leaves the track, update its status to idle, and release resources.

[0104] Step 2: MILP model construction

[0105] The MILP model consists of input parameters, defined variables, objective function, constraints, and model solution.

[0106] 1. Input parameters

[0107] The input parameters include the node s where the AGV is currently located, the task queue task_queue=[T1,T2,…,T m The starting point S of each task x in x 、End point E x , deadline D x and cargo width The length d of each edge in the orbital graph G = (V, E) ij With the allowable width W ij , AGV speed v n and its own width

[0108] 2. Define variables and objective function

[0109] Define a binary variable x i,j,t ∈{0,1}, indicating whether the AGV enters node j from node i at time t (t represents a discrete time step, t∈{0,T}, T is the maximum time step); define the continuous time variable y i,t ∈{0,1}, used to describe whether the AGV reaches node i at t, defining the variable and Indicates whether the pickup or unloading of task x is completed at time t, and defines the variable w t∈R+ represents the total width of the AGV at time t (the maximum value of its own width and the cargo width);

[0110] The objective function is the shortest path, as follows:

[0111]

[0112] Where E is the node set in the orbit graph G.

[0113] 3. Define constraints

[0114] Define the path continuity constraint, that is, the inflow and outflow of the AGV must be conserved:

[0115]

[0116] The sum of all adjacent nodes j connected to node i (representing all possible paths to enter or leave) is calculated. The goal is to ensure that the number of times the AGV flows into a node = the number of times it flows out of the node in the path. i,j / v n Represents the travel time on track segment (i, j). If AGVn arrives at node j at time t, it should arrive at time td i,j / v n Starting from node i; Indicates that at time td i,j / v n Enter node i from node j.

[0117] Define a time consistency constraint to ensure that if an edge is selected, the arrival time of the next node must be no less than the time of the current node plus the travel time d i,j / v n :

[0118]

[0119] That is, if the AGV starts from node i to j at time t, then it can only arrive at time t+d at the earliest. i,j / v n Arrive at node j, no earlier; Indicates whether the AGV is at t+d i,j / v n Arrives at node j.

[0120] Define task loading and unloading constraints, including that each task can only be loaded and unloaded at the corresponding node:

[0121]

[0122] and Indicates whether the AGV is at the starting point and end point of task x at time t.

[0123] Each task requires one pickup and one unloading:

[0124]

[0125] Here t = 0 to the maximum time step T.

[0126] Loading must be completed before the unloading deadline:

[0127]

[0128] Deadline D x Completed within:

[0129]

[0130] Define the cargo width and track constraints to ensure that the effective passage width of AGVn in the current cargo state does not exceed the track allowable width W ij :

[0131]

[0132] x i,j,t w t ≤W ij

[0133] in, represents the width of the cargo under task x; Indicates the width of AGVn in the empty state, x i,j,t w t It represents the effective passage width of the AGV under the current loading state when it walks on track (i, j) at time t.

[0134] Define task order constraints, that is, tasks must be completed in order:

[0135]

[0136] in, and are the pickup time and delivery time of task x respectively. There are m tasks in the task sequence.

[0137] 4. Model Solution

[0138] Submit the model to the MILP solver. The MILP solver searches for the optimal solution based on the constraints and outputs the optimal value of each decision variable, that is, the complete path and schedule of the AGV. The complete path consists of all x i,j,t =1, the timetable consists of all y i,t =1 composition.

[0139] Step 3: Petri net scheduling execution and triggering the call of MILP for path planning

[0140] Put all task tokens into the waiting start library of the task module And assign tasks to each AGV according to the pre-assignment rules. The AGV token contains the task sequence information. Each AGV token is placed in the corresponding AGV library in the AGV resource module. In the Token_Track, set the initial position of each AGV token, and initialize the path[] and time_table[] fields to empty. ij The state is initially set to Idle.

[0141] When the Petri net starts running, each AGV selects the first task from its task queue and triggers the task module to start transition T StartTask Start the task from the waiting library Put the executing library into Update its status from "unstarted" to "in_progress", the AGV token updates the current task information, and triggers the path planning request transition T of the AGV resource module PathPlan Call the MILP model.

[0142] Set the node s where the AGV is currently located, task queue task_queue=[T1,T2,…,T m The starting point S of each task x in x 、End point E x , deadline D x and cargo width The length d of each edge in the orbital graph G = (V, E) ij With the allowable width W ij , the speed of AGVn v n and its own width Input MILP model, MILP model outputs the complete path of AGV (all xi ,j,t = 1) and timetable (all y i,t =1).

[0143] Feedback the complete path and schedule to the AGV token of the corresponding AGV, that is, update the temporary path[] and time_table[] fields. path[] is the node sequence and also represents the path function; time_table[] is the arrival time of the corresponding node.

[0144] Step 4: Petri scheduling executes to handle path conflicts between multiple AGVs

[0145] AGV triggers the AGV movement transition T of the AGV resource module based on the updated path data move Execute the movement in sequence. move When a request is made to enter a track segment (i, j), the track resource module's entry track transition is triggered. At the same time, the guard condition for entering the track transition is determined: first check the track segment status to determine whether the track segment is occupied by other AGVs. If so, stop and wait. Then determine whether the track segment is a parallel track. If the track segment (i, j) belongs to the parallel track group G, query the occupancy status of all track segments in the same group and calculate the total occupied width W. other , calculate the remaining safety width W remain =δ-W other ,when When , AGVn is allowed to occupy the track segment. When the guard conditions are met, the entry track transition is executed Enter the track segment, update the position and time in the AGV token, update the occupancy status of the corresponding track token, and trigger the departure track transition after leaving the track segment. Release track resources.

[0146] When AGVn reaches the starting point of task x, the loading transition T of the AGV resource module is triggered. ArriveStart , and update the actual width of AGVn of the AGV token and the current task index current_task_index field, the actual width of AGVn Updated to When reaching the task end point, the unloading transition T of the AGV resource module is triggered ArriveEnd , update the actual width of the AGVn of the Pro brand and current_task_index field, the actual width of AGVn Updated to At the same time, the task module's task end transition T is triggered FinishTask , put the task token into the completed library

[0147] When all AGVs pass through each node in turn according to the MILP planned path and complete all tasks (all task tokens are transferred to the completed library The system outputs the final solution by recording the actual path and schedule of each AGV. Petri nets have sophisticated mechanisms for monitoring resource mutual exclusion and track conflicts, while MILP can optimally solve the full task path of a single AGV under a rigorous mathematical model. The combined effect of these two modules ensures an optimal solution without deadlock or conflicts.

[0148] The present invention uses Petri nets to model the problem. Petri nets are used for system modeling, resource state management, and path execution logic. The task module, AGV resource module, and track resource module are independent of each other and highly scalable. When the track topology or task type needs to be modified, only the corresponding library and transition of the new task, AGV, and track need to be inserted at the Petri net level. This solves the problem that traditional scheduling algorithms usually rely on fixed task or scenario structures, and modifying the topology or task type often requires a complete reconstruction of the model. MILP is used for path optimization, and the objective function is set to achieve the shortest path. Cargo width and track constraints are added. The AGV width (widening after picking up and restoring after unloading) is used as the key variable of MILP. The impact of vehicle load on size is considered, and the path accessibility constraints are dynamically adjusted. This explicit modeling of the impact of cargo behavior on the path is more in line with real-world scenarios. The solution of MILP is placed in the Petri net for operation and verification. The transition guard conditions in the Petri net are used to flexibly handle resource conflicts and track interference problems, realizing dynamic resource conflicts and track interference.

[0149] Any matters not described in the present invention are applicable to the prior art.

Claims

1. A multi-AGV path planning method based on the collaboration of Petri net and mixed integer linear programming, characterized in that: The method includes the following: Step 1: Introduce Petri nets to model the dynamic state of resources in the entire production workshop. AGVs, tasks, and tracks are considered as three types of resources. The corresponding places, tokens, and transitions are modeled for each of these three resources, forming an AGV resource module, a task module, and a track resource module. The three modules are independent of each other. Step 2: Construct a MILP model to solve the path planning of a single AGV; Step 3: The Petri net triggers the path planning request transition in the AGV resource module, converting the resource conflicts, path feasibility, load width changes, and task deadlines in the Petri net into decision variables and logical constraints in the MILP. Each AGV root uses the current location and the start and end points of all assigned tasks to plan a feasible path in the track network. The parsed optimal path and time data are written to the AGV token in the AGV resource module. Step 4: Petri scheduling is executed to handle the path conflicts between multiple AGVs. The solution of the MILP model is put into the Petri net for verification, and the transition guard conditions in the Petri net are used to deal with resource conflicts and track interference problems. When each AGV completes all tasks in sequence according to the path output by the MILP model, the system outputs the complete path and corresponding schedule of each AGV as the final solution.

2. The method according to claim 1, characterized in that The specific process of step one is: Conduct modular modeling of the production workshop and initialize input data, including task data, AGV data, and track map, where the track map is represented by a graph model; Build the task module: Generate corresponding task attribute tokens from all task information. Each task information includes the starting point, end point, latest completion time, and cargo width attributes. Create three corresponding places to store tokens for tasks that have not yet started, tasks that are being executed, and tasks that have been completed. Create task start and task end transitions to start and complete a task, respectively. Constructing the AGV resource module: For each AGV, a corresponding AGV token is generated based on its inherent attributes and the tasks it is bound to. A corresponding library is created for each AGV to store the AGV's status and assigned task information. Path planning request transitions, loading transitions, unloading transitions, and AGV movement transitions are created. These four transitions are used to trigger the call of the MILP model to generate a path, the AGV's arrival at the task point for loading, the AGV's arrival at the task point for unloading, and the AGV's movement within the track. Constructing a track resource module: Each track segment in the track graph is an edge in the graph model, and the two endpoints of the track segment are nodes in the graph model. For the workshop track network, each track segment is modeled as a track place, and a corresponding track token is generated for each track segment. The track token contains the occupant information of the track segment. Entering track transitions and leaving track transitions are created. These two transitions are used for AGVs to enter and leave the current track. At the same time, according to the actual layout of the workshop, track pairs that may physically interfere with each other are marked to enable conflict detection and width calculation during Petri net execution. Guard functions are embedded in the entering track transition to perform multi-layer conditional judgment: 1) If the target track does not belong to the conflict group, determine whether the current track is occupied; 2) If the target track belongs to a conflicting group, calculate the total width occupied by the tracks in the same group in real time; 3) Based on a preset threshold and the current AGV width, determine whether the remaining space meets the safe coexistence condition. The safe coexistence condition is: when multiple AGVs pass through adjacent parallel track segments at the same time, the system must meet the spatial layout constraints to avoid physical interference between parallel vehicles.

3. The method according to claim 1, characterized in that In step 2, the MILP model includes the following key parts: 1) Construct decision variables and objective functions Define two decision variables, namely binary variables x i,j,t and the continuous-time variable y i,t , binary variable x i,j,t Indicates whether the AGV moves from node i to node j at time t; the continuous time variable y i,t Used to describe the time it takes for AGV to arrive at node i; Set the objective function to minimize the total path; 2) Add various constraints Path continuity constraint: ensures that the inflow and outflow of each node satisfy the conservation relationship; Time consistency constraint: If an edge is selected, the arrival time of the next node must be no less than the time of the current node plus the travel time; Cargo width and track constraints: Ensure that the effective passage width of the AGV under the current loading state does not exceed the allowed width of the track; Task constraints: ensure that each task does not exceed the deadline and is completed; Task order constraint: ensures that tasks are executed in the order of the queue; 3) MILP model solution The MILP solver searches for the optimal solution based on the constraints and outputs the optimal value of each decision variable, i.e., the edge selection and node arrival time of the AGV at each moment.

4. The method according to claim 1, wherein The specific process of step 4 is as follows: the AGV moves sequentially according to the updated optimal path and time data. Before entering each track segment, the Petri net triggers the track resource module's entry track transition and executes the Guard check for resource mutual exclusion and track merging conflicts. If the current track is occupied, it enters the waiting queue. If the current track is idle, it checks whether the track is a marked parallel track. If it is a parallel track, it queries the occupancy status of all tracks in the same group, calculates the total occupied width and the remaining safety width, and allows the AGV to obtain the current track if the safety width is greater than the current AGV's actual width. The safety width refers to the minimum effective space width required for a certain track section to allow an AGV to pass through in order to avoid interference with other AGVs on the parallel track. When the Petri net plans a path for each AGV, a path planning request transition is triggered, and MILP is called to obtain an optimal solution. Finally, the optimized solution obtained by MILP is fed back to the Petri net to trigger subsequent state evolution. The Petri net is used to handle congestion and deadlock problems encountered during AGV operation until all AGVs complete their assigned tasks. The path and schedule of each AGV are recorded as the final solution output.

5. The method according to claim 4, characterized in that When the AGV completes the current track segment, it triggers the departure track transition in the track resource module to release the resources, updates the position in the AGV token to the end node of the current departure track segment, and records the time information of arriving at the node; At the same time, the loading and unloading transitions of the AGV resource module control the loading / unloading operations at each key node. The loading and unloading transitions will update the loading status and actual width of the AGV. The actual width takes the maximum value of the cargo width and the AGV width.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the steps of the method according to any one of claims 1 to 5 can be implemented.

Images