Robot task scheduling method and system, robot and storage medium

Abstract

The invention belongs to the field of robot control, and discloses a robot task scheduling method and system, a robot and a storage medium, and the method comprises the steps: responding to a request of a target task, and querying the state of a global task lock in the robot; under the condition that the global task lock is not occupied, whether the target task can be executed currently or not is determined according to the running state of a function module associated with the target task in the robot and a preset conflict strategy table; wherein the preset conflict strategy table is used for describing the running state of the robot and the logic relation between the tasks; under the condition that the target task can be executed currently, the global task lock is updated to be in an occupied state, an independent scheduling thread is created, a task starting instruction is issued to an associated function module through the independent scheduling thread, and then the robot is controlled to execute the target task. According to the method provided by the invention, the robot tasks can be uniformly and efficiently scheduled and managed.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of robot control, and in particular to a robot task scheduling method and system, a robot, and a storage medium. BACKGROUND

[0002] With the rapid development of robot technology, robots are increasingly widely used in industrial manufacturing, services, medical treatment, warehousing, and other fields. In order to ensure the operation safety and task execution efficiency of robots, modern robot systems usually introduce a state machine mechanism to model and control various operating states of robots. However, in actual applications, traditional state machines are usually used as decentralized state control mechanisms in different modules, and lack unified scheduling and coordination of global behaviors, which may cause concurrent calls of multiple algorithm modules by a business layer or an upper task system, and may cause problems such as call conflicts and chaotic execution sequences. SUMMARY

[0003] The present application provides a robot task scheduling method and system, a terminal device, and a storage medium, and aims to solve the problem that in the prior art, unified and efficient scheduling and management cannot be achieved when the state of a robot is converted.

[0004] In a first aspect, an embodiment of the present application provides a robot task scheduling method, including: In response to a request of a target task, querying a state of a global task lock in a robot; If the global task lock is not occupied, determining whether the target task is currently executable according to an operating state of a function module associated with the target task in the robot and a preset conflict strategy table, wherein the preset conflict strategy table is used to describe a logical relationship between operating states of the robot and tasks; If the target task is currently executable, updating the global task lock to an occupied state, and creating an independent scheduling thread to issue a start task instruction to the associated function module through the independent scheduling thread, so as to control the robot to execute the target task.

[0005] In some embodiments, the logical relationship includes mutual exclusion relationships and dependency relationships between operating states of the robot and different tasks; The step of determining whether the target task is currently executable according to the operating state of the function module associated with the target task in the robot and the preset conflict strategy table includes: If the function module associated with the target task is currently in an operating state, querying the preset conflict strategy table to determine whether the function module is in the operating state and the target task are in a mutual exclusion relationship; If not mutually exclusive, further confirm whether the first running state of the robot in a dependency relationship with the target task exists and is satisfied, and if the first running state is satisfied, confirm that the target task is currently executable; If mutually exclusive, or not mutually exclusive but the first running state of the robot in a dependency relationship with the target task exists and is not satisfied, confirm that the target task is currently not executable.

[0006] In some embodiments, the step of determining whether the target task is currently executable according to the running state of the functional module associated with the target task and the preset task conflict strategy table further comprises: If the functional module is currently in an idle state, query the preset conflict strategy table to determine whether the second running state of the robot in a dependency relationship with the target task exists and is satisfied; If satisfied, confirm that the target task is currently executable; if not satisfied, confirm that the target task is currently not executable.

[0007] In some embodiments, the logical relationship includes an interrupt relationship between different priority tasks of the robot, and the method further comprises: If the global task lock is occupied, if the target task has the highest priority, or if the priority of the target task is higher than the priority of the task being executed based on the preset conflict strategy table, determine that the target task is currently executable, otherwise, determine that the target task is currently not executable.

[0008] In some embodiments, the robot task scheduling method further comprises: If the target task is currently executable, create the independent scheduling thread, issue a stop instruction to a first target module associated with the task being executed which needs to be interrupted through the independent scheduling thread, issue a start task instruction to the functional module, and further control the robot to execute the target task.

[0009] In some embodiments, the robot task scheduling method further comprises: During execution of the target task by the robot, set a request for a new task to a waiting state or wait for the global task lock to be released before executing the new task when the priority of the new task is lower than the priority of the target task being executed; wherein the conditions for the global task lock to be released include that the target task ends execution or is interrupted abnormally.

