A ROS2 hybrid scheduling executor system
By introducing real-time schedulers and fair schedulers into ROS2 executors, combined with registry and thread pool design, the limitations of existing ROS2 executors in handling hybrid workloads are solved, achieving more efficient system real-time and throughput.
Patent Information
- Application Number
- CN202510119854.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-01-25
- Publication Date
- 2025-05-02
- Estimated Expiration
- 2045-01-25
AI Technical Summary
The existing ROS2 executors have limitations when handling hybrid workloads, and it is difficult to meet the simultaneous execution requirements of critical and ordinary tasks. Since the scheduling mechanism is non-preemptive, critical tasks may be blocked by ordinary tasks, affecting the real-time nature of the system.
A ROS2 hybrid scheduling executor system is proposed, which uses a combination of real-time scheduler and fair scheduler to achieve separate scheduling of critical tasks and ordinary tasks through the design of registry, ready callback set, scheduler and thread pool. The real-time scheduler adopts the CIL-EDF strategy, the fair scheduler adopts the default strategy, and the shared thread provides two execution modes to regulate the system's real-time and throughput.
It effectively solves the limitations of ROS2 actuators when dealing with hybrid workloads, improves the real-time and throughput of the system, can meet the needs of different workloads, and ensures timely execution of critical tasks.
Smart Images

