Method for binding cpu allocation of intelligent robot operating system and storage medium

Abstract

The application discloses a smart robot operating system binding CPU distribution method and a storage medium, belongs to a conventional Linux binding CPU, and needs to specify a CPU number. Once the number is improperly set, different applications will be bound to the same CPU, causing CPU binding conflicts. The technical problem to be solved by the application is a smart robot operating system. The technical scheme adopted by the application is that the method is to modify an RLinux kernel dependent on IROS, so that when the RLinux starts, a bindable CPU pool is established, and configured CPU cores are distributed to the bindable CPU pool. Meanwhile, the Rlinux provides two system call functions, which are respectively used for binding CPU cores and unbinding CPU cores. IROS applications perform CPU core binding and CPU core unbinding by calling corresponding system call functions. The RLinux automatically performs CPU core binding or CPU core unbinding for the IROS applications that have called the system call functions, so as to avoid CPU core calling conflicts.

Description

Technical Field

[0001] This invention relates to the field of intelligent robot operating system technology, specifically to an intelligent robot operating system CPU allocation method and storage medium. Background Technology

[0002] The Intelligent Robot Operating System (IROS) is a system with similar functionality to ROS, replacing the open-source ROS kernel, providing ROS-compatible interfaces, solving ROS's reliability, performance, and security issues, and adding new features such as supporting cloud-based robot development, cloud-edge-device communication, and multi-robot collaboration. IROS also provides a dedicated Linux distribution, RLinux, for real-time robot operation, while ROS primarily relies on Ubuntu Linux.

[0003] IROS supports multi-core CPU architectures. In a multi-core CPU architecture, each core has its own L1 and L2 caches, while the L3 cache is shared. If a process switches between cores, the cache hit rate of each core will be affected. Conversely, if a process can always execute on a single core regardless of scheduling, the L1 and L2 cache hit rates can be significantly improved. The Linux system provides a system call called `sched_setaffinity`, which can bind a process to a specified CPU, thereby improving the process's performance. However, the `sched_setaffinity` system call requires specifying a specific CPU number. When multiple unrelated applications need to bind to a CPU, if the number is set incorrectly, it will result in duplicate numbers, causing the CPU binding to fail and failing to achieve the desired effect.

[0004] Therefore, how to avoid CPU binding conflicts and thus obtain better real-time performance is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] The technical objective of this invention is to provide a method and storage medium for binding CPUs to an intelligent robot operating system, in order to solve the problem that when binding a CPU in conventional Linux, a CPU number needs to be specified. If the number is not set correctly, different applications will be bound to the same CPU, causing CPU binding conflicts.

[0006] The technical objective of this invention is achieved as follows: a method for binding CPU allocation in an intelligent robot operating system. This method modifies the RLinux kernel, which IROS depends on, so that when RLinux starts, it establishes a bindable CPU pool and allocates the configured CPU cores to the bindable CPU pool. Simultaneously, RLinux provides two system call functions, one for binding CPU cores and the other for unbinding CPU cores. IROS applications bind and unbind CPU cores by calling the corresponding system call functions. RLinux automatically binds or unbinds CPU cores for IROS applications that have already called the system call functions, effectively avoiding CPU core call conflicts.

[0007] Preferably, the system call functions are sched_bind_iros and sched_unbind_iros;

[0008] Among them, sched_bind_iros is used to bind CPU cores;

[0009] `sched_unbind_iros` is used to unbind CPU cores.

[0010] Better yet, the Rlinux kernel allocates the configured CPU cores to a bindable CPU pool based on the number of CPU cores and the corresponding code for each CPU core. The CPU cores allocated to the bindable CPU pool do not participate in ordinary CPU task scheduling and are used by IROS applications that require CPU core binding.

[0011] More preferably, the construction rules for bindable CPU pools are as follows:

[0012] In the RLinux kernel, not all CPU cores can be assigned to the bindable CPU pool; at least one CPU core must be reserved for regular CPU task scheduling.

[0013] When all configured CPU cores in the RLinux kernel are assigned to a bindable CPU pool, the RLinux kernel automatically excludes the first CPU core from the bindable CPU pool and uses the first CPU core as a regular CPU task for scheduling.

