Dispensing equipment data management method, management device and electronic equipment

Abstract

The application relates to the technical field of automatic control, and provides a dispensing equipment data management method, a management device and electronic equipment. The method sets a real-time kernel and a general kernel in a processor, peripheral device data of a dispensing equipment is saved in a preset resource space of a Zenoh protocol communication layer, the real-time kernel acquires image data from the preset resource space by using a shared memory mechanism, acquires valve control data and distance data, generates a real-time task based on the acquired data, the general kernel acquires weight data from the preset resource space, generates a non-real-time task based on the acquired data, and finally executes the generated real-time task and non-real-time task, so that the Zenoh protocol is used to realize unified integration of peripheral device data of the dispensing equipment, the real-time kernel is used to improve data processing efficiency, the general kernel is used to process non-real-time tasks while avoiding task competition, and dispensing equipment data management efficiency is improved.

Description

Data management methods, management devices and electronic equipment for dispensing equipment Technical Field

[0001] This application relates to the field of automatic control technology, and in particular to a data management method, management device and electronic equipment for dispensing equipment. Background Technology

[0002] Dispensing equipment is widely used in fields such as electronics manufacturing, semiconductor packaging, and medical device assembly. It needs to integrate various peripherals (such as dispensing valves, sensors, and cameras) to achieve high-precision dispensing.

[0003] However, the integration efficiency of peripheral data of dispensing equipment in related technologies is low, and there are problems such as high data integration complexity and insufficient real-time performance. Summary of the Invention

[0004] In view of this, embodiments of this application provide a data management method, management device, and electronic device for dispensing equipment to solve the problem of low integration efficiency of peripheral data of dispensing equipment in the prior art.

[0005] A first aspect of the embodiments of this application provides a data management method for a dispensing device, the method being executed by a processor, the processor including at least a real-time kernel and a conventional kernel;

[0006] The method includes:

[0007] The real-time kernel uses a shared memory mechanism to obtain the first peripheral data subscribed to from the preset resource space. The first peripheral data includes at least the image data of the dispensing device.

[0008] The real-time kernel obtains subscribed second peripheral data from the first topic of the preset resource space. The second peripheral data includes at least valve control data and distance data of the dispensing device. The first topic includes at least the valve control data topic and the distance data topic.

[0009] The regular kernel obtains the subscribed third peripheral data from the second topic in the preset resource space. The third peripheral data includes at least the weight data of the dispensing device, and the second topic includes at least the weight data topic.

[0010] The real-time kernel generates real-time tasks based on first peripheral data and second peripheral data. The real-time tasks include at least one of dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks.

[0011] The regular kernel generates non-real-time tasks based on data from a third peripheral device. These non-real-time tasks include at least the glue weighing task.

[0012] Execute real-time and non-real-time tasks;

[0013] The preset resource space is the storage space in the Zenoh protocol communication layer.

[0014] A second aspect of the present application provides a dispensing equipment data management device, the device including a processor, the processor including at least a real-time kernel and a conventional kernel;

[0015] The real-time kernel is configured to use a shared memory mechanism to obtain subscribed first peripheral data from a preset resource space. The first peripheral data includes at least the image data of the dispensing device.

[0016] The real-time kernel is also configured to obtain subscribed second peripheral data from a first topic in a preset resource space. The second peripheral data includes at least valve control data and distance data of the dispensing device, and the first topic includes at least a valve control data topic and a distance data topic.

[0017] The regular kernel is configured to obtain subscribed third peripheral data from a second topic in a preset resource space. The third peripheral data includes at least the weight data of the dispensing device, and the second topic includes at least the weight data topic.

[0018] The real-time kernel is also configured to generate real-time tasks based on first peripheral data and second peripheral data. The real-time tasks include at least one of dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks.

[0019] The regular kernel is also configured to generate non-real-time tasks based on third-party peripheral data, including at least the glue weighing task.

[0020] The real-time kernel and the regular kernel are configured to perform real-time tasks and non-real-time tasks;

[0021] The preset resource space is the storage space in the Zenoh protocol communication layer.

[0022] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0023] The beneficial effects of this application embodiment compared with the prior art are as follows: This application embodiment sets up a real-time kernel and a conventional kernel in the processor. The peripheral data of the dispensing device is stored in the preset resource space of the Zenoh protocol communication layer. The real-time kernel uses a shared memory mechanism to obtain image data, valve control data and distance data from the preset resource space, and then generates real-time tasks based on the obtained data. The conventional kernel obtains weight data from the preset resource space and then generates non-real-time tasks based on the obtained data. Finally, the generated real-time and non-real-time tasks are executed. Thus, the Zenoh protocol is used to realize the unified integration of peripheral data of the dispensing device. At the same time, the real-time kernel improves the data processing efficiency, and the conventional kernel avoids task contention while handling non-real-time tasks, thereby improving the data management efficiency of the dispensing device. Attached Figure Description

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

[0025] Figure 1 is a flowchart illustrating a data management method for dispensing equipment provided in an embodiment of this application.

[0026] Figure 2 is a flowchart illustrating the method for determining first peripheral data provided in an embodiment of this application.

[0027] Figure 3 is a flowchart illustrating the method for determining the second peripheral data and the third peripheral data provided in an embodiment of this application.

[0028] Figure 4 is a flowchart illustrating the method for generating dynamic dispensing tasks based on first peripheral data and second peripheral data provided in this application embodiment.

[0029] Figure 5 is a flowchart illustrating the method for generating aerial photography tasks based on first peripheral data and second peripheral data provided in this application embodiment.

[0030] Figure 6 is a flowchart illustrating the method for generating dynamic ranging tasks based on first peripheral data and second peripheral data in a real-time kernel according to an embodiment of this application.

[0031] Figure 7 is a flowchart illustrating the method for generating glue weighing tasks based on third peripheral data provided in this application embodiment.