[0010] In some embodiments, the robot task scheduling method further comprises: The state changes of the global task lock, task interruption behaviors, and task execution exception events are recorded to generate a task scheduling log.

[0011] Secondly, embodiments of this application provide a robot task scheduling system, including: The status query module is used to query the status of the global task lock in the robot in response to the request of the target task; An executability assessment module is used to determine whether the target task is currently executable based on the running status of the functional modules associated with the target task in the robot and a preset conflict strategy table, when the global task lock is not occupied; wherein, the preset conflict strategy table is used to describe the running status of the robot and the logical relationship between tasks; The scheduling and execution module is used to update the global task lock to an occupied state when the target task is currently executable, and to create an independent scheduling thread to issue a task start instruction to the associated functional module through the independent scheduling thread, thereby controlling the robot to execute the target task.

[0012] Thirdly, embodiments of this application provide a robot, including: a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, it implements the robot task scheduling method described above.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the robot task scheduling method described above.

[0014] Compared to existing technologies, this application provides a robot task scheduling method, system, robot, and storage medium. The method pre-sets a global task lock within the robot for unified task management. Upon receiving a request from a target task, it first checks the status of the global task lock to prevent concurrent tasks from directly preempting resources and thus preventing scheduling conflicts. If the global task lock is not occupied, it further evaluates the executability of the target task based on the operating status of the functional modules associated with the target task and a preset conflict strategy table. If it is currently executable, it updates the global task lock to an occupied state to maintain the exclusivity during task execution and creates an independent scheduling thread to ensure that scheduling operations do not block the main control logic, thereby controlling the robot to execute the target task. This method achieves unified and efficient scheduling and management of robot tasks, solving many drawbacks of traditional distributed state control. Attached Figure Description

[0015] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A flowchart illustrating the robot task scheduling method provided in this application; Figure 2 A flowchart illustrating the feasibility assessment in the robot task scheduling method provided in this application; Figure 3 A schematic diagram illustrating an application of the robot task scheduling method provided in this application; Figure 4 This is a schematic diagram of a robot task scheduling system provided in this application.

[0017] Figure reference numerals: 110 - Status query module; 130 - Executability assessment module; 150 - Scheduling execution module. Detailed Implementation

[0018] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0019] The components of the embodiments of this application described and illustrated in the accompanying drawings can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of the embodiments of this application provided in the drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] In the following text, the terms "comprising," "having," and their cognates, which may be used in various embodiments of this application, are intended only to indicate a particular feature, number, step, operation, element, component, or combination thereof, and should not be construed as primarily excluding the presence of one or more other features, numbers, steps, operations, elements, components, or combinations thereof, or adding the possibility of one or more combinations thereof. Furthermore, the terms "first," "second," "third," etc., are used only for distinguishing descriptions and should not be construed as indicating or implying relative importance.

[0021] Unless otherwise specified, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which the various embodiments of this application pertain. Terms (such as those defined in commonly used dictionaries) shall be interpreted as having the same meaning as in their contextual meaning in the relevant technical field and shall not be construed as having an idealized or overly formal meaning, unless clearly defined in the various embodiments of this application.

[0022] This application provides a robot task scheduling method. It establishes a global task lock mechanism, ensuring all tasks are processed by the scheduler, guaranteeing that only one task can enter the scheduling process at a time, thus preventing concurrent tasks from directly competing for resources. Simultaneously, it introduces a pre-defined conflict policy table describing the robot's operating state and the logical relationships between tasks for comprehensive judgment. Task scheduling is only allowed when tasks are conflict-free and satisfy the relevant dependencies of their operating states. During task scheduling, an independent scheduling thread is created to interrupt executing tasks or functional modules and issue start commands, thereby controlling the corresponding functional modules to execute the target task. Through the synergy of these methods, more efficient, stable, and intelligent task management and state control can be achieved, effectively improving the execution efficiency and accuracy of robot tasks.

[0023] The following describes the design scheme of the robot task scheduling method through some embodiments.

[0024] Please see Figure 1 This application provides a robot task scheduling method, including steps S100-S300: S100: In response to the request of the target task, query the status of the global task lock in the robot.