Figure CN119557076B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of robot operating systems, and in particular to a ROS2 hybrid scheduling executor system. Background Art
[0002] The Robot Operating System (ROS) is an open source middleware framework widely used in the development of robot applications. ROS improves the development efficiency of robot applications through the modularity and composability of software. However, over the past few decades, ROS has exposed its major flaw of lacking real-time performance, which limits its use in safety-critical fields with high real-time requirements. Against this background, in 2017, the ROS community released the second-generation robot operating system ROS2, which was reconstructed based on the ROS framework. One of the main goals of the ROS2 design is to improve the real-time performance of the framework to support the development of real-time applications for robots. ROS2 uses data distribution service (DDS) as the underlying communication framework for end-to-end data exchange. Compared with ROS, ROS2 can provide better real-time support for robot applications.
[0003] The ROS2 executor uses one or more threads of the underlying operating system to schedule the execution of ready callback instances. The ROS2 executor uses a polling callback instance scheduling method by default, which is a fairness-oriented scheduling method and is not suitable for safety-critical applications.
[0004] As robotic systems become increasingly complex, the need to handle both critical and common tasks has increased significantly. For example, intelligent robots need to execute large model workloads and real-time control workloads simultaneously. Critical tasks have real-time constraints and must be completed before the deadline. Common workloads, on the other hand, are insensitive to end-to-end latency and are more concerned with fairness between tasks. The existing ROS2 architecture only supports a single scheduling strategy, which is difficult to meet the needs of mixed workloads, which limits the optimal performance of robots when performing tasks. In addition, since the scheduling mechanism of the actuator is non-preemptive, critical tasks may be blocked by common tasks, affecting the real-time performance of the system.
[0005] Therefore, the present invention proposes a ROS2 hybrid scheduling executor system to solve the above-mentioned problems. Summary of the invention
[0006] In view of the problems existing in the prior art, the object of the present invention is to provide a ROS2 hybrid scheduling executor system to solve the problems raised in the above background technology.
[0007] To achieve the above object, the present invention provides a ROS2 hybrid scheduling executor system, the system comprising a registry, two ready callback sets, two schedulers and two thread pools;
[0008] The registry stores key type information of all callbacks in the system;
[0009] The two schedulers are respectively a real-time scheduler and a fair scheduler; the real-time scheduler is responsible for scheduling the callback instance of the critical chain; the fair scheduler is responsible for scheduling the callback instance of the common chain;
[0010] The two thread pools include dedicated threads and shared threads, wherein the dedicated threads exclusively run the real-time scheduler; the shared threads can run both the real-time scheduler and the fair scheduler; the shared threads include two execution modes: (i) real-time scheduler priority: the thread runs the real-time scheduler first, and only when the priority queue of the real-time scheduler is empty, does it run the fair scheduler; (ii) fair scheduler priority: the thread runs the fair scheduler first, and only when the vector set of the fair scheduler is empty, does it run the real-time scheduler.
[0011] Furthermore, the two ready callback sets are respectively a priority queue and a vector set.
[0012] Furthermore, the real-time scheduler and the fair scheduler each allocate a ready callback set; the ready callback set of the real-time scheduler is a priority queue; the callback instances in the queue are prioritized according to the deadline of the corresponding chain instance, and the callback instance at the head of the queue has the highest priority; the ready callback set of the fair scheduler consists of four vectors, which store four types of callback instances: timer, subscription, service, and client.
[0013] Furthermore, the scheduler calls the collect callback instance function before scheduling the callback instance; the lock clt_lock is used to ensure that only one thread collects the callback instance at any time.
[0014] Furthermore, for the priority queue, in order to prevent priority inversion between instances of the critical chain, the scheduler adds the callback instances of the critical chain to the priority queue before scheduling; for the vector set, in order to ensure fairness between ordinary chains, the scheduler adds the ready callback instances of the ordinary chain to the corresponding vector only when all vectors are empty.
[0015] Furthermore, the real-time scheduler schedules the callback instance at the head of the priority queue each time; the fair scheduler schedules the first callback instance in the four vectors in the order of timer, subscription, service, and client.
[0016] Furthermore, the real-time scheduler execution process is as follows:
[0017] S101. Check whether the lock clt_lock is acquired; if so, proceed to step S102, if not, return to the initial stage and perform the test again;
[0018] S102. Call the collection callback instance function;
[0019] S103. Release the lock clt_lock;
[0020] S104. Determine whether the priority queue is empty; if so, return failure and end the task; if not, proceed to step S105;
[0021] S105. Take the callback instance at the head of the queue and pass it to the callback reference cb;
[0022] S106. Return success and end the task.
[0023] Furthermore, the fair scheduler execution process is as follows:
[0024] S201. Check whether the lock clt_lock is acquired; if so, proceed to step S202, if not, return to the initial stage and perform the test again;
[0025] S202. Call the collection callback instance function;
[0026] S203. Release the lock clt_lock;
[0027] S204. Determine whether the timer vector is empty; if not, take out the first callback instance from the timer vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the subscription vector is empty, if not, take out the first callback instance from the subscription vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the service vector is empty, if not, take out the first callback instance from the service vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the client vector is empty, if so, return failure and end the task, if not, take out the first callback instance from the client vector and pass it to the callback reference cb, and then enter step S205;
[0028] S205; Return success and end the task.
[0029] Furthermore, the execution flow of the collection callback instance function is as follows:
[0030] S301. Add the ready callback instance of the critical chain to the priority queue;
[0031] S302. Determine whether all vectors in the vector set are empty; if so, proceed to step S303, if not, terminate the task;
[0032] S303. Collect the ready callback instances of the common chain into the corresponding vector.
[0033] Furthermore, when the callback instance is collected to the executor, it is judged by the key type information of the registry. If it is a callback instance of the critical chain, it is added to the priority queue, and the queue reorders the callback instances in the queue according to the deadline of the callback instance; if it is a callback instance of the ordinary chain, it is added to the corresponding vector according to the type of the callback instance.
[0034] Beneficial effects:
[0035] The present invention proposes a ROS2 hybrid scheduling executor system and execution method to overcome the limitations of the existing ROS2 executor in processing mixed workloads. A real-time scheduler and a fair scheduler are introduced to meet the needs of different workloads. The real-time scheduler schedules critical tasks, and the fair scheduler schedules ordinary tasks. By introducing exclusive threads and shared threads, shared threads provide two execution modes, so that the system real-time performance and throughput can be regulated by thread configuration. Shared threads can run both real-time schedulers and fair schedulers, so that ready callback instances can be scheduled as early as possible, maximizing the system throughput. BRIEF DESCRIPTION OF THE DRAWINGS
[0036] Figure 1 A schematic diagram of the ROS2 hybrid scheduling executor system architecture according to the present invention is shown;
[0037] Figure 2 Shows a real-time scheduler execution flow chart according to the present invention;
[0038] Figure 3 shows a fair scheduler execution flow chart according to the present invention;
[0039] Figure 4 The execution flow chart of the collection callback instance function according to the present invention is shown;
[0040] Figure 5 shows an execution flow chart of a dedicated thread according to the present invention;
[0041] Figure 6 The following is a flowchart showing the execution of a shared thread according to the present invention. DETAILED DESCRIPTION
[0042] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.
[0043] In the description of the present invention, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc., indicating the orientation or positional relationship, are based on the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as limiting the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only, and cannot be understood as indicating or implying relative importance.
[0044] In the description of the present invention, it should be noted that, unless otherwise clearly specified and limited, the terms "installed", "connected", and "connected" should be understood in a broad sense, for example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection, or it can be indirectly connected through an intermediate medium, or it can be the internal communication of two components. For ordinary technicians in this field, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.
[0045] The following combination Figure 1-Figure 6 The specific embodiments of the present invention are described in detail. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present invention, and are not used to limit the present invention.
[0046] As shown in FIG1 , the ROS2 hybrid scheduling executor system according to the present invention includes a registry, two ready callback sets (priority queues and vector sets), two schedulers and two thread pools. In order to meet the scheduling requirements of different types of chains, the present invention has two built-in schedulers in the hybrid scheduling executor: a real-time scheduler and a fair scheduler. The real-time scheduler is responsible for scheduling the callback instances of the critical chain, that is, the workloads with high real-time requirements. The existing real-time scheduling strategies of ROS2 are PiCAS and CIL-EDF. Compared with PiCAS, CIL-EDF has a finer-grained priority allocation and is not prone to "starvation" under overload conditions. Therefore, the scheduling strategy adopted by the real-time scheduler is CIL-EDF. The fair scheduler is responsible for scheduling the callback instances of ordinary chains, which have no real-time constraints and focus on fairness. The default scheduling strategy of ROS2 is a fair scheduling strategy, so the fair scheduler adopts the default scheduling strategy.
[0047] In order to adapt the storage structure of the ready callback set to the architecture of the dual scheduler including the real-time scheduler and the fair scheduler, the present invention allocates a ready callback set to each of the real-time scheduler and the fair scheduler. The ready callback set of the real-time scheduler is a priority queue. The callback instances in the queue are prioritized according to the deadline of the corresponding chain instance, and the callback instance at the head of the queue has the highest priority. The ready callback set of the fair scheduler consists of four vectors, which respectively store four types of callback instances: timer, subscription, service and client.
[0048] Figure 2 The execution flow chart of the real-time scheduler is given. Figure 3 The execution process of the fair scheduler is given. Figure 4 The execution flow chart of callback instance collection is given.
[0049] Specifically, Figure 2 As shown, the real-time scheduler execution process is as follows:
[0050] S101. Check whether the lock clt_lock is acquired; if so, proceed to step S102, if not, return to the initial stage and perform the test again;
[0051] S102. Call the collection callback instance function;
[0052] S103. Release the lock clt_lock;
[0053] S104. Determine whether the priority queue is empty; if so, return failure and end the task; if not, proceed to step S105;
[0054] S105. Take the callback instance at the head of the queue and pass it to the callback reference cb;
[0055] S106. Return success and end the task.
[0056] like Figure 3 As shown, the execution process of the fair scheduler is as follows:
[0057] S201. Check whether the lock clt_lock is acquired; if so, proceed to step S202, if not, return to the initial stage and perform the test again;
[0058] S202. Call the collection callback instance function;
[0059] S203. Release the lock clt_lock;
[0060] S204. Determine whether the timer vector is empty; if not, take out the first callback instance from the timer vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the subscription vector is empty, if not, take out the first callback instance from the subscription vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the service vector is empty, if not, take out the first callback instance from the service vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the client vector is empty, if so, return failure and end the task, if not, take out the first callback instance from the client vector and pass it to the callback reference cb, and then enter step S205;
[0061] S205; Return success and end the task.
[0062] like Figure 4 As shown, the execution process of the collection callback instance function is as follows:
[0063] S301. Add the ready callback instance of the critical chain to the priority queue;
[0064] S302. Determine whether all vectors in the vector set are empty; if so, proceed to step S303, if not, terminate the task;
[0065] S303. Collect the ready callback instances of the common chain into the corresponding vector.
[0066] The scheduler will call the callback instance collection function before scheduling the callback instance. In order to prevent data competition and inconsistency, the present invention uses the lock clt_lock to ensure that only one thread collects the callback instance at any time. For the priority queue, in order to prevent priority inversion between instances of the critical chain, the scheduler will add the callback instance of the critical chain to the priority queue before scheduling. For the vector set, in order to ensure fairness between ordinary chains, the scheduler will only add the ready callback instance of the ordinary chain to the corresponding vector when all vectors are empty. The real-time scheduler schedules the callback instance at the head of the priority queue each time. The fair scheduler schedules the first callback instance in the four vectors in the order of timer, subscription, service and client.
[0067] The registry stores the key type information of all callback chains in the system. When a callback instance is collected to the executor, it will be judged by the key type information in the registry. If it is a callback instance of a critical chain, it will be added to the priority queue, and the queue will reorder the callback instances in the queue according to the deadline of the callback instance. If it is a callback instance of a normal chain, it will be added to the corresponding vector according to the type of the callback instance.
[0068] Since the scheduling mechanism of the executor is non-preemptive, the callback instance of the critical chain may be blocked by the callback instance of the common chain, thereby affecting the real-time performance of the system. In order to solve this problem, the present invention divides threads into dedicated threads and shared threads. Figure 5 and Figure 6 The execution flow charts of dedicated threads and shared threads are given respectively.
[0069] Specifically, Figure 5 As shown, the execution flow of the dedicated thread is as follows:
[0070] S401. Check whether the lock scd_lock is acquired; if so, proceed to step S402, if not, return to the initial stage of this step and perform the test again;
[0071] S402 determines whether to execute the real-time scheduler; if it proceeds to step S403, if not, returns to the initial stage of the step and executes the judgment again;
[0072] S403. Release the lock scd_lock;
[0073] S404. Execute callback handle cb.
[0074] like Figure 6 As shown, the execution flow of the shared thread is as follows:
[0075] S501. Check whether the lock scd_lock is acquired; if so, proceed to step S502, if not, return to the initial stage and perform the test again;
[0076] S502. Determine whether the real-time scheduler has priority; if so, proceed to step S503; if not, proceed to step S504;
[0077] S503. Determine whether to execute the real-time scheduler, if so, proceed to step S505; if not, continue to determine whether to execute the fair scheduler, if so, proceed to step S505, if not, return to the initial stage of the step to determine again whether to execute the real-time scheduler;
[0078] S504. Determine whether to execute the fair scheduler; if so, proceed to step S505; if not, continue to determine whether to execute the real-time scheduler, if so, proceed to step S505, if not, return to the initial stage of the step to determine again whether to execute the fair scheduler;
[0079] S505. Release the lock scd_lock.
[0080] Among them, the lock scd_lock is used to ensure that only one thread enters the program that schedules the callback instance at any time. Among them: (1) Dedicated threads: Dedicated threads run the real-time scheduler exclusively. Even in idle time, these threads will not run the fair scheduler to ensure that the callback instances of the critical chain can be executed in time to meet the real-time constraints. (2) Shared threads: Shared threads can run both the real-time scheduler and the fair scheduler, so that ready callback instances can be scheduled as early as possible to maximize the performance of the system. Shared threads provide two execution modes: (1) Real-time scheduler priority: The thread runs the real-time scheduler first, and only when the priority queue of the real-time scheduler is empty, does it run the fair scheduler. (2) Fair scheduler priority: The thread runs the fair scheduler first, and only when the vector set of the fair scheduler is empty, does it run the real-time scheduler.
[0081] The present invention designs a chain-aware thread mapping strategy by analyzing the scheduling behavior of the hybrid scheduling executor for ROS2 and the timing characteristics of the task chain. This strategy aims to map threads to CPUs to optimize performance while meeting real-time constraints given a fixed number of CPUs.
[0082] Specifically, the chain-aware thread mapping strategy is implemented as follows:
[0083] First, we model the ROS2 workload according to the hierarchy of ROS2 system callbacks, chains, and executors. The ROS2 system consists of n chains. .
[0084] Callbacks Representation Chain The jth callback, where The callback model is:
[0085]
[0086] in, yes The worst case execution time (WCET) of is a timer callback, it is usually a chain The first callback in T i Release an instance periodically.
[0087] chain Depend on callbacks, where callbacks are executed sequentially; that is, Can be After the execution is completed, the execution begins. The chain model is as follows:
[0088]
[0089] in, yes WCET, by The sum of all callbacks in is obtained, . yes The release cycle of the instance.
[0090] As mentioned earlier, Too The release cycle of the instance. For the critical chain, yes The relative deadline of The expiration time of the instance is determined by The release time of the instance Add to confirm.
[0091] Workload rate: The workload rate represents the workload produced per unit time, and its formula is as follows:
[0092] (1)
[0093] Emergency rate: For critical chain , the emergency rate represents the amount of work that needs to be processed per unit time, and its formula is as follows:
[0094] (2)
[0095] The hybrid scheduling executor system model for ROS2 is as follows:
[0096]
[0097] in, and are the sets of critical chains and common chains respectively, and They are respectively a collection of exclusive threads and shared threads.
[0098] In order to evaluate the overall performance of the ROS2 system, the following parameters are introduced as performance indicators: Real-time Index (RTI):
[0099] The larger the RTI is, the larger the sum of the differences between the response time and the deadline of all critical chain instances in the system is. The real-time performance of the system is inversely proportional to the RTI. The calculation formula is as follows:
[0100]
[0101] in, express The number of instances released, indicating the kth The response time of the instance.
[0102] Fairness Index (FI):
[0103] The larger the FI is, the larger the standard deviation of the waiting time of all instances in the common chain is. The fairness performance of the system is also inversely proportional to the FI.
[0104] The calculation formula is as follows:
[0105]
[0106] in, represents the waiting time of the kth instance, express The average wait time of all normal instances in the chain.
[0107] As can be seen from the above, the exclusive thread only runs the real-time scheduler to schedule the callback instance of the critical chain. If too many CPUs are mapped to the exclusive thread and too few CPUs are mapped to the shared thread, the exclusive thread in the system may be idle most of the time, and the ordinary callback instance chain needs to wait for a long time before being scheduled, which will lead to poor system performance. Therefore, in the present invention, a thread mapping strategy is designed to maximize the system performance (average response time of all chains) under the premise of meeting the real-time constraints. The formula is expressed as follows:
[0108]
[0109] in, express The number of instances of , H(·) is a step function, Meaning: If , 0, the system does not meet the real-time constraints, and returns 1; otherwise, the system meets the real-time constraints and returns 0.
[0110] For Chain , if the actuator ω can be Released instances processed per unit time Units of work, then The average response time reaches a minimum.
[0111] Due to data dependencies between adjacent callbacks, An example can be found in The execution starts after the instance of is completed. Therefore, at any given time, only one callback instance in the chain is executing. If ω can handle one unit of workload for one instance per unit of time, the response time of the instance is minimized.
[0112] Next, we analyze the maximum number of simultaneous chain instances with the minimum response time. Let t be The release time is the shortest, and The execution was completed at the above time.
[0113] (1)
[0114] This means , All instances of a chain are executed sequentially; each instance completes before the next instance is issued. There is no concurrent execution, and at most 1 chain instance exists at any given time.
[0115] (2)
[0116] In the next release cycle to Inside, Maximum release instances, and the completion time of these times must be greater than , therefore, the maximum number of releases is: instances occur simultaneously. In summary, for , there can be at most simultaneous instances.
[0117] Therefore, if ω can be The released instances are processed in unit time workload, then The average response time is minimized.
[0118] For executor ω, if the number of shared threads is not less than , then the average response time of the chain reaches the minimum.
[0119] If ω can be processed per unit time workload, the average response time of the chain in ω is minimized. Because shared threads can execute instances of critical chains and common chains at the same time, when the number of shared threads is not less than When ω, the average response time of the chain in ω is the smallest.
[0120] For the critical chain , To meet the real-time constraint, the executor ω must process no less than workloads.
[0121] Using the method of contradiction, Released at time t , assuming that ω is less than Denote by W, at time Complete an execution instance , , according to the parameter values, there are ,Right now Impossible in time Before the execution is completed, It is impossible to hold, so the assumption is not true. Therefore, to ensure To meet the real-time constraint, for any release instance, ω must process no less than workloads.
[0122] For executor ω, if the number of exclusive threads is not less than , all critical chains satisfy the real-time constraints.
[0123] For any critical chain that satisfies the real-time constraints, there can be at most If ω can handle all critical chains per unit time units of workload, then all critical chains in ω satisfy the real-time constraints.
[0124] Because exclusive threads can only execute instances of critical chains, if the number of exclusive threads is not less than .
[0125] For the actuator ω, if , and the number of threads is constant, the more shared threads there are, the shorter the average response time of all chains.
[0126] Since exclusive threads only execute instances released by critical chains, they switch to the idle state once all critical chains are completed, wasting computing resources even if there are instances released by normal chains waiting to be executed. Since shared threads can execute instances of both critical and normal chains at the same time, they are never idle while instances are waiting to be executed.
[0127] For executor ω, if the number of shared threads is greater than
[0128] All critical chains satisfy real-time constraints, and shared threads run in a real-time scheduler priority mode.
[0129] Since the executor adopts a non-preemptive scheduling mechanism, in the real-time scheduler priority mode, when the shared thread is running, the release instance of the critical chain may be blocked once by the callback instance of the common chain before starting to execute. The workload caused by these callback instances can be bounded as follows: . Consider this workload as part of a critical chain instance if the shared thread of ω can process all critical chains per unit time , units of workload, then all critical chains in ω meet the real-time constraints. Therefore, if the number of shared threads is not less than , then all critical chains satisfy the real-time constraints.
[0130] For the actuator ω, if , then for shared threads, the average response time of all chains running in fair scheduler priority mode is no less than the average response time of all chains running in realtime scheduler priority mode.
[0131] If both the critical chain callback instance and the ordinary chain callback instance are waiting for scheduling, the shared thread will adopt different modes and have different scheduling behaviors, which are analyzed as follows: (a) Real-time scheduler priority: shared threads and exclusive threads compete for the scheduling of critical chain callback instances. Shared threads will schedule ordinary chain callback instances only after all callback instances of the critical chain have been scheduled. It may happen that all shared threads are executing critical chain callback instances, and some idle exclusive threads and some callback instances are waiting for scheduling, resulting in a waste of computing resources. Therefore, the response time of the chain instance increases. (b) Fair scheduler priority: shared threads will only schedule critical chain callback instances after executing all ordinary chain callback instances. Therefore, the problem of wasting computing resources in (a) does not occur. The technical advantages of the present invention are as follows:
[0132] 1. In order to meet the scheduling requirements of different types of chains, the present invention has two built-in schedulers in the hybrid scheduling executor: a real-time scheduler and a fair scheduler. The scheduling strategy adopted by the real-time scheduler is CIL-EDF. The fair scheduler adopts the default scheduling strategy.
[0133] 2. In order to adapt the storage structure of the ready callback set to the architecture of the dual scheduler, the present invention allocates a ready callback set to each of the real-time scheduler and the fair scheduler. The ready callback set of the real-time scheduler is a priority queue. The callback instances in the queue are prioritized according to the deadline of the corresponding chain instance, and the callback instance at the head of the queue has the highest priority. The ready callback set of the fair scheduler consists of four vectors, which store four types of callback instances: timer, subscription, service, and client.
[0134] 3. The registry stores the key type information of all callbacks in the system. When a callback instance is collected to the executor, it will be judged by the key type information of the registry. If it is a callback instance of the critical chain, it will be added to the priority queue. If it is a callback instance of the normal chain, it will be added to the corresponding vector according to the type of the callback instance.
[0135] 4. Threads run exclusively the real-time scheduler. Even in idle time, these threads will not run the fair scheduler to ensure that callback instances of the critical chain can be executed in time to meet the real-time constraints.
[0136] 5. Shared threads can run both real-time schedulers and fair schedulers, so that ready callback instances can be scheduled as early as possible to maximize system performance.
[0137] 6. Shared threads provide two execution modes: (1) Real-time scheduler priority: The thread runs the real-time scheduler first, and only runs the fair scheduler when the priority queue of the real-time scheduler is empty. (2) Fair scheduler priority: The thread runs the fair scheduler first, and only runs the real-time scheduler when the vector set of the fair scheduler is empty.
[0138] Any process or method description in the flowchart of the present invention or described in other ways herein can be understood as a module, segment or part of a code including one or more executable instructions for implementing the steps of a specific logical function or process, which can be implemented in any computer-readable medium for use by an instruction execution system, device or equipment, and the computer-readable medium can be any medium containing storage, communication, propagation or transmission programs for use by execution systems, devices or equipment, including read-only memories, magnetic disks or optical disks, etc.
[0139] In the description of this specification, the description with reference to the terms "embodiment", "example", etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. In addition, those skilled in the art can combine or combine different embodiments or examples described in this specification and the features therein without causing any contradiction.
[0140] Although the above content has shown and described the embodiments of the present invention, it can be understood that the above embodiments are exemplary and cannot be understood as limitations of the present invention. Ordinary technicians in the field can change, modify, replace, modify and other update operations on the above embodiments within the scope of the present invention.
Claims
1. A ROS2 hybrid scheduling executor system, characterized in that: The system includes a registry, two ready callback sets, two schedulers and two thread pools; The registry stores key type information of all callbacks in the system; The two schedulers are respectively a real-time scheduler and a fair scheduler; the real-time scheduler is responsible for scheduling the callback instance of the critical chain; the fair scheduler is responsible for scheduling the callback instance of the common chain; The two thread pools include dedicated threads and shared threads, wherein the dedicated threads exclusively run the real-time scheduler; the shared threads can run both the real-time scheduler and the fair scheduler; the shared threads include two execution modes: (i) real-time scheduler priority: the thread runs the real-time scheduler first, and only when the priority queue of the real-time scheduler is empty, does it run the fair scheduler; (ii) fair scheduler priority: the thread runs the fair scheduler first, and only when the vector set of the fair scheduler is empty, does it run the real-time scheduler.
2. The ROS2 hybrid scheduling executor system according to claim 1, characterized in that: The two ready callback sets are a priority queue and a vector set respectively.
3. The ROS2 hybrid scheduling executor system according to claim 2, characterized in that: The real-time scheduler and the fair scheduler are each assigned a ready callback set; the ready callback set of the real-time scheduler is a priority queue; the callback instances in the queue are prioritized according to the deadline of the corresponding chain instance, and the callback instance at the head of the queue has the highest priority; the ready callback set of the fair scheduler consists of four vectors, which store four types of callback instances: timer, subscription, service, and client.
4. The ROS2 hybrid scheduling executor system according to any one of claims 2-3, characterized in that: The scheduler calls the collect callback instance function before scheduling the callback instance; the lock clt_lock is used to ensure that only one thread collects the callback instance at any time.
5. The ROS2 hybrid scheduling executor system according to claim 4, characterized in that: For the priority queue, to prevent priority inversion between critical chain instances, the scheduler adds the callback instances of the critical chain to the priority queue before scheduling; for the vector set, to ensure fairness between ordinary chains, the scheduler adds the ready callback instances of the ordinary chain to the corresponding vector only when all vectors are empty.
6. The ROS2 hybrid scheduling executor system according to claim 5, characterized in that: The real-time scheduler schedules the callback instance at the head of the priority queue each time; the fair scheduler schedules the first callback instance in the four vectors in the order of timer, subscription, service, and client.
7. The ROS2 hybrid scheduling executor system according to any one of claims 1 to 3, characterized in that: The real-time scheduler execution process is as follows: S101. Check whether the lock clt_lock is acquired; if so, proceed to step S102, if not, return to the initial stage and perform the test again; S102. Call the collection callback instance function; S103. Release the lock clt_lock; S104. Determine whether the priority queue is empty; if so, return failure and end the task; if not, proceed to step S105; S105. Take the callback instance at the head of the queue and pass it to the callback reference cb; S106. Return success and end the task.
8. The ROS2 hybrid scheduling executor system according to claim 3, characterized in that: The execution process of the fair scheduler is as follows: S201. Check whether the lock clt_lock is acquired; if so, proceed to step S202, if not, return to the initial stage and perform the test again; S202. Call the collection callback instance function; S203. Release the lock clt_lock; S204. Determine whether the timer vector is empty; if not, take out the first callback instance from the timer vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the subscription vector is empty, if not, take out the first callback instance from the subscription vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the service vector is empty, if not, take out the first callback instance from the service vector and pass it to the callback reference cb, and then enter step S205; if so, continue to determine whether the client vector is empty, if so, return failure and end the task, if not, take out the first callback instance from the client vector and pass it to the callback reference cb, and then enter step S205; S205; Return success and end the task.
9. The ROS2 hybrid scheduling executor system according to claim 4, characterized in that: The execution flow of the collection callback instance function is as follows: S301. Collect the ready callback instances of the critical chain into the priority queue; S302. Determine whether all vectors in the vector set are empty; if so, proceed to step S303, if not, terminate the task; S303. Collect the ready callback instances of the common chain into the corresponding vector.
10. The ROS2 hybrid scheduling executor system according to claim 9, characterized in that: When the callback instance is collected to the executor, it is judged by the key type information of the registry. If it is a callback instance of the critical chain, it is added to the priority queue, and the queue reorders the callback instances in the queue according to the deadline of the callback instance; if it is a callback instance of the common chain, it is added to the corresponding vector according to the type of the callback instance.