[0032] Figure 8 is a system architecture diagram for implementing the dispensing equipment data management method provided in the embodiments of this application.

[0033] Figure 9 is a data interaction diagram of the dispensing equipment data management method provided in the embodiments of this application.

[0034] Figure 10 is a schematic diagram of the working process of the dispensing valve adapter.

[0035] Figure 11 is a schematic diagram of the working process of the infrared rangefinder adapter.

[0036] Figure 12 is a schematic diagram of the CCD camera adapter's workflow.

[0037] Figure 13 is a schematic diagram of the working process of the glue weighing instrument adapter.

[0038] Figure 14 is a flowchart illustrating the process of running a dynamic dispensing task in a real-time kernel.

[0039] Figure 15 is a flowchart illustrating the real-time kernel operation of the aerial photography mission.

[0040] Figure 16 is a flowchart illustrating the process of running a dynamic ranging task in a real-time kernel.

[0041] Figure 17 is a flowchart illustrating the process of running a weighing task in the regular kernel.

[0042] Figure 18 is a schematic diagram of a dispensing equipment data management device provided in an embodiment of this application.

[0043] Figure 19 is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0044] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0045] A data management method and apparatus for dispensing equipment according to embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0046] As mentioned above, the integration efficiency of peripheral data of dispensing equipment in related technologies is low, and there are problems such as high data integration complexity and insufficient real-time performance.

[0047] In related technologies, dispensing valve control, rangefinders, and weighing instruments typically employ communication protocols such as RS232, RS422, and RS485. These protocols are based on serial communication with baud rates ranging from 9600 to 2Mbps, suitable for low-speed control and sensor data acquisition. CCD (Charge Coupled Device) cameras, on the other hand, usually use the GigE Vision communication protocol. This protocol, based on Gigabit Ethernet, supports high-bandwidth image transmission and is commonly used for visual guidance and defect detection. Furthermore, other peripheral devices in dispensing equipment may use communication protocols such as CAN (Controller Area Network), Modbus, and EtherCAT; some devices may use proprietary protocols.

[0048] In related technologies, when integrating data from various peripheral devices, dedicated drivers are typically developed for each peripheral device, and the data is managed by the operating system. For example, RS232 uses the POSIX serial port API (Application Programming Interface), and GigE uses the GVSP (GigE Vision Streaming Protocol) protocol stack, such as the open-source project Aravis.

[0049] Alternatively, middleware such as MQTT, DDS, or OPC UA can be used to achieve peripheral data interaction. MQTT is commonly used for low-frequency data (such as weighing), while DDS is used for high-bandwidth data (such as images). In traditional industrial scenarios, peripheral data can also be integrated through a PLC (Programmable Logic Controller) via a bus (such as Profibus) to control the dispensing process.

[0050] Furthermore, when processing peripheral data, some data may need to be processed as real-time tasks. Related technologies include setting up a real-time operating system, such as VxWorks, FreeRTOS, or RTEMS, for embedded platforms to handle high-frequency tasks. Alternatively, real-time patches, such as PREEMPT_RT, can be added to the Linux operating system for x86 platforms to support soft real-time tasks. Other solutions employ dedicated hardware such as FPGAs (Field Programmable Gate Arrays) or DSPs (Digital Signal Processing) for ultra-low latency tasks.

[0051] The above-mentioned method of integrating peripheral data has the following technical problems:

[0052] 1) Difficulty in managing heterogeneous protocols: RS232, RS422, RS485, and GigE use different protocol stacks, requiring separate development of drivers and parsing logic. For example, RS232's Modbus requires dedicated parsing, and GigE's GVSP requires TCP (Transmission Control Protocol) / UDP (User Datagram Protocol) processing, increasing development and maintenance costs.

[0053] 2) Lack of a unified interface: Existing middleware is usually optimized for specific scenarios, making it difficult to manage high-bandwidth and low-frequency data in a unified manner. For example, the middleware MQTT (Message Queuing Telemetry Transport) is suitable for low-frequency deployments, while the middleware DDS (Data Distribution Service) is suitable for high bandwidth, but the two are difficult to coordinate.

[0054] 3) Redundant data copying: Traditional communication methods such as sockets and MQTT involve multiple copies during data transmission, which increases latency and is not suitable for high-frequency tasks.

[0055] 4) Insufficient real-time performance: On the one hand, Linux PREEMPT_RT provides soft real-time performance with a scheduling jitter of approximately 50-100μs, which is insufficient for high-frequency tasks. For example, dynamic dispensing requires a jitter of less than 10μs (microseconds) to ensure an accuracy of less than 0.1mm (millimeters). On the other hand, existing systems struggle to effectively isolate real-time and non-real-time tasks. For instance, in a Linux environment, low-frequency weighing tasks may interfere with high-frequency aerial photography tasks, increasing scheduling overhead.

[0056] 5) High-bandwidth data processing efficiency is low: On the one hand, GigE camera images require multiple copies for transmission via TCP / UDP, resulting in a delay of approximately 50-100 μs (microseconds). This high image transmission overhead may affect the real-time performance of aerial photography. On the other hand, image processing in CCD aerial photography under Linux is affected by CPU (Central Processing Unit) contention, potentially leading to excessive latency.

[0057] 6) Limited dynamic adjustment capability: Currently, most peripheral data is processed by the Linux kernel, which has a large latency and is difficult to adjust dynamically; at the same time, there are also shortcomings in noise processing of the data.

[0058] 7) Poor scalability and maintainability: including complex adaptation to new peripheral devices, cumbersome middleware configuration, and limited monitoring capabilities.

[0059] 8) Balancing cost and performance is difficult: Using dedicated hardware is costly, and some dedicated hardware is power-intensive and not suitable for long-term operation. On the other hand, most existing solutions run on embedded platforms, and the multi-core performance of traditional processors is not effectively utilized.