[0025] The Global Task Lock is a mutual exclusion mechanism used to constrain the concurrent initiation of related tasks, ensuring that only one task is in execution at any given time. The target task can be a user-issued task or a timed task triggered by a timer mechanism. For example, the target task may include, but is not limited to, return-to-home, charging, emergency stop, navigation, and object recognition tasks.

[0026] It's important to note that the global task lock here primarily targets high-level, complex tasks involving multi-module collaboration, consuming critical resources, possessing security sensitivity, or requiring exclusive execution environments, such as food delivery, patrolling, charging, and emergency obstacle avoidance. This is to prevent hardware resource conflicts, chaotic control commands, inconsistent states, and increased security risks. Lightweight auxiliary tasks that do not affect the overall system state can still run in parallel under safe conditions without preempting the task lock, such as LED lighting effects, voice broadcasts, uploading and synchronizing runtime data or logs, and scanning for Wi-Fi signal connections.

[0027] As an example, after receiving a request for a target task, the robot will preprocess the request information, including determining the validity of the target task, parameter information, priority information, and which related functional modules are required for execution. For example, navigation tasks typically require a vision acquisition module and a navigation algorithm module. Simultaneously, the robot will determine whether any tasks are currently executing to decide whether to allow the target task to enter the scheduling process. Specifically, the robot queries the current state of the global task lock. If it is in an occupied state (also known as locked), it indicates that there is an executing task; if it is in an unoccupied state (not locked), it indicates that there is no currently executing task for the robot.

[0028] Normally, when a task begins execution, the robot control system locks the global task lock, setting it to an occupied state. If a new task request arrives at this time, it is not allowed to enter the task scheduling process, ensuring that only one task can enter the scheduling process at a time, thus achieving orderly task access. When the task completes or exits abnormally, the global task lock is released, setting it to an unoccupied state. At this point, entry into the task scheduling process is allowed, and the new task is added to the task scheduling queue.

[0029] For example, suppose a user simultaneously issues two commands: "Start Patrol" and "Charge Now." Without a global task lock, the navigation module might have already started moving, while the power management module would also be preparing to charge. This would cause a conflict between the chassis movement and the charging port docking. The charging port needs to connect to a charging station, but the charging station's location is fixed. Therefore, if the chassis is moving, the charging task cannot be completed. However, in this application, by adding a global task lock, only one task can acquire the lock and execute first; the other must wait or be interrupted according to priority. It can be understood that by setting a global task lock, the execution of these high-level composite tasks is determined uniformly, effectively avoiding the resource contention or state chaos caused by multiple modules making their own judgments in traditional solutions.

[0030] S200. If the global task lock is not occupied, determine whether the target task is currently executable based on the running status of the functional modules associated with the target task in the robot and the preset conflict strategy table.

[0031] The preset conflict strategy table primarily describes the robot's operating status and the logical relationships between tasks. It can be predefined by system architects or engineers during the system design phase, based on the robot's application scenario, safety requirements, and task logic. For example, in an industrial robot, the "safety control" module has the highest priority and can interrupt all other tasks. Optionally, users can customize or modify this conflict strategy table through a visual interface or configuration interface. Alternatively, the system can automatically optimize the conflict strategy table using machine learning based on historical scheduling data, task conflict events, and task execution success rates.

[0032] In some embodiments, the logical relationships described in the above-mentioned preset conflict strategy table may specifically include one or more combinations of mutual exclusion, dependency, interruption and parallel relationships between the robot's operating state and different tasks.

[0033] The robot's operating states can be categorized according to different scenarios. For example, based on movement, they can include stationary and moving states; based on battery status, they can include low battery and fully charged states; based on whether the operation is normal, they can include normal and fault states; based on task execution, they can include standby, idle, and execution states. The idle state can be a waiting state after the previous task has ended but before entering a new task, while the standby state is generally a low-power state entered when no task has been executed for a long time; the execution state refers to the state where the robot is performing a specific task. In this implementation, a conflict strategy table is suggested between the robot's various states and various tasks, listing whether each task conflicts with or depends on any of the various states. Furthermore, different tasks are prioritized. For example, during task execution, the emergency stop task has the highest priority and can interrupt all execution-type tasks; when the battery is low, the charging task usually also has the highest priority. The specific priorities of various tasks can be set according to the actual application scenario, and are not limited here.

