A robot and computing power dynamic allocation method

Abstract

The application provides a robot and a computing power dynamic allocation method. By acquiring system load data determined by one or more of a central processor load value, a neural network processor load value and a graphics processor load value, the computing pressure state of the heterogeneous hardware can be comprehensively reflected. After determining a target load level according to the system load data and a load level mapping relationship, a corresponding allocation strategy is executed on a plurality of tasks currently running based on the target load level, so that the strong real-time priority task can preferentially obtain computing resources under various load conditions.

Description

Technical Field

[0001] This application relates to the field of robotics technology, and in particular to a method for dynamic allocation of computing power between a robot and computing power. Background Technology

[0002] With the rapid popularization of robots and other embodied intelligent terminals, low-cost, low-power embedded motherboards have become the mainstream hardware solution. These terminals need to run multiple types of business tasks concurrently, such as camera acquisition, facial recognition, gimbal control, chassis movement, and SLAM navigation. Especially in the core home mobile scenario where the user follows the robot, the high-frequency concurrency of multiple tasks places stringent requirements on the real-time performance and stability of computing power scheduling. However, current low-cost home robots generally face the contradiction between scarce computing resources and low scheduling efficiency. High-real-time business and low-real-time background tasks compete for computing power in an disorderly manner, which easily leads to problems such as gimbal lag, chassis shaking, and sudden drops in facial recognition frame rate, seriously affecting the user experience.

[0003] To address these issues, a general computing power reuse architecture can be constructed to improve utilization efficiency through dynamic allocation of computing resources. For example, the native Linux operating system provides a basic process priority scheduling mechanism, which can achieve initial allocation of CPU resources.

[0004] The advantage of a general computing power reuse architecture lies in its high versatility. However, in contrast, for the exclusive business links and heterogeneous hardware characteristics of low-cost home robots, the general computing power reuse architecture is difficult to achieve deep collaborative optimization. This leads to a conflict between the computing power requirements of low computing power and high-frequency concurrent tasks, which in turn can easily cause the robot to frequently experience system lag. Summary of the Invention

[0005] This application provides a method for dynamic allocation of computing power between robots and computing power to solve the problem that general computing power reuse architectures are difficult to achieve deep collaborative optimization, resulting in conflicts between the computing power requirements of low computing power and high-frequency concurrent tasks, which in turn can easily lead to frequent system lag in robots.

[0006] In a first aspect, embodiments of this application provide a robot, comprising: The controller is configured as follows: Obtain system load data; the system load data is determined by the load values ​​of the sub-controllers included in the controller; The target load level is determined based on the system load data and the load level mapping relationship; wherein, the load level mapping relationship includes the correspondence between the system load data and the load level; the load level includes a first load level, a second load level and a third load level, wherein the system load corresponding to the first load level is lower than the system load corresponding to the second load level, and the system load corresponding to the second load level is lower than the system load corresponding to the third load level; Based on the target load level, an allocation strategy corresponding to the target load level is executed on the currently running multiple tasks to ensure that high real-time priority tasks among the multiple tasks obtain computing resources first; the multiple tasks include high real-time priority tasks, weak real-time priority tasks, and background priority tasks.

[0007] In this way, by acquiring system load data determined by the load values ​​of the sub-controllers, the controller can comprehensively reflect the actual computational pressure of the robot's heterogeneous hardware, rather than relying solely on a single-dimensional load indicator. Based on the determined target load level, the controller executes an allocation strategy corresponding to that load level for multiple currently running tasks, ensuring that high real-time priority tasks receive computing resources first under various load conditions. This prioritizes the response performance of core real-time services when computing power is scarce, while accommodating the execution of weak real-time tasks and background tasks when computing power is sufficient. This load-level-based hierarchical allocation mechanism allows the robot to dynamically adjust its task execution strategy according to the actual computing power situation, effectively balancing the allocation efficiency of computing resources with the operational stability of the system. It avoids disorderly contention between high real-time services and weak real-time background tasks, significantly reducing system stuttering issues such as gimbal lag, chassis walking vibration, and sudden drops in face recognition frame rate, thereby improving the robot's real-time response capability and user experience in multi-task concurrent scenarios.

[0008] In some feasible embodiments, the controller is further configured to: The business types of the currently running multiple tasks are identified according to a preset structured configuration file, wherein the structured configuration file includes the node name, node dependency relationship, business type description and priority attribute field of each task; the priority attribute field is used to determine the priority of each task and to determine whether the priority of each task can be adjusted. Based on the business type and priority attribute field, a priority identifier is assigned to each task; the priority attribute field includes a priority identifier, a dynamic identifier, and a static identifier; the priority identifier is used to characterize the priority of the task; the dynamic identifier is used to characterize the priority of the task that changes during execution, and the static identifier is used to characterize the priority of the task that remains unchanged during execution. Based on the node names and node dependencies in the structured configuration file, a task dependency graph is constructed; the task dependency graph is used to determine the execution order and recovery order of the multiple tasks.

[0009] In this way, before acquiring system load data, the controller pre-identifies and pre-classifies multiple currently running tasks using a structured configuration file, uniformly managing key information such as task business type, node dependencies, and priority attributes in a structured manner. Each task is assigned a priority and priority identifier through business type and priority attribute fields. The distinction between dynamic and static identifiers allows the system to flexibly handle priority adjustment needs for different types of tasks, ensuring priority stability for high-real-time tasks while allowing for dynamic priority adjustment of low-real-time tasks under specific conditions. Furthermore, a task dependency graph is constructed using node names and node dependencies, clarifying execution and recovery constraints between tasks. This provides a reliable sequence basis for subsequent allocation strategy execution and task recovery, avoiding execution errors or data inconsistencies caused by neglecting task dependencies.

[0010] In some feasible embodiments, the controller executes an allocation strategy corresponding to the target load level for the currently running multiple tasks, specifically configured as follows: When the target load level is the first load level, at least one first target task with a background priority is determined among the plurality of tasks; The execution of at least one first target task is suspended to release the computing resources occupied by the first target task.

[0011] In this way, when the system load is at the highest level, the controller only suspends background priority tasks, releasing the computing resources they occupy for use by high real-time priority tasks and low real-time priority tasks. Since background priority tasks have the lowest real-time requirements, suspending background tasks has the least impact on the user experience, while the released computing resources can effectively alleviate the computing power shortage problem under mild overload conditions, allowing high real-time tasks and low real-time tasks to continue to operate normally.

[0012] In some feasible embodiments, the controller is further configured to: When the target load level is the second load level, at least one second target task with a weak real-time priority is determined among the plurality of tasks; Based on the fact that at least one first target task has been paused, the execution of at least one second target task is paused in order to keep the task with strong real-time priority running continuously.

[0013] In this way, when the system load is at the second load level, the controller, having already paused background priority tasks, further pauses weak real-time priority tasks, concentrating all freed computing resources on strong real-time priority tasks. Since the system load at the second load level is significantly higher than at the first load level, simply pausing background tasks is insufficient to alleviate computing power strain; further pausing weak real-time tasks is necessary to ensure the stable operation of core real-time services. This strategy ensures that strong real-time priority tasks can continue to run under moderate overload scenarios, preventing core real-time services such as gimbal control and chassis movement from experiencing stuttering or jitter due to insufficient computing power. Simultaneously, by using a progressively tiered pausing approach, the system retains the maximum range of tasks executable at the current load level, ensuring the stability of the robot's core functions under moderate overload scenarios.

[0014] In some feasible embodiments, the controller is further configured to: When the target load level is the third load level, determine all non-strong real-time priority tasks among the multiple tasks, except those with strong real-time priority. Suspend the execution of all non-strong real-time priority tasks and generate an overload alarm.