[0060] In view of this, this application provides a data management method for dispensing equipment. By setting a real-time kernel and a conventional kernel in the processor, the peripheral data of the dispensing equipment is stored in a preset resource space of the Zenoh protocol communication layer. The real-time kernel uses a shared memory mechanism to obtain image data, valve control data and distance data from the preset resource space, and then generates real-time tasks based on the obtained data. The conventional kernel obtains weight data from the preset resource space and then generates non-real-time tasks based on the obtained data. Finally, the generated real-time and non-real-time tasks are executed. Thus, the Zenoh protocol is used to achieve unified integration of peripheral data of the dispensing equipment. At the same time, the real-time kernel improves data processing efficiency, and the conventional kernel avoids task contention while handling non-real-time tasks, thereby improving the data management efficiency of the dispensing equipment.

[0061] Figure 1 is a flowchart illustrating a data management method for a dispensing equipment according to an embodiment of this application. As shown in Figure 1, the method includes the following steps:

[0062] In step S101, the real-time kernel uses a shared memory mechanism to obtain the subscribed first peripheral data from the preset resource space.

[0063] The first peripheral data includes at least the image data of the dispensing device.

[0064] In step S102, the real-time kernel obtains the subscribed second peripheral data from the first topic in the preset resource space.

[0065] The second peripheral data includes at least valve control data and distance data of the dispensing equipment, and the first topic includes at least valve control data topic and distance data topic.

[0066] In step S103, the regular kernel obtains the subscribed third peripheral data from the second topic of the preset resource space.

[0067] The third peripheral data includes at least the weight data of the dispensing equipment, and the second subject includes at least the weight data subject.

[0068] In step S104, the real-time kernel generates a real-time task based on the first peripheral data and the second peripheral data.

[0069] Among them, real-time tasks include at least one of dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks.

[0070] In step S105, the regular kernel generates a non-real-time task based on data from the third peripheral device.

[0071] Among them, non-real-time tasks include at least the glue weighing task.

[0072] In step S106, real-time tasks and non-real-time tasks are executed.

[0073] In some embodiments of this application, the method can be executed by a processor. The processor can be a multi-core processor, which includes at least a real-time kernel and a regular kernel. For example, if the processor is an 8-core x86 processor, cores 0-3 can be regular kernels, such as the Linux kernel, and cores 4-6 can be real-time kernels.

[0074] In some embodiments of this application, the real-time kernel may be, for example, the Xenomai kernel.

[0075] In some embodiments of this application, the real-time kernel may employ a shared memory mechanism to obtain subscribed first peripheral data from a preset resource space. This first peripheral data includes at least image data from the dispensing device.

[0076] The default resource space can be the storage space in the Zenoh protocol communication layer. A portion of this storage space can be designated as shared memory, and the real-time kernel can subscribe to the first peripheral data within this shared memory. For example, the real-time kernel can subscribe to image data in this shared memory space, and when image data is published, the real-time kernel can retrieve the published data via shared memory. In one example, the default resource space could be a namespace.

[0077] On the other hand, the real-time kernel can also obtain subscribed second peripheral data from the first topic of the preset resource space. The second peripheral data includes at least valve control data and distance data of the dispensing device, and the first topic includes at least the valve control data topic and the distance data topic.

[0078] In other words, valve control data and distance data can also be stored in the storage space of the Zenoh protocol communication layer and published to their respective topics through mechanisms such as Pub-Sub (publish-subscribe). For example, valve control data can be published to the valve control data topic, and distance data to the distance data topic. The real-time kernel subscribes to these topics and retrieves the corresponding data after the data in each topic has been published. For example, the real-time kernel can retrieve valve control data from the valve control data topic and distance data from the distance data topic.

[0079] In some embodiments of this application, the conventional kernel can obtain subscribed third peripheral data from the second topic of the preset resource space. The third peripheral data includes at least the weight data of the dispensing device, and the second topic includes at least the weight data topic.

[0080] In other words, weight data can also be stored in the Zenoh protocol communication layer and published to the corresponding topic via mechanisms such as Pub-Sub. The real-time kernel subscribes to the topic and retrieves the corresponding data after the topic's data is published. For example, the real-time kernel can retrieve weight data from the weight data topic.

[0081] The real-time kernel can generate real-time tasks based on first and second peripheral data, which may include at least one of dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks. The regular kernel can generate non-real-time tasks based on third peripheral data, which may include at least one glue weighing task.

[0082] Both the real-time kernel and the regular kernel can execute the generated tasks. In one example, the real-time kernel and the regular kernel can send the generated tasks to the corresponding peripheral devices to control their operation. In another example, the real-time kernel and the regular kernel can also execute the generated tasks themselves.

[0083] According to the technical solution provided in the embodiments of this application, by setting a real-time kernel and a conventional kernel in the processor, the peripheral data of the dispensing device is stored in the preset resource space of the Zenoh protocol communication layer. The real-time kernel uses a shared memory mechanism to obtain image data, valve control data and distance data from the preset resource space, and then generates real-time tasks based on the obtained data. The conventional kernel obtains weight data from the preset resource space and then generates non-real-time tasks based on the obtained data. Finally, the generated real-time and non-real-time tasks are executed. Thus, the Zenoh protocol is used to realize the unified integration of peripheral data of the dispensing device. At the same time, the real-time kernel improves the data processing efficiency, and the conventional kernel avoids task contention while processing non-real-time tasks, thereby improving the data management efficiency of the dispensing device.

[0084] In some embodiments of this application, the peripheral device transmits its collected real-time data to the gateway device according to different communication protocols, including RS232, RS422, RS485, GigE, etc. The processor can obtain the data transmitted by the peripheral device from the gateway device through the Zenoh protocol.

[0085] Figure 2 is a flowchart illustrating the method for determining first peripheral data provided in an embodiment of this application. As shown in Figure 2, the method includes the following steps:

