Task allocation method, device and equipment of robot cluster and medium

Abstract

A task allocation method, device, equipment and medium of a robot cluster are disclosed. The method comprises: acquiring real-time task amounts received by the robot cluster in each period, and determining a peak period according to a comparison result of the real-time task amounts and a warning threshold; determining a historical task amount of the peak period, and determining task shielding information of the peak period according to the historical task amount, the real-time task amount, the warning threshold and a maximum service request peak value of the robot cluster; shielding low-priority tasks received in the peak period according to the task shielding information, and allocating other tasks not shielded to the robot cluster for execution. The present application adaptively determines the peak period, and in the task allocation of the peak period, dynamically shields low-priority tasks in combination with the double factors of historical data and real-time data, dynamically releases transport capacity resources, improves the task execution efficiency of the robot cluster, and further improves the reliability and intelligent level of the hospital logistics system.

Description

Technical Field

[0001] This invention relates to the field of robotics, and in particular to a method, apparatus, device, and medium for task allocation in a robot swarm. Background Technology

[0002] In the construction of modern smart hospitals, logistics robot clusters have been widely used for the automated distribution of supplies such as medicines, specimens, and consumables. However, as business scenarios become increasingly complex, robot systems need to handle multiple types of tasks simultaneously, such as emergency medicine delivery (high priority), routine ward replenishment (medium priority), and non-emergency material transfer (low priority).

[0003] Existing scheduling methods mostly employ static priority rules or simple queue mechanisms, which are difficult to dynamically adapt to the real-world needs of hospitals during peak hours when both capacity constraints and sudden task demands coexist. Especially during peak periods, a large number of low-priority tasks continuously consume robot resources, leading to delays in the response of high-priority tasks, impacting clinical efficiency and even patient safety. While some systems introduce manual intervention for task filtering, they lack automated, data-driven filtering mechanisms, failing to balance capacity optimization and service assurance. Furthermore, manual maintenance requires configuration modifications at different times, demanding high experience levels, being complex, and prone to causing confusion. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and medium for task allocation in robot swarms to solve the problem of low task execution efficiency of robot swarms during peak hours.

[0005] According to one aspect of the present invention, a task allocation method for a robot swarm is provided, comprising: Obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result of the real-time task volume and the warning threshold; Determine the historical task volume during the peak period, and determine the task blocking information for the peak period based on the historical task volume, the real-time task volume, the early warning threshold, and the maximum service request peak of the robot cluster; Low-priority tasks received during peak periods are blocked according to the task blocking information, and other unblocked tasks are assigned to the robot cluster for execution.

[0006] According to another aspect of the present invention, a task allocation device for a robot swarm is provided, comprising: The peak period determination module is used to obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result of the real-time task volume and the warning threshold. The task masking determination module is used to determine the historical task volume during the peak period, and to determine the task masking information during the peak period based on the historical task volume, the real-time task volume, the warning threshold, and the maximum service request peak of the robot cluster. The task allocation module is used to block low-priority tasks received during the peak period according to the task blocking information, and to allocate other unblocked tasks to the robot cluster for execution.

[0007] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the task allocation method for robot clusters according to any embodiment of the present invention.

[0008] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the task allocation method for robot clusters according to any embodiment of the present invention.

[0009] According to another aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the task allocation method for robot swarms described in any embodiment of this application.

[0010] The technical solution of this invention automatically determines peak periods and dynamically adjusts the system for different time periods without human intervention, thus improving the accuracy of peak period determination. Furthermore, in the task allocation during peak periods, it combines historical and real-time data to dynamically and adaptively shield low-priority tasks, dynamically release transportation resources, improve the task execution efficiency of the robot cluster, and thereby enhance the reliability and intelligence level of the hospital logistics system.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention, 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a flowchart of a task allocation method for a robot swarm provided according to an embodiment of the present invention; Figure 2 This is a flowchart of another task allocation method for robot clusters provided according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a task allocation device for a robot swarm provided according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device that implements the task allocation method for robot clusters according to embodiments of the present invention. Detailed Implementation