[0015] In this way, when the system load reaches the third load level, which is the highest load level, the controller suspends all non-strong real-time priority tasks and concentrates all available computing resources on the execution of strong real-time priority tasks, ensuring that core real-time services can still maintain a minimum level of operation even under extreme overload conditions. At the same time, the controller generates overload alarm information to promptly indicate that the system is currently in a state of severe overload, so that maintenance personnel or upper-layer applications can take further measures.

[0016] In some feasible embodiments, the controller is further configured to: When the system load data drops below the load threshold corresponding to the first load level, the suspended non-strong real-time priority tasks are resumed according to the preset recovery priority order.

[0017] In this way, when the system load drops below the load threshold corresponding to the first load level, the controller gradually resumes the suspended non-strong real-time priority tasks according to the preset recovery priority order, realizing the dynamic recycling of computing resources. When the system load recovers from a high load state to a low load state, the weak real-time tasks and background tasks that were previously suspended to ensure strong real-time tasks can be rescheduled for execution, allowing the system to gradually restore complete business functions. Resumption according to the recovery priority order avoids the problem of sudden load increases and secondary overload caused by the simultaneous resumption of all suspended tasks, ensuring that the system maintains stable load throughout the recovery process. This effectively improves the utilization efficiency of computing resources and the integrity of system functions, enabling the robot to adaptively adjust its task execution state under load fluctuation scenarios and ensuring continuous and stable multi-task concurrent operation.

[0018] In some feasible embodiments, when the system load data drops below the load threshold corresponding to the first load level, the controller resumes the execution of the suspended non-strong real-time priority tasks according to a preset recovery priority order, specifically configured as follows: If the system load data is confirmed to be stable, resume the suspended tasks with a low real-time priority. After confirming that the system load data has been restored to the paused task with the weak real-time priority, and provided that the system load data remains stable, the paused task with the background priority is restored.

[0019] In this way, when the controller resumes paused tasks, it adopts a phased, gradual recovery strategy: first, it confirms that the system load data is stable before resuming weak real-time priority tasks; then, after the weak real-time priority tasks have resumed, it confirms again that the system load data remains stable before continuing to resume background priority tasks. This step-by-step verification recovery mechanism sets load stability verification conditions at each recovery stage, ensuring that each recovery step does not cause the system to re-enter an overload state, effectively avoiding secondary overload problems caused by sudden load increases during the recovery process. The order of resuming weak real-time tasks first and then background tasks corresponds to the pause order when the load level increases progressively, forming a complete pause-resumption symmetrical mechanism. This ensures that the system maintains stable operation during load fluctuations, improving the robustness and reliability of dynamic computing power allocation.

[0020] In some feasible embodiments, the sub-controller includes a central processing unit, a neural network processor, and / or a graphics processor; after assigning a corresponding priority and priority identifier to each task based on the service type and priority attribute field, the controller is further configured to: Tasks with strong real-time priority are bound to the large cores of the CPU, tasks with background priority are bound to the small cores of the CPU, and tasks with weak real-time priority are bound to either the large or small cores of the CPU; the computing power of the large cores of the CPU is higher than that of the small cores of the CPU. And / or, allocate the computational load of artificial intelligence recognition tasks to the neural network processor, and / or allocate the computational load of graphics rendering tasks to the graphics processor.

[0021] In this way, the controller, based on task priority allocation, further performs precise binding and load distribution of heterogeneous hardware according to task priority and business type. High real-time priority tasks are bound to the large cores of the central processing unit (CPU) to ensure that core real-time services receive the highest performance computing resources; background priority tasks are bound to small cores to prevent them from consuming large core resources and affecting real-time services. Weak real-time priority tasks are flexibly bound to either large or small cores according to actual needs, balancing performance requirements and resource utilization efficiency. Simultaneously, AI recognition tasks are allocated to neural network processors, and graphics rendering tasks are allocated to graphics processors, achieving a reasonable distribution of computing load among heterogeneous processors and fully leveraging the dedicated acceleration advantages of each processor. This heterogeneous hardware-aware task binding and load distribution mechanism ensures that computing power allocation not only considers the real-time priority of tasks but also the matching degree between tasks and hardware computing characteristics, achieving deep optimization of computing resources at the processor architecture level. This effectively improves the overall utilization efficiency of heterogeneous computing power on the embedded motherboard and the real-time response capability of the system.

[0022] In some feasible embodiments, the controller is further configured to: During the execution of the allocation strategy, in response to the received user operation instructions, the target task and its priority corresponding to the user operation instructions are determined. When the priority of the target task is strong real-time priority, computing resources are allocated to the target task first. Suspend or delay the execution of the degradation operation for the target task in the allocation strategy.

[0023] In this way, when the controller receives a user operation command during the execution of the allocation strategy, it can identify the target task and its priority corresponding to the command. If the target task has a strong real-time priority, computing resources are allocated to that task first, and the degradation operation for that task in the allocation strategy is paused or delayed. This ensures that the strong real-time operation triggered by the user is not interrupted or delayed by the system's automatic degradation strategy. This user operation intervention mechanism establishes a coordination channel between the system's automatic computing power allocation and the user's active operation. This allows the dynamic computing power allocation system to flexibly respond to the user's immediate operation needs while ensuring overall stability. It avoids operation delays or interruptions caused by conflicts between the automatic degradation strategy and the user's operation intentions, improves the robot's human-machine interaction responsiveness and user experience, and ensures that users can still obtain real-time control of core functions even in overload scenarios.

[0024] Secondly, embodiments of this application provide a method for dynamic allocation of computing power, including: Obtain system load data; the system load data is determined by the load values ​​of the sub-controllers included in the controller; The target load level is determined based on the system load data and the load level mapping relationship; wherein, the load level mapping relationship includes the correspondence between the system load data and the load level; the load level includes a first load level, a second load level and a third load level, wherein the system load corresponding to the first load level is lower than the system load corresponding to the second load level, and the system load corresponding to the second load level is lower than the system load corresponding to the third load level; Based on the target load level, an allocation strategy corresponding to the target load level is executed on the currently running multiple tasks to ensure that high real-time priority tasks among the multiple tasks obtain computing resources first; the multiple tasks include high real-time priority tasks, weak real-time priority tasks, and background priority tasks.

[0025] In this way, by acquiring system load data determined by one or more of the following: CPU load, neural network processor load, and graphics processor load, the computational pressure status of heterogeneous hardware can be comprehensively reflected. After determining the target load level based on the system load data and the load level mapping relationship, corresponding allocation strategies are executed for multiple currently running tasks based on the target load level, ensuring that high real-time priority tasks receive computing resources preferentially under various load conditions. Attached Figure Description

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

[0027] Figure 1 This is a schematic diagram of the overall structure of the robot provided in some embodiments of this application; Figure 2 A block diagram showing the module configuration of a controller 600 provided in some embodiments of this application; Figure 3 This is a schematic diagram of a robot communication scenario provided in some embodiments of this application; Figure 4 Flowcharts of a robot's dynamic computing power allocation method provided in some embodiments of this application; Figure 5 Timing diagrams of robot data acquisition system load provided in some embodiments of this application; Figure 6 A flowchart illustrating robot task pre-identification and priority allocation provided in some embodiments of this application; Figure 7 A flowchart illustrating the robot executing an allocation strategy based on a first load level, provided in some embodiments of this application; Figure 8 A flowchart illustrating the robot's execution of an allocation strategy based on a second load level, provided in some embodiments of this application; Figure 9 A flowchart illustrating the robot's execution of an allocation strategy based on a third load level, provided in some embodiments of this application; Figure 10 A flowchart illustrating the robot resuming a paused task is provided for some embodiments of this application; Figure 11 A flowchart illustrating robot task binding based on heterogeneous hardware provided in some embodiments of this application; Figure 12 A flowchart illustrating a robot responding to user operation commands, provided for some embodiments of this application. Detailed Implementation

[0028] The embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following examples do not represent all embodiments consistent with this application.