[0034] The relationships are as follows: mutual exclusion means that two tasks cannot run simultaneously (e.g., "automatic charging" and "autonomous movement" cannot be performed at the same time); dependency means that task B can only be executed after task A is completed (e.g., "starting work" requires "completion of positioning"), or that to execute task C, the robot must first be in running state D (e.g., "delivery task" requires "sufficient power" to start); interruption means that a high-priority task can interrupt a low-priority task (e.g., "emergency stop" allows interruption of all executing tasks); and parallelism means that two tasks can run simultaneously (e.g., "photographing" and "moving" can be performed simultaneously). Since parallelism does not cause conflicts, it will not be discussed further in this application. It is understood that the tasks described in the above conflict strategy table mainly include tasks that require unified management using a global task lock.

[0035] Among them, the functional modules associated with the target task refer to the software and hardware components that the robot needs to call when performing the target task. For example, these functional modules may include, but are not limited to, one or more of the following: motion control module (responsible for the robot's motion control, including path execution, obstacle avoidance, speed control, direction adjustment, etc.), perception module (responsible for the robot's collection and processing of environmental information, such as LiDAR, visual recognition, SLAM (simultaneous localization and mapping), etc.), human-computer interaction module (handling human-computer interaction tasks, such as voice interaction, interface operation, command input, etc.), algorithm module and task execution module (responsible for performing specific business tasks, such as grasping, handling, sorting, assembly, etc.).

[0036] For step S200, as an example, if the global task lock is found to be currently unoccupied (i.e., in an unlocked or released state), it indicates that the robot control system is currently idle and there are no tasks in progress. At this point, it is initially considered schedulable, and the target task is allowed to enter the task scheduling process. However, before executing the task scheduling, further judgment is needed to determine whether it is currently executable. If it is currently executable, an executable status is returned, and the task scheduler schedules it for execution. Conversely, if it is currently not executable, the specific reason for the non-execution is returned to remind the user to handle it promptly.

[0037] Regarding the determination of executability, in some embodiments, such as Figure 2As shown, the current execution status of the target task can be comprehensively determined based on the current running status (e.g., idle, executing, or completed) of the functional modules associated with the target task, combined with a preset conflict strategy table. It can be understood that the current running status of the aforementioned functional modules can have multiple states. If it is idle or completed, it indicates that it is available for subsequent calls and can therefore be considered idle. Conversely, if it is executing, it indicates that it is currently occupied and is therefore considered running. Similarly, the conflict strategy table also has multiple logical relationships, so there are multiple combinations for determining whether the task is currently executable, which will be explained one by one below.

[0038] In one scenario, if a functional module associated with the target task is detected to be currently running (corresponding to...) Figure 2 In step S201, the preset conflict strategy table is further queried to determine whether the functional module's running state and the target task are mutually exclusive (corresponding to...). Figure 2 Step S203 in the above steps confirms whether the running functional module can simultaneously execute the corresponding function in the target task. If they are mutually exclusive, it means they cannot be executed simultaneously with the target task, and it can be directly determined that they are currently not executable (corresponding to...). Figure 2 Step S211 in the process.

[0039] Conversely, if they are not mutually exclusive, it means that the execution of the target task is not affected. Further optionally, if they are not mutually exclusive, it can be further confirmed whether there are other logical conflicts, such as dependencies. In one optional scheme, if they are not mutually exclusive, it is confirmed whether there is a first operating state of the robot that is dependent on the target task (corresponding to...). Figure 2 Step S205 in the text refers to the robot needing to meet a first operating state before executing the target task. If this dependency exists, it is necessary to further determine whether the robot's current operating state is in the first operating state (corresponding to...). Figure 2 Step S207 in the process. Specifically, when the robot is currently in this first running state, it is confirmed that the target task is currently executable (corresponding to...). Figure 2 In step S209), and when the robot does not currently meet the first operating state, it is confirmed that the target task is currently unexecutable (corresponding to...). Figure 2 (Step S211 in the above). Conversely, if the above dependency does not exist, skip this step and confirm that the target task is currently executable (corresponding to...). Figure 2 Step S209 in the process.