[0014] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0015] It should be noted that the terms "candidate," "target," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0016] Figure 1This invention provides a flowchart of a task allocation method for a robot cluster. This embodiment is applicable to optimizing task scheduling for robot clusters performing multi-priority tasks. The method can be executed by a task allocation device for the robot cluster, which can be implemented in hardware and / or software and configured within the robot cluster's scheduling server. Figure 1 As shown, the method includes: S110. Obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result between the real-time task volume and the warning threshold.

[0017] Robot swarms refer to integrated systems composed of multiple collaborative logistics robots. These robots are assigned tasks, planned paths, and monitored through a unified scheduling platform, enabling them to navigate autonomously, avoid obstacles, and efficiently complete transportation tasks in a shared environment. For example, in hospital settings, robot swarms are typically used to perform tasks such as automatically delivering medicines, specimens, and consumables between nodes such as pharmacies, laboratories, wards, and operating rooms.

[0018] The time for the robot cluster to execute tasks is divided into time slots. The duration of each time slot can be adjusted according to specific scenario requirements and is not limited here; for example, the duration of a time slot can be one hour or half an hour. Specifically, the actual number of tasks received by the robot cluster in each time slot of the hospital is continuously collected as a real-time task volume reflecting the current logistics load. The real-time task volume corresponding to the current time slot is compared with a pre-set warning threshold: if the real-time task volume of the current time slot is greater than or equal to the warning threshold, the current time slot is determined to be a peak time slot; if the real-time task volume of the current time slot is less than the warning threshold, the current time slot is determined to be a normal time slot.

[0019] Among them, the warning threshold can be a pre-set critical value, such as the capacity critical value obtained based on historical data statistics. The warning threshold is a value that is less than the total number of robots in the robot cluster. That is, before the real-time task volume received by the robot cluster reaches the number of robots in the robot cluster, the corresponding time period is determined as the peak period, and task management is carried out in advance to ensure the rationality of task allocation.

[0020] By identifying peak periods, we can dynamically and objectively identify time windows of tight capacity, providing an accurate basis for timing judgments to subsequently trigger the blocking of low-priority tasks and prioritize the execution of high-priority tasks. This avoids relying on fixed schedules or human experience and improves the real-time performance and adaptability of scheduling responses.

[0021] In one feasible embodiment, the method further includes: Obtain the volume of multiple historical tasks received by the robot cluster in each time period; dynamically adjust the warning threshold corresponding to each time period based on the change information of multiple historical task volumes in each time period.

[0022] Because hospital logistics workloads exhibit significant non-uniformity and periodicity across different time periods—for example, morning medication deliveries, midday specimen deliveries, and nighttime off-peak periods show marked differences—using a uniform, fixed warning threshold would fail to effectively trigger peak detection during naturally high-load periods (e.g., 8–10 AM), while during low-load periods (e.g., late at night), a small number of tasks could be mistakenly identified as peaks, leading to resource scheduling imbalances. Therefore, it is necessary to differentiate warning thresholds based on historical workload data for each time period. For instance, a higher threshold could be set for high-load periods to reflect their normal capacity limits, while a lower threshold could be set for low-load periods to improve sensitivity.

[0023] Specifically, the number of tasks received by the robot cluster in different dates and at the same time periods is collected in advance to obtain the number of historical tasks corresponding to each time period. For example, the number of historical tasks received by the robot cluster from 8:00 to 9:00 every day within a week is collected to obtain seven historical task data corresponding to the time period of 8:00 to 9:00. The historical task volume of each other time period is obtained according to the same method.

[0024] The system comprehensively analyzes the changes in historical task volume across different time periods, including averages, fluctuation ranges, trends, and seasonal variations, and dynamically adjusts the warning threshold for each time period. For example, if the historical task volume for a certain time period shows a continuous upward trend or significant fluctuations, the warning threshold is increased accordingly to avoid frequent misjudgments of peaks; conversely, if the task volume tends to be stable and low, the threshold can be appropriately lowered to more sensitively capture true peaks.