[0029] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0030] The terms "first," "second," "third," etc., used in the specification and accompanying drawings of this application are used to distinguish similar or related objects or entities, and do not necessarily imply a specific order or sequence, unless otherwise specified. It should be understood that such terms can be used interchangeably where appropriate.

[0031] The terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclude inclusion, for example, a product or device that includes a range of components is not necessarily limited to all of the components that are clearly listed, but may include other components that are not clearly listed or that are inherent to such product or device.

[0032] The term "module" refers to any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code that is capable of performing the functions associated with that element.

[0033] Figure 1 is a schematic diagram of the overall structure of a robot provided in some embodiments of this application. As shown in Figure 1, the robot may include at least one of a display 100, an actuator 200, a sensor 300, a moving mechanism 400, and a body 500. The body 500 serves as the main load-bearing structure of the robot, used to install and support the aforementioned functional components, providing mechanical support and protection for each component.

[0034] The display 100 is used to present visual information and user interaction interfaces. For example, the display 100 can display the robot's working status, environmental information, task progress, etc., and can also be used to display menu control interfaces and user control UI interfaces. In some embodiments, the display 100 can be a touch screen, allowing users to directly input control commands on the display 100 via touch operation to achieve human-machine interaction with the robot.

[0035] The actuator 200 is used to perform specific tasks. For example, the actuator 200 can be a robotic arm, a cleaning brush head, a vacuum cleaner, a mopping module, etc., used to complete corresponding actions according to control commands, such as grasping objects, cleaning the floor, and moving objects. In some embodiments, the actuator 200 may include one or more kinematic joints with one or more degrees of freedom to achieve complex motion trajectories and operational actions.

[0036] Sensor 300 is used to collect information about the external environment or the robot's own state. For example, sensor 300 may include a vision sensor (such as a camera), LiDAR, ultrasonic sensor, infrared sensor, collision sensor, odometry, etc., for sensing the surrounding environment, detecting obstacles, locating the robot's position, identifying target objects, etc. In some embodiments, the information collected by sensor 300 is used to assist the robot in making decisions and controlling its operation.

[0037] The mobile mechanism 400 is used to drive the overall movement of the robot. For example, the mobile mechanism 400 can be a wheeled mobile mechanism, a tracked mobile mechanism, a legged mobile mechanism, etc. According to the control commands from the controller 600, the mobile mechanism 400 drives the robot body 500 to move in the working environment to reach a designated location or perform tasks such as patrolling or cruising. In some embodiments, the mobile mechanism 400 can work with the sensor 300 to achieve autonomous navigation and obstacle avoidance functions.

[0038] Figure 2 is a block diagram of the module configuration of the controller 600 provided in some embodiments of this application.

[0039] The controller 600 is the core control unit of the robot, used to control and coordinate the operation of various components. The controller 600 receives environmental information collected by the sensor 300 and user-input operation commands, processes the data, and performs decision analysis before outputting corresponding control commands to components such as the actuator 200, the moving mechanism 400, and the display 100 to control the robot to complete various tasks. In some embodiments, the controller 600 may be located inside the robot body 500 and establish communication connections with various functional components via wired or wireless means.

[0040] In some embodiments, the controller 600 may include at least one of a task identification module 601, a computing power scheduling module 602, a load detection module 603, an overload protection module 604, and a dependency management module 605. These modules can be implemented through hardware circuits, software programs, or a combination of hardware and software to jointly perform the various control functions of the controller 600.

[0041] In some embodiments, the task recognition module 601 is used to recognize and parse the input task information. For example, the task recognition module 601 can receive task instructions input by the user via voice, touch, mobile terminal, etc., perform semantic analysis and intent recognition on the instruction content, and convert it into a standardized task description that the controller 600 can recognize and process. The task recognition module 601 can also analyze the environmental information collected by the sensor 300 to identify the type of task to be performed and the target object.

[0042] The computing power scheduling module 602 is used to allocate and schedule computing resources within the controller 600. For example, the computing power scheduling module 602 can rationally allocate computing resources such as CPU, GPU, and NPU based on factors such as the number, priority, and computational load of tasks currently pending processing, ensuring that high-priority tasks can obtain sufficient computing power while improving the overall utilization rate of computing resources. In some embodiments, the computing power scheduling module 602 supports dynamic resource adjustment, which can adjust the resource allocation ratio of each task in real time according to changes in task load.

[0043] The load detection module 603 is used to detect the operating load status of the controller 600 in real time. For example, the load detection module 603 can monitor operating indicators such as CPU utilization, memory usage, power consumption level, and temperature parameters to obtain the current load status of the controller 600. The load detection module 603 can feed back the detected load information to the computing power scheduling module 602 and the overload protection module 604, providing data basis for resource scheduling and overload protection.

[0044] The overload protection module 604 is used to execute a protection mechanism when the controller 600 is overloaded. For example, when the load detection module 603 detects that the load of the controller 600 exceeds a preset threshold, the overload protection module 604 can trigger corresponding protection strategies, such as reducing the running priority of non-critical tasks, suspending some background tasks, and limiting the maximum utilization of computing resources, to prevent the controller 600 from crashing, freezing, or suffering hardware damage due to overload.

[0045] The dependency management module 605 manages the dependencies between tasks. For example, it maintains the execution order, data dependencies, and resource dependencies between tasks, ensuring that tasks are executed in the correct logical order and preventing task failures or incorrect results due to conflicting dependencies. In some embodiments, the dependency management module 605 also supports dynamic dependency updates, allowing for real-time adjustments to dependencies based on task execution progress.

[0046] In some embodiments, the task recognition module 601 can perform secondary recognition and in-depth analysis on the preliminary recognition results. For example, the task recognition module 601 can perform more refined semantic understanding and intent reasoning for complex tasks or multimodal input information to further clarify the specific requirements, execution conditions, and expected goals of the task. The task recognition module 601 can also combine historical task data and user preference information to optimize and correct the recognition results, thereby improving the accuracy and intelligence of task recognition.

[0047] In some embodiments, the controller 600 may further include a memory (not shown) for storing program instructions, task data, configuration parameters, historical records, and other information of the aforementioned modules. The controller 600 controls the overall operation of the robot and responds to user operations by running the software control program stored in the memory.

[0048] It should be noted that the above examples are merely illustrative of the robot's components and do not limit the specific structural configuration of the robot in the embodiments of this application. Depending on the robot's function, application scenario, and other factors, the types and number of components included in the robot may take other forms.

[0049] Figure 3 This is a schematic diagram of a robot communication scenario provided in some embodiments of this application.

[0050] Figure 3 is a schematic diagram illustrating the interaction scenarios between a home robot and a display device and a server according to some embodiments of this application. As shown in Figure 3, the home robot can interact with the display device 700 and the server 800 through various communication methods to achieve collaborative work and resource sharing. The home robot includes components such as a display 100, actuators 200, sensors 300, a movement mechanism 400, and a body 500. The specific structure and function of each component can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0051] Display device 700 is used to present visual information to users and receive user operation commands. For example, display device 700 can be an electronic device with display function such as a smart TV, tablet computer, smartphone, or smart display screen. Display device 700 can display information such as the working status of the home robot, task progress, environmental map, and images and videos collected by sensors. It can also provide a user interface for users to send control commands to the home robot via touch, voice, remote control, etc.

[0052] In some embodiments, the display device 700 can establish a direct communication connection with the home robot for data interaction. For example, the display device 700 can establish a point-to-point connection with the home robot via wireless communication methods such as WiFi, Bluetooth, or ZigBee, or an indirect connection via a local area network router. The home robot can transmit collected environmental data, task execution status, audio and video content, etc., to the display device 700 for display in real time; users can also issue task commands, configure parameters, and set working modes to the home robot through the operation interface on the display device 700.