[0086] In step S201, the raw image data of the dispensing equipment is acquired.

[0087] In step S202, the original image data is parsed using a preset image data adapter to obtain the first peripheral data.

[0088] In step S203, the first peripheral data is saved to the image data resource space in the preset resource space, and the first peripheral data is published to the image data topic.

[0089] In some embodiments of this application, the Zenoh protocol can determine the first peripheral data by acquiring raw image data from the dispensing device from the gateway device. This raw image data can be real-time image data transmitted from a CCD industrial camera to the gateway device via the GigE communication protocol. In some embodiments, the Jumbo Frame technology and ROI (Region of Interest) cropping can also be combined to transmit real-time image data, further reducing the network overhead of image transmission and processing.

[0090] In some embodiments of this application, the Zenoh protocol can use a preset image data adapter to parse the raw image data to obtain first peripheral data. Then, the first peripheral data is saved to the image data resource space in a preset resource space and published to the image data topic.

[0091] Zenoh-pico technology can be used to develop different adapters for various peripheral devices that transmit data using different communication protocols, thus simplifying the communication protocol parsing process. For example, Zenoh-pico technology can be used to configure a GigE TCP / IP plugin for an industrial CCD camera, and then this plugin can be used to parse and acquire image data.

[0092] In some embodiments of this application, the Zenoh protocol can save the parsed image data to an image data resource space within a preset resource space. In one example, the Zenoh protocol can abstract the image data into a resource namespace / glue / camera / image.

[0093] Figure 3 is a flowchart illustrating the method for determining second peripheral data and third peripheral data provided in an embodiment of this application. As shown in Figure 3, the method includes the following steps:

[0094] In step S301, valve control data, distance data, and weight data of the dispensing equipment are acquired.

[0095] In step S302, the valve control data and distance data are parsed using a preset serial communication data adapter to obtain the second peripheral data, and the weight data is parsed using the preset serial communication data adapter to obtain the third peripheral data.

[0096] The type of serial communication data adapter must match the communication protocol of the peripheral device corresponding to the parsed data.

[0097] In step S303, the second peripheral data is saved to the valve control data resource space and distance data resource space in the preset resource space, the parsed valve control data is published to the valve control data topic, and the parsed distance data is published to the distance data topic.

[0098] In step S304, the third peripheral data is saved to the weight data resource space in the preset resource space, and the parsed weight data is published to the weight data topic.

[0099] In some embodiments of this application, the Zenoh protocol can determine the second peripheral data and the third peripheral data in the following manner: acquiring valve control data, distance data, and weight data from the gateway device. Specifically, the valve control data is sent to the gateway device, for example, by a dispensing valve via the RS232 communication protocol; the distance data is sent to the gateway device, for example, by an infrared rangefinder via the RS422 communication protocol; and the weight data is sent to the gateway device, for example, by a glue weighing instrument via the RS485 communication protocol.

[0100] Adapters, such as RS232, RS422, and RS485 adapters, can be pre-developed using Zenoh-pico technology for each device. Then, the corresponding adapter can be used to parse the data from the gateway device to obtain the parsed data. For example, an RS232 adapter can be used to parse valve control data, an RS422 adapter to parse distance data, and an RS485 adapter to parse weight data.

[0101] The parsed data can be saved to the corresponding storage space in the preset resource space and published to the corresponding topic. For example, valve control data can be published to the resource namespace / glue / valve / control, distance data to the resource namespace / glue / distance / value, and weight data to the resource namespace / glue / weight / value.

[0102] In some embodiments of this application, the data parsed by Zenoh can also be saved to a target database. In one example, the target database may be a RocksDB database.

[0103] Figure 4 is a flowchart illustrating the method for generating dynamic dispensing tasks based on first peripheral data and second peripheral data in a real-time kernel according to an embodiment of this application. As shown in Figure 4, the method includes the following steps:

[0104] In step S401, the real-time kernel obtains the subscribed valve control data from the valve control data topic.

[0105] In step S402, cubic spline interpolation is performed on the acquired valve control data to obtain the dispensing path.

[0106] In step S403, the dispensing path is updated based on the image data and distance data to obtain the updated dispensing path.

[0107] In step S404, a valve control command is generated based on the updated dispensing path and sent to the dispensing valve.

[0108] In some embodiments of this application, the real-time kernel can subscribe to a valve control data Topic, and after the Topic publishes data, it can obtain real-time valve control data, and then perform cubic spline interpolation on the obtained valve control data to obtain the dispensing path.

[0109] Wherein, cubic spline interpolation can be P(t) = a0 + a1t + a2t 2 +a3t 3 , where P(t) is the dispensing path point, a0, a1 and a2 are cubic spline coefficients, which are obtained based on the substrate position and path planning determined by CCD aerial photography, and t is greater than or equal to 0 and less than or equal to 1.

[0110] In some embodiments of this application, the dispensing path can be updated based on image data and distance data to obtain an updated dispensing path. In one example, the current path can be determined by referring to image data, and the current height of the dispensing device can be determined by referring to distance data. Then, the current path, the current height, and the boundary conditions of the planned dispensing path are combined to update the dispensing path so that the updated dispensing path meets conditions such as higher accuracy and smoother path.

[0111] The real-time kernel can generate valve control commands based on the updated dispensing path and send these commands to the dispensing valve. Simultaneously, the real-time kernel can also receive feedback information from the dispensing valve.

[0112] Figure 5 is a flowchart illustrating the method for generating a drone photography task based on first peripheral data and second peripheral data provided in this application embodiment. As shown in Figure 5, the method includes the following steps:

[0113] In step S501, the real-time kernel uses a shared memory mechanism to obtain subscribed image data from the image data topic.

[0114] In step S502, edge detection is performed on the acquired image data to obtain at least one of path offset information and defect information.