[0025] Furthermore, the warning threshold for each time period can be predicted based on the historical task volume corresponding to each time period. For example, the historical task volume corresponding to each time period can be input into the trained prediction model, and the warning threshold for that time period can be predicted by the model.

[0026] Furthermore, the system obtains the volume of multiple historical tasks received by the robot cluster within each time period; and determines the warning threshold for different dates within each time period based on the change information of the multiple historical task volumes corresponding to each time period.

[0027] For example, for each time period (e.g., 8:00-9:00 every day), the task volume data received by the robot cluster during that time period on multiple historical dates (e.g., the past 30 days) is collected to form a set of historical task volume sequences for that time period; based on the variation characteristics of the historical task volume sequences, such as mean, standard deviation, maximum value, trend, or differences between weekdays and holidays, personalized early warning thresholds are calculated and set for that time period on different types of dates, such as weekdays, weekends, or holidays.

[0028] For example, if historical task volume is generally high on weekdays but significantly decreases on weekends, a higher warning threshold is assigned to weekdays and a lower threshold to weekends. This refined method of determining warning thresholds makes peak-hour judgments more aligned with actual business patterns, avoiding misjudgments or omissions caused by using a single static threshold, thereby improving the accuracy of task scheduling and the dynamic adaptability of robot resources.

[0029] This embodiment uses a historical data-based adaptive optimization method to enable the warning threshold to more accurately reflect the actual business load characteristics, thereby improving the reliability of peak-hour identification and the intelligence level of scheduling strategies. Furthermore, the dynamic adaptation mechanism can more accurately identify the true capacity shortage, avoid scheduling misjudgments caused by uniform thresholds, and ensure that high-priority tasks receive capacity support when they are truly needed, thereby improving the overall service efficiency and response reliability of the robot cluster.

[0030] S120. Determine the historical task volume during peak periods, and determine the task masking information during peak periods based on the historical task volume, real-time task volume, early warning threshold, and the maximum service request peak of the robot cluster.

[0031] After determining that the current period is a peak period, the historical task volume of the current period is determined. For example, the average of multiple historical task data corresponding to the current period is determined as the historical task volume. Combined with the current actual received real-time task volume, warning threshold, and the maximum service request peak of the robot cluster, a comprehensive evaluation is performed to dynamically generate task blocking information. For example, the task blocking information is to determine the low-priority task volume to be blocked during the current peak period to prevent the total task volume from exceeding the maximum service capacity of the cluster.

[0032] For example, as the real-time task volume gradually increases during peak hours, the shielding effect on low-priority tasks gradually increases; conversely, as the real-time task volume gradually decreases, the shielding effect on low-priority tasks automatically decreases. Task shielding information is used to reflect the shielding effect on low-priority tasks, such as a low-priority task shielding rate or a low-priority task shielding quantity. The specific value of the task shielding information can be determined comprehensively based on historical task volume, real-time task volume, warning threshold, and the maximum service request peak of the robot cluster.

[0033] For example, if the real-time task volume is greater than or equal to the warning threshold and (real-time task volume + historical task volume) / 2 is greater than or equal to the first ratio × the maximum service request peak, then the task blocking information is determined to be the low-priority task blocking rate as the first value; if the real-time task volume is greater than or equal to the warning threshold and (real-time task volume + historical task volume) / 2 is greater than or equal to the second ratio × the maximum service request peak, then the task blocking information is determined to be the low-priority task blocking rate as the second value; wherein, if the first ratio is greater than the second ratio, then the first value is greater than the second value. Furthermore, the low-priority task blocking rate in the task blocking information can be further subdivided, and the degree of subdivision is not limited here.

[0034] By integrating historical patterns, real-time status, and system capability boundaries to comprehensively determine task masking information, adaptive control commands based on multi-dimensional data fusion can be implemented, enabling flexible balancing of capacity assurance and service priorities.