[0040] In another scenario, if a functional module associated with the target task is detected to be currently idle, it indicates that these functional modules are currently available for use. Next, a preset conflict strategy table can be queried to determine if there is a second operating state for the robot that depends on the target task. It is understood that the distinction between the first and second operating states is primarily for ease of differentiation between the robot's operating states under two different conditions (the operating state and the idle state of the functional modules).

[0041] Optionally, if this dependency exists, it is necessary to further determine whether the robot's current operating state is in the second operating state. Specifically, if the robot is currently in the second operating state, the target task is confirmed to be executable; if the robot is not currently in the second operating state, the target task is confirmed to be unexecutable. Conversely, if the dependency does not exist, this step is skipped, and the target task is confirmed to be executable.

[0042] It is understandable that by judging the running status of the functional module and combining it with the preset conflict strategy table to determine whether there are mutual exclusion relationships and dependencies, fine-grained and semantic scheduling decisions can be made, thereby improving the rationality and security of scheduling.

[0043] Optionally, the logical relationships described in the preset conflict strategy table also include the interruption relationships between different priority tasks of the robot. It can be understood that task requests involving safety sensitivity usually have the highest priority. Therefore, in order to reduce damage to the robot, the currently executing task needs to be interrupted in a timely manner. In some embodiments, the process of querying the state of the global task lock in the robot further includes: If the global task lock is occupied, the target task is determined to be executable if it has the highest priority, or if the target task's priority is determined to be higher than the priority of the currently executing task based on the preset conflict policy table. Optionally, if the target task's priority is not higher than the priority of the currently executing task, the target task is determined to be unexecutable and will enter a waiting state.

[0044] It is understandable that even if the global task lock is occupied (i.e., in a locked state), if the target task has the highest priority, such as an emergency stop, or a higher priority than the currently executing task, it can still be considered executable. However, the currently executing task needs to be interrupted before the target task can be executed.

[0045] As an alternative, when the global task lock is held and the target task enters a waiting state, a timeout mechanism can be set. Specifically, if the global task lock is still held after a preset waiting time (i.e., a timeout has occurred), it indicates that the currently executing task may have encountered an error or is taking too long. At this point, based on the priority of the currently executing task, it can be determined whether to actively release the global task lock, thus preventing prolonged blocking. In short, by setting a timeout mechanism after determining that the global task lock is held, system blocking caused by prolonged waiting can be effectively prevented.

[0046] It is understandable that after conducting an executability assessment of the target task, the decision on whether to immediately enter the task scheduling process to execute the target task can be made based on the assessment results. It is worth noting that in this embodiment, a separate scheduling thread will be used to uniformly send control commands.

[0047] S300: If the target task is currently executable, update the global task lock to an occupied state and create an independent scheduling thread to issue a task start instruction to the associated functional module through the independent scheduling thread, thereby controlling the robot to execute the target task.

[0048] As an example, upon determining that the target task is currently executable, a separate scheduling thread will be created to send task start instructions to various associated functional modules, ensuring the orderly distribution of instructions among the modules. Optionally, the robot will automatically reclaim thread resources after completing all instructions for the target task, thereby reducing system resource overhead.

[0049] At the same time, the robot control system updates the global task lock from its unoccupied state to an occupied state, i.e., performs a "locking" operation. This ensures that other lower-priority tasks cannot preempt the target task during its execution.

[0050] As an alternative approach, considering the possibility that the target task has the highest priority or a higher priority than the currently executing task, the currently executing task must be interrupted before the target task can be executed. Exemplarily, the method further includes: If the target task is currently executable, an independent scheduling thread is created to issue a stop command to the first target module associated with the currently executing task that needs to be interrupted, thereby interrupting its current task. Then, a start task command is issued to the functional module, thereby controlling the robot to execute the target task.

[0051] It is understood that the scheduling thread in this embodiment has two operations: first, it sends a "stop execution" instruction to the preempted functional module; second, it sends a "start task" instruction to the functional module that is about to start. By using an independent scheduling thread to send unified instructions, orderly control between modules can be ensured. By interrupting in advance and then starting to execute a new task, the closed-loop controllability of the state transition process can be ensured, avoiding intermediate exceptions generated by partial execution.