[0115] In step S503, path offset information is sent to the dynamic dispensing task, and / or defect information is sent to the target database.

[0116] In some embodiments of this application, the real-time kernel can subscribe to an image data Topic, and after the Topic publishes data, it can use a shared memory mechanism to obtain real-time image data, and then use the obtained image data to generate a drone photography task.

[0117] In some implementations, the real-time kernel can perform edge detection on the acquired image data to obtain at least one of path offset information and defect information. Edge detection can be I... edge =Canny(I raw ,θ1,θ2), where I raw For the original image, I edge The image is after edge detection. Canny() is the edge detection function. θ1 and θ2 are thresholds. In one example, θ1 can be 100 and θ2 can be 200.

[0118] The detected edge features can be used to determine the path offset information of the dispensing path, including the offset of the horizontal axis and the vertical axis in a three-dimensional Cartesian coordinate system. On the other hand, this defect information can also be sent to a target database.

[0119] Figure 6 is a flowchart illustrating the method for generating a dynamic ranging task based on first peripheral data and second peripheral data in a real-time kernel according to an embodiment of this application. As shown in Figure 6, the method includes the following steps:

[0120] In step S601, the real-time kernel obtains the subscribed location data from the location data topic.

[0121] In step S602, the acquired position data is filtered to obtain the updated height position of the dispensing equipment.

[0122] In step S603, the updated height position is sent to the dynamic dispensing task.

[0123] In some embodiments of this application, the real-time kernel can subscribe to a location data Topic, obtain real-time location data after the Topic publishes data, and then use the obtained location data to generate a dynamic ranging task.

[0124] In some implementations, the real-time kernel can filter the acquired location data. In one example, a Kalman filter can be used to process the location data. The Kalman filter is... in State estimation at time k, Given the states at past k-1 times, predict the state at time k.k Let H be the error covariance matrix, and H be a user-defined matrix.

[0125] The height of the dispensing path can be updated based on the Kalman filter result, which is the value of the vertical axis in the three-dimensional Cartesian coordinate system.

[0126] Figure 7 is a flowchart illustrating a method for generating a glue weighing task based on third peripheral data using a conventional kernel, as provided in an embodiment of this application. As shown in Figure 7, the method includes the following steps:

[0127] In step S701, the regular kernel obtains the subscribed weight data from the weight data topic.

[0128] In step S702, the weight data is sent to the target database and / or the weight data is displayed.

[0129] In some embodiments of this application, a conventional kernel can subscribe to a weight data topic, obtain real-time weight data after the topic publishes data, and then use the obtained weight data to generate a glue weighing task.

[0130] A standard kernel can send the acquired weight data to the target database for data monitoring, or it can send the weight data to the user interface for display.

[0131] In some embodiments of this application, when adding a peripheral device to a dispensing device, the Zenoh protocol can quickly integrate the new peripheral device data in the following manner: In response to determining the addition of a target peripheral device, a target data adapter for the target peripheral device is customized, and the processing type of the target peripheral device data is determined; wherein, the processing type includes real-time processing type and non-real-time processing type; In response to determining that the processing type is real-time processing type, the target peripheral data of the target peripheral device is parsed using the target data adapter, and the parsed target peripheral data is saved to a preset resource space; the parsed target peripheral data is published to a target data topic, so that real-time kernels that have subscribed to the target data topic can obtain the target peripheral data using a shared memory mechanism; In response to determining that the processing type is non-real-time processing type, the target peripheral data of the target peripheral device is parsed using the target data adapter, and the parsed target peripheral data is saved to a preset resource space; the parsed target peripheral data is published to a target data topic, so that regular kernels that have subscribed to the target data topic can obtain the target peripheral data.

[0132] Figure 8 is a system architecture diagram for implementing the dispensing equipment data management method provided in the embodiments of this application. As shown in Figure 8, the system may include an x86 main controller, which may include a Xenomai real-time kernel and a Linux non-real-time kernel (i.e., a conventional kernel). Furthermore, the x86 main controller may also connect to a peripheral layer, which connects to various peripheral devices and acquires data from each peripheral device. These peripheral devices may include a dispensing valve, an infrared rangefinder, a CCD camera, and a glue weighing instrument.

[0133] The Zenoh communication layer can obtain data from various peripheral devices through preset adapters. It then uses a shared memory mechanism to transfer large data volumes, such as image data from a CCD camera, to the Xenomai real-time kernel, and a Pub-Sub mechanism to transfer smaller data volumes to either the Xenomai real-time kernel or the Linux non-real-time kernel. The Zenoh communication layer can also transfer various data volumes to the RocksDB database for data flow monitoring.

[0134] The Xenomai real-time kernel can generate dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks based on the acquired data, while the Linux non-real-time kernel can generate glue weighing tasks based on the acquired data.

[0135] Figure 9 is a data interaction diagram of the dispensing equipment data management method provided in the embodiments of this application. As shown in Figure 9, the dispensing valve data can be abstracted to / glue / valve / control by the Zenoh communication protocol, the infrared rangefinder data can be abstracted to / glue / distance / value by the Zenoh communication protocol, the CCD camera data can be abstracted to / glue / camera / image by the Zenoh communication protocol, and the glue weighing instrument data can be abstracted to / glue / weight / value by the Zenoh communication protocol.

[0136] The Xenomai real-time kernel can obtain image data, distance data, and valve control data from the Zenoh protocol communication layer via a shared memory mechanism. Alternatively, the Xenomai real-time kernel can also obtain distance and valve control data from the Zenoh protocol communication layer via a Pub-Sub subscription mechanism. The Linux non-real-time kernel can obtain weight data from the Zenoh protocol communication layer via a Pub-Sub subscription mechanism. The Xenomai real-time kernel can send recorded real-time data to the RocksDB database for monitoring, while the Linux non-real-time kernel can send recorded non-real-time data to the RocksDB database for monitoring.