[0035] Among them, the maximum service request peak of the robot cluster refers to the upper limit of tasks that the robot cluster can process within a unit of time period. That is, the upper limit of the maximum number of task requests that the robot cluster can stably undertake and complete under the current resource configuration, path planning capability and task processing efficiency. For example, the maximum service request peak of the robot cluster is equal to the number of robots, or it can be determined comprehensively based on factors such as the number of robots, the operating speed of a single machine, charging scheduling, average task time, path congestion, and the processing capacity of the central scheduling system, so as to reflect the extreme throughput capacity of the robot scheduling system under high load scenarios.

[0036] In one feasible embodiment, the peak value of the maximum service requests in each time period is dynamically adjusted based on the number of robots in the robot cluster and the task execution status of the previous time period.

[0037] The actual service capacity of a robot swarm is not constant but is affected by multiple time-varying factors. First, the actual service capacity of a robot swarm fluctuates over time, as some robots may be charging, undergoing maintenance, or experiencing malfunctions at specific times, leading to a decrease in effective capacity. Second, the task execution efficiency of a robot swarm has a significant time-dependent effect. For example, during morning rush hours, dense crowds, long elevator wait times, and congested passageways significantly extend the completion time of individual tasks, thereby reducing overall service capacity. Conversely, at night or during off-peak hours, when paths are clear, tasks are executed faster, maintaining a higher service capacity. Therefore, using a fixed maximum service request peak value will not accurately reflect these dynamic changes. This could lead to accepting tasks at high thresholds when actual capacity is limited, easily causing task backlog and delays; while during periods of ample capacity, it may result in overly conservative approaches, wasting resources.

[0038] In this embodiment, by combining the number of robots with the task execution status of the previous period, where the task execution status includes indicators affecting task execution and / or evaluation indicators of task completion progress, such as completion rate and average time consumption, the peak value of the maximum service request in each period is dynamically adjusted. This enables the scheduling system to more accurately assess its own service capacity boundaries, thereby ensuring the response of high-priority tasks while achieving efficient and flexible utilization of transportation resources.

[0039] Specifically, considering factors such as charging, malfunctions, or maintenance, the total number of available robots in the robot cluster for the current time period is determined as the robot count. The task execution status of the previous time period is also determined, including metrics such as task completion rate, task execution progress, and path congestion. If the task execution status reaches the expected level, the number of currently available robots is taken as the peak service request for the current time period, meaning that all currently available robots in the robot cluster can be scheduled and executed for the tasks of the current time period. Otherwise, the number of currently available robots is taken as the peak service request for the current time period, meaning that some robots in the robot cluster are still in the process of executing tasks from the previous time period and cannot execute real-time tasks for the current time period. The proportion of this portion of robots can be adjusted according to actual needs, for example, determined based on the task completion rate of the previous time period, or comprehensively determined based on metrics such as task completion rate, task execution progress, and path congestion.

[0040] This embodiment uses a dynamic adjustment mechanism for the peak service request at different times to make the system's assessment of its own service capabilities more closely reflect the real-time operating status, thereby providing a more accurate basis for decision-making on task masking and priority scheduling.

[0041] S130. Based on the task blocking information, low-priority tasks received during peak periods are blocked, and other unblocked tasks are assigned to the robot cluster for execution.

[0042] Task masking information indicates the masking status of real-time tasks during peak periods. For example, it includes the masking amount of low-priority tasks. Based on this task masking information, low-priority tasks among the real-time tasks received during the current peak period are filtered out. That is, tasks that are pre-marked as low-priority, such as non-urgent material replenishment and document transfer, are automatically intercepted or rejected, so that they do not enter the scheduling queue of the robot cluster. Other tasks that are not masked, including high-priority tasks such as emergency medicine delivery and surgical specimen transportation, as well as low-priority tasks that may be retained, enter the scheduling queue of the robot cluster normally and are assigned to available logistics robots by the scheduling system according to path, load, and timing requirements for execution.

