A ros2 multi-threaded executor scheduling method based on deadline driving
By adopting a deadline-driven scheduling method and error correction mechanism, the real-time performance problem of ROS2 multithreaded executors in safety-critical areas is solved, achieving more efficient multithreaded scheduling and improved real-time performance.
Patent Information
- Application Number
- CN202411101999.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-12
- Publication Date
- 2025-12-26
- Estimated Expiration
- 2044-08-12
AI Technical Summary
The existing scheduling methods of the ROS2 multithreaded executor suffer from priority inversion and preemption of low-priority tasks by high-priority tasks in safety-critical domains with high real-time requirements, leading to latency and inconsistency.
A deadline-driven scheduling method is adopted, which uses the deadline of the chain instance as the scheduling basis. The scheduling unit is designed and an error correction mechanism is introduced to ensure the priority ordering and real-time performance of callback instances. Temporary variables and locking mechanisms are used to avoid data races, and the multi-threaded executor architecture is reconstructed.
It improves the real-time performance of ROS2 applications, meets the strict real-time constraints of safety-critical areas, avoids data races and inconsistency issues, and improves the scheduling efficiency of multi-threaded executors.
Smart Images

Figure CN118964031B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the field of robot operating system, and particularly relates to a ROS2 multi-threaded executor scheduling method based on deadline driving. BACKGROUND
[0002] Robot Operating System (ROS) is an open-source middleware framework widely used in the development of robot application programs; ROS improves the development efficiency of robot application programs through the modularity and composability of software, however, in the past decades, ROS has exposed a major defect of lacking real-time performance, which limits its use in safety-critical fields with higher real-time requirements; In this context, the ROS community released the second generation of robot operating system ROS2 in 2017, ROS2 is a reconstruction based on the ROS framework; One of the main goals of the design of ROS2 is to improve the real-time performance of the framework to support the development of robot real-time application programs; ROS2 uses data distribution service (DDS) as the underlying communication framework for end-to-end data exchange, and supports deployment on real-time operating systems; Compared with ROS, although ROS2 can provide better real-time support for robot application programs, it is not fully suitable for robot application programs in hard real-time or safety-critical fields.
[0003] The core component related to the real-time performance of ROS2 is the executor, ROS2 provides two types of executors: one is a single-threaded executor with a single thread built-in the executor, which sequentially executes the ready callbacks in a single thread; the other is a multi-threaded executor with multiple threads built-in the executor, which distributes the ready callbacks to multiple threads for parallel execution. With the increasing complexity of robot application programs, it is often necessary to implement different application programs on a multi-threaded executor to fully utilize the parallel processing capabilities of multi-core platforms; The existing scheduling method of ROS2 multi-threaded executor has the following problems:
[0004] (1) The default scheduling method of ROS2 multi-threaded executor adopts a polling scheduling method, which is a fair-oriented scheduling method, the ready callback set is updated at the polling point, which is prone to priority inversion problems, and is not suitable for applications in safety-critical fields with higher real-time requirements;
[0005] (2) The PiCAS scheduling method of ROS2 multi-threaded executor performs well in real-time on chains with higher priority, but the scheduling of low-priority chains may be disproportionately preempted by high-priority chains, resulting in large delays; Especially when the system load is large, low-priority chains may appear to be "starved".
[0006] Therefore, the application proposes a ROS2 multi-threaded executor scheduling method based on deadline driving to solve the above-mentioned problems. SUMMARY
[0007] In view of the problems existing in the prior art, the application aims to provide a ROS2 multi-threaded executor scheduling method based on deadline driving to solve the problems mentioned in the background.
[0008] To achieve the above-mentioned purpose, the application provides a ROS2 multi-threaded executor scheduling method based on deadline driving, which is applied to a robot operating system, and the method takes the deadline of a chain instance as the basis for scheduling a callback instance of the ROS2 multi-threaded executor, and the specific steps are as follows:
[0009] Step S1: multiple threads of the multi-threaded executor compete to acquire a lock, and the thread that acquires the lock executes the next step, and the thread that does not acquire the lock waits for the release of the lock until the thread holding the lock releases the lock and competes for the lock again;
[0010] Step S2: using a temporary variable t to temporarily store the head element of the priority queue of the multi-threaded executor, the head element is deleted, and the callback instance corresponding to the CallbackExecutable structure pointed to by the temporary variable t is the callback instance with the highest priority at present;
[0011] Step S3: releasing the lock;
[0012] Step S4: executing the function pointed to by the function handle of the CallbackExecutable structure pointed to by the temporary variable t;
[0013] Step S5: querying whether there is a newly released callback instance, and if so, adding the CallbackExecutable structure pointer corresponding to the newly released callback instance to the priority queue;
[0014] Step S6: returning to step S1.
[0015] Further, the method performs priority granularity division on the callback instance at the chain instance level, which is used to ensure that the ROS2 application in the safety-critical field meets the strict real-time constraints.
[0016] Further, the multi-threaded executor has only one lock, which ensures that only one thread holds the lock at the same time, and other threads need to wait for the release of the lock before continuing to execute, thereby avoiding the data competition and inconsistency problems caused by multiple threads accessing the priority queue at the same time.
[0017] Further, in order to associate the deadlines of the callback instances and the chain instances, the scheduling unit is designed as follows: encapsulating the function handle of the callback, the callback type and the corresponding chain attribute into a structure CallbackExecutable as the scheduling unit of the ROS2 multi-threaded executor.
[0018] Further, the relative deadline of the chain and the release period of the chain are defined by the application developer, the relative deadline of the chain is represented as D, and the release period of the chain is represented as T, and the release time of the chain instance represents the time when the chain releases the instance with T as the period.
[0019] Further, the deadline of the chain instance is equal to the release time of the chain instance plus the relative deadline of the chain, and all callback instances of the same chain instance are based on the same deadline.
[0020] Further, the deadlines field of the CallbackExecutable corresponding to all callbacks of the same chain all point to the same vector chain_deadlines_deque, and the size of the chain_deadlines_deque is set to , which stores the deadline queue of different instances of the chain, and the head element of the queue represents the deadline of the chain instance.
[0021] Further, the cur_index field in the CallbackExecutable represents the chain instance number corresponding to the current callback instance.
[0022] Further, after any callback instance is scheduled by the ROS2 multi-threaded executor, the cur_index is updated to , indicating that the next time the callback instance is scheduled belongs to the next chain instance.
[0023] Further, an error correction mechanism is introduced to autonomously and quickly eliminate the priority inversion situation; the error correction mechanism ensures that when the cur_index of two chain instances is the same, the priority of the first released chain instance is greater than that of the second released chain instance.
[0024] Compared with the existing ROS2 multi-threaded executor scheduling method, the ROS2 multi-threaded executor scheduling method based on the deadline driving has the beneficial effects that: the ROS2 multi-threaded executor scheduling method based on the deadline driving divides the priority granularity of the callback instance at the chain instance level, and improves the real-time performance of the ROS2 application program. BRIEF DESCRIPTION OF DRAWINGS
[0025] Fig. 1 A thread workflow diagram in the ROS2 multi-threaded executor according to the application is shown;
[0026] Fig. 2 An instance diagram of a CallbackExecutable structure according to the present application is shown;
[0027] Fig. 3 A ROS2 multi-threaded executor architecture schematic diagram according to the present application is shown. DETAILED DESCRIPTION
[0028] The technical solutions of the present application will be described below in conjunction with the accompanying drawings, apparently, the described embodiments are part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative efforts belong to the scope of protection of the present application.
[0029] In the description of the present application, it should be noted that the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer" and the like indicate the orientation or positional relationship shown in the drawings, and are only for the convenience of describing the present application and simplifying the description, and do not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the terms "first", "second", "third" are only for the purpose of description, and cannot be understood as indicating or implying relative importance.
[0030] In the description of the present application, it should be noted that unless otherwise explicitly specified and limited, the terms "mounting", "connecting", "connecting" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium; it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.
[0031] The following will be described in detail Figs. 1-3 The specific embodiments of the present application will be described in detail. It should be understood that the specific embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application.
[0032] The ROS2 multi-threaded executor scheduling method based on the deadline driving according to the application has the following application concept: a scheduling unit is designed, which can read and update the chain instance attribute corresponding to the callback instance when the ROS2 multi-threaded executor is scheduled; an error correction mechanism is introduced, which can autonomously and quickly eliminate the priority inversion; the ROS2 multi-threaded executor architecture is reconstructed, which can perform real-time priority sorting on the set of ready callback instances and reduce the runtime overhead; the ROS2 multi-threaded executor provides callback instances with priority granularity division at the chain instance level, which can ensure that the ROS2 application in the safety-critical field meets the strict real-time constraints.
[0033] In one embodiment, as shown in FIG. 1, a ROS2 multi-threaded executor scheduling method based on deadline driving takes the deadline of a chain instance as the basis for scheduling callback instances of the ROS2 multi-threaded executor, and the scheduling method specifically implements the following steps: Figs. 1-3
[0034] Step S1: Multiple threads of the multi-threaded executor compete to acquire a lock (the multi-threaded executor has only one lock), and the thread that acquires the lock performs the next step. The threads that do not acquire the lock wait for the release of the lock, and then re-competes for the lock after the thread holding the lock releases the lock.
[0035] The multi-threaded executor has only one lock, which ensures that only one thread holds the lock at the same time, and other threads need to wait for the release of the lock before continuing to execute, thereby avoiding the data competition and inconsistency problems caused by multiple threads accessing the priority queue at the same time.
[0036] Step S2: Use a temporary variable t to temporarily store the head element of the priority queue of the multi-threaded executor, and delete the head element. The callback instance corresponding to the CallbackExecutable structure pointed to by t is the callback instance with the highest priority at present. The head element of the queue represents the deadline of the chain instance.
[0037] Step S3: Release the lock.
[0038] Step S4: Execute the function pointed to by the function handle of the CallbackExecutable structure pointed to by t.
[0039] Step S5: Query whether there is a newly released callback instance, and if so, add the CallbackExecutable structure pointer corresponding to the newly released callback instance to the priority queue.
[0040] Step S6: Return to step S1.
[0041] The specific implementation scheme of the ROS2 multi-threaded executor implementing the scheduling method includes:
[0042] To associate the deadlines of callback instances and chain instances, the design scheduling unit encapsulates the function handle of callback, callback type and corresponding chain attribute into a structure CallbackExecutable.
[0043] The relative deadline of a chain is denoted as D, and the release period of a chain is denoted as T. The release time of a chain instance represents the time when the chain releases the instance with a period of T. The deadline of a chain instance is equal to the release time of the chain instance plus D. All callback instances of the same chain instance are subject to the same deadline. All callbacks of the same chain correspond to the same chain_deadlines_deque vector in the field of deadlines of the CallbackExecutable structure. The size of the chain_deadlines_deque vector is set to , which stores the deadline queues of different instances of the chain. The head element of the queue represents the deadline of the chain instance.
[0044] The cur_index field in the CallbackExecutable structure represents the chain instance number corresponding to the current callback instance. After any callback instance is scheduled by the ROS2 multi-threaded executor, the cur_index is updated to , indicating that the next scheduled instance of the callback belongs to the next chain instance.
[0045] The update rule of the deadline queue in the chain_deadlines_deque vector is as follows:
[0046] (1) If the callback instance is the first callback of the chain instance, the interval between the current time and the next release time of the chain instance is obtained through the timer_until_trigger field of the callback. The interval plus the relative deadline of the chain is the deadline of the next chain instance. The deadline is added to the queue of the chain_deadlines_deque vector.
[0047] (2) If the callback instance is the last callback of the chain instance, the head element of the cur_index queue of the chain_deadlines_deque vector is removed.
[0048] The error correction mechanism ensures that the priority of the chain instance released first is higher than that of the chain instance released later when the cur_index of the two chain instances is the same; a counter is added to the CallbackExecutable structure to represent the number of times the callback corresponding to the CallbackExecutable structure is scheduled, and the priority comparison rule of the callback instance is:
[0049] (1) The chain instance corresponding to the callback instance has different deadlines, and the priority of the chain instance with the smaller deadline is higher;
[0050] (2) The chain instance corresponding to the callback instance has the same deadline, and the priority of the chain instance with the smaller counter is higher.
[0051] The reconstructed ROS2 multithreaded executor architecture includes a priority queue and a hash table, the hash table stores all callback corresponding CallbackExecutable structures in the system, and the mapping from the function handle of the callback to the CallbackExecutable structure corresponding to the callback is realized; the priority queue stores the pointers of the CallbackExecutable structures of the ready callback instances, so as to reduce the runtime overhead, the pointers of the CallbackExecutable structures are sorted according to the priority of the callback instances; the CallbackExecutable structure pointed to by the head pointer of the priority queue is scheduled in a mutually exclusive manner between the threads of the ROS2 multithreaded executor, and then the head element of the priority queue is deleted, and the specific operation is performed according to the function handle of the CallbackExecutable structure; the ROS2 multithreaded executor checks whether there is a newly released callback instance after executing the callback instance each time, and adds the CallbackExecutable structure pointer corresponding to the newly released callback instance to the priority queue.
[0052] According to the ROS2 multithreaded executor scheduling method based on the deadline driving provided by the application, the chain instance takes the deadline as the basis for the priority size, the smaller the deadline of the chain instance is, the higher the priority of the chain instance is; the priority of the callback instance is equal to the priority of the chain instance corresponding to the callback instance; the threads of the ROS2 multithreaded executor access the set of ready callback instances in a mutually exclusive manner, and the thread schedules the callback instance with the highest priority each time.
[0053] The method provided by the application further includes:
[0054] (1) A scheduling unit is designed, which is used for the ROS2 multithreaded executor to read and update the chain instance attribute corresponding to the callback instance during scheduling;
[0055] (2) Introducing an error correction mechanism for autonomously and quickly eliminating the priority inversion situation;
[0056] (3) Reconstructing the ROS2 multithreaded executor architecture for real-time priority sorting of the set of ready callback instances and reducing the runtime overhead.
[0057] Compared with the existing ROS2 multithreaded executor scheduling method, the ROS2 multithreaded executor scheduling method driven by the deadline in the application improves the real-time performance of the ROS2 application program by performing priority granularity division on the callback instance at the chain instance level.
[0058] Any process or method descriptions of the flowchart diagrams or otherwise described herein can be understood as representing code modules, segments, or portions of code which include one or more executable instructions for implementing specific logic functions or other operations as described in the description of the application, and that the modules, segments, or portions of code can be implemented in any computer readable medium for use with an instruction execution system, apparatus, or device, and that the computer readable medium can be any of the media listed above.
[0059] In the description of the present specification, the description referring to the terms "embodiment", "example", and the like means that the specific features, structures, materials, or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present application. In the present specification, the illustrative expressions of the above terms are not necessarily directed to the same embodiment or example. In addition, a person skilled in the art can combine or combine the different embodiments or examples described in the present specification and the features thereof without producing a contradiction.
[0060] Although the above has shown and described the embodiments of the present application, it can be understood that the above embodiments are exemplary and cannot be understood as limiting the present application, and a person skilled in the art can make changes, modifications, replacements, and updates such as updating operations on the above embodiments within the scope of the present application.
Claims
1. A ROS2 multi-threaded executor scheduling method based on deadline-driven, applied to a robot operating system, comprising the steps of: The method takes the deadline of the chain instance as the basis for the ROS2 multithreaded executor to schedule the callback instance, and the specific steps are as follows: Step S1: Multiple threads of the multithreaded executor compete to acquire a lock, and the thread that acquires the lock executes the next step. The thread that does not acquire the lock waits for the release of the lock until the thread holding the lock releases the lock, and then competes for the lock again; Step S2: Use a temporary variable t to temporarily store the head element of the priority queue of the multithreaded executor, delete the head element, and the callback instance corresponding to the CallbackExecutable structure pointed to by the temporary variable t is the callback instance with the highest priority at present; Step S3: Release the lock; Step S4: Execute the function pointed to by the function handle of the CallbackExecutable structure pointed to by the temporary variable t; Step S5: Query whether there is a newly released callback instance, and if so, add the CallbackExecutable structure pointer corresponding to the newly released callback instance to the priority queue; Step S6: Return to step S1; Wherein, the deadlines fields of the CallbackExecutable structures corresponding to all callbacks of the same chain all point to the same chain_deadlines_deque vector; The deadline queue update rule in the chain_deadlines_deque vector is: (1) If the callback instance is the first callback of a chain instance, the interval between the current time and the next chain instance release time is obtained from the timer_until_trigger field of the callback, this interval plus the relative deadline of the chain is the deadline of the next chain instance, this deadline is added to the first queue of the chain_deadlines_deque vector; (2) If the callback instance is not the first callback of a chain instance, the interval between the current time and the next chain instance release time is obtained from the timer_until_trigger field of the callback, this interval plus the relative deadline of the chain is the deadline of the next chain instance, this deadline is added to the last queue of the chain_deadlines_deque vector. (2) If the callback instance is the last callback of the chain instance, remove the head element of the cur_index queue of the chain_deadlines_deque vector; A counter counter is added to the CallbackExecutable structure, indicating the number of times the callback corresponding to the CallbackExecutable structure is scheduled, and the priority comparison rule of the callback instance is: (1) The deadlines of the chain instances corresponding to the callback instances are different, and the deadline is smaller; (2) The deadlines of the chain instances corresponding to the callback instances are the same, and the counter is smaller; The reconstructed ROS2 multi-threaded executor architecture includes a priority queue and a hash table, the hash table stores all callback corresponding CallbackExecutable structures in the system, and the function handle of the callback is mapped to the CallbackExecutable structure corresponding to the callback; the priority queue stores the pointers of the CallbackExecutable structures of the ready callback instances, so as to reduce the runtime overhead, and the pointers of the CallbackExecutable structures are sorted according to the priority of the callback instances; the CallbackExecutable structure pointed to by the head pointer of the priority queue is scheduled between the ROS2 multi-threaded executor threads in a mutual exclusion manner, then the head element of the priority queue is deleted, and the specific operation is performed according to the function handle of the CallbackExecutable structure; after the ROS2 multi-threaded executor executes each callback instance, it checks whether there is a newly released callback instance, and adds the CallbackExecutable structure corresponding to the newly released callback instance to the priority queue; The relative deadline of the chain is represented as D, and the release period of the chain is represented as T. The cur_index field in the CallbackExecutable represents the chain instance number corresponding to the current callback instance.
2. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 1, wherein, The method performs chain instance level priority granularity division on the callback instance, which is used to ensure that the ROS2 application in the safety critical field meets the strict real-time constraints.
3. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 1, wherein, The multi-threaded executor only has one lock, which ensures that only one thread holds the lock at the same time, and other threads need to wait for the lock to be released before continuing to execute, thereby avoiding the data race and inconsistency problems caused by multiple threads accessing the priority queue at the same time.
4. The ROS2 multithreaded executor scheduling method driven based on the deadline time according to claim 3, wherein, In order to associate the deadlines of the callback instances and the chain instances, the scheduling unit is designed as follows: the function handle of the callback, the callback type and the corresponding chain attribute are encapsulated into a structure CallbackExecutable as the scheduling unit of the ROS2 multi-threaded executor.
5. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 4, wherein, The relative deadline of the chain and the release period are defined by the application developer, and the release time of the chain instance represents the time of the instance release time of the chain with T as the period.
6. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 5, wherein, The CallbackExecutable, the deadline of the chain instance is equal to the release time of the chain instance plus the relative deadline of the chain, and all callback instances of the same chain instance are based on the same deadline.
7. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 6, wherein, chain_deadlines_deque is sized to store the deadline queues of different instances of the chain, the head element of the queue representing the deadline of the chain instance.
8. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 4, wherein, When any callback instance is scheduled by the ROS2 multithreading executor, its cur_index is updated to , indicating that the next scheduled instance of this callback belongs to the next chain instance.
9. The deadline-driven ROS2 multithreaded executor scheduling method according to claim 8, wherein, An error correction mechanism is introduced to autonomously and quickly eliminate the priority inversion situation. The error correction mechanism ensures that when the cur_index of two chain instances is the same, the priority of the first released chain instance is greater than that of the second released chain instance.