[0014] As a preferred method, IROS applications perform CPU core binding and unbinding by calling the corresponding system call functions, as follows:

[0015] The system call function used for CPU core binding does not require any parameters;

[0016] When the CPU core is successfully bound, a handle is returned;

[0017] If the CPU core binding fails (e.g., there is no free CPU core to bind to), then -1 is returned.

[0018] The system call function used to unbind a CPU core requires the handle returned by the system call function used to bind the CPU core as a parameter. The RLinux kernel determines which CPU core to unbind based on the returned handle.

[0019] As a preferred option, CPU cores can be removed from the pool of bindable CPUs, as follows:

[0020] When the system call function sched_bind_iros successfully binds a CPU core, the RLinux kernel removes the bound CPU core from the pool of available CPUs.

[0021] As a preferred option, CPU cores are placed in the pool of bindable CPUs, as follows:

[0022] When the system call function sched_unbind_iros successfully unbinds a CPU core, the RLinux kernel will put the unbound CPU core back into the pool of bindable CPUs to participate in CPU core scheduling and allocation.

[0023] As a preferred option, the RLinux kernel modifies the system call process, as follows:

[0024] When an IROS application that calls the CPU core binding system call function sched_bind_iros exits without calling the CPU core unbinding system call function sched_unbind_iros or exits abnormally, the system scheduling process detects that the IROS application has exited. If the IROS application used CPU core binding, the CPU core bound to the IROS application is returned to the pool of available CPUs, so that the CPU core bound to the IROS application can be bound again by other IROS applications.

[0025] When an IROS application that calls the unbind CPU core system call function sched_unbind_iros does not exit, the system scheduler will schedule the IROS application to run on other unbound CPU cores. If the IROS application calls the bound CPU core system call function sched_bind_iros again and succeeds, the system scheduler will rebind the IROS application to any idle CPU core in the bindable CPU pool.

[0026] An electronic device includes: a memory and at least one processor;

[0027] The memory contains computer programs;

[0028] The at least one processor executes the computer program stored in the memory, causing the at least one processor to execute the intelligent robot operating system CPU allocation method described above.

[0029] A computer-readable storage medium storing a computer program that can be executed by a processor to implement the intelligent robot operating system-bound CPU allocation method described above.

[0030] The intelligent robot operating system binding CPU allocation method and storage medium of the present invention have the following advantages:

[0031] (i) This invention modifies the RLinux kernel on which IROS depends, so that RLinux allocates bindable CPU cores and establishes a bindable CPU pool when it starts. RLinux provides two new system call functions to bind and unbind CPU cores respectively. IROS applications can call these two system call functions to bind and unbind CPU cores. Neither system call function needs to specify the CPU number. The RLinux kernel automatically binds or unbinds CPU cores for IROS applications that call these two system call functions, so there will be no problem of CPU core conflict.

[0032] (ii) This invention changes the RLinux kernel on which IROS depends and provides a new system call function. Applications based on IROS can obtain CPU core binding by calling this system call function without causing CPU core binding conflicts, thereby achieving better real-time performance and meeting the needs of real-time robot application scenarios.

[0033] (III) To address the conflict caused by different applications binding to the same CPU when binding a CPU in conventional Linux, which requires specifying the CPU number, this invention adopts a new system call function to avoid CPU binding conflicts, thereby achieving better real-time performance. Attached Figure Description

[0034] The invention will be further described below with reference to the accompanying drawings.

[0035] Appendix Figure 1 A schematic diagram illustrating the CPU allocation method for binding the operating system of an intelligent robot. Detailed Implementation

[0036] The following detailed description of the intelligent robot operating system CPU allocation method and storage medium of the present invention, with reference to the accompanying drawings and specific embodiments, is provided.

[0037] Example 1:

[0038] As attached Figure 1As shown, this embodiment provides a method for binding CPU allocation in an intelligent robot operating system. This method modifies the RLinux kernel, which IROS depends on, so that when RLinux starts, it establishes a bindable CPU pool and allocates the configured CPU cores to the bindable CPU pool. At the same time, RLinux provides two system call functions, which are used to bind and unbind CPU cores, respectively. IROS applications bind and unbind CPU cores by calling the corresponding system call functions. RLinux automatically binds or unbinds CPU cores for IROS applications that have already called the system call functions, effectively avoiding CPU core call conflicts.