[0053] In some embodiments, the display device 700 can also serve as an extended display terminal for the home robot, enabling multi-screen collaboration. For example, the home robot's own display 100 can show concise status information, while detailed task interfaces, high-definition video feeds, and complex setting menus can be projected onto the display device 700 for display, resulting in a larger display size and better visual effects. The display device 700 can also run applications that control the home robot, simulating the functions of a dedicated controller to enable remote control of the home robot.

[0054] Server 800 is used to provide cloud services and data support for home robots. For example, Server 800 can be a cloud server, edge computing server, local server, etc. Server 800 can store information such as the home robot's system firmware, applications, map data, and user configurations, and can also provide services such as data computing, task scheduling, model training, and remote monitoring.

[0055] In some embodiments, the server 800 can communicate with the home robot via a network. The home robot can establish a communication connection with the server 800 through various network methods such as a local area network (LAN), wireless local area network (WLAN), and mobile internet. The home robot can upload collected sensor data, task execution records, and operation logs to the server 800 for storage and analysis; the server 800 can also send system updates, application installations, task instructions, configuration parameters, and other data to the home robot.

[0056] In some embodiments, server 800 can also provide powerful computing capabilities to assist home robots in completing complex computational tasks. For example, for tasks requiring significant computing power (such as 3D environment reconstruction, deep learning model inference, path planning optimization, etc.), the home robot can upload raw data to server 800, which will then perform the computation and return the results to the home robot for execution, thereby reducing the local computational burden on the home robot and improving task processing efficiency.

[0057] In some embodiments, the display device 700 can also communicate with the server 800. For example, the display device 700 can obtain historical data, statistical reports, remote monitoring images, and other information about the home robot from the server 800, and can also forward control commands to the home robot through the server 800 to achieve remote control across the network. The server 800 can act as a data relay and service dispatch center between the display device 700 and the home robot, enabling collaborative work among multiple devices.

[0058] Based on such Figures 1-3The robot structure and system architecture shown indicate that the robot can perform tasks by following the user and providing real-time feedback of various media images to the user through a configured display device. For example, the robot can be equipped with actuators to assist the user in moving objects or walking. However, this interaction method between the robot and the television consumes a significant amount of the display device's computing resources during the interaction process, and the interaction introduces latency, resulting in poor real-time performance of the robot's tasks.

[0059] Furthermore, home use scenarios involve high concurrency of tasks, placing high demands on computing resources. Deploying high computing power on the robot's edge would increase hardware costs. If the robot communicates with the cloud and relies on cloud-deployed computing resources to assist in task execution, it could also lead to increased task response time, resulting in a significant increase in task execution time.

[0060] For example, robots can perform multiple tasks, such as camera capture, facial recognition, gimbal control, chassis movement, and SLAM (Simultaneous Localization and Mapping) navigation. In core home mobility scenarios such as user following, robots need to run multiple business tasks simultaneously. The high-frequency concurrency of multiple tasks places stringent demands on the real-time performance and stability of computing power scheduling. Furthermore, in multi-task concurrency scenarios, each task consists of multiple sub-tasks, and the response time of each sub-task increases, thus multiplying the response and execution time of a single task.

[0061] Even though computing power reuse frameworks from servers, computers, and other edge devices can be migrated and deployed on the robot's edge to optimize the robot's computing power allocation strategy, the computing power reuse architecture, while generally universal, struggles to achieve deep collaborative optimization on the robot's edge due to the high concurrency characteristics and low computing power requirements of home use scenarios. This leads to conflicts between the low computing power and the computing power demands of high-frequency concurrent tasks, resulting in frequent system lag in the robot. To address these issues, this application provides a robot embodiment.

[0062] Figure 4 This is a flowchart illustrating a method for dynamically allocating computing power for robot execution, provided in some embodiments of this application.

[0063] like Figure 4 As shown, the controller is configured to perform the following steps: S400: Obtain system load data; The system load data is determined by the load values ​​of the sub-controllers included in the controller 600.

[0064] The sub-controllers may include a central processing unit (CPU), a neural network processor (NPU), and / or a graphics processing unit (GPU). System load data may be determined by one or more of the CPU load value, NPU load value, and GPU load value. During the operation of the robot, the load detection module 603 in the controller 600 reads the load value of each sub-controller according to a preset acquisition cycle, and performs a weighted calculation on the load values ​​of each sub-controller to obtain the system load data.

[0065] In some embodiments, the load detection module 603 reads the load value of each sub-controller every 100ms. The weighted calculation method can be adjusted according to the importance and resource proportion of each sub-controller in the current business scenario. For example, for business scenarios mainly involving CPU computation, the CPU load value has a higher weight. For business scenarios mainly involving artificial intelligence inference, the neural network processor load value has a higher weight. For business scenarios mainly involving graphics rendering, the graphics processor load value has a higher weight.

[0066] In other embodiments, the system load data can be calculated as follows: System load data = w1 × CPU load value + w2 × NPU load value + w3 × GPU load value, where w1, w2, and w3 are the weight coefficients corresponding to each sub-controller, and w1 + w2 + w3 = 1. The specific values ​​of the weight coefficients can be dynamically adjusted according to the robot's business configuration. For example, when the robot executes follow mode, the CPU load has a higher weight because follow mode mainly relies on the CPU for motion control and obstacle avoidance calculations; when the robot executes security patrol mode, the NPU load has a higher weight because security patrol mode mainly relies on the NPU for target detection and recognition.

[0067] Figure 5 Timing diagrams for robot data acquisition system load data provided in some embodiments of this application.

[0068] like Figure 5 As shown, in some examples, controller 600 includes a load detection module 603 and a computing power scheduling module 602. The load detection module 603 sends load query requests to each sub-controller (including CPU, NPU, GPU, etc.) at a preset period. Each sub-controller returns its current load value upon receiving the load query request. The load detection module 603 calculates system load data based on the load values ​​returned by each sub-controller and preset weighting coefficients, and reports the system load data to the computing power scheduling module 602. The computing power scheduling module 602 determines the target load level based on the system load data and executes the corresponding allocation strategy.

[0069] In this way, the robot can comprehensively reflect the actual computing pressure of heterogeneous hardware, rather than relying on a single-dimensional load indicator, providing an accurate load status basis for subsequent load level determination and allocation strategy execution.

[0070] S401: Determine the target load level based on the system load data and the load level mapping relationship.

[0071] The load level mapping relationship includes the correspondence between system load data and load levels. Load levels include first load level, second load level, and third load level. The system load corresponding to the first load level is lower than the system load corresponding to the second load level, and the system load corresponding to the second load level is lower than the system load corresponding to the third load level.

[0072] In some embodiments, the load level mapping relationship can be defined by preset load threshold ranges. For example, when the system load data is in the range of 0% to 60%, the target load level is determined as the first load level; when the system load data is in the range of 60% to 85%, the target load level is determined as the second load level; and when the system load data is in the range of 85% to 100%, the target load level is determined as the third load level. It is understood that the specific values ​​of the above load threshold ranges are only examples, and those skilled in the art can flexibly adjust them according to actual hardware performance and business needs.

[0073] In other embodiments, the load level mapping relationship can also be determined comprehensively based on the load values ​​of each sub-controller. For example, when the CPU load value exceeds 80% or the NPU load value exceeds 90%, even if the weighted value of the system load data does not reach the threshold of the second load level, the target load level can still be determined as the second load level or a higher level, so as to achieve timely response to overload of critical sub-controllers. This multi-dimensional determination mechanism can avoid the problem of overload of a single sub-controller being masked by weighted averaging, ensuring that the system can respond promptly to various overload scenarios.

[0074] In some examples, after receiving the system load data reported by the load detection module 603, the computing power scheduling module 602 compares the system load data with each load threshold interval in the load level mapping relationship to determine the load level interval to which the system load data belongs, and then determines the target load level.