[0052] As an alternative approach, if a new task is received while the robot is executing the target task, the request for the new task is set to a waiting state. Alternatively, if the priority of the new task is lower than that of the currently executing target task, the robot waits for the global task lock to be released before executing the new task. The conditions for releasing the global task lock include: the target task completing execution or being abnormally interrupted.

[0053] It is important to understand that if one or more new tasks are received subsequently, these tasks can be added to the scheduling queue. Optionally, when adding them to the scheduling queue, the scheduling order can be determined based on the priority of these new tasks to ensure that high-priority tasks are executed first.

[0054] In one embodiment, the robot task scheduling method further includes: Record global task lock state changes, task interruption behaviors, and task execution exception events to generate task scheduling logs.

[0055] As an example, throughout the entire task scheduling process, the state transitions of the global task lock, task interruptions, and abnormal task execution events can be recorded in their entirety, generating a task scheduling log. For instance, it can record and generate timestamps of global task lock state transitions, including the locking and releasing transition trajectories; record instances where lower-priority tasks are interrupted in the event of conflicts between different tasks; and record abnormal task execution events during task scheduling, such as module scheduling anomalies and communication failures. This log is primarily intended for later debugging and fault analysis, thus providing data support for system maintenance, operational diagnosis, and behavior tracing.

[0056] The following example, using a specific task, illustrates the robot's task scheduling method: like Figure 3 As shown, taking delivery as the target task, the robot first preprocesses the delivery request after receiving it (corresponding to...). Figure 3 Step S301 in the process confirms the validity of the task and information such as the destination. Upon confirming the need to execute a delivery task, it checks whether the global task lock is in an occupied state (corresponding to...). Figure 3Step S302 in the process determines whether a task is currently being executed and decides whether to proceed with the task executability assessment process based on the query result. If the query result indicates an occupied state, the process enters a waiting state and continues querying (corresponding to...). Figure 3 (Step S303 in the process). If the query result is "unoccupied," it indicates that there is no task in progress at this time. Further determination will be made as to whether the delivery task is currently executable (corresponding to...). Figure 3 (Step S304 in the text). Since the delivery task involves operations such as positioning, navigation, and obstacle avoidance, and the functional modules involved include positioning, navigation, and obstacle avoidance modules, the robot will query whether these related functional modules are currently running. If they are idle, they can be considered initially schedulable. If at least one functional module is running, it is necessary to further determine whether the executing functional module and the delivery task are mutually exclusive. If they are mutually exclusive, it is considered that the task is currently not executable, and the reason for non-execution can be returned (corresponding to...). Figure 3 Step S305 in the process allows the user to handle the situation promptly. If there are no mutual exclusions, a further determination of dependencies can be made. For example, if the robot's current battery level is found to be lower than the required power for the delivery task, a warning should be issued and the robot advised to charge to the preset power level before execution. Conversely, if the robot's current battery level is sufficient, the delivery task is confirmed to be executable. After confirming the task's executable status, the robot enters the task scheduling process to create an independent scheduling thread. Optionally, the delivery task may involve calls to some underlying modules; for these running modules, it can be determined whether they need to be interrupted (corresponding to...). Figure 3 In step S306, if interruption is required, the scheduling thread will send an interruption command (corresponding to...). Figure 3 Step S307 in the process terminates the operation being performed by the module, preparing for the current task. Conversely, if no module needs to be interrupted, the scheduling thread will directly call the appropriate function to execute the current task. Simultaneously, the robot updates the global task lock's state to occupied (locked) (corresponding to...) Figure 3 Step S308 in the process indicates that a task is currently being executed. During task execution, the scheduling thread issues start instructions to the idle associated functional modules and other functions to execute the current task (corresponding to...). Figure 4 Step S309 in the process.

[0057] It's understandable that the dependency example above only illustrates the robot's battery status. In other scenarios, it's possible to determine the existence of other dependencies, such as detecting whether goods are already in the robot's cargo hold or on the cargo platform. It's also understandable that if the battery might be insufficient, upon receiving a charging task, the charging task will have a higher priority than the delivery task. In this case, the delivery task will enter a waiting state, and can enter the delivery task scheduling process after charging is complete. During the charging process, if a new task is received, its priority and execution time can be determined. If it is not higher than the delivery task, the delivery task will be executed first. Another possible scenario is that during the delivery task, if the obstacle avoidance module malfunctions or communication fails, an emergency stop command will typically be issued to avoid collisions with the external environment during movement. Since the emergency stop command has the highest priority or higher than execution-type task commands, the robot will interrupt the currently executing task when it receives an emergency stop request.