[0039] In this embodiment, the system call functions are sched_bind_iros and sched_unbind_iros;

[0040] Among them, sched_bind_iros is used to bind CPU cores;

[0041] `sched_unbind_iros` is used to unbind CPU cores.

[0042] In this embodiment, the Rlinux kernel allocates the configured CPU cores to a bindable CPU pool based on the number of CPU cores and the corresponding code of each CPU core. The CPU cores allocated to the bindable CPU pool do not participate in ordinary CPU task scheduling and are used by IROS applications that require CPU core binding.

[0043] The specific rules for constructing the bindable CPU pool in this embodiment are as follows:

[0044] In the RLinux kernel, not all CPU cores can be assigned to the bindable CPU pool; at least one CPU core must be reserved for regular CPU task scheduling.

[0045] When all configured CPU cores in the RLinux kernel are assigned to a bindable CPU pool, the RLinux kernel automatically excludes the first CPU core from the bindable CPU pool and uses the first CPU core as a regular CPU task for scheduling.

[0046] In this embodiment, the IROS application performs CPU core binding and unbinding by calling the corresponding system call functions, as follows:

[0047] The system call function used for CPU core binding does not require any parameters;

[0048] When the CPU core is successfully bound, a handle is returned;

[0049] If the CPU core binding fails (e.g., there is no free CPU core to bind to), then -1 is returned.

[0050] The system call function used to unbind a CPU core requires the handle returned by the system call function used to bind the CPU core as a parameter. The RLinux kernel determines which CPU core to unbind based on the returned handle.

[0051] In this embodiment, removing a CPU core from the bindable CPU pool occurs as follows:

[0052] When the system call function sched_bind_iros successfully binds a CPU core, the RLinux kernel removes the bound CPU core from the pool of available CPUs.

[0053] In this embodiment, CPU cores are placed in the bindable CPU pool as follows:

[0054] When the system call function sched_unbind_iros successfully unbinds a CPU core, the RLinux kernel will put the unbound CPU core back into the pool of bindable CPUs to participate in CPU core scheduling and allocation.

[0055] In this embodiment, the RLinux kernel modifies the system call process, as follows:

[0056] When an IROS application that calls the CPU core binding system call function sched_bind_iros exits without calling the CPU core unbinding system call function sched_unbind_iros or exits abnormally, the system scheduling process detects that the IROS application has exited. If the IROS application used CPU core binding, the CPU core bound to the IROS application is returned to the pool of available CPUs, so that the CPU core bound to the IROS application can be bound again by other IROS applications.

[0057] When an IROS application that calls the unbind CPU core system call function sched_unbind_iros does not exit, the system scheduler will schedule the IROS application to run on other unbound CPU cores. If the IROS application calls the bound CPU core system call function sched_bind_iros again and succeeds, the system scheduler will rebind the IROS application to any idle CPU core in the bindable CPU pool.

[0058] Example 2:

[0059] This embodiment also provides an electronic device, including: a memory and a processor;

[0060] The memory stores the instructions executed by the computer.

[0061] The processor executes computer execution instructions stored in the memory, causing the processor to execute the intelligent robot operating system binding CPU allocation method in any embodiment of the present invention.

[0062] The processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), off-the-shelf programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can be a microprocessor or any conventional processor.

[0063] Memory is used to store computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory, and by accessing data stored in the memory. Memory can mainly include a program storage area and a data storage area. The program storage area can store the operating system, at least one application program required for a function, etc.; the data storage area can store data created based on the use of the terminal, etc. In addition, memory can also include high-speed random access memory, and can also include non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart memory cards (SMC), secure digital cards (SD cards), flash memory cards, at least one disk storage device, flash memory devices, or other volatile solid-state storage devices.

[0064] Example 3:

[0065] This embodiment also provides a computer-readable storage medium storing multiple instructions, which are loaded by a processor to cause the processor to execute the intelligent robot operating system binding CPU allocation method in any embodiment of the present invention. Specifically, a system or device equipped with a storage medium may be provided, on which software program code implementing the functions of any of the above embodiments is stored, and the computer (or CPU or MPU) of the system or device may read and execute the program code stored in the storage medium.