[0075] The allocation strategy for the first load level is to suspend background priority tasks; for the second load level, it's to suspend both background priority tasks and weak real-time priority tasks; and for the third load level, it's to suspend all non-strong real-time priority tasks and generate overload alarms. The intervention intensity of the allocation strategies for the three load levels increases progressively, achieving a precise match between the repair strength and the severity of the load. It's understandable that the three load levels cover the entire range of system load data from low to high, with no uncovered load intervals, ensuring that there is a corresponding allocation strategy available to execute under any load condition.

[0076] S402: Based on the target load level, execute the allocation strategy corresponding to the target load level for the currently running multiple tasks, so that the high real-time priority tasks among the multiple tasks can obtain computing resources first.

[0077] The currently running tasks include high real-time priority tasks, low real-time priority tasks, and background priority tasks. High real-time priority tasks are those with strict response time requirements, such as gimbal control, chassis motion control, and obstacle avoidance detection. Delays in these tasks directly impact the robot's motion safety and user experience. Low real-time priority tasks are those with some response time requirements but tolerate short delays, such as face recognition, voice interaction, and SLAM map updates. Short delays in these tasks do not cause safety issues but affect user experience. Background priority tasks have lower real-time requirements, such as log uploads, data synchronization, and system update checks. Delays in these tasks have a smaller impact on user experience.

[0078] In some embodiments, after determining the target load level, the computing power scheduling module 602 queries the corresponding allocation policy from the preset policy configuration table according to the target load level, and performs corresponding operations on multiple currently running tasks according to the allocation policy, including pausing tasks, resuming tasks, binding processor cores, etc.

[0079] The allocation strategies corresponding to different load levels are described in detail below. It should be noted that the embodiments of the allocation strategies corresponding to each load level are described independently, and there is no necessary combination relationship between the embodiments corresponding to different dependent claims.

[0080] Figure 6 This is a flowchart illustrating robot task pre-identification and priority allocation provided in some embodiments of this application.

[0081] In some feasible embodiments, the controller 600 is further configured to: S600: Identifies the business types of the multiple currently running tasks based on a preset structured configuration file; The structured configuration file includes the node name of each task, node dependencies, business type description, and priority attribute field. The priority attribute field is used to determine the priority of each task and whether the priority of each task is adjustable.

[0082] In some embodiments, the structured configuration file is written in JSON or XML format and pre-configured by developers during the robot deployment phase. Each task node in the structured configuration file contains the following fields: node name (node_name) to uniquely identify the task; dependencies to describe the preceding tasks that the task depends on; business type description (business_type) to identify the business attributes of the task, such as "motion control", "visual perception", "data synchronization", etc.; and priority attribute field (priority_attribute) to determine the priority of the task and whether the priority is adjustable.

[0083] In some examples, the structured configuration file contains the following: the node name for the gimbal control task is "gimbal_control", the service type is described as "motion control", and the priority attribute field is "strong_realtime_static", indicating that the task has a strong real-time priority and the priority cannot be adjusted; the node name for the face recognition task is "face_recognition", the service type is described as "visual perception", and the priority attribute field is "weak_realtime_dynamic", indicating that the task has a weak real-time priority and the priority can be dynamically adjusted; the node name for the log upload task is "log_upload", the service type is described as "data synchronization", and the priority attribute field is "background_static", indicating that the task has a background priority and the priority cannot be adjusted.

[0084] S601: Assign a priority identifier to each task based on the business type and priority attribute field; The computing power scheduling module 602 in the controller 600 assigns a corresponding priority and priority identifier to each task based on the business type description and priority attribute field in the structured configuration file. The priority attribute field includes a priority identifier, a dynamic identifier, and a static identifier. The priority identifier is used to represent the priority of the task, the dynamic identifier is used to represent that the priority of the task can change during execution, and the static identifier is used to represent that the priority of the task remains unchanged during execution.

[0085] In some embodiments, the computing power scheduling module 602 initially classifies tasks based on the service type description, and then determines the final priority and priority identifier by combining the priority attribute field. For tasks marked with a dynamic identifier and a weak real-time priority, the computing power scheduling module 602 can dynamically adjust its priority during operation based on the system load and the actual needs of the task. For example, when the system load is low, the priority of the face recognition task can be increased from weak real-time to strong real-time to improve the recognition frame rate; when the system load is high, it can be reduced back to weak real-time to release computing power. For tasks marked with a static identifier, their priority remains unchanged during task execution, ensuring that strong real-time tasks always enjoy the highest priority guarantee.

[0086] S602: Construct a task dependency graph based on the node names and node dependencies in the structured configuration file; The task dependency graph is used to determine the execution order and recovery order of multiple tasks. The dependency management module 605 in the controller 600 constructs a task dependency graph in the form of a directed acyclic graph based on the node names and node dependencies in the structured configuration file. The nodes in the graph represent tasks, and the directed edges represent the dependencies between tasks.

[0087] In some embodiments, the task dependency graph can be used not only to determine the execution order of tasks, but also to determine the recovery order of tasks. When the system load decreases and it is necessary to resume suspended tasks, the computing power scheduling module 602 determines the dependencies of each task according to the task dependency graph, and prioritizes the recovery of preceding tasks that are depended on by other tasks, so as to ensure that the resumed tasks can be executed normally and avoid execution errors caused by the failure to recover dependent tasks.

[0088] In some embodiments, the task dependency graph is also used to determine a safe pause order when pausing tasks. If task B depends on the output of task A, then task B needs to be paused before pausing task A to avoid task B encountering anomalies due to its inability to obtain the output of task A. The computing power scheduling module 602 determines the safe pause order based on the inverse topological sort of the task dependency graph, ensuring that the pause operation does not disrupt the data dependencies between tasks.

[0089] In this way, the controller 600 pre-identifies and pre-classifies multiple currently running tasks through structured configuration files, and manages key information such as task business type, node dependency relationship and priority attribute in a structured manner, providing a reliable sequence basis for subsequent allocation strategy execution and task recovery.

[0090] Figure 7 A flowchart illustrating the robot's execution of an allocation strategy based on a first load level, provided in some embodiments of this application.

[0091] In some feasible embodiments, the controller 600 executes an allocation strategy corresponding to the target load level for the currently running multiple tasks, specifically configured as follows: S700: When the target load level is the first load level, determine at least one first target task with background priority among the plurality of tasks; When the system load data is at the first load level, it indicates that the system is in a state of slight overload. At this time, the computing power scheduling module 602 selects the background priority task from the multiple currently running tasks as the first target task. Background priority tasks have the lowest real-time requirements, including but not limited to log uploading, data synchronization, and system update checks.

[0092] In some embodiments, the computing power scheduling module 602 maintains a task list, which records the priority identifier of each task. The computing power scheduling module 602 traverses the task list and determines the task with the priority identifier of background priority as the first target task.

[0093] S701: Suspend the execution of the at least one first target task to release the computing resources occupied by the first target task.

[0094] After determining the first target task, the computing power scheduling module 602 sends a pause command to the first target task, causing it to stop execution and releasing the computing resources it occupies, such as CPU time slices, memory space, and I / O resources. The released computing resources can be used by high real-time priority tasks and low real-time priority tasks to alleviate computing power strain under mild overload conditions.

[0095] In some embodiments, when pausing the first target task, the computing power scheduling module 602 records the current execution status and context information of the first target task, including the breakpoint position of the task execution, the loaded data, the open file handle, etc., so that execution can continue from the pause point when it is resumed later, avoiding task data loss or duplicate calculation.

[0096] In some other embodiments, before pausing the first target task, the computing power scheduling module 602 first checks whether the task is performing a critical operation (such as file writing, data submission, etc.). If the task is performing a critical operation, the computing power scheduling module 602 delays the pause operation and waits for the critical operation to be completed before pausing the task, in order to avoid data inconsistency problems caused by forced pause.