[0137] Figure 10 is a schematic diagram of the dispensing valve adapter's workflow. As shown in Figure 10, the dispensing valve adapter's workflow can be as follows: Input valve control commands, which can be 8-bit, 9600 baud rate commands. After initializing the RS232 serial port and configuring the 9600 baud rate, the adapter parses Modbus or custom format data and then publishes it to Zenoh resources / glue / valve / control. In specific implementations, it can be set to poll every 10ms (milliseconds) to publish the valve status, including open and closed states, and supports dynamic dispensing feedback.

[0138] Figure 11 is a schematic diagram of the infrared rangefinder adapter's workflow. As shown in Figure 11, the infrared rangefinder adapter's workflow can be as follows: Input distance data, which can be floating-point data. After initializing the RS422 serial port and configuring a baud rate of 115200, parse the ASCII or binary distance value and then publish it to Zenoh resources / glue / distance / value.

[0139] Figure 12 is a schematic diagram of the CCD camera adapter's workflow. As shown in Figure 12, the CCD camera adapter's workflow can be as follows: Input image data and initialize the GigE Vision protocol. Next, capture image frames; in one example, the Aravis library can be used to capture image frames and parse the GVSP data stream. Finally, publish the captured image frames to Zenoh resources / glue / camera / image.

[0140] Figure 13 is a schematic diagram of the glue weighing instrument adapter's workflow. As shown in Figure 13, the workflow of the glue weighing instrument adapter can be as follows: Input weight data, which can be 16-bit data with a baud rate of 9600. After initializing the RS485 serial port, configure Modbus RTU to parse and obtain the weight data. Finally, publish the weight data to Zenoh resources / glue / weight / value.

[0141] Figure 14 is a flowchart illustrating the dynamic dispensing task running in the real-time kernel. As shown in Figure 14, the Xenomai real-time kernel can subscribe to the Zenoh resource / glue / valve / control. After acquiring the valve control data, it performs cubic spline interpolation to generate the dispensing path and sends valve control commands. It can then receive valve status feedback and update the dispensing path by combining CCD camera data and infrared rangefinder data.

[0142] Figure 15 is a flowchart illustrating the real-time kernel's operation of the aerial photography task. As shown in Figure 15, the Xenomai real-time kernel can subscribe to the Zenoh resource / glue / camera / image via a shared memory mechanism. After acquiring image data from the CCD camera, it performs Canny edge detection to extract substrate features or defects. Then, based on the extracted features, it determines the XY (horizontal axis - vertical axis) offset of the dispensing device and sends this XY offset to the path planner to update the dispensing path, or sends the defects to the RocksDB database for recording and monitoring.

[0143] Figure 16 is a flowchart illustrating the real-time kernel's execution of the dynamic ranging task. As shown in Figure 16, the Xenomai real-time kernel can subscribe to the Zenoh resource ` / glue / distance / value`. After acquiring the distance data, a Kalman filter can be performed to smooth the distance data, resulting in an updated vertical axis value `z`. Finally, this updated `z` value can be sent to the path planner to update the dispensing path.

[0144] Figure 17 is a flowchart illustrating the process of a regular kernel running a weighing task. As shown in Figure 17, the Linux non-real-time kernel can subscribe to the Zenoh resource / glue / weight / value. After obtaining the weight data, it parses the weight value and then stores the weight value in the RocksDB database or sends it to the user interface for display.

[0145] The technical solution provided in this application uses the Zenoh protocol to replace independent drivers and middleware, unifying RS232, RS422, RS485, and GigE data into a unified resource namespace, simplifying the development process. Simultaneously, the adapter supports rapid adaptation to new peripherals, reducing maintenance costs. Furthermore, the use of a shared memory mechanism for transmitting large amounts of data achieves zero-copy, enhancing real-time performance and improving dynamic processing capabilities.

[0146] On the other hand, core isolation avoids task contention and fully utilizes x86 multi-core capabilities. The Xenomai real-time kernel is bound to a dedicated kernel, optimizing high-bandwidth processing. Zenoh's automatic discovery and unified namespace simplify configuration, RocksDB provides efficient data logging and optimized debugging, and the Zenoh-pico adapter is modular, supporting rapid expansion.

[0147] Furthermore, the x86 platform is less expensive than dedicated FPGA hardware implementations and offers superior performance compared to embedded real-time operating systems. Moreover, the Zenoh and Xenomai software solutions reduce hardware dependencies and lower power consumption.

[0148] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0149] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0150] Figure 18 is a schematic diagram of a data management device for a dispensing equipment according to an embodiment of this application. As shown in Figure 18, the device includes a processor 1801, which includes at least a real-time core 1802 and a conventional core 1803.

[0151] The real-time kernel 1802 is configured to use a shared memory mechanism to obtain subscribed first peripheral data from a preset resource space. The first peripheral data includes at least the image data of the dispensing device.

[0152] The real-time kernel 1802 is also configured to obtain subscribed second peripheral data from a first topic in a preset resource space. The second peripheral data includes at least valve control data and distance data of the dispensing device, and the first topic includes at least a valve control data topic and a distance data topic.

[0153] The standard kernel 1803 is configured to obtain subscribed third peripheral data from a second topic in a preset resource space. The third peripheral data includes at least the weight data of the dispensing device, and the second topic includes at least the weight data topic.

[0154] The real-time kernel 1802 is also configured to generate real-time tasks based on first peripheral data and second peripheral data, including at least one of dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks.

[0155] The standard kernel 1803 is also configured to generate non-real-time tasks based on third peripheral data, including at least a glue weighing task.

[0156] The real-time kernel 1802 and the regular kernel 1803 are configured to perform real-time and non-real-time tasks.

[0157] The preset resource space is the storage space in the Zenoh protocol communication layer.