[0043] For example, the task masking information is the low-priority task masking rate. The number of low-priority tasks pre-marked among the real-time tasks received during the current peak period is determined. The number of low-priority tasks to be masked is determined by multiplying the low-priority task masking rate by the number of low-priority tasks. The corresponding masked tasks are then selected from the low-priority tasks based on this number. If the low-priority task masking rate is 100%, then the remaining unmasked tasks are all non-low-priority tasks. If the low-priority task masking rate is less than 100%, then the remaining unmasked tasks are all non-low-priority tasks and a subset of low-priority tasks. The subset of unmasked low-priority tasks can be randomly selected from the low-priority tasks or determined based on their sorting priority.

[0044] In one feasible embodiment, assigning other tasks that are not masked to the robot cluster for execution includes: High-priority tasks that are not masked will be assigned to the robot cluster for execution according to their corresponding timing requirements. After the high-priority tasks are assigned, the low-priority tasks that are not masked are assigned to the robot cluster for execution according to their corresponding timing requirements.

[0045] After masking low-priority tasks during peak hours, identify the remaining unmasked tasks. First, assign all high-priority tasks to the robot cluster for execution according to their respective execution time windows or sequence requirements, such as delivery within 10 minutes or processing in the order of receipt, to ensure the timeliness and reliability of high-priority tasks. After all high-priority tasks during peak hours have been assigned, if the robot cluster still has remaining capacity, then schedule and assign the remaining unmasked low-priority tasks according to their own time requirements, such as deadlines or queuing order.

[0046] Furthermore, high-priority tasks differ at different times. For example, in a hospital, specimen delivery takes priority from 7:00 AM to 10:00 AM, while disinfection of outpatient departments takes priority from 5:00 PM to 6:00 PM. Therefore, high-priority tasks are pre-sorted according to the requirements of different time periods, and then executed in that order.

[0047] This embodiment uses a priority-based phased allocation mechanism to maximize the use of idle capacity while ensuring core business operations, thus balancing service efficiency and resource utilization.

[0048] The technical solution of this embodiment automatically determines peak periods and dynamically adjusts the system for different time periods without human intervention, thereby improving the accuracy of peak period determination. Furthermore, in the task allocation during peak periods, it combines historical and real-time data to dynamically and adaptively shield low-priority tasks, dynamically release transportation resources, improve the task execution efficiency of the robot cluster, and thus enhance the reliability and intelligence level of the hospital logistics system.

[0049] Figure 2 This is a flowchart illustrating another task allocation method for a robot swarm provided by an embodiment of the present invention. This embodiment further refines the process of determining task masking information in the above embodiments. For example... Figure 2 As shown, the method includes: S210. Obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result of the real-time task volume and the warning threshold, and determine the historical task volume of the peak period.

[0050] S220. Determine the historical pressure impact parameters for peak periods based on historical task volume.

[0051] Based on the historical task volume corresponding to the peak period, a quantitative indicator is determined to assess the historical load pressure level of that period, namely the historical pressure impact parameter. The historical pressure impact parameter for the peak period characterizes the average pressure level exerted on the robot swarm during historical operations. For example, the average historical task volume of multiple historical periods corresponding to the peak period can be used as the historical pressure impact parameter, or the historical pressure impact parameter can be determined based on the statistical characteristics of the historical task volume of multiple historical periods corresponding to the peak period. These statistical characteristics include, but are not limited to, peak frequency, fluctuation amplitude, or the proportion of days exceeding conventional thresholds.

[0052] For example, if a hospital's peak hours are both 9:00-10:00 AM and 10:00-11:00 PM, then by analyzing the historical workload for each of these periods, and determining that the historical workload for 9:00-10:00 AM is greater than that for 10:00-11:00 PM, the historical pressure impact parameter for 9:00-10:00 AM is greater than that for 10:00-11:00 PM. This indicates that 9:00-10:00 AM is a period of consistently high pressure, while 10:00-11:00 PM may be an occasional peak period.

[0053] In one feasible embodiment, S220 includes: The historical pressure impact parameter is determined based on the ratio of historical task volume to the peak of maximum service requests.

[0054] Specifically, the historical pressure impact parameter is determined based on the ratio of the historical task volume corresponding to the current peak period to the peak service request volume. For example, if the average of multiple historical task data points during the current peak period is determined as the historical task volume M', and the peak service request volume during the current peak period is determined as M, then the historical pressure impact parameter is expressed as M' / M.