[0097] In some examples, when the computing power scheduling task is detected to be paused or released, the thread corresponding to the first target task is paused or released to reduce the robot's load level. That is, the release and creation of threads occupying the robot's computing power resources depends on the task allocation of the computing power scheduling module 602, thereby avoiding the accidental release of important threads due to dynamic adjustments in the load level, which could lead to the interruption of the execution of important tasks.

[0098] In this way, when the system load is at the highest level, the controller 600 only suspends background priority tasks, releasing their computing resources for use by high real-time priority tasks and low real-time priority tasks. Since background priority tasks have the lowest real-time requirements, suspending them has minimal impact on the user experience, while the released computing resources effectively alleviate computing power strain under mild overload conditions, allowing high and low real-time tasks to continue operating normally. This allocation strategy achieves a precise match between the repair intensity and the load level, avoiding unnecessary damage to the system's functional integrity caused by excessive degradation.

[0099] Figure 8 A flowchart illustrating the robot's execution of an allocation strategy based on a second load level, provided for some embodiments of this application.

[0100] In some feasible embodiments, the controller 600 is further configured to: S800: When the target load level is the second load level, determine at least one second target task among the plurality of tasks that has a weak real-time priority; When the system load data is at the second load level, it indicates that the system is in a moderate overload state. At this time, the computing power scheduling module 602 selects a task with a weak real-time priority from the multiple currently running tasks as the second target task. The weak real-time priority task has certain requirements for response time but tolerates short delays, including but not limited to face recognition, voice interaction, SLAM map updates, etc.

[0101] S801: Based on the fact that at least one first target task has been paused, the execution of at least one second target task is paused to keep the task with strong real-time priority running continuously.

[0102] After determining the second target task, the computing power scheduling module 602 first confirms that the first target task (the background priority task) has been paused. Based on the pause of the first target task, it further sends a pause command to the second target task, suspending its execution and releasing the computing resources it occupies. The released computing resources are then fully allocated to the high real-time priority task to ensure its continued operation even under moderate overload scenarios.

[0103] It should be noted that when the system load jumps directly from a low load state to the second load level, the computing power scheduling module 602 will simultaneously suspend background priority tasks and weak real-time priority tasks, without waiting for the first target task to complete its suspension operation before suspending the second target task. That is, the allocation strategy corresponding to the second load level covers the content of the allocation strategy corresponding to the first load level, ensuring that the corresponding allocation strategy is correctly executed even in scenarios involving load level jumps.

[0104] In some embodiments, when pausing a weak real-time priority task, the computing power scheduling module 602 determines a safe pausing order based on the task dependency graph. If weak real-time priority task B depends on the output of weak real-time priority task A, then task B is paused first, followed by task A, to avoid task B encountering an anomaly due to its inability to obtain the output of task A.

[0105] In this way, when the system load is at the second load level, the controller 600, having already suspended background priority tasks, further suspends weak real-time priority tasks, and concentrates all the released computing resources on strong real-time priority tasks, ensuring that core real-time services can continue to run under moderate overload scenarios, and avoiding stuttering or jittering of core real-time services such as gimbal control and chassis movement due to insufficient computing power.

[0106] Figure 9 A flowchart illustrating the robot's execution of an allocation strategy based on a third load level, provided for some embodiments of this application.

[0107] In some feasible embodiments, the controller 600 is further configured to: S900: When the target load level is the third load level, determine all non-strong real-time priority tasks among the plurality of tasks, except those with strong real-time priority. When the system load data is at the third load level, it indicates that the system is in a state of severe overload. At this time, the computing power scheduling module 602 determines all non-strong real-time priority tasks from the multiple currently running tasks, including weak real-time priority tasks and background priority tasks.

[0108] S901: Suspend the execution of all non-strong real-time priority tasks and generate an overload alarm message.

[0109] The computing power scheduling module 602 suspends the execution of all non-strong real-time priority tasks and concentrates all available computing resources on the execution of strong real-time priority tasks. At the same time, the computing power scheduling module 602 generates overload alarm information, which can be displayed on the display 100 or sent to the mobile terminal 300 or the server 400 via a communication device, so that maintenance personnel or upper-layer applications can be promptly informed that the system is currently in a state of severe overload.

[0110] In some embodiments, overload alarm information includes current system load data, load values ​​of each sub-controller, a list of suspended tasks, and suggested handling measures, so that operations and maintenance personnel can quickly locate the cause of the overload and take corresponding measures. For example, overload alarm information may include "CPU load value 95%, NPU load value 78%, all non-real-time tasks have been suspended, it is recommended to reduce concurrent services or upgrade hardware configuration," etc.

[0111] In other embodiments, after generating overload alarm information, the computing power scheduling module 602 can further reduce the execution frequency of some high real-time priority tasks according to a preset frequency reduction strategy to further reduce the system load. For example, the control frequency of the gimbal control task can be reduced from 100Hz to 50Hz, and the detection frequency of the obstacle avoidance detection task can be reduced from 30Hz to 15Hz. Although reducing the execution frequency will affect the response accuracy of real-time services, it can prevent system crashes in extreme overload scenarios and ensure the normal operation of the robot's basic motion functions.

[0112] In this way, when the system load is at the third load level, which is the highest load level, the controller 600 suspends all non-strong real-time priority tasks and concentrates all available computing resources on the execution of strong real-time priority tasks, ensuring that core real-time services can still maintain a minimum level of operation under extreme overload conditions. At the same time, overload alarm information is generated, realizing the transparency of the overload status and facilitating rapid response and troubleshooting.

[0113] Figure 10 A flowchart illustrating the robot resuming a suspended task, provided for some embodiments of this application.

[0114] In some feasible embodiments, the controller 600 is further configured to: S1000: When the system load data drops below the load threshold corresponding to the first load level, resume the execution of the suspended non-strong real-time priority task according to the preset recovery priority order.

[0115] When the system load data drops below the load threshold corresponding to the first load level, it indicates that the system has recovered from the overload state to the normal operating state. At this time, the computing power scheduling module 602 gradually restores the previously suspended non-strong real-time priority tasks according to the preset recovery priority order. The recovery priority order is: first restore the suspended tasks with weak real-time priority, then restore the suspended tasks with background priority. This order is the reverse of the suspension order, that is, those suspended first are restored later (background tasks were suspended first but restored later), and those suspended later are restored first (weak real-time tasks were suspended later but restored first), forming a symmetrical pause-restore mechanism.

[0116] In some feasible embodiments, the controller 600 resumes the execution of the suspended non-strong real-time priority tasks according to a preset recovery priority order, specifically configured as follows: S1001: Under the condition that the system load data is confirmed to be stable, resume the suspended tasks with a weak real-time priority. Before resuming a suspended task, the computing power scheduling module 602 first confirms that the system load data is in a stable state. The criteria for determining a stable state may include: the system load data is below the load threshold corresponding to the first load level for N consecutive sampling periods, and the fluctuation range of the system load data does not exceed a preset stability threshold. For example, the system load data is below 60% of the load threshold for 5 consecutive sampling periods (i.e., 500ms), and the change in load data between adjacent sampling periods does not exceed 5%. After confirming that the system load data is stable, the computing power scheduling module 602 resumes the suspended task with the weak real-time priority.

[0117] In some embodiments, when resuming weak real-time priority tasks, the computing power scheduling module 602 determines the recovery order based on the task dependency graph. If there are dependencies between weak real-time priority tasks, the preceding tasks that are depended upon by other tasks are recovered first. For example, if the SLAM map update task depends on the output of the LiDAR data acquisition task, the LiDAR data acquisition task is recovered first, followed by the SLAM map update task.

[0118] S1002: After confirming that the system load data has been restored to the suspended task with the weak real-time priority, and the system load data remains stable, restore the suspended task with the background priority.

[0119] After the suspended tasks with weak real-time priority resume, the computing power scheduling module 602 reconfirms that the system load data remains stable. That is, after the weak real-time priority tasks resume execution, the load detection module 603 continues to collect system load data according to a preset cycle, and the computing power scheduling module 602 determines whether the system load data has re-entered an overload state due to the resumption of the weak real-time priority tasks. If the system load data remains stable after the weak real-time priority tasks resume, then the suspended background priority tasks continue to resume.