[0058] This application introduces a centralized state machine service mechanism into the robot system, combining a task scheduler and state control logic to achieve unified definition, dynamic scheduling, and safe switching of the robot's operating state. This effectively improves the system's stability, maintainability, and task execution efficiency, making it a robot application system particularly suitable for multi-task scheduling and high reliability requirements in complex scenarios. A clearly structured and semantically defined state model is established, covering multiple task states and safety states of the robot in actual operation. Simultaneously, it reduces the risk of system failures caused by concurrent module calls or erroneous state triggering, improves the overall safety of the robot's operation, facilitates subsequent maintenance, debugging, and expansion, and enhances the engineering and reusability of the entire robot system.

[0059] Please see ​ This application provides a robot task scheduling system, including: The status query module 110 is used to query the status of the global task lock in the robot in response to the request of the target task; The executability assessment module 130 is used to determine whether the target task is currently executable based on the running status of the functional modules associated with the target task in the robot and a preset conflict strategy table when the global task lock is not occupied; wherein, the preset conflict strategy table is used to describe the running status of the robot and the logical relationship between tasks. The scheduling execution module 150 is used to update the global task lock to an occupied state when the target task is currently executable, and to create an independent scheduling thread to issue a task start instruction to the associated functional module through the independent scheduling thread, thereby controlling the robot to execute the target task.

[0060] In some embodiments, the logical relationships include mutual exclusion and dependency relationships between the robot's operating state and different tasks; the executability assessment module 130 determines whether the target task is currently executable by including: If the functional module associated with the target task is currently running, then the preset conflict strategy table is queried to determine whether the running state of the functional module and the target task are mutually exclusive. If they are not mutually exclusive, then it is further confirmed whether the first running state of the robot that is dependent on the target task is satisfied. If the first running state is satisfied, then it is confirmed that the target task is currently executable. If the first operating state of the robot, which is mutually exclusive or not mutually exclusive but depends on the target task, is not satisfied, then the target task is confirmed to be currently unexecutable.

[0061] In some embodiments, the executability assessment module 130, in determining whether the target task is currently executable, further includes: If the functional module is currently in an idle state, the preset conflict strategy table is queried to determine whether the second running state of the robot that is dependent on the target task is satisfied; if satisfied, the target task is confirmed to be currently executable; if not satisfied, the target task is confirmed to be currently unexecutable.

[0062] In some embodiments, the logical relationship includes the interruption relationship between different priority tasks of the robot; the executability evaluation module 130 is further configured to determine that the target task is currently executable if the target task has the highest priority or if the priority of the target task is determined to be higher than the priority of the task being executed based on the preset conflict strategy table, and otherwise determine that the target task is currently not executable.

[0063] In some embodiments, the scheduling execution module 150 is further configured to create the independent scheduling thread when the target task is currently executable, so as to issue a stop instruction to the first target module associated with the task that needs to be interrupted through the independent scheduling thread, and then issue a start task instruction to the functional module, thereby controlling the robot to execute the target task.

[0064] In some embodiments, the robot task scheduling system further includes: The scheduling and waiting module is used to set a new task request to a waiting state or, when the priority of the new task is lower than the priority of the currently executing target task, wait for the global task lock to be released before executing the new task; wherein, the conditions for the global task lock to be released include: the target task execution ends or is abnormally interrupted.

[0065] In some embodiments, the robot task scheduling system further includes: The event logging module is used to record the state changes of the global task lock, task interruption events, and task execution exception events to generate a task scheduling log.

[0066] It is understood that each module in the robot task scheduling system of this embodiment is used to execute the corresponding steps in the method of the above embodiment, and the options in the above embodiment are also applicable to this embodiment.

[0067] This application also provides a robot, exemplary in that the robot includes a processor and a memory, wherein the memory stores a computer program, and the processor, by running the computer program, causes a terminal device to perform the functions of the various modules in the robot task scheduling method or the robot task scheduling system described above.

[0068] The processor can be an integrated circuit chip with signal processing capabilities. The processor can be a general-purpose processor, including at least one of a Central Processing Unit (CPU), Graphics Processing Unit (GPU), Network Processor (NP), Digital Signal Processor (DSP), Application-Specific Integrated Circuit (ASIC), Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application.