[0055] S230. Determine the real-time pressure impact parameters during peak periods based on real-time task volume, early warning threshold, and maximum service request peak.

[0056] Based on the current peak-hour real-time task volume, warning threshold, and peak service request volume of the robot cluster, a quantitative indicator to characterize the current instantaneous load pressure level is calculated, namely the real-time pressure impact parameter. This real-time pressure impact parameter reflects the degree of stress on the robot cluster's actual operating pressure relative to its service capacity at the current moment.

[0057] For example, when the real-time task volume approaches or exceeds the warning threshold and is close to the peak of maximum service requests, the real-time pressure impact parameter value is high, indicating that the system is under high load or even on the verge of overload; conversely, if the real-time task volume reaches the warning threshold but is far below the maximum service capacity, the parameter value is low. This parameter can serve as a key basis for dynamically adjusting the task shielding intensity or triggering resource scheduling optimization, enabling accurate perception and rapid response to capacity risks.

[0058] In one feasible embodiment, S230 includes: The real-time task difference is determined based on the difference between the real-time task volume and the warning threshold. The extreme task difference is determined based on the difference between the peak value of the maximum service requests and the warning threshold; The real-time stress impact parameter is determined based on the ratio of the real-time task difference to the extreme task difference.

[0059] The real-time task difference refers to the difference between the real-time task volume received by the robot cluster during the current peak period and the corresponding warning threshold for that period. It is used to quantify the degree to which the current load exceeds the warning level. This real-time task difference reflects the degree of deviation of the current actual pressure from the warning baseline; the larger the value, the more significant the current task pressure.

[0060] The limit task difference refers to the difference between the maximum peak service request of the robot cluster and the warning threshold, representing the tolerable task redundancy space between the warning threshold and the upper limit of the system's processing capacity. The larger the difference, the stronger the system's buffering capacity after the warning is triggered; if the difference is smaller, it means that the warning threshold is set too high or the system capacity is close to its limit, and even a slight increase in tasks may lead to overload.

[0061] For example, if the real-time task volume during the current peak period is determined to be Y, the warning threshold is W, and the maximum service request peak is M, then the real-time task difference is YW, the extreme task difference is MW, and the real-time pressure impact parameter is expressed as (YW) / (MW).

[0062] S240. Determine the task shielding information for peak periods based on historical pressure impact parameters and real-time pressure impact parameters.

[0063] Task masking information for peak periods is determined based on a combination of historical and real-time pressure impact parameters. For example, task masking information is determined by a weighted sum of historical and real-time pressure impact parameters.