[0120] In some embodiments, if the system load data exceeds the load threshold corresponding to the first load level again after the weak real-time priority task is restored, the computing power scheduling module 602 pauses the restoration operation and waits for the system load to drop below the load threshold corresponding to the first load level before resuming restoration. If the wait times out (e.g., the waiting time exceeds a preset restoration wait timeout threshold, such as 30 seconds), the current state is maintained, and only the restored weak real-time priority tasks are run, without restoring background priority tasks, to avoid wasting system resources due to long waiting times.

[0121] In this way, the controller 600 adopts a phased and gradual recovery strategy, and sets load stability verification conditions in each recovery stage to ensure that each recovery step will not cause the system to re-enter the overload state, effectively avoiding the problem of secondary overload caused by a sudden increase in load during the recovery process.

[0122] Figure 11 This is a flowchart illustrating the robot's task binding based on heterogeneous hardware, provided in some embodiments of this application.

[0123] In some feasible embodiments, the sub-controller includes a central processing unit, a neural network processor, and / or a graphics processor. After assigning a corresponding priority and priority identifier to each task based on the service type and priority attribute fields, the controller 600 is further configured to: S1100: Bind tasks with strong real-time priority to the large core of the central processing unit, bind tasks with background priority to the small core of the central processing unit, and bind tasks with weak real-time priority to the large or small core of the central processing unit. The large cores of a central processing unit (CPU) have higher computing power than the small cores. In a heterogeneous architecture with large and small cores, large cores are suitable for performing computationally intensive tasks with high real-time requirements, while small cores are suitable for performing tasks with lower computational demands and lower real-time requirements.

[0124] In some embodiments, the computing power scheduling module 602 binds tasks to corresponding processor cores based on their priority. High real-time priority tasks (such as gimbal control, chassis motion control, obstacle avoidance detection, etc.) are bound to large cores to ensure these tasks receive the highest performance computing resources and guarantee real-time response speed. Background priority tasks (such as log uploads, data synchronization, etc.) are bound to small cores to prevent them from consuming large core resources and affecting the execution of real-time services. Low real-time priority tasks (such as face recognition, voice interaction, etc.) can be flexibly bound to large or small cores according to the current load and the task's computing requirements.

[0125] In some examples, when the system load is low, the computing power scheduling module 602 binds weak real-time priority tasks to large cores to improve their execution efficiency; when the system load is high, the computing power scheduling module 602 migrates weak real-time priority tasks to small cores to free up large core resources for strong real-time priority tasks. This dynamic binding strategy allows the processor core allocation of weak real-time priority tasks to be adaptively adjusted according to the system load, maximizing the execution efficiency of weak real-time priority tasks while ensuring the performance of strong real-time priority tasks.

[0126] S1101: and / or, allocate the computational load of artificial intelligence recognition tasks to the neural network processor, and / or, allocate the computational load of graphics rendering tasks to the graphics processor.

[0127] Neural network processors are dedicated processors for accelerating artificial intelligence inference calculations, while graphics processing units (GPUs) are dedicated processors for accelerating graphics rendering and parallel computing. Assigning specific types of computational workloads to their respective dedicated processors can fully leverage the specialized acceleration advantages of each processor type, thereby improving computational efficiency.

[0128] In some embodiments, the computing power scheduling module 602 allocates the computing load of a task to a corresponding dedicated processor based on the task's business type. For AI recognition tasks (such as face recognition, object detection, semantic segmentation, etc.), the computing load is allocated to the neural network processor, utilizing its dedicated inference acceleration unit to improve recognition speed and reduce power consumption. For graphics rendering tasks (such as map rendering, UI drawing, 3D visualization, etc.), the computing load is allocated to the graphics processor, utilizing its parallel rendering pipeline to improve rendering efficiency.

[0129] In other embodiments, when the load value of the neural network processor or graphics processor exceeds its corresponding load threshold, the computing power scheduling module 602 can roll back some of the computing load of artificial intelligence recognition tasks or graphics rendering tasks to the central processing unit (CPU) for execution, in order to avoid task delays caused by overloading the dedicated processor. Tasks rolled back to the CPU will be assigned a lower priority to avoid affecting the execution of high real-time priority tasks running on the CPU.

[0130] In this way, the controller 600, based on the priority of tasks, further performs precise binding and load distribution of heterogeneous hardware according to task priority and business type, realizing deep optimization of computing resources at the processor architecture level, effectively improving the overall utilization efficiency of heterogeneous computing power of embedded motherboard and the real-time response capability of the system.

[0131] Figure 12 A flowchart illustrating a robot responding to user operation commands, provided for some embodiments of this application.

[0132] In some feasible embodiments, the controller 600 is also configured to: S1200: During the execution of the allocation strategy, in response to the received user operation instruction, determine the target task and its priority corresponding to the user operation instruction; During the execution of the allocation strategy by the computing power scheduling module 602, users may input operation commands to the robot via voice commands, touch operations, remote controls, etc. After receiving the user's operation command, the controller 600 determines the target task and its priority based on the content of the user's operation command. For example, if the user triggers the chassis motion control task by using the voice command "move forward," this task is a high real-time priority task; if the user views the map by touch operation, triggering the map rendering task, this task is a low real-time priority task.

[0133] S1201: When the priority of the target task is strong real-time priority, computing resources are allocated to the target task first; The computing power scheduling module 602 determines the priority of the target task. When the target task has a strong real-time priority, computing resources are allocated to it first. Even if the system is currently implementing a degradation strategy (such as pausing weak real-time tasks or background tasks), the computing power scheduling module 602 will ensure that strong real-time priority tasks actively triggered by the user receive sufficient computing resources to respond to the user's operation needs.

[0134] S1202: Pause or delay the execution of the degradation operation for the target task in the allocation strategy.

[0135] If the allocation strategy includes a degradation operation for the target task (such as pausing the task, reducing the resource allocation for the task, etc.), the computing power scheduling module 602 will suspend or delay the execution of the degradation operation to ensure that the user's active operation will not be interrupted by the system's automatic degradation strategy.

[0136] In some embodiments, after pausing the degradation operation, the computing power scheduling module 602 continuously monitors the execution status of the target task. When the target task is completed or the operation corresponding to the user operation instruction is completed, the computing power scheduling module 602 resumes the previously paused degradation operation to ensure that the system load can return to normal management after the user operation ends.

[0137] In other embodiments, if the target task corresponding to the user operation command has a weak real-time priority or a background priority, the computing power scheduling module 602 processes it according to the normal allocation strategy without providing special protection. This ensures that the user operation intervention mechanism only applies to tasks with strong real-time priority, avoiding the impact on the overall stability of the system due to special protection for low-priority tasks.

[0138] Furthermore, when a new task is detected and it's necessary to determine whether to execute it, resources can be allocated by combining dynamic and static identifiers. For example, when a new task is detected, the computing power scheduling module 602 needs to allocate sufficient computing power resources for it. The computing power scheduling module 602 can read the identifier corresponding to the weak real-time task running on the large core of the central processing unit (CPU). If a dynamic identifier is read, it indicates that the weak real-time task can be migrated during execution. Therefore, if computing power is insufficient, the weak real-time task can be migrated to a smaller core of the CPU for execution, freeing up the computing power of the large core for executing the new task. If a static identifier is read, it indicates that the weak real-time task cannot be migrated during execution. Therefore, if computing power is insufficient, it's necessary to continue reading other tasks running on the large core of the CPU to free up the computing power of the large core.