[0066] In this case, the program code read from the storage medium can itself implement the function of any of the above embodiments, and therefore the program code and the storage medium storing the program code constitute part of the present invention.

[0067] Storage media embodiments for providing program code include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RYM, DVD-RW, DVD+RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, program code can be downloaded from a server computer via a communication network.

[0068] Furthermore, it should be clear that not only can the program code read by the computer be executed, but also the operating system or other components operating on the computer can be instructed based on the program code to perform some or all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0069] Furthermore, it is understood that the program code read from the storage medium is written to the memory set in the expansion board inserted into the computer or to the memory set in the expansion unit connected to the computer. Then, based on the instructions of the program code, the CPU or other components installed on the expansion board or expansion unit execute some and all of the actual operations, thereby realizing the function of any of the embodiments described above.

[0070] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for binding CPU allocation to an intelligent robot operating system, characterized in that, This method modifies the RLinux kernel, which IROS depends on, to create a bindable CPU pool upon RLinux startup and allocate the configured CPU cores to the bindable CPU pool. Simultaneously, RLinux provides two system call functions, one for binding CPU cores and the other for unbinding CPU cores. IROS applications bind and unbind CPU cores by calling the corresponding system call functions. RLinux automatically binds or unbinds CPU cores for IROS applications that have already called the system call functions, avoiding CPU core call conflicts. The system call functions are sched_bind_iros and sched_unbind_iros, respectively. Among them, sched_bind_iros is used to bind CPU cores; sched_unbind_iros is used to unbind CPU cores; The Rlinux kernel allocates the configured CPU cores to a bindable CPU pool based on the number of CPU cores and the corresponding code of each CPU core. The CPU cores allocated to the bindable CPU pool are used by IROS applications that require CPU core binding. The specific rules for building a bindable CPU pool are as follows: In the RLinux kernel, at least one CPU core is reserved for regular CPU task scheduling; When all configured CPU cores in the RLinux kernel are assigned to the bindable CPU pool, the RLinux kernel automatically excludes the first CPU core from the bindable CPU pool and uses the first CPU core as a regular CPU task for scheduling. IROS applications perform CPU core binding and unbinding by calling corresponding system call functions, as follows: The system call function used for CPU core binding does not require any parameters; When the CPU core is successfully bound, a handle is returned; If the CPU core binding fails, -1 is returned. The system call function used to unbind a CPU core requires the handle returned by the system call function used to bind the CPU core as a parameter. The RLinux kernel determines which CPU core to unbind based on the returned handle. A CPU core is removed from a bindable CPU pool as follows: When the system call function sched_bind_iros used for CPU core binding successfully binds a CPU core, the RLinux kernel removes the bound CPU core from the pool of available CPUs. CPU cores are added to the bindable CPU pool, as follows: When the system call function sched_unbind_iros used for CPU unbinding successfully unbinds a CPU core, the RLinux kernel will put the unbound CPU core back into the pool of bindable CPUs to participate in CPU core scheduling and allocation. The RLinux kernel has modified the system call process, as follows: When an IROS application that calls the CPU core binding system call function sched_bind_iros exits without calling the CPU core unbinding system call function sched_unbind_iros or exits abnormally, the system scheduling process detects that the IROS application has exited. If the IROS application used CPU core binding, the CPU core bound to the IROS application is returned to the pool of available CPUs, so that the CPU core bound to the IROS application can be bound again by other IROS applications. When an IROS application that calls the unbind CPU core system call function sched_unbind_iros does not exit, the system scheduler will schedule the IROS application to run on other unbound CPU cores. If the IROS application calls the bound CPU core system call function sched_bind_iros again and succeeds, the system scheduler will rebind the IROS application to any idle CPU core in the bindable CPU pool.

2. An electronic device, characterized in that, include: Memory and at least one processor; The memory contains computer programs; The at least one processor executes the computer program stored in the memory, causing the at least one processor to execute the intelligent robot operating system CPU allocation method as described in claim 1.

3. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that can be executed by a processor to implement the intelligent robot operating system binding CPU allocation method as described in claim 1.

Images