[0158] According to the technical solution provided in the embodiments of this application, by setting a real-time kernel and a conventional kernel in the processor, the peripheral data of the dispensing device is stored in the preset resource space of the Zenoh protocol communication layer. The real-time kernel uses a shared memory mechanism to obtain image data, valve control data and distance data from the preset resource space, and then generates real-time tasks based on the obtained data. The conventional kernel obtains weight data from the preset resource space and then generates non-real-time tasks based on the obtained data. Finally, the generated real-time and non-real-time tasks are executed. Thus, the Zenoh protocol is used to realize the unified integration of peripheral data of the dispensing device. At the same time, the real-time kernel improves the data processing efficiency, and the conventional kernel avoids task contention while processing non-real-time tasks, thereby improving the data management efficiency of the dispensing device.

[0159] In some implementations, the Zenoh protocol determines the first peripheral data in the following manner: acquiring the raw image data of the dispensing device; parsing the raw image data using a preset image data adapter to obtain the first peripheral data; saving the first peripheral data to the image data resource space in the preset resource space, and publishing the first peripheral data to the image data topic.

[0160] In some implementations, the Zenoh protocol determines the second and third peripheral data in the following manner: It acquires valve control data, distance data, and weight data from the dispensing device; it parses the valve control data and distance data using a preset serial communication data adapter to obtain the second peripheral data, and parses the weight data using the same preset serial communication data adapter to obtain the third peripheral data; wherein the type of the serial communication data adapter matches the communication protocol of the peripheral device corresponding to the parsed data; it saves the second peripheral data to the valve control data resource space and distance data resource space in a preset resource space, publishes the parsed valve control data to the valve control data topic, and publishes the parsed distance data to the distance data topic; it saves the third peripheral data to the weight data resource space in the preset resource space, and publishes the parsed weight data to the weight data topic.

[0161] In some implementations, in response to determining that the real-time task is a dynamic dispensing task, the real-time kernel generates the real-time task based on first peripheral data and second peripheral data, including: the real-time kernel acquiring subscribed valve control data from the valve control data topic; performing cubic spline interpolation on the acquired valve control data to obtain a dispensing path; updating the dispensing path based on image data and distance data to obtain an updated dispensing path; generating valve control commands based on the updated dispensing path, and sending the valve control commands to the dispensing valve.

[0162] In some implementations, in response to determining that the real-time task is a drone photography task, the real-time kernel generates a real-time task based on first peripheral data and second peripheral data, including: the real-time kernel uses a shared memory mechanism to obtain subscribed image data from the image data topic; performs edge detection on the obtained image data to obtain at least one of path offset information and defect information; sends the path offset information to the dynamic dispensing task, and / or sends the defect information to the target database.

[0163] In some implementations, in response to determining that the real-time task is a dynamic ranging task, the real-time kernel generates a real-time task based on first peripheral data and second peripheral data, including: the real-time kernel obtaining subscribed location data from the location data topic; filtering the obtained location data to obtain the updated height position of the dispensing device; and sending the updated height position to the dynamic dispensing task.

[0164] In some implementations, in response to determining that a non-real-time task is a glue weighing task, the regular kernel generates a non-real-time task based on third peripheral data, including: the regular kernel obtaining subscribed weight data from a weight data topic; sending the weight data to a target database; and / or displaying the weight data.

[0165] In some implementations, the Zenoh protocol also operates as follows: In response to identifying a new target peripheral device, a target data adapter for the target peripheral device is customized, and the processing type of the target peripheral device data is determined; wherein, the processing type includes real-time processing type and non-real-time processing type; In response to determining that the processing type is real-time processing type, the target peripheral data of the target peripheral device is parsed using the target data adapter, and the parsed target peripheral data is saved to a preset resource space; The parsed target peripheral data is published to a target data topic, so that real-time kernels that have subscribed to the target data topic can obtain the target peripheral data using a shared memory mechanism; In response to determining that the processing type is non-real-time processing type, the target peripheral data of the target peripheral device is parsed using the target data adapter, and the parsed target peripheral data is saved to a preset resource space; The parsed target peripheral data is published to a target data topic, so that regular kernels that have subscribed to the target data topic can obtain the target peripheral data.

[0166] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0167] Figure 19 is a schematic diagram of an electronic device provided in an embodiment of this application. As shown in Figure 19, the electronic device 19 of this embodiment includes: a processor 1901, a memory 1902, and a computer program 1903 stored in the memory 1902 and executable on the processor 1901. When the processor 1901 executes the computer program 1903, it implements the steps in the various method embodiments described above. Alternatively, when the processor 1901 executes the computer program 1903, it implements the functions of each module / unit in the various device embodiments described above.

[0168] Electronic device 19 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 19 may include, but is not limited to, processor 1901 and memory 1902. Those skilled in the art will understand that FIG19 is merely an example of electronic device 19 and does not constitute a limitation on electronic device 19, and may include more or fewer components than illustrated, or different components.

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

[0170] The memory 1902 can be an internal storage unit of the electronic device 19, such as a hard disk or RAM of the electronic device 19. The memory 1902 can also be an external storage device of the electronic device 19, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, FlashCard, etc., equipped on the electronic device 19. The memory 1902 can also include both internal and external storage units of the electronic device 19. The memory 1902 is used to store computer programs and other programs and data required by the electronic device.

[0171] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0172] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