[0064] For example, based on the above example, the task masking information represents the low-priority task masking rate as ((YW) / (MW)) × (M' / M). This means that when Y is greater than W, low-priority tasks begin to be masked. As the real-time task volume Y increases, the masking rate for low-priority tasks gradually increases. When the Y value approaches M, the masking rate for low-priority tasks approaches 100%, thus ensuring the execution of high-priority tasks. Furthermore, based on the historical task volume M', the total task pressure multiplier during the current peak period can be obtained. The larger the historical data M', the faster the rate of increase in the low-priority task masking rate.

[0065] S250: Based on the task masking information, mask low-priority tasks received during peak periods, and assign other unmasked tasks to the robot cluster for execution.

[0066] Optionally, the robot cluster operation and management system determines peak task periods based on statistical big data and real-time operational big data. When a peak is predicted, it automatically adjusts the task release restrictions for each department, blocks the release permissions for some low-priority tasks, and notifies the reason for rejection. As a result, high-priority tasks can automatically obtain robot service resources without being affected.

[0067] Optionally, when blocking the posting of some low-priority tasks during peak periods, the system can provide a reason and suggest waiting until after the peak to post the task. If the task is urgently needed, manual intervention can be initiated to complete the delivery, thereby alleviating system pressure during peak times. After the peak period, the system will automatically lift the restriction, and low-priority tasks can regain their task posting privileges.

[0068] This embodiment uses historical and real-time data to determine and predict peak periods for robot tasks, and automatically adjusts the release permissions of different priority tasks, dynamically blocking the release of low-priority tasks to ensure the smooth execution of high-priority tasks. Based on real-time data, it blocks low-priority tasks and dynamically adjusts according to actual pressure to ensure the robot cluster outputs maximum capacity efficiency. After the peak period, it dynamically releases the release channel for low-priority tasks, ensuring the smooth execution of high-priority tasks while enabling the robot cluster to output maximum capacity to gradually meet the needs of low-priority tasks. When the system blocks low-priority tasks, it outputs the predicted end time of the peak period so that users can decide whether to wait or switch to manual execution based on the predicted end time.

[0069] The technical solution of this embodiment achieves automatic priority adjustment through dynamic masking at different time periods. As the real-time task volume increases in different time periods, the masking amount of low-priority tasks corresponding to that time period also increases, thereby achieving dynamic adjustment of task scheduling. This ensures the smooth execution of high-priority tasks while avoiding resource waste caused by static thresholds, maintaining the maximum capacity output of the robot cluster, and avoiding waste of robot resources.

[0070] Figure 3 This is a schematic diagram of a task allocation device for a robot swarm provided in an embodiment of the present invention. Figure 3 As shown, the device includes: The peak period determination module 310 is used to obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result of the real-time task volume and the warning threshold. The task masking determination module 320 is used to determine the historical task volume during the peak period, and to determine the task masking information during the peak period based on the historical task volume, the real-time task volume, the warning threshold, and the maximum service request peak of the robot cluster. The task allocation module 330 is used to block low-priority tasks received during the peak period according to the task blocking information, and to allocate other unblocked tasks to the robot cluster for execution.

[0071] The technical solution of this embodiment automatically determines peak periods and dynamically adjusts the system for different time periods without human intervention, thereby improving the accuracy of peak period determination. Furthermore, in the task allocation during peak periods, it combines historical and real-time data to dynamically and adaptively shield low-priority tasks, dynamically release transportation resources, improve the task execution efficiency of the robot cluster, and thus enhance the reliability and intelligence level of the hospital logistics system.

[0072] Optionally, the task masking determination module 320 includes: The historical pressure impact parameter determination unit is used to determine the historical pressure impact parameters of the peak period based on the historical task volume. The real-time pressure impact parameter determination unit is used to determine the real-time pressure impact parameters for the peak period based on the real-time task volume, the early warning threshold, and the maximum service request peak value. The task masking information determination unit is used to determine the task masking information for the peak period based on the historical pressure impact parameters and the real-time pressure impact parameters.

[0073] Optional, the historical pressure influence parameter determination unit is specifically used for: The historical pressure impact parameter is determined based on the ratio of the historical task volume to the peak value of the maximum service request.

[0074] Optional, a real-time pressure influence parameter determination unit, specifically used for: The real-time task difference is determined based on the difference between the real-time task volume and the warning threshold; The extreme task difference is determined based on the difference between the maximum service request peak and the warning threshold; The real-time pressure influence parameter is determined based on the ratio of the real-time task difference to the extreme task difference.

[0075] Optionally, the device also includes a dynamic adjustment module for the warning threshold, used for: Obtain the volume of multiple historical tasks received by the robot cluster within each time period; The warning threshold for each time period is dynamically adjusted based on the changes in the historical task volume for each time period.

[0076] Optionally, the peak value of the maximum service request in each time period is dynamically adjusted based on the number of robots in the robot cluster and the task execution status of the previous time period.

[0077] Optional, a task assignment module, including a robot execution unit, is used for: The high-priority tasks that are not masked are sequentially assigned to the robot cluster for execution according to their corresponding timing requirements; After the high-priority tasks are assigned, the low-priority tasks that are not masked are assigned to the robot cluster for execution according to their corresponding timing requirements.

[0078] The task allocation device for robot clusters provided in this embodiment of the invention can execute the task allocation method for robot clusters provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0079] The acquisition, storage, use, and processing of data in this application comply with relevant national laws and regulations and do not violate public order and good morals.