[0069] The memory can be, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), etc. The memory is used to store computer programs, and the processor can execute the computer programs accordingly after receiving execution instructions.

[0070] This application also provides a computer-readable storage medium for storing the computer program used in the robot described above. For example, the computer-readable storage medium may include, but is not limited to, various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0071] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that, as an alternative implementation, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0072] In addition, the functional modules or units in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0073] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a smartphone, personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0074] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A robot task scheduling method, characterized in that, include: In response to a request from the target task, query the status of the global task lock in the robot; If the global task lock is not occupied, the system determines whether the target task is currently executable based on the running status of the functional modules associated with the target task in the robot and a preset conflict strategy table; wherein, the preset conflict strategy table is used to describe the running status of the robot and the logical relationship between tasks. If the target task is currently executable, update the global task lock to an occupied state and create an independent scheduling thread to issue a task start command to the associated functional module through the independent scheduling thread, thereby controlling the robot to execute the target task.

2. The task scheduling method according to claim 1, characterized in that, The logical relationships include the mutual exclusion and dependency relationships between the robot's operating state and different tasks; The step of determining whether the target task is currently executable based on the operating status of the functional modules associated with the target task in the robot and a preset conflict strategy table includes: If the functional module associated with the target task is currently running, then the preset conflict strategy table is queried to determine whether the running state of the functional module and the target task are mutually exclusive. If they are not mutually exclusive, then it is further confirmed whether the first running state of the robot that is dependent on the target task is satisfied. If the first running state is satisfied, then it is confirmed that the target task is currently executable. If the first operating state of the robot, which is mutually exclusive or not mutually exclusive but depends on the target task, is not satisfied, then the target task is confirmed to be currently unexecutable.

3. The task scheduling method according to claim 2, characterized in that, The step of determining whether the target task is currently executable based on the running status of the functional modules associated with the target task and a preset task conflict strategy table further includes: If the functional module is currently in an idle state, the preset conflict strategy table is queried to determine whether the second running state of the robot that is dependent on the target task is satisfied; If the conditions are met, the target task is confirmed to be currently executable; if the conditions are not met, the target task is confirmed to be currently unexecutable.

4. The task scheduling method according to claim 1, characterized in that, The logical relationship includes the interruption relationship between different priority tasks of the robot, and the method further includes: If the global task lock is occupied, the target task is determined to be currently executable if the target task has the highest priority, or if the priority of the target task is determined to be higher than the priority of the currently executing task based on the preset conflict policy table; otherwise, the target task is determined to be currently inexecutable.

5. The task scheduling method according to claim 4, characterized in that, The method further includes: If the target task is currently executable, an independent scheduling thread is created to issue a stop command to the first target module associated with the currently executing task that needs to be interrupted, and then issue a start task command to the functional module, thereby controlling the robot to execute the target task.

6. The task scheduling method according to claim 1, characterized in that, The method further includes: During the execution of the target task by the robot, a request for a new task is set to a waiting state, or if the priority of the new task is lower than the priority of the target task being executed, the robot waits for the global task lock to be released before executing the new task; wherein, the conditions for the global task lock to be released include: the target task execution is completed or abnormally interrupted.

7. The task scheduling method according to claim 1, characterized in that, The method further includes: The state changes of the global task lock, task interruption events, and task execution exception events are recorded to generate a task scheduling log.

8. A robot task scheduling system, characterized in that, include: The status query module is used to query the status of the global task lock in the robot in response to the request of the target task; An executability assessment module is used to determine whether the target task is currently executable based on the running status of the functional modules associated with the target task in the robot and a preset conflict strategy table, when the global task lock is not occupied; wherein, the preset conflict strategy table is used to describe the running status of the robot and the logical relationship between tasks; The scheduling and execution module is used to update the global task lock to an occupied state when the target task is currently executable, and to create an independent scheduling thread to issue a task start instruction to the associated functional module through the independent scheduling thread, thereby controlling the robot to execute the target task.

9. A robot, characterized in that, The robot includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, implements the robot task scheduling method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that, when executed by a processor, implements the robot task scheduling method as described in any one of claims 1-7.

Images