[0173] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A data management method for dispensing equipment, characterized in that, The method is executed by a processor, which includes at least a real-time kernel and a regular kernel. The method includes: acquiring raw data from various peripherals of the dispensing device via the Zenoh protocol communication layer, the raw data including at least image raw data transmitted via a first communication protocol, valve control and distance raw data transmitted via a second communication protocol, and weight raw data transmitted via a third communication protocol; parsing the raw data in the Zenoh protocol communication layer using a data adapter compatible with each communication protocol, and saving the parsed image data, valve control data, distance data, and weight data to a preset resource space in the Zenoh protocol communication layer, and publishing them to the corresponding data topic; the real-time kernel using a shared memory mechanism to acquire subscribed first peripheral data from the preset resource space, the first peripheral data including at least the dispensing data... The system generates image data of the dispensing equipment; the real-time kernel obtains subscribed second peripheral data from a first topic in the preset resource space, the second peripheral data including at least valve control data and distance data of the dispensing equipment, and the first topic including at least a valve control data topic and a distance data topic; the conventional kernel obtains subscribed third peripheral data from a second topic in the preset resource space, the third peripheral data including at least weight data of the dispensing equipment, and the second topic including at least a weight data topic; the real-time kernel generates a real-time task based on the first peripheral data and the second peripheral data, the real-time task including at least one of a dynamic dispensing task, a flying photography task, and a dynamic ranging task; the conventional kernel generates a non-real-time task based on the third peripheral data, the non-real-time task including at least a glue weighing task; and executes the real-time task and the non-real-time task.

2. The method according to claim 1, characterized in that, The Zenoh protocol determines the first peripheral data in the following way: acquiring the raw image data of the dispensing device; parsing the raw image data using a preset image data adapter to obtain the first peripheral data; Save the first peripheral data to the image data resource space in the preset resource space, and publish the first peripheral data to the image data topic.

3. The method according to claim 1, characterized in that, The Zenoh protocol determines the second peripheral data and the third peripheral data in the following manner: it acquires the valve control data, distance data, and weight data of the dispensing device; The valve control data and distance data are parsed using a preset serial communication data adapter to obtain the second peripheral data, and the weight data is parsed using the preset serial communication data adapter to obtain the third peripheral data; wherein, the type of the serial communication data adapter matches the communication protocol of the peripheral device corresponding to the parsed data; Save the second peripheral data to the valve control data resource space and distance data resource space in the preset resource space, publish the parsed valve control data to the valve control data topic, and publish the parsed distance data to the distance data topic; save the third peripheral data to the weight data resource space in the preset resource space, and publish the parsed weight data to the weight data topic.

4. The method according to claim 1, characterized in that, In response to determining that the real-time task is a dynamic dispensing task, the real-time kernel generates a real-time task based on the first peripheral data and the second peripheral data, including: the real-time kernel obtains subscribed valve control data from the valve control data topic; performs cubic spline interpolation on the obtained valve control data to obtain a dispensing path; updates the dispensing path based on the image data and distance data to obtain an updated dispensing path; generates a valve control command based on the updated dispensing path, and sends the valve control command to the dispensing valve.

5. The method according to claim 2, characterized in that, In response to determining that the real-time task is a flight photography task, the real-time kernel generates a real-time task based on the first peripheral data and the second peripheral data, including: the real-time kernel uses a shared memory mechanism to obtain subscribed image data from the image data topic; performs edge detection on the obtained image data to obtain at least one of path offset information and defect information; sends the path offset information to the dynamic dispensing task, and / or sends the defect information to the target database.

6. The method according to claim 1, characterized in that, In response to determining that the real-time task is a dynamic ranging task, the real-time kernel generates a real-time task based on the first peripheral data and the second peripheral data, including: the real-time kernel obtaining subscribed distance data from the distance data topic; filtering the obtained distance data to obtain the updated height position of the dispensing device; and sending the updated height position to the dynamic dispensing task.

7. The method according to claim 1, characterized in that, In response to determining that the non-real-time task is a glue weighing task, the regular kernel generates a non-real-time task based on the third peripheral data, including: the regular kernel obtaining subscribed weight data from the weight data topic; sending the weight data to the target database; and / or displaying the weight data.

8. The method according to any one of claims 1-7, characterized in that, The Zenoh protocol also operates as follows: In response to identifying a new target peripheral device, a target data adapter for the target peripheral device is customized, and the processing type of the target peripheral device data is determined; wherein, the processing type includes real-time processing type and non-real-time processing type; In response to determining that the processing type is real-time processing type, the target peripheral data of the target peripheral device is parsed using the target data adapter, and the parsed target peripheral data is saved to a preset resource space; the parsed target peripheral data is published to a target data topic, so that real-time kernels subscribed to the target data topic can obtain the target peripheral data using a shared memory mechanism; In response to determining that the processing type is non-real-time processing type, the target data adapter is used to parse the target peripheral data of the target peripheral device, and the parsed target peripheral data is saved to a preset resource space; the parsed target peripheral data is published to a target data topic, so that regular kernels subscribed to the target data topic can obtain the target peripheral data.

9. A data management device for dispensing equipment, used to perform the method according to any one of claims 1-8, characterized in that, The device includes a processor, which includes at least a real-time kernel and a regular kernel. The real-time kernel is configured to acquire subscribed first peripheral data from a preset resource space using a shared memory mechanism. The first peripheral data includes at least image data of the dispensing device. The real-time kernel is also configured to acquire subscribed second peripheral data from a first topic in the preset resource space. The second peripheral data includes at least valve control data and distance data of the dispensing device. The first topic includes at least a valve control data topic and a distance data topic. The regular kernel is configured to acquire subscribed third peripheral data from a second topic in the preset resource space. The third peripheral data includes at least the weight data of the dispensing device, and the second topic includes at least the weight data topic; the real-time kernel is also configured to generate real-time tasks based on the first peripheral data and the second peripheral data, the real-time tasks including at least one of dynamic dispensing tasks, aerial photography tasks, and dynamic ranging tasks; the conventional kernel is also configured to generate non-real-time tasks based on the third peripheral data, the non-real-time tasks including at least the glue weighing task; the real-time kernel and the conventional kernel are configured to execute the real-time tasks and non-real-time tasks; wherein, the preset resource space is the storage space in the Zenoh protocol communication layer.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 8.

Images