[0139] In this way, when the controller 600 receives a user operation command during the execution of the allocation strategy, it can identify the target task and its priority corresponding to the command. If the priority of the target task is a strong real-time priority, it will prioritize the allocation of computing resources to the task and pause or delay the degradation operation for the task. This ensures that the strong real-time operation actively triggered by the user will not be interrupted or delayed by the automatic degradation strategy of the system, thereby improving the robot's human-machine interaction responsiveness and user experience.

[0140] This application also provides a method for dynamic allocation of computing power, including: Acquire system load data; the system load data is determined by one or more of the following: CPU load value, neural network processor load value, and graphics processor load value; The target load level is determined based on the system load data and the load level mapping relationship; wherein, the load level mapping relationship includes the correspondence between the system load data and the load level; the load level includes a first load level, a second load level and a third load level, wherein the system load corresponding to the first load level is lower than the system load corresponding to the second load level, and the system load corresponding to the second load level is lower than the system load corresponding to the third load level; Based on the target load level, an allocation strategy corresponding to the target load level is executed on the currently running multiple tasks to ensure that high real-time priority tasks among the multiple tasks obtain computing resources first; the multiple tasks include high real-time priority tasks, weak real-time priority tasks, and background priority tasks.

[0141] In some embodiments, the dependency management module 605 loads task dependencies during the robot startup phase and creates corresponding threads. The computing power scheduling module 602 coordinates and allocates tasks that need to be executed and those that are idle. The dependency management module 605 starts the corresponding threads to execute tasks according to the allocation and coordination of the computing power scheduling module 602. The load detection module 603 periodically detects the load and reports it to the computing power scheduling module 602 and the overload protection module 604. The computing power scheduling module 602 and the overload protection module 604 dynamically upgrade / downgrade tasks according to the load.

[0142] In some examples, the task identification module 601 continuously monitors whether new tasks appear. After timely identification of a task, the computing power scheduling module 602 allocates the task according to the task priority. The dependency management module 605 creates and runs the corresponding process based on the computing core according to the task allocation result of the computing power scheduling module 602.

[0143] Continuing with the example above, after the overload protection module 604 detects an increase in load level after the creation of the process corresponding to a new task, it releases or migrates some processes in the computing core where the new process resides. The task priority of these released or migrated processes is lower than the task newly detected by the task identification module 601. The migrated processes have dynamic identifiers. Processes with static identifiers are typically those that are difficult to migrate or whose migration would likely lead to system risks; therefore, the overload protection module 604 will not migrate processes with static identifiers.

[0144] In this way, the overall load of the robot is scheduled from the perspective of task allocation, rather than optimizing the load level from the perspective of thread release. Based on the dependencies and priorities of tasks, and with task allocation / release as the premise or cooperating condition for thread creation / release, the creation or release of threads can effectively avoid the problem that it is difficult to allocate the load according to the importance of tasks due to single thread monitoring, which can easily lead to important tasks being abnormally terminated in multi-concurrency scenarios.

[0145] Similar parts between the embodiments provided in this application can be referred to mutually. The specific implementation methods provided above are only a few examples under the overall concept of this application and do not constitute a limitation on the scope of protection of this application. For those skilled in the art, any other implementation methods extended from the solution of this application without creative effort shall fall within the scope of protection of this application.

Claims

1. A robot, characterized in that, include: The controller is configured as follows: Obtain system load data; the system load data is determined by the load values ​​of the sub-controllers included in the controller; The target load level is determined based on the system load data and the load level mapping relationship; wherein, the load level mapping relationship includes the correspondence between the system load data and the load level; the load level includes a first load level, a second load level and a third load level, wherein the system load corresponding to the first load level is lower than the system load corresponding to the second load level, and the system load corresponding to the second load level is lower than the system load corresponding to the third load level; Based on the target load level, an allocation strategy corresponding to the target load level is executed on the currently running multiple tasks to ensure that high real-time priority tasks among the multiple tasks obtain computing resources first; the multiple tasks include high real-time priority tasks, weak real-time priority tasks, and background priority tasks.

2. The robot according to claim 1, characterized in that, Before the controller acquires system load data, it is also configured to: The business types of multiple currently running tasks are identified based on a preset structured configuration file. The structured configuration file includes the node name, node dependency relationship, business type description and priority attribute field for each task. The priority attribute field is used to determine the priority of each task and whether the priority of each task can be adjusted. Based on the business type and priority attribute field, a priority identifier is assigned to each task; the priority attribute field includes a priority identifier, a dynamic identifier, and a static identifier; the priority identifier is used to characterize the priority of the task; the dynamic identifier is used to characterize the priority of the task that changes during execution, and the static identifier is used to characterize the priority of the task that remains unchanged during execution. Based on the node names and node dependencies in the structured configuration file, a task dependency graph is constructed; the task dependency graph is used to determine the execution order and recovery order of the multiple tasks.

3. The robot according to claim 2, characterized in that, The controller executes an allocation strategy corresponding to the target load level for the currently running tasks, specifically configured as follows: When the target load level is the first load level, at least one first target task with a background priority is determined among the plurality of tasks; The execution of at least one first target task is suspended to release the computing resources occupied by the first target task.

4. The robot according to claim 3, characterized in that, The controller is further configured as follows: When the target load level is the second load level, at least one second target task with a weak real-time priority is determined among the plurality of tasks; Based on the fact that at least one first target task has been paused, the execution of at least one second target task is paused in order to keep the task with strong real-time priority running continuously.

5. The robot according to claim 4, characterized in that, The controller is also configured to: When the target load level is the third load level, determine all non-strong real-time priority tasks among the multiple tasks, except those with strong real-time priority. Suspend the execution of all non-strong real-time priority tasks and generate an overload alarm.

6. The robot according to claim 5, characterized in that, The controller is also configured to: When the system load data drops below the load threshold corresponding to the first load level, the suspended non-strong real-time priority tasks are resumed according to the preset recovery priority order.

7. The robot according to claim 6, characterized in that, When the system load data drops below the load threshold corresponding to the first load level, the controller resumes the execution of the suspended non-strong real-time priority tasks according to a preset recovery priority order, specifically configured as follows: If the system load data is confirmed to be stable, resume the suspended tasks with a low real-time priority. After confirming that the system load data has been restored to the paused task with the weak real-time priority, and provided that the system load data remains stable, the paused task with the background priority is restored.

8. The robot according to claim 2, characterized in that, The sub-controller includes a central processing unit, a neural network processor, and / or a graphics processing unit; after assigning a corresponding priority and priority identifier to each task based on the service type and priority attribute field, the controller is further configured to: Tasks with strong real-time priority are bound to the large cores of the CPU, tasks with background priority are bound to the small cores of the CPU, and tasks with weak real-time priority are bound to either the large or small cores of the CPU; the computing power of the large cores of the CPU is higher than that of the small cores of the CPU. And / or, allocate the computational load of artificial intelligence recognition tasks to the neural network processor, and / or allocate the computational load of graphics rendering tasks to the graphics processor.

9. The robot according to claim 1, characterized in that, The controller is also configured to: During the execution of the allocation strategy, in response to the received user operation instructions, the target task and its priority corresponding to the user operation instructions are determined. When the priority of the target task is strong real-time priority, computing resources are allocated to the target task first. Suspend or delay the execution of the degradation operation for the target task in the allocation strategy.

10. A method for dynamic allocation of computing power, characterized in that, include: Obtain system load data; the system load data is determined by the load value of the sub-controller; The target load level is determined based on the system load data and the load level mapping relationship; wherein, the load level mapping relationship includes the correspondence between the system load data and the load level; the load level includes a first load level, a second load level and a third load level, wherein the system load corresponding to the first load level is lower than the system load corresponding to the second load level, and the system load corresponding to the second load level is lower than the system load corresponding to the third load level; Based on the target load level, an allocation strategy corresponding to the target load level is executed on the currently running multiple tasks to ensure that high real-time priority tasks among the multiple tasks obtain computing resources first; the multiple tasks include high real-time priority tasks, weak real-time priority tasks, and background priority tasks.

Images