Control command generation method and device, electronic equipment and storage medium
By introducing a finite state machine into a dual-core operating system, low-latency communication and high data synchronization between the real-time kernel and the regular kernel are achieved, solving the communication latency and synchronization problems when integrating ROS2 and Xenomai, making it suitable for high-precision motion control.
Patent Information
- Application Number
- CN202510911151.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-02
- Publication Date
- 2025-11-07
AI Technical Summary
In existing technologies, the integration of ROS2 and Xenomai suffers from high communication latency, poor data synchronization, and insufficient complexity and compatibility, which cannot meet the real-time requirements of high-precision motion control.
By introducing a finite state machine into a dual-core operating system, the real-time kernel acquires real-time data at a high frequency and stores it in a preset buffer, while the regular kernel acquires and filters the data at a low frequency and then generates control commands, thereby achieving low-latency communication between the real-time kernel and the regular kernel.
It achieves low-latency communication between the real-time kernel and the regular kernel, with good data synchronization, high compatibility, and a good user experience, making it suitable for high-precision motion control.
Smart Images
Figure CN120909812A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application relates to the technical field of automatic control, and particularly relates to a control command generation method and device, electronic equipment and a storage medium. BACKGROUND
[0002] With the wide application of robot technology in the fields of industrial automation, medical robots and service robots, the demand for real-time control systems is increasing. As an open source robot operating system, ROS2 (Robot Operating System 2) has become an industry standard for robot development due to its modular design and DDS (Data Distribution Service) communication framework. However, ROS2 relies on the scheduling mechanism of the Linux kernel and can only provide soft real-time performance. The communication delay and jitter are usually in the order of milliseconds, which cannot meet the hard real-time requirements of high-precision motion control such as multi-axis interpolation and high-speed trajectory tracking.
[0003] To make up for this deficiency, real-time operating systems such as Xenomai and RTEMS (Real Time Executive for Multiprocessor Systems) have been introduced into the field of robot control. Xenomai achieves microsecond-level task scheduling accuracy on Linux through a dual-kernel architecture and is widely used in embedded real-time systems. However, ROS2 and Xenomai still have defects such as high communication delay, poor data synchronization, insufficient complexity and compatibility when integrated. SUMMARY
[0004] Therefore, the embodiments of the present application provide a control command generation method and device, electronic equipment and a storage medium to solve the problem of high communication delay and poor data synchronization between two kernels in a dual-kernel operating system including a real-time kernel and a conventional kernel in the prior art.
[0005] The first aspect of the embodiments of the present application provides a control command generation method, which is used for generating a control command in a dual-kernel operating system including a real-time kernel and a conventional kernel. The method comprises the following steps: In response to receiving a real-time task processing instruction, the real-time kernel initializes a real-time task, and the conventional kernel establishes a communication pipeline with the real-time kernel; In response to determining that a finite state machine in the real-time kernel is in a running state, the real-time kernel acquires real-time data at a first frequency and saves the real-time data to a preset buffer. The real-time data is real-time running data of a controlled object, and the preset buffer is located in a preset path of the communication pipeline. The regular kernel accesses the preset path at a second frequency to obtain real-time data; the second frequency is less than the first frequency. The regular kernel filters the real-time data to obtain target data. The regular kernel generates a control command based on the target data, and sends the control command to the real-time kernel, so that the real-time kernel controls the controlled object based on the control command.
[0006] In a second aspect, the embodiment of the present application provides a control command generation device, the control command being generated in a dual-core operating system, the dual-core operating system comprising a real-time kernel and a regular kernel; the device comprises: A preprocessing module is configured to initialize a real-time task by the real-time kernel and establish a communication pipeline with the real-time kernel in response to receiving a real-time task instruction; An obtaining module is configured to obtain real-time data at a first frequency by the real-time kernel and save the real-time data to a preset buffer in response to determining that a finite state machine in the real-time kernel is in a running state; the real-time data is real-time running data of a controlled object, and the preset buffer is located in a preset path of the communication pipeline; The obtaining module is further configured to access the preset path at a second frequency by the regular kernel to obtain the real-time data; the second frequency is less than the first frequency. A filtering module is configured to filter the real-time data by the regular kernel to obtain target data. A generating module is configured to generate a control command by the regular kernel based on the target data, and send the control command to the real-time kernel, so that the real-time kernel controls the controlled object based on the control command.
[0007] In a third aspect, the embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above method when executing the computer program.
[0008] In a fourth aspect, the embodiment of the present application provides a computer readable storage medium, the computer readable storage medium storing a computer program, and the computer program implements the steps of the above method when executed by a processor.
[0009] Compared with the prior art, the embodiment of the present application has the beneficial effects that: the embodiment of the present application manages the interaction between the real-time kernel and the general kernel in the dual-core operating system through the finite state machine, the real-time kernel acquires real-time data at a higher frequency and stores the real-time data to a preset buffer when the finite state machine is in a running state, the general kernel can acquire real-time data from a preset path at a lower frequency and filter the real-time data, then generates a control command based on the filtered data, and finally sends the control command to the real-time kernel, so that the real-time kernel can control the controlled object based on the control command, realizing low-delay communication between the real-time kernel and the general kernel, and good data synchronization. At the same time, the real-time kernel and the controlled object can work with any communication protocol, as long as the real-time kernel and the general kernel realize information interaction in the above manner, the scheme has low complexity, high compatibility, and good user experience. BRIEF DESCRIPTION OF DRAWINGS
[0010] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.
[0011] Figure 1 is a flowchart of a control command generation method provided by the embodiment of the present application.
[0012] Figure 2 is a flowchart of a method for filtering real-time data to obtain target data provided by the embodiment of the present application.
[0013] Figure 3 is a flowchart of another method for filtering real-time data to obtain target data provided by the embodiment of the present application.
[0014] Figure 4 is a flowchart of a method for the general kernel to generate a control command based on the target data provided by the embodiment of the present application.
[0015] Figure 5 is a flowchart of another control command generation method provided by the embodiment of the present application.
[0016] Figure 6 is a flowchart of another control command generation method provided by the embodiment of the present application.
[0017] Figure 7 is a communication interaction diagram of the real-time kernel and the general kernel provided by the embodiment of the present application.
[0018] Figure 8is a flowchart of another control command generation method provided by an embodiment of the present application.
[0019] Figure 9 is a schematic diagram of a control command generation device provided by an embodiment of the present application.
[0020] Figure 10 is a schematic diagram of an electronic device provided by an embodiment of the present application. DETAILED DESCRIPTION
[0021] In the following description, for the purpose of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
[0022] A control command generation method and device according to an embodiment of the present application will be described in detail below with reference to the accompanying drawings.
[0023] Glossary: ROS2: Second generation Robot Operating System, providing a DDS-based soft real-time communication framework.
[0024] Xenomai: A Linux real-time extension that provides solid real-time capabilities through a dual-kernel architecture.
[0025] XDDP (Cross-Domain Datagram Protocol): Xenomai's cross-domain communication protocol for data exchange between real-time and non-real-time environments.
[0026] RTDM (Real-Time Driver Model): Xenomai's real-time device model that supports real-time network interfaces.
[0027] FSM (Finite State Machine): A finite state machine used to coordinate system state transitions.
[0028] As mentioned above, ROS2 and Xenomai still have the defects of high communication delay, poor data synchronization, insufficient complexity and compatibility, etc. when integrated.
[0029] For example, traditional bridging solutions for ROS2 and Xenomai, such as shared memory solutions or user-mode intermediate state solutions, introduce additional scheduling overhead, and the communication delay is usually more than 50 microseconds, which cannot meet the high-frequency control requirement of 1 millisecond cycle.
[0030] On the other hand, the low-frequency soft real-time loop frequency of ROS2 is usually 10 Hz (Hertz) to 100 Hz, which is significantly different from the high-frequency real-time loop frequency of Xenomai, which is usually 100 Hz to 10000 Hz. Direct integration of the two may cause data to be outdated or lost, affecting control accuracy.
[0031] In another aspect, the solutions in the related art are mostly customized middleware or complex configurations, increasing the development difficulty and being difficult to adapt to diversified hardware platforms.
[0032] In view of this, the embodiments of the present application provide a control command generation method, which manages the interaction between the real-time kernel and the general kernel in the dual-core operating system through a finite state machine. When the finite state machine is in a running state, the real-time kernel acquires real-time data at a higher frequency and stores the real-time data in a preset buffer. The general kernel can acquire real-time data from a preset path at a lower frequency and filter the real-time data. Then, the general kernel generates a control command based on the filtered data. Finally, the control command is sent to the real-time kernel, so that the real-time kernel can control the controlled object based on the control command. This method realizes low-latency communication between the real-time kernel and the general kernel, and has good data synchronization. At the same time, the real-time kernel and the controlled object can work with any communication protocol, as long as the real-time kernel and the general kernel realize information interaction in the above manner. This method has low complexity, high compatibility, and good user experience.
[0033] Figure 1 is a flowchart of a control command generation method provided by the embodiments of the present application. As shown in Figure 1 , the method comprises the following steps: In step S101, in response to receiving a processing real-time task instruction, the real-time kernel initializes a real-time task, and the general kernel establishes a communication pipeline with the real-time kernel.
[0034] In step S102, in response to determining that the finite state machine in the real-time kernel is in a running state, the real-time kernel acquires real-time data at a first frequency and saves the real-time data in a preset buffer.
[0035] The real-time data is real-time running data of the controlled object, and the preset buffer is located in a preset path of the communication pipeline.
[0036] In step S103, the general kernel accesses the preset path at a second frequency to acquire the real-time data.
[0037] The second frequency is less than the first frequency.
[0038] In step S104, the general kernel filters the real-time data to obtain target data.
[0039] In step S105, the general kernel generates a control command based on the target data, and sends the control command to the real-time kernel to make the real-time kernel control the controlled object based on the control command.
[0040] In some embodiments of the present application, the method can be performed by a terminal or a server. The terminal or the server is deployed with a dual-core operating system, and the method can be used to generate a control command. The dual-core operating system includes a real-time kernel and a general kernel. In an example, the real-time kernel in the dual-core operating system can be a Xenomai kernel, and the general kernel can be a ROS2 kernel, a Linux kernel, or other kernels. For the convenience of explanation and description, the following will be described by taking the real-time kernel as a Xenomai kernel and the general kernel as a ROS2 kernel as an example.
[0041] In some embodiments of the present application, after receiving a real-time task instruction, the dual-core operating system can make the real-time kernel initialize the real-time task, and make the general kernel establish a communication pipeline between the real-time kernel and the general kernel. The communication pipeline can be an XDDP communication pipeline.
[0042] An FSM can be deployed in the real-time kernel, and the FSM is used to manage the interaction between the real-time kernel and the general kernel. The states of the FSM can include Idle, Initialising, Run, and Stopping. The real-time kernel can acquire real-time data at a first frequency when it is determined that the FSM is in the Run state, and save the acquired real-time data to a preset buffer. The real-time data is real-time running data of the controlled object, and the preset buffer is located in a preset path of the communication pipeline. In an example, the preset path can be a path / dev / rtp0 in the XDDP, or a path / dev / rtp1 in the XDDP.
[0043] In an example, if the controlled object is a two-axis motor, the real-time data can be motor encoder data representing the real-time positions of the two axes, including the real-time angles and real-time distances of the two axes. In another example, if the controlled object is a robot, the real-time data can be data representing the real-time motion trajectory and real-time posture of the robot. For different controlled objects, the real-time data can also be any other data that needs to be acquired, which is not limited herein.
[0044] The preset buffer in the embodiments of the present application can be a ring buffer with the characteristics of circular coverage, fixed memory, and O(1) (time complexity) access, or other buffers according to actual needs, which is not limited herein.
[0045] In some embodiments of the present application, the conventional kernel can access the preset path at a second frequency to obtain the real-time data. The second frequency is less than the first frequency. In an example, Xenomai can obtain real-time data from the sensor of the controlled object at a frequency of 1 kHz (kilohertz), and ROS2 can obtain target data from the preset path at a frequency of 10 Hz (hertz).
[0046] The conventional kernel can filter the data in the preset buffer to obtain filtered target data. The specific filtering method is described in detail below, and will not be repeated here.
[0047] The conventional kernel can generate a control command based on the filtered target data, and send the control command to the real-time kernel, so that the real-time kernel controls the controlled object based on the control command.
[0048] According to the technical scheme provided by the embodiments of the present application, the interaction between the real-time kernel and the conventional kernel in the dual-core operating system is managed by the finite state machine. When the finite state machine is in the running state, the real-time kernel obtains real-time data at a higher frequency and stores the real-time data in a preset buffer. The conventional kernel can obtain real-time data from the preset path at a lower frequency, filter the real-time data, then generate a control command based on the filtered data, and finally send the control command to the real-time kernel, so that the real-time kernel can control the controlled object based on the control command. This realizes low-latency communication between the real-time kernel and the conventional kernel, and good data synchronization. At the same time, the real-time kernel and the controlled object can work with any communication protocol, as long as the real-time kernel and the conventional kernel can realize information interaction in the above manner. The scheme has low complexity, high compatibility, and good user experience.
[0049] Figure 2 is a flowchart of the method for filtering real-time data to obtain target data provided by the embodiments of the present application. As shown in Figure 2 the method comprises the following steps: In step S201, a data filtering threshold is obtained.
[0050] The data filtering threshold includes at least one of a time threshold and a quantity threshold.
[0051] In step S202, the real-time data is time-filtered based on the data filtering threshold to obtain first target data.
[0052] In step S203, it is determined that the first target data is the target data.
[0053] The first target data is data in the preset buffer with a timestamp later than the time threshold, or data in the preset buffer with a sorting position matching the quantity threshold.
[0054] In some embodiments of the present application, filtering the real-time data can be filtering the old data in the preset buffer and retaining the new data. When filtering, the data filtering threshold can be obtained first, which can be a time threshold or a quantity threshold.
[0055] The real-time data in the preset buffer can be time filtered based on the data filtering threshold to obtain first target data. The first target data can be data in the preset buffer with a timestamp later than the time threshold. For example, if the ROS2 kernel obtains target data at a frequency of 10 Hz, the target data can be set as data collected in the last 1 kHz, so the time threshold can be calculated based on the set frequency value 1 kHz, and then the data in the preset buffer with a timestamp later than the time threshold is determined as the first target data.
[0056] On the other hand, the first target data can also be data in the preset buffer with a sorting position matching the quantity threshold. If the data in the preset buffer is sorted in the order from new to old or from old to new, the first target data can be determined as the data from the latest stored data to the data after the latest stored data with a quantity threshold.
[0057] In some embodiments of the present application, the first target data can be determined as the filtered target data.
[0058] By using the technical solutions provided in the embodiments of the present application, the data in the preset buffer is filtered by the real-time kernel to obtain the latest target data, and then the latest target data is saved to the preset path using the XDDP pipeline for the regular kernel to read, which can provide the latest data for the regular kernel, avoid using outdated data to generate incorrect control commands, and also avoid the delay or data redundancy caused by the mismatch between the data read and write frequencies of the real-time kernel and the regular kernel, while reducing the computational overhead.
[0059] In some embodiments of the present application, filtering the real-time data can also include filtering the obtained new data.
[0060] Figure 3 is another flowchart of a method for filtering real-time data to obtain target data provided by the embodiments of the present application. In the method, Figure 3 Steps S301 to S302 in the embodiments shown in the method are basically the same as steps S201 to S202 in the embodiments shown in the method Figure 2 Steps S201 to S202 in the embodiments shown in the method are basically the same as steps S201 to S202 in the embodiments shown in the method, which will not be described here. As Figure 3 The method further includes the following steps: In step S303, the first target data is filtered to obtain second target data.
[0061] In step S304, the second target data is determined as the target data.
[0062] In some embodiments of the present application, the first target data can be filtered to obtain the second target data, and then the second target data is determined as the target data. The filtering can include smoothing the first target data and / or denoising the first target data.
[0063] In an example, the target data can be smoothed and denoised using a weighted average method. The weighted average calculation formula is, for example, filtered_data = a * new_data + b * last_filtered_data, where filtered_data is the processed target data, new_data is the newly stored data, last_filtered_data is the target data processed last time, and a and b are weight coefficients. The values of a and b can be determined according to actual needs, for example, a can be set to 0.8 and b can be set to 0.2.
[0064] In this way, the data obtained by the regular kernel is more stable, and the influence of data jitter on control accuracy is reduced.
[0065] In some embodiments of the present application, determining that the finite state machine is in the running state can be determining that the current state of the finite state machine is the running state; or determining that the current state of the finite state machine is the idle state, making the finite state machine enter the initializing state, and determining that the finite state machine enters the running state after completing the initialization.
[0066] That is, after the real-time task is initialized, if the state of the FSM is determined to be Run, the subsequent operation of obtaining real-time data can be performed. On the other hand, if the state of the FSM is determined to be Idle, the FSM can first be made to enter the Initialising state, and then the FSM can be made to enter the Run state after the initialization is completed.
[0067] In some embodiments of the present application, the regular kernel can implement message transmission based on a publish-subscribe model.
[0068] Figure 4 is a flowchart of a method for generating a control command based on target data by a regular kernel provided by an embodiment of the present application. As shown in Figure 4 the method includes the following steps: In step S401, a first node in the regular kernel publishes target data to a topic.
[0069] In step S402, the second node in the regular kernel generates control commands based on the target data in the topic.
[0070] The first node is the node that obtains the target data from the preset path, and the second node is the node that has subscribed to the topic.
[0071] In some embodiments of this application, the ROS2 kernel can implement message transmission based on a publish-subscribe model. In this case, the node in the ROS2 kernel obtains target data from a preset path at a second frequency, and this node can be referred to as the first node.
[0072] The first node can publish the acquired target data to a Topic. Other nodes in ROS2 that have subscribed to this Topic can then access the data within it. In one example, the second node can generate control commands based on the target data in this Topic and then transmit these commands to the real-time kernel, allowing the real-time kernel to control the controlled object using these commands. This second node is a node that has subscribed to this Topic.
[0073] In some embodiments of this application, a third node of ROS2 that has subscribed to the Topic can also obtain the target data and perform other operations on the target data. For example, if the third node is a monitoring node, it can monitor the target data; or if the third node is a user interface node, it can transmit the target data to the user interface.
[0074] In some embodiments of this application, the conventional kernel can send a stop signal to the FSM to abort the current real-time task.
[0075] Figure 5 This is a flowchart illustrating another control command generation method provided in an embodiment of this application. Figure 5 Steps S501 to S505 in the illustrated embodiment are Figure 1 Steps S101 to S105 in the illustrated embodiment are basically the same and will not be repeated here. Figure 5 As shown, the method also includes the following steps: In step S506, in response to determining that the task exit condition is met, the regular kernel generates a stop signal and sends the stop signal to the real-time kernel.
[0076] In step S507, in response to receiving a stop signal, the real-time kernel switches the finite state machine to the stop state.
[0077] In step S508, in response to determining that the real-time task cleanup is complete, the real-time kernel switches the finite state machine to the idle state.
[0078] In some embodiments of the present application, the conventional kernel can generate a stop signal when it determines that the task exit condition is met, and send the stop signal to the real-time kernel. Wherein, the task exit condition can be determined by the conventional kernel itself, or a task termination instruction can be sent to the conventional kernel by an external, which is not limited here.
[0079] After receiving the stop signal, the real-time kernel can first switch the state of the FSM to Stopping, then execute the real-time task cleaning task, and switch the state of the FSM to Idle after completing the cleaning, thereby completing the operation of exiting the real-time task.
[0080] In some embodiments of the present application, the FSM can be used to manage the initialization operation and emptying operation of the preset buffer. In some other embodiments of the present application, in addition to being used to manage the initialization operation and emptying operation of the preset buffer, the FSM can also be used to add a timestamp to the data saved to the preset buffer, so as to realize data synchronization in the real-time kernel and the conventional kernel.
[0081] Figure 6 is a flowchart of another method for generating a control command provided by an embodiment of the present application. As shown in Figure 6 , a system for implementing the method can be first built, including building a hardware environment and a software environment. The hardware environment can be an x86 platform of Intel-N97 CPU to provide high-performance computing capability. The software environment can be Ubuntu 22.04, Xenomai 4 (sampling Xenomai 3 features, kernel v5.15), and ROS2 Humble, wherein Xenomai provides a real-time kernel, and ROS2 provides a conventional kernel.
[0082] The real-time task can be run in Xenomai, and the real-time task is coordinated and controlled by the FSM. The data of Xenomai can be saved to the preset path of the XDDP channel, and the filtered target data is obtained from the preset path by the node of ROS2, and the control command is generated based on the target data.
[0083] Figure 7 is a communication interaction diagram of the real-time kernel and the conventional kernel provided by an embodiment of the present application. As shown in Figure 7 , the real-time kernel includes a Xenomai real-time module, the conventional kernel includes a ROS2 node, and in addition, there is a communication pipeline XDDP between the real-time kernel and the conventional kernel, and the XDDP includes a preset path.
[0084] Wherein, the Xenomai real-time module runs a solid real-time task, and is responsible for high-frequency control logic; the ROS2 node runs a soft real-time task, and processes user interaction and data publishing; the XDDP protocol realizes the bidirectional communication between ROS2 and Xenomai, and supports multiple real-time protocol extensions.
[0085] The Xenomai real-time module can write data to the preset path at a high frequency (e.g., 1 kHz), the ROS2 node can read data from the preset path at a low frequency (e.g., 10 Hz), and generate a control command based on the read data, and finally send the control command to the Xenomai real-time task.
[0086] Figure 8 is a flowchart of another control command generation method provided by an embodiment of the present application. As shown in Figure 8 The Xenomai real-time module and the ROS2 node first complete initialization, and then judge the FSM state. If the FSM state is Run, the Xenomai acquires data from the sensor at a frequency of 1 kHz, and saves the acquired data to the preset path of the XDDP. The ROS2 node reads data from the preset path at a frequency of 10 Hz, and the ROS2 node can filter the read data. That is, the Xenomai side can use the wake-up buffer to store high-frequency data, and the ROS2 side can filter the latest data, and the FSM can be used to coordinate the task state.
[0087] Next, the ROS2 node can publish the filtered data to the Topic. The ROS2 node generates a control command based on the data in the Topic, and saves the control command to the preset path. The Xenomai real-time module can acquire the control command from the preset path, and then execute the control command.
[0088] If the Xenomai real-time module receives a stop command, it switches the FSM state to Stopping, and then switches to Idle after the Xenomai completes task cleaning. Otherwise, if no stop command is received, the next operation of acquiring real-time data is continued.
[0089] On the other hand, if the FSM state is not Run, the Xenomai real-time module and the ROS2 do not interact until the FSM state is switched to Run.
[0090] That is, in the task initialization phase, the Xenomai can initialize the real-time task, the ROS2 starts the node, and the XDDP communication pipeline is recommended.
[0091] In the state detection and switching phase, the current state can be detected by the FSM. If it is Idle, it enters Initialising, and switches to Run after completing hardware initialization.
[0092] After determining that the FSM enters the Run state, real-time data acquisition and control can be performed. In the real-time data acquisition and control phase, Xenomai acquires sensor data at a frequency of 1 kHz, sends the sensor data to ROS2 through XDDP, and ROS2 generates control commands at a frequency of 10 Hz and feeds back to Xenomai. Among them, ROS2 filters the sensor data to obtain the latest data, and Xenomai stores the sensor data in a wake-up buffer to ensure data continuity.
[0093] If a stop signal is received, the FSM switches from the Run state to the Stopping state, and returns to the Idle state after completing task cleaning.
[0094] By establishing an efficient and low-latency bidirectional communication interface between ROS2 and Xenomai, the technical solution provided by the embodiment of the application realizes seamless integration of soft real-time and hard real-time environments. The system runs on an Intel-N97 x86 platform, uses the XDDP protocol to realize data exchange, and supports the adaptation of multiple real-time communication protocols. In combination with data filtering and state machine coordination, the system realizes a communication overhead of less than 15 microseconds and a sampling jitter of less than 10 microseconds within a 1-millisecond cycle time, and is suitable for high-precision motion control applications.
[0095] The technical solution provided by the embodiment of the application can provide ultra-low latency and high real-time performance for the interaction between the real-time kernel and the general kernel, improve the data synchronization of the two, and effectively solve the problem of outdated data caused by frequency difference through the latest data filtering on the ROS2 side and the ring buffer design on the Xenomai side, thereby ensuring control accuracy.
[0096] Meanwhile, the method is based on the open-source XDDP protocol, reduces the need for customized development, supports the Intel-N97 x86 platform, and is easy to extend to other hardware architectures. The implementation of the method does not depend on a specific real-time communication protocol, can adapt to multiple industrial standards such as EtherCAT and CANopen, has strong flexibility in application scenarios, and can meet the high standard requirements of industrial real-time control through modular design.
[0097] All the optional technical solutions described above can be combined to form optional embodiments of the application, which will not be described one by one here.
[0098] The following is an apparatus embodiment of the application, which can be used to execute the method embodiments of the application. For details not disclosed in the apparatus embodiments of the application, please refer to the method embodiments of the application.
[0099] Figure 9 is a schematic diagram of a control command generation device provided by an embodiment of the application. As shown in Figure 9 The device comprises: The preprocessing module 901 is configured to, in response to receiving a real-time task processing instruction, initialize the real-time task in the real-time kernel and establish a communication channel between the regular kernel and the real-time kernel.
[0100] The acquisition module 902 is configured to, in response to determining that the finite state machine in the real-time kernel is in a running state, acquire real-time data at a first frequency and save the real-time data to a preset buffer; the real-time data is the real-time running data of the controlled object, and the preset buffer is located at a preset path of the communication pipe.
[0101] The acquisition module 902 is also configured to access a preset path at a second frequency by the regular kernel to acquire real-time data; the second frequency is less than the first frequency.
[0102] The filtering module 903 is configured to filter real-time data using the regular kernel to obtain the target data.
[0103] The generation module 904 is configured to generate control commands based on target data by the regular kernel and send the control commands to the real-time kernel so that the real-time kernel can control the controlled object based on the control commands.
[0104] According to the technical solution provided in this application, a finite state machine is used to manage the interaction between the real-time kernel and the conventional kernel in a dual-core operating system. When the finite state machine is running, the real-time kernel acquires real-time data at a high frequency and stores the real-time data in a preset buffer. The conventional kernel can acquire real-time data from a preset path at a lower frequency, filter the real-time data, generate control commands based on the filtered data, and finally send the control commands to the real-time kernel so that the real-time kernel can control the controlled object based on the control commands. This achieves low-latency communication between the real-time kernel and the conventional kernel with good data synchronization. Furthermore, the real-time kernel and the controlled object can operate using any communication protocol, as long as the real-time kernel and the conventional kernel achieve information interaction in the above manner. The solution has low complexity, high compatibility, and a good user experience.
[0105] In some implementations, filtering real-time data to obtain target data includes: obtaining a data filtering threshold; the data filtering threshold includes at least one of a time threshold and a quantity threshold; performing time filtering on the real-time data based on the data filtering threshold to obtain first target data; and determining the first target data as target data; wherein the first target data is data in a preset buffer whose timestamp is later than the time threshold, or data in a preset buffer whose sorting position matches the quantity threshold.
[0106] In some implementations, filtering real-time data to obtain target data further includes: filtering the first target data to obtain second target data; and determining the second target data as the target data.
[0107] In some embodiments, determining that the finite state machine is in the running state comprises: determining that the current state of the finite state machine is the running state; or determining that the current state of the finite state machine is the idle state, making the finite state machine enter the initialization state, and determining that the finite state machine enters the running state after completing the initialization.
[0108] In some embodiments, the regular kernel implements message transmission based on a publish-subscribe model; and the regular kernel generates a control command based on target data, comprising: a first node in the regular kernel publishes the target data to a topic; and a second node in the regular kernel generates the control command based on the target data in the topic; wherein the first node is a node that acquires the target data from a preset path, and the second node is a node that subscribes to the topic.
[0109] In some embodiments, the method further comprises: in response to determining that the task exit condition is met, the regular kernel generates a stop signal and sends the stop signal to the real-time kernel; in response to receiving the stop signal, the real-time kernel switches the finite state machine to the stop state; and in response to determining that the real-time task cleaning is completed, the real-time kernel switches the finite state machine to the idle state.
[0110] In some embodiments, the finite state machine manages the initialization and emptying operation of the preset buffer; or the finite state machine manages the initialization and emptying operation of the preset buffer and adds a time stamp to the data saved to the preset buffer.
[0111] It should be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and inherent logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.
[0112] Figure 10 is a schematic diagram of an electronic device provided by an embodiment of the present application. As shown in Figure 10 The electronic device 10 of this embodiment includes a processor 1001, a memory 1002, and a computer program 1003 stored in the memory 1002 and executable on the processor 1001. The processor 1001 implements the steps in each of the above method embodiments when executing the computer program 1003. Alternatively, the processor 1001 implements the functions of each module / unit in each of the above device embodiments when executing the computer program 1003.
[0113] The electronic device 10 can be a desktop computer, a notebook computer, a palm computer, a cloud server, and the like. The electronic device 10 can include but is not limited to the processor 1001 and the memory 1002. Those skilled in the art can understand that Figure 10 The electronic device 10 is merely an example and does not constitute a limitation on the electronic device 10, and can include more or fewer components or different components than those shown.
[0114] The processor 1001 can be a central processing unit (CPU), or can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gates or transistor logic, discrete hardware components, etc.
[0115] The memory 1002 can be an internal storage unit of the electronic device 10, for example, a hard disk or a memory of the electronic device 10. The memory 1002 can also be an external storage device of the electronic device 10, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the electronic device 10. The memory 1002 can also include both the internal storage unit and the external storage device of the electronic device 10. The memory 1002 is used to store computer programs and other programs and data required by the electronic device.
[0116] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above division of functional units and modules is taken as an example, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit or module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or in the form of a software functional unit.
[0117] The integrated modules / units, if implemented in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program can be executed by a processor to implement the steps of the above-mentioned various method embodiments. The computer program can include computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), electric carrier wave signal, telecommunication signal, and software distribution medium, etc.
[0118] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions recorded in the foregoing embodiments, or make equivalent replacements for part of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.
Claims
1. A control command generation method characterized by, The method is used for generating a control command in a dual-core operating system including a real-time kernel and a general kernel; The method comprises: In response to receiving a processing real-time task instruction, the real-time kernel initializes the real-time task, and the general kernel establishes a communication pipeline with the real-time kernel; In response to determining that a finite state machine in the real-time kernel is in a running state, the real-time kernel acquires real-time data at a first frequency and saves the real-time data to a preset buffer; the real-time data is real-time running data of a controlled object, and the preset buffer is located in a preset path of the communication pipeline; The general kernel accesses the preset path at a second frequency to acquire the real-time data; the second frequency is less than the first frequency; The general kernel filters the real-time data to obtain target data; The general kernel generates a control command based on the target data and sends the control command to the real-time kernel, so that the real-time kernel controls the controlled object based on the control command.
2. The method of claim 1, wherein, Filtering the real-time data to obtain target data comprises: Obtaining a data filtering threshold; the data filtering threshold comprises at least one of a time threshold and a quantity threshold; Time filtering the real-time data based on the data filtering threshold to obtain first target data; Determining that the first target data is the target data; Wherein, the first target data is data in the preset buffer with a time stamp later than the time threshold, or data in the preset buffer with a sorting position matching the quantity threshold.
3. The method of claim 2, wherein, Filtering the real-time data to obtain target data further comprises: Filtering the first target data to obtain second target data; Determining that the second target data is the target data.
4. The method of claim 1, wherein, Determining that the finite state machine is in a running state comprises: Determining that the current state of the finite state machine is a running state; or Determining that the current state of the finite state machine is an idle state, making the finite state machine enter an initialization state, and determining that the finite state machine enters a running state after completing initialization.
5. The method of claim 1, wherein, The general kernel implements message transmission based on a publish-subscribe model; The general kernel generates a control command based on the target data, comprising: A first node in the general kernel publishes the target data to a topic; A second node in the general kernel generates the control command based on the target data in the topic; Wherein, the first node is a node that acquires the target data from the preset path, and the second node is a node that subscribes to the topic.
6. The method of claim 1, wherein, The method further comprises: In response to determining that a task exit condition is met, the general kernel generates a stop signal and sends the stop signal to the real-time kernel; In response to receiving the stop signal, the real-time kernel switches the finite state machine to a stop state; In response to determining that real-time task cleaning is completed, the real-time kernel switches the finite state machine to an idle state.
7. The method according to any one of claims 1 to 6, characterized in that, The finite state machine manages initialization and emptying operations of the preset buffer; or The finite state machine manages initialization and emptying operations of the preset buffer, and adds a time stamp to data saved to the preset buffer.
8. A control command generation device characterized by comprising: The control command is a control command generated in a dual-core operating system including a real-time kernel and a regular kernel. The device comprises: a preprocessing module configured to, in response to receiving a processing real-time task instruction, initialize the real-time task by the real-time kernel and establish a communication pipeline with the real-time kernel by the regular kernel; an acquisition module configured to, in response to determining that a finite state machine in the real-time kernel is in a running state, acquire real-time data at a first frequency by the real-time kernel and save the real-time data to a preset buffer; the real-time data is real-time running data of a controlled object, and the preset buffer is located in a preset path of the communication pipeline; the acquisition module is further configured to access the preset path at a second frequency by the regular kernel to acquire the real-time data; the second frequency is less than the first frequency; a filtering module configured to filter the real-time data by the regular kernel to obtain target data; a generation module configured to generate a control command based on the target data by the regular kernel and send the control command to the real-time kernel, so that the real-time kernel controls the controlled object based on the control command.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 7.
10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 7.