[0080] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0081] Figure 4 A schematic diagram of an electronic device 10, which can be used to implement embodiments of the present invention, is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0082] like Figure 4 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0083] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0084] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods described above, such as the task allocation method for robot swarms.

[0085] In some embodiments, the task allocation method for the robot swarm can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the task allocation method for the robot swarm described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to execute the task allocation method for the robot swarm by any other suitable means (e.g., by means of firmware).

[0086] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific reference products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0087] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0088] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0089] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0090] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as data servers), or computing systems that include switching components (e.g., application servers), or computing systems that include front-end components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such back-end, switching, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0091] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0092] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication unit 19, or installed from storage unit 18, or installed from ROM 12. When the computer program is executed by processor 11, it performs the functions defined in the methods of the embodiments of the present invention.

[0093] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the task allocation method for robot clusters as provided in any embodiment of this application.

[0094] In implementing the computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0095] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0096] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for task allocation in a robot swarm, characterized in that, The method includes: Obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result of the real-time task volume and the warning threshold; Determine the historical task volume during the peak period, and determine the task blocking information for the peak period based on the historical task volume, the real-time task volume, the early warning threshold, and the maximum service request peak of the robot cluster; Low-priority tasks received during peak periods are blocked according to the task blocking information, and other unblocked tasks are assigned to the robot cluster for execution.

2. The method according to claim 1, characterized in that, The task blocking information for peak periods is determined based on the historical task volume, the real-time task volume, the early warning threshold, and the maximum service request peak of the robot cluster, including: The historical pressure impact parameters for the peak period are determined based on the historical task volume. The real-time pressure impact parameters for the peak period are determined based on the real-time task volume, the early warning threshold, and the maximum service request peak. The task masking information for the peak period is determined based on the historical pressure impact parameters and the real-time pressure impact parameters.

3. The method according to claim 2, characterized in that, Based on the historical task volume, the historical pressure impact parameters for the peak period are determined, including: The historical pressure impact parameter is determined based on the ratio of the historical task volume to the peak value of the maximum service request.

4. The method according to claim 2, characterized in that, The real-time pressure impact parameters for the peak period are determined based on the real-time task volume, the early warning threshold, and the maximum service request peak value, including: The real-time task difference is determined based on the difference between the real-time task volume and the warning threshold; The extreme task difference is determined based on the difference between the maximum service request peak and the warning threshold; The real-time pressure influence parameter is determined based on the ratio of the real-time task difference to the extreme task difference.

5. The method according to claim 1, characterized in that, The method also includes: Obtain the volume of multiple historical tasks received by the robot cluster within each time period; The warning threshold for each time period is dynamically adjusted based on the changes in the historical task volume for each time period.

6. The method according to claim 1, characterized in that, in, The peak value of the maximum service requests in each time period is dynamically adjusted based on the number of robots in the robot cluster and the task execution status of the previous time period.

7. The method according to claim 1, characterized in that, Assigning other tasks that are not masked to the robot cluster for execution, including: The high-priority tasks that are not masked are sequentially assigned to the robot cluster for execution according to their corresponding timing requirements; After the high-priority tasks are assigned, the low-priority tasks that are not masked are assigned to the robot cluster for execution according to their corresponding timing requirements.

8. A task allocation device for a robot swarm, characterized in that, The device includes: The peak period determination module is used to obtain the real-time task volume received by the robot cluster in each time period, and determine the peak period based on the comparison result of the real-time task volume and the warning threshold. The task masking determination module is used to determine the historical task volume during the peak period, and to determine the task masking information during the peak period based on the historical task volume, the real-time task volume, the warning threshold, and the maximum service request peak of the robot cluster. The task allocation module is used to block low-priority tasks received during the peak period according to the task blocking information, and to allocate other unblocked tasks to the robot cluster for execution.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the task allocation method for the robot swarm according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the task allocation method for the robot cluster as described in any one of claims 1-7.

Images