Data communication method and device for robot system and robot

Abstract

The invention relates to the technical field of data communication, and discloses a data communication method and device for a robot system and a robot. The method comprises the following steps: when a data acquisition agent module monitors that business data is written into a shared memory area, acquiring the business data from the shared memory area; caching the business data according to the data type of the business data; and acquiring a network state of the robot system, and uploading the cached service data to a server or locally storing the cached service data according to the network state and the data type of the service data. Through a data acquisition and cache uploading separation mechanism, the problems of high occupation of data communication bandwidth, conflict between real-time performance and flexibility, high thread scheduling load and the like in an existing robot system are solved, and the communication efficiency and the data management capability of the system are remarkably improved.

Description

Technical Field

[0001] This application relates to the field of data communication technology, and in particular to a data communication method, apparatus and robot for robot systems. Background Technology

[0002] Currently, the robot system employs a modular data acquisition and feedback architecture for data communication. The main communication process includes: the business process acquires sensor or task data, which is then distributed in real-time through a Data Distribution Service (DDS) middleware. The receiving module deserializes the data and passes it to the business logic module for calculation and analysis. Subsequently, the processing results are reserialized and written to local storage, and finally transmitted back to the cloud platform via the network. This process, with the robot as the core execution entity, realizes a closed-loop communication mechanism from data acquisition to remote synchronization, exhibiting excellent real-time performance and scalability.

[0003] However, DDS's default Quality of Service (QoS) policy favors real-time transmission, leading to the high-frequency broadcasting of a large amount of non-critical or redundant data, consuming network bandwidth and impacting the overall system communication efficiency. Furthermore, as the number of subscribed topics (logical channels or topics for data transmission) increases, the system's thread management and scheduling pressure grows linearly, easily triggering resource contention and affecting the real-time performance of the robot's core functions. Summary of the Invention

[0004] One objective of this application is to provide a data communication method, apparatus, and robot for robot systems, in order to solve the technical problems of low communication efficiency and high system scheduling pressure in related technologies.

[0005] To address the aforementioned technical problems, one technical solution adopted in this application is: providing a data communication method for a robot system, the robot system including a shared memory region and a data acquisition proxy module, the method comprising: when the data acquisition proxy module detects that business data is being written to the shared memory region, obtaining the business data from the shared memory region; caching the business data according to its data type; obtaining the network status of the robot system, and uploading the cached business data to a server or storing it locally according to the network status and the data type of the business data.

[0006] This solution employs a data monitoring mechanism using shared memory and a data acquisition agent module, avoiding unnecessary communication protocol overhead, reducing CPU load, and improving communication efficiency. Furthermore, the use of shared memory and the data acquisition agent module decouples data communication from main business processing, thereby reducing thread scheduling overhead. Additionally, through intelligent caching and hierarchical transmission control, data can be categorized and cached according to data type, enabling on-demand categorized storage and distribution of data. Automatic selection between uploading and local temporary storage based on network status ensures data integrity and reliability. Therefore, this solution, through its data acquisition and cache upload separation mechanism, solves the problems of high data communication bandwidth consumption, conflicts between real-time performance and flexibility, and high thread scheduling load in existing robot systems, significantly improving the system's communication efficiency and data management capabilities.

[0007] In some embodiments, the robot system further includes a data recording service module. After obtaining business data from the shared memory region, the method further includes: submitting the business data to the data recording service module, and preprocessing the business data through the data recording service module to obtain preprocessed business data; wherein, the preprocessing includes data filtering and format conversion.

[0008] In this way, by obtaining business data from the data acquisition agent module through the data recording service module and preprocessing the business data, the uniformity and manageability of the data structure are improved, laying the foundation for subsequent caching, classification, compression and hierarchical transmission.

[0009] In some embodiments, before obtaining business data from the shared memory region, the method further includes: creating a control structure for managing the state of the shared memory region when the robot system starts; applying for a physical memory region of a preset size based on the parameters corresponding to the control structure, the physical memory region being used to accept access from multiple business processes; dividing the physical memory region into a metadata area and a data area, the metadata area being used to store the parameters corresponding to the control structure, and the data area being used to store business data; establishing an access interface, the access interface being used to support write and read operations of business processes on the shared memory region; and registering the control structure, the physical memory region, and the access interface to a communication middleware to obtain a shared memory region for unified management and access.

[0010] This solution initializes shared memory, obtaining a structured, accessible, and communicable shared memory region. This zero-copy access eliminates the CPU overhead of traditional multiple copy operations, improving the system's real-time responsiveness, and is particularly suitable for robots' needs for rapid processing of large amounts of data such as images and radar data.

[0011] In some embodiments, the method further includes: when business data is detected to be generated, requesting write space from the shared memory region through the business process; according to the requested write space, the business process writes the business data into the data area through the access interface, and updates the content of the metadata area when the business data writing is completed; when the data acquisition agent module detects that business data is being written in the shared memory region, obtaining the business data from the shared memory region, including: when the data acquisition agent module detects that a change flag or data status in the metadata area has changed, determining that business data is being written in the shared memory region, and obtaining the business data from the data area through the access interface.

[0012] This solution eliminates the need for complex intermediate message queues or additional thread blocking and waiting, and reduces system resource consumption through lightweight status flag monitoring.

[0013] In some embodiments, data types include emergency data, regular data, and log data; wherein, emergency data refers to data that needs to be processed or transmitted immediately during the operation of the robot system, regular data refers to data that is periodically or continuously collected and recorded in the robot system, and log data is data used to record the operation history and operation records during the operation of the robot system; caching of business data according to the data type of business data includes: when the data type of business data is emergency data, storing the business data in a memory cache; when the data type of business data is regular data, storing the business data in a solid-state drive; and when the data type of business data is log data, storing the business data in a hard disk drive. By storing different types of data separately in memory, solid-state drives, and hard disk drives, the real-time performance of data processing, system resource utilization, and storage cost efficiency are effectively improved.

[0014] In some embodiments, after caching the business data according to the data type of the business data, the method further includes: compressing and encrypting the cached business data to obtain compressed and encrypted cached data; hashing the compressed and encrypted cached data to obtain a hash value corresponding to the compressed and encrypted cached data; and storing the hash value in the blockchain.

[0015] This solution compresses and encrypts the cached data and stores its corresponding hash value in the blockchain. In this way, while ensuring data transmission efficiency and security, it also achieves data tamper-proof and traceable evidence storage.

[0016] In some embodiments, the network status of the robot system is obtained, and cached business data is uploaded to the server or stored locally according to the network status and the data type of the business data. This includes: obtaining the network signal strength, bandwidth parameters, and latency parameters of the robot system; determining the network status of the robot system based on the network signal strength, bandwidth parameters, and latency parameters; when the network status meets the high-quality transmission conditions and the data type of the business data is urgent data, transmitting and uploading the cached business data to the server via a fourth-generation mobile communication technology (4G or 5G) channel; when the network status meets the high-quality transmission conditions and the data type of the business data is regular data, transmitting and uploading the cached business data to the server via a wireless local area network (WLAN) channel; when the network status meets the high-quality transmission conditions and the data type of the business data is log data, storing the cached business data on the local disk, and uploading the business data from the local disk to the server when the robot system is idle.

[0017] This solution dynamically selects transmission channels based on data type and network status, prioritizing the rapid transmission of critical data and preventing non-critical data from consuming network resources. Specifically, urgent data is transmitted using low-latency fourth-generation or fifth-generation mobile communication technology channels to ensure the robot can respond promptly to emergencies; routine data is transmitted using high-bandwidth wireless LANs to improve batch data transmission efficiency while avoiding the consumption of critical network resources; log data is initially stored locally and uploaded in batches during system downtime to reduce network pressure during peak periods. In summary, this intelligent data management and transmission strategy significantly improves the data communication performance of the robot system.

[0018] In some embodiments, when the network conditions do not meet the requirements for high-quality transmission, the method further includes: reducing the amount of cached data corresponding to the business data when performing caching of business data according to the data type of the business data.

[0019] This solution reduces the amount of cached data, avoiding excessive memory consumption and system resource strain caused by excessive caching, thus improving system stability. This, in turn, enhances the data processing and transmission efficiency of the robot system under poor network conditions.

[0020] To address the aforementioned technical problems, one technical solution adopted in this application is: providing a data communication device for a robot system. The robot system includes a shared memory region and a data acquisition agent module. The device includes: a business data acquisition module, used to acquire business data from the shared memory region when the data acquisition agent module detects business data being written to the shared memory region; a cache processing module, used to cache the business data according to its data type; and a data transmission module, used to acquire the network status of the robot system and, according to the network status and the data type of the business data, upload the cached business data to a server or store it locally.

[0021] To solve the above-mentioned technical problems, one technical solution adopted in this application is: to provide a robot, including: a memory and a processor, the memory being connected to the processor, the processor being used to execute one or more computer programs stored in the memory, and when the processor executes one or more computer programs, enabling the robot to implement a data communication method for robot systems applied to the robot. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application 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.

[0023] Figure 1 This is a schematic diagram illustrating an application scenario provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a data communication method for a robot system provided in an embodiment of this application; Figure 3 This is a flowchart of a data communication method for a robot system provided in another embodiment of this application; Figure 4 This is a schematic diagram of the structure of a data communication device for a robot system provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a robot provided in an embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0025] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be performed in a different order than the module division in the device or the order in the flowchart.

[0026] Data communication for robotic systems refers to the efficient and real-time exchange of data between functional modules within a robot, and between the robot and external systems (such as cloud platforms, edge servers, or other robots). As application scenarios become increasingly complex, the robot's perception, decision-making, and execution modules place higher demands on the high-frequency exchange of sensor data, control commands, and task status. To meet the communication requirements of low latency, high reliability, and good scalability, modern robotic systems generally adopt a modular communication architecture based on a publish / subscribe model data middleware (such as DDS) to achieve real-time information distribution and synchronization. This mechanism is a key foundation for ensuring multi-task collaboration, autonomous operation, and remote monitoring of robots.

[0027] In DDS, the communicating parties exchange data by defining topics. Publishers publish data to designated topics, and subscribers receive data by subscribing to those topics. This model decouples the communicating parties, offering good modularity and flexibility, making it particularly suitable for complex, multi-tasking distributed systems like robots.

[0028] However, DDS's default QoS policy typically favors real-time data and reliability, such as enabling reliable transmission and high-frequency broadcasting. Without prioritizing data importance, this can easily lead to frequent transmissions of non-critical data (such as debugging information or low-priority sensor data), consuming valuable network bandwidth and system resources, thus compressing the transmission space for critical task data and weakening the system's communication efficiency and real-time response capabilities.

[0029] Furthermore, without setting differentiated QoS policies for different types of data, low-priority data may also be transmitted at a high frequency. Since this data is often large in size and has low real-time requirements, its frequent transmission will exacerbate the communication load. Once the network is congested, critical task data (such as motion control, obstacle avoidance feedback, etc.) may be queued or lost. In severe cases, this will affect the robot's ability to respond to environmental changes and even jeopardize the stability of task execution.

[0030] Furthermore, as the number of subscribed topics in the system continues to grow, DDS allocates an independent listening thread or event handling mechanism to each subscription channel. While this mechanism improves concurrent processing capabilities, the linear increase in the number of threads also brings system scheduling burden and context switching overhead. When the total number of threads exceeds the system's processing capacity, it can easily lead to resource contention and thread starvation, causing delays or loss in some data processing. Once this problem occurs in the robot's core task chain, it will directly affect the real-time performance and reliability of its perception, decision-making, and execution.

[0031] Therefore, improper QoS policy configuration and non-standard Topic management are two key hidden dangers affecting the communication performance and stable operation of robot systems, which urgently need to be optimized and controlled in system design.

[0032] Based on this, embodiments of this application provide a data communication method for robot systems. This method employs a mechanism of caching, judgment, and control of upload to preprocess business data and avoid all data being directly broadcast through DDS. Specifically, business data is first written to a shared memory area, which is then monitored and extracted by a data acquisition agent module. Subsequently, based on the data type and current network status, the importance and transmission conditions of the data are determined, deciding whether to upload it to the server or transfer it to local storage.

[0033] This method effectively avoids frequent broadcasting of low-priority, low-real-time data, significantly reducing DDS network bandwidth consumption. Simultaneously, through on-demand uploading and local caching strategies, it achieves fine-grained scheduling of communication resources, improving the system's data processing efficiency and communication performance in complex task scenarios. This mechanism controls data traffic at the source, helping to alleviate communication bottlenecks caused by improper QoS policy configuration and chaotic Topic management, further enhancing the stability and real-time performance of the robot system under conditions of multi-task concurrency and dynamic network changes.

[0034] The data communication method for robot systems described in this application is applicable to data acquisition and feedback scenarios in robot systems, especially in distributed systems where robots need to interact with host computers (such as edge servers or cloud platforms) at high frequency. For example, Figure 1As shown, this application scenario includes a communication network architecture consisting of multiple front-end execution entities 10 (such as industrial robots, service robots, special robots, etc.) and one or more servers 20.

[0035] The front-end execution entity 10 is the robot end, which is the data acquisition terminal. Each robot integrates multiple types of sensors (such as vision, touch, photoelectric, force feedback, temperature and humidity, etc.) and a local control module to continuously generate various types of business data, including perception information, task status, operation logs, and fault diagnosis data. These data have significant differences in real-time requirements and priorities, and are numerous. The server 20 is the data collection and processing center, undertaking functions such as centralized data analysis, task scheduling, and remote monitoring. Critical task data (such as positioning status, target recognition results, alarm events, etc.) has high timeliness requirements, while some raw data (such as complete video streams and equipment logs) can be uploaded delayed or on demand. In a high-frequency data acquisition environment, directly broadcasting all data through DDS can easily cause network congestion and delays in the transmission of critical information, especially in scenarios involving multi-robot collaboration, unstable wireless communication, or limited bandwidth. The method in this application introduces a caching and proxy decision-making mechanism in the front-end execution entity 10, which dynamically determines whether to upload to the server 20 based on the network status and data type, effectively reducing the need for real-time transmission of non-critical data, ensuring the stable uploading of high-priority task data, and improving the overall communication efficiency and robustness of the system.

[0036] In this embodiment, the robot system is installed in the front-end execution unit 10, meaning that each robot device integrates this robot system. The front-end execution unit 10 executes the data communication method for robot systems proposed in this application based on this system, enabling it to locally complete data acquisition, caching, judgment, and upload control operations, thereby achieving efficient data interaction and communication collaboration with the server 20. The front-end execution unit 10 and the server 20 are connected via a network, forming a closed-loop communication architecture for data acquisition, processing, and feedback, suitable for multi-robot collaborative operation scenarios.

[0037] Figure 1The application scenarios illustrated include a communication network architecture comprised of multiple front-end execution entities 10 (e.g., industrial robots, service robots, special-purpose robots, etc.) and one or more servers 20. Based on this flexible and scalable architecture, various application scenarios can be supported: For example, multiple industrial robots (front-end execution entities 10) are distributed on a production line, responsible for automated welding, assembly, and quality inspection. They collect and transmit operational status and process data in real time to the factory's central control server (server 20) through robot systems, enabling centralized monitoring and dynamic adjustment of the production process to improve manufacturing efficiency and product quality. Another example is multiple security patrol robots (front-end execution entities 10) patrolling important urban areas, collecting video surveillance, environmental sensor data, and abnormal alarm information, and transmitting the data to the urban safety management platform (server 20) via a wireless network, thereby achieving 24 / 7 intelligent monitoring and rapid event response. Yet another example is multiple unmanned vehicles (front-end execution entities 10) deployed in specific areas such as roads, industrial parks, or mining areas. Each vehicle operates an internal robot system that collects sensor data (such as LiDAR, cameras, millimeter-wave radar, etc.) in real time and determines its location information and driving status. This data can be initially processed and cached locally, and then uploaded to server 20 (such as an edge computing node, traffic control center, or cloud platform) depending on the task type and network conditions. Server 20 can then perform global route planning and traffic scheduling based on the acquired data.

[0038] The above application scenario is only one example. The data communication method for robot systems in this application embodiment can also be widely applied to many other scenarios.

[0039] like Figure 2 As shown, Figure 2 This is a flowchart illustrating a data communication method for a robot system provided in an embodiment of this application. The method is applied to a robot system and can be executed by the aforementioned front-end execution entity 10. The method includes: S101. When the data acquisition agent module detects that business data is being written to the shared memory area, it retrieves the business data from the shared memory area.

[0040] The aforementioned robot system is an embedded control system or operating system platform deployed within the robot itself. It is a runtime environment specifically deployed in each front-end robot device, including but not limited to: an embedded operating system, a driver management module, software processes (perception nodes, decision nodes, data proxy modules, etc.), communication middleware service processes such as DDS, and storage and data transmission mechanisms. This robot system is primarily used to implement the data communication method for robot systems as described in this application. Its core function is to integrate and complete data acquisition, type identification, priority judgment, cache management, on-demand uploading, and local storage operations within the robot itself, thereby efficiently scheduling and strategically uploading and transmitting business data, and ultimately interacting with the server system.

[0041] The DataRecorder Agent module is an intermediate functional unit located in the robot system that monitors, collects, caches, and regulates the uploading behavior of business data. It acts as a data channel coordinator between local modules (such as sensing, control, and navigation) and the remote host computer system. Specifically, it can monitor the shared memory area, for example, detecting whether new data is being written to the shared memory area by business modules; extracting business data (such as sensor data, task status, and control logs) from the shared memory area; identifying data types and priorities; and classifying and caching data according to policies. Compared to the traditional direct DDS broadcast mechanism, by setting up the data acquisition agent module, an indirect uploading and policy-controlled data communication method is achieved, thereby optimizing network bandwidth usage and improving the overall communication performance and stability of the system.

[0042] A shared memory region refers to a physical memory area that can be accessed by multiple processes. In this robot system, it is used for efficient data exchange between business modules or between business modules and agent modules.

[0043] Business data refers to task-related data generated during the execution of robot business logic. For example, for the perception module, the generated business data includes LiDAR point clouds, camera images, IMU data, distance measurements, etc.; for the control module, the generated business data includes motion commands, speed feedback, etc.; and for the log and monitoring module, the generated business data includes operation logs, fault logs, resource usage information, etc.

[0044] The data acquisition agent module does not directly participate in business calculations, but it uses a monitoring mechanism to detect whether new data is being written to the shared memory area. Specifically, when the business module writes business data (such as sensor data, task status information, or control logs) to the shared memory area, it simultaneously updates the status flags, timestamps, or data version numbers in the shared memory area. The data acquisition agent module can monitor changes in these flags or metadata through timed polling, event triggering, or signal notifications to determine whether new data has been written. Once new data is confirmed to have been written, the data acquisition agent module retrieves the business data from the shared memory area.

[0045] In some embodiments, the robot system also integrates a data recording service module (DataRecorderService). After acquiring business data, the method further includes: submitting the business data to the data recording service module, and preprocessing the business data through the data recording service module to obtain preprocessed business data. Preprocessing includes data filtering and format conversion. The data recording service module is a system-level data processing service deployed within the robot system. Its function is to preprocess raw business data from multiple business modules or data acquisition agent modules to facilitate subsequent uploading, compression, or analysis. Preprocessing includes, but is not limited to, data filtering and format conversion, used to remove redundant data, unify data structures, add metadata, etc., ultimately outputting structured and standardized data content to support subsequent data uploading or storage. As an intermediate processing link in the communication process, the data recording service module helps improve the efficiency, accuracy, and maintainability of system data communication. In the following steps, corresponding data communication methods can be executed based on the preprocessed business data.

[0046] In related technologies, such as DDS-based communication architectures, data is directly broadcast by business modules via DDS, which can easily lead to problems such as high-frequency broadcasting of redundant data, bandwidth consumption, and competition for transmission resources between non-critical and critical data. The method in this application embodiment, however, uses the aforementioned data acquisition proxy module as an intermediary for data monitoring and acquisition, extracting business data from shared memory and isolating business and communication processes. The data recording service module filters and structures the data, improving data quality and communication efficiency. Together, these two modules achieve preprocessing, diversion, and optimization control of the data communication link, thereby solving problems such as fixed QoS and resource conflicts in DDS in robotic scenarios, and improving system communication efficiency, data upload control capabilities, and real-time performance.

[0047] S102. Cache business data according to its data type.

[0048] The data types of business data include emergency data, routine data, and log data. Emergency data refers to data generated during the operation of the robot system that needs immediate processing or transmission. It has strong real-time requirements and is related to safety, control, or fault warnings, such as obstacle avoidance commands and sensor anomaly alarms. Routine data refers to data that is periodically or continuously collected and recorded in the robot system, such as pose, battery level, speed, and sensor readings. Log data is used to record the operating history and operation records of the robot system. It does not have strong real-time requirements and includes task logs, control module records, and debugging data.

[0049] To identify different types of business data, a data type identifier field can be set in the business data structure. This identifier is attached by the business process that generates the data when writing it to the shared memory area. This identifier indicates whether the data is urgent, regular, or log data. When reading data, the system can access this identifier field to quickly determine the type of business data and then take appropriate processing strategies based on the real-time requirements of the data. Specifically, when a business process generates data, it can set corresponding type identifiers in the data structure based on the data's source, purpose, and processing time limit, combined with preset business rules. For example, obstacle avoidance related instructions can be identified as "urgent data type," periodically collected status information as "regular data type," and operation record data as "log data type."

[0050] Specifically, when the data type is urgent, it is stored in a memory cache; when the data type is regular, it is stored on a solid-state drive (SSD); and when the data type is log data, it is stored on a hard disk drive (HDD). This implementation aims to improve the system's data processing efficiency and resource utilization. Specifically, storing urgent data in a memory cache enables high-speed read / write and low-latency access, ensuring that critical task data can be processed and uploaded quickly. Storing regular data on an SSD balances read / write performance and storage capacity, making it suitable for periodic data with moderate real-time requirements. Storing log data on an HDD leverages its large capacity and low cost to store a large amount of historical information with low access frequency. This transmission strategy rationally allocates data based on its real-time nature, persistence, and access frequency, effectively alleviating storage resource competition and improving the communication stability and overall performance of the robot system under high load.

[0051] To address the different types of business data, the system employs differentiated caching and storage strategies to balance real-time performance and resource efficiency. Emergency data, such as emergency stop signals and fault alarms, has extremely high real-time requirements and must be processed immediately upon generation. Therefore, it is directly stored in the memory cache, leveraging the high-speed read / write capabilities of memory to ensure rapid data retrieval and transmission, guaranteeing the robot's safe operation. Regular data, such as operating status and general sensor data, while requiring transmission, has lower real-time requirements. The system stores this data on SSDs (Solid State Drives) and performs batch compression, improving storage efficiency and facilitating subsequent orderly uploading. Log data, primarily used to record the robot's operational history and behaviors, has the lowest timeliness. The system writes this data to HDDs (Hard Disk Drives) for long-term storage and delays uploading during periods of system idleness or low network load, maximizing communication resource savings and improving overall system efficiency. Thus, storing different types of data separately in memory, SSDs, and HDDs effectively improves data processing real-time performance, system resource utilization, and storage cost efficiency.

[0052] In some embodiments, within the framework of the current three basic categories of "emergency data, routine data, and log data", the data types of business data can be further subdivided to enable more precise scheduling and transmission strategy formulation and improve the system's responsiveness to critical tasks.

[0053] For example, emergency data can be further subdivided into "safety-related data" (such as obstacle avoidance feedback and collision detection), "control command data" (such as attitude adjustment and navigation correction), and "system anomaly data" (such as hardware fault alarms and communication link loss alerts). Although all of these are high-priority data, their timeliness requirements, fault tolerance, and transmission frequencies may differ. The system can formulate differentiated scheduling strategies based on these subcategories. For instance, safety-related data can be uploaded immediately through a dedicated high-priority channel, control command data can be processed locally in real time and reported synchronously, and anomaly alarms can be configured with retry mechanisms and acknowledgment response links. This ensures the real-time performance of critical functions while avoiding resource contention and processing conflicts within the same "emergency data" category, thus achieving refined management of communication resources.

[0054] Regular data can be further subdivided into sensor monitoring data (such as data collected periodically by temperature, humidity, lidar, IMU, etc.), status reporting data (such as current task status, pose, path progress, etc.), and operational statistics (such as power consumption, task completion time, module load, etc.). For high-frequency and large-volume sensor monitoring data, sliding window caching, compression preprocessing, and delayed upload mechanisms can be used to alleviate real-time transmission pressure. For status reporting data with moderate change frequency but important data, an event-driven triggering caching strategy can be adopted, setting change thresholds and batch writing to SSDs to achieve a balance between timely data updates and resource utilization. For operational statistics data that are generated infrequently and need long-term storage, a strategy of periodically archiving and offline uploading using low-speed storage (such as HDDs) can be adopted to maximize the overall data management efficiency and communication performance of the system.

[0055] Log data can be further subdivided into operation logs, system operation logs, and communication logs. Operation logs primarily record key operations performed by users or the system, possessing auditing and traceability value. They can be written to an HDD with a set backup cycle to ensure complete retention. System operation logs record status changes and anomalies during the operation of various modules of the robot system. They are typically generated frequently and are suitable for batch writing and rotation storage mechanisms to control log volume and facilitate subsequent troubleshooting and analysis. Communication logs reflect data interactions between the robot and external systems, exhibiting strong temporal and continuous characteristics. They can be archived and stored by day, month, or year using timestamp indexing, and the recording granularity can be dynamically adjusted based on network status to achieve effective tracking of the communication process and rational allocation of bandwidth resources.

[0056] In some embodiments, after caching the business data according to its data type, the method further includes: compressing and encrypting the cached business data to obtain compressed and encrypted cached data; hashing the compressed and encrypted cached data to obtain a hash value corresponding to the compressed and encrypted cached data; and storing the hash value in a blockchain. This embodiment, by compressing and encrypting the cached data and storing its corresponding hash value in a blockchain, achieves data tamper-proofing and traceable evidence storage while ensuring data transmission efficiency and security.

[0057] S103. Obtain the network status of the robot system, and upload the cached business data to the server or store it locally according to the network status and the data type of the business data.

[0058] Building upon the steps outlined above, the network status of the robot system is further acquired to obtain network signal strength, bandwidth parameters, and latency parameters. The network signal strength refers to the received signal strength of the wireless network (such as 4G / 5G or Wi-Fi) currently connected to the robot, reflecting the stability and anti-interference capability of the wireless connection. The bandwidth parameter is the maximum data transmission rate supported by the current network, representing the amount of data that can be transmitted per unit time. The latency parameter refers to the time required from when the robot initiates a request to when the server receives a response, used to measure the timeliness of communication responses.

[0059] Next, based on the network signal strength, bandwidth parameters, and latency parameters, it is determined whether the current network state meets the conditions for high-quality transmission. These high-quality transmission conditions refer to a network environment with good performance and strong data transmission capabilities, allowing the system to perform high-priority or large-volume data transmission operations. For example, if the network signal strength is above a set threshold (e.g., >-70dBm), the bandwidth parameter is above a certain critical value (e.g., >10Mbps), and the communication latency is below an acceptable range (e.g., <50ms), then the network state is considered to meet the conditions for high-quality transmission and is suitable for large-capacity or real-time data transmission.

[0060] If the network condition meets the requirements for high-quality transmission, and the data type of the service data is the aforementioned urgent data, then the cached service data will be transmitted and uploaded to the server via the 4G / 5G channel to ensure the timely delivery of critical task data.

[0061] If the network condition meets the requirements for high-quality transmission and the data type of the business data is regular data, the cached business data will be transmitted to the server via the Wi-Fi channel to balance network resource usage and data transmission efficiency.

[0062] If the network condition meets the requirements for high-quality transmission and the data type of the business data is log data, the cached business data will be stored on the local disk, and the business data on the local disk will be uploaded to the server when the robot system is idle, thereby avoiding interference with real-time task communication and optimizing network bandwidth usage.

[0063] Through this network state awareness and type matching transmission control mechanism, on-demand scheduling, hierarchical transmission, and bandwidth optimization of business data uploads are achieved, effectively ensuring the stability and real-time performance of the robot system in complex communication environments.

[0064] If the network conditions described above do not meet the requirements for high-quality transmission, the amount of cached business data corresponding to the business data should be reduced when caching business data based on data type. This can be achieved through strategies such as compression, sampling, and filtering for different data types. For example, for routine sensor data, the sampling frequency can be appropriately reduced, retaining only data from critical moments or those showing significant changes; for log data, content filtering can be enabled, caching only error logs, abnormal events, or key operation records, omitting repetitive or low-value information; for large volumes of data such as images and point clouds, only core data content such as thumbnails and keyframes can be retained. By reducing the amount of cached data, excessive memory consumption and system resource strain caused by caching too much data can be avoided, improving system stability. Furthermore, it improves the data processing and transmission efficiency of the robot system under poor network conditions.

[0065] The data communication method for robot systems provided in this application employs a data monitoring mechanism using shared memory and a data acquisition proxy module. This avoids unnecessary communication protocol overhead, reduces CPU load, and improves communication efficiency. Furthermore, the use of shared memory and the data acquisition proxy module decouples data communication from main business processing, thereby reducing thread scheduling overhead. Additionally, through intelligent caching and hierarchical transmission control, data can be categorized and cached according to data type, enabling on-demand categorized storage and distribution of data. Automatic selection between uploading and local temporary storage based on network status ensures data integrity and reliability. Therefore, this method, through a data acquisition and cache upload separation mechanism, solves problems such as high bandwidth consumption, conflicts between real-time performance and flexibility, and high thread scheduling load in existing robot systems, significantly improving the system's communication efficiency and data management capabilities.

[0066] like Figure 3 As shown, Figure 3 This is a flowchart illustrating a data communication method for a robot system according to another embodiment of this application. The method is applied to a robot system and can be executed by the aforementioned front-end execution entity 10. The method includes: S201. When the robot system starts up, create a control structure to manage the state of the shared memory region.

[0067] This control structure, including metadata headers, flags, read / write indexes, etc., is used for the unified management of the shared memory region's status, such as coordinating the access of multiple business processes to the shared memory region, judging the read / write status, and controlling concurrency.

[0068] S202. Based on the parameters corresponding to the control structure, apply for a physical memory region of a preset size. The physical memory region is used to accept access from multiple business processes.

[0069] During the shared memory initialization phase, the system can calculate the total capacity of the required physical memory region based on memory management-related parameters in the control structure, such as the total size of the buffer, the size of each data slot, and the maximum number of data slots, and then request a physical memory region of the corresponding size from the operating system. This process can be implemented through system calls to relevant interfaces; for example, in Linux systems, memory allocation can be performed using the shmget or mmap functions.

[0070] For example, if each data slot is 4KB in size and a maximum of 256 data slots are allowed, the system will request approximately 1MB of data area space. It also needs to reserve space for the metadata area to store management information such as read / write indexes and status flags. Therefore, the actual physical memory area requested will be greater than 1MB. This mechanism of dynamically calculating and allocating memory based on parameters not only ensures the rational allocation of physical memory resources but also provides structured support for subsequent data writing and reading, facilitating efficient shared access between multiple processes.

[0071] S203. Divide the physical memory area into a metadata area and a data area. The metadata area is used to store parameters corresponding to the control structure, and the data area is used to store business data.

[0072] The physical memory area is logically divided into two parts: a metadata area and a data area. The metadata area stores control information, such as data write flags, timestamps, and data lengths. The data area stores actual business data, such as sensor data and control logs.

[0073] S204. Establish an access interface, which is used to support business processes to write and read operations on the shared memory area.

[0074] This access interface can be a wrapped function or an application programming interface (API) used to implement standardized read and write operations on shared memory regions. This interface shields the underlying memory operation implementation details, allowing business processes to interact with data without needing to concern themselves with the internal structure and management logic of shared memory, thereby improving system modularity and maintainability. For example, the write interface checks remaining space and updates control bits, simplifying data operations between business processes and improving code maintainability and security.

[0075] S205. Register the control structure, physical memory region, and access interface to the communication middleware to obtain a shared memory region for unified management and access.

[0076] After initializing the shared memory region, the system registers its key components, including the control structure, physical memory region, and access interfaces, with the communication middleware. This middleware, acting as a data coordination and transmission hub between various business modules in the system, can perceive and uniformly manage the shared memory region through the registration mechanism, thereby providing schedulable and accessible shared memory resource support for multiple business processes.

[0077] The shared memory region obtained in this embodiment can serve as a complete communication channel, which has a structural definition, physical carrier, and access mechanism, enabling cross-module data sharing, event triggering, and resource scheduling.

[0078] S206. When business data is detected to be generated, the business process requests write space from the shared memory area.

[0079] When the publisher detects the generation of business data, it requests write space from the shared memory region through the ZeroCopy API of ROS 2 (RobotOperating System 2, an open-source middleware platform for building robot software systems). It then directly writes the serialized data to the corresponding data area in the shared memory region, without first writing it to its own memory and then copying it to the communication channel. This write space is a contiguous memory area allocated to the publisher from the system's pre-allocated shared memory region for writing business data (such as sensor data and control commands). At this time, the control structure updates the corresponding write pointers and status flags. Since the data is directly located in the shared memory region, the data acquisition agent module (DataRecorder Agent), upon detecting a change in the metadata area, can directly read the data without copying it, using only pointers or mappings to complete data acquisition and caching. This process avoids multiple memory moves in the traditional copying and transmission links, significantly reducing system memory usage and CPU overhead.

[0080] S207. Based on the requested write space, the business process writes business data to the data area through the access interface, and updates the content of the metadata area when the business data writing is complete. Specifically, the metadata area is updated immediately after the write operation is completed, for example, by setting a data ready flag and updating the timestamp, so that subsequent listening modules can determine whether new data has been written.

[0081] S208. When the data acquisition agent module detects a change flag or data status change in the metadata area, it determines that business data has been written to the shared memory area and retrieves the business data from the data area through the access interface.

[0082] S209. Cache the business data according to its data type.

[0083] S210. Obtain the network status of the robot system, and upload the cached business data to the server or store it locally according to the network status and the data type of the business data.

[0084] Steps S201 to S205 above clarify the creation process of the shared memory region. By constructing a unified control structure, allocating physical memory, dividing the metadata area and data area, establishing access interfaces, and registering with the communication middleware, fine-grained management and efficient resource scheduling of the shared memory region's state are achieved. This provides a high-speed, low-latency shared data channel supporting concurrent access for multiple business processes, significantly reducing data copying frequency and memory usage, and improving data exchange efficiency and real-time response capabilities between modules within the robot system. Steps S206 to S207 above clarify the specific process by which business processes write business data into the shared memory region. After detecting the generation of business data, the business process actively requests write space from the shared memory, and after obtaining the write space, writes the business data into the data area while updating the status parameters (such as write pointer, data length, validity flag, etc.) in the metadata area, achieving efficient sharing of business data among multiple processes. Thus, a zero-copy, low-overhead data write path is achieved, avoiding repeated copy operations in traditional communication mechanisms, and significantly improving data write efficiency and system response speed. Steps S208 to S210 above clarify how the data acquisition agent module implements the entire process of data monitoring, caching, and upload control based on the shared memory mechanism. By monitoring changes in the flag bits of the metadata area in step S208, the data acquisition agent module does not need to actively poll but instead perceives data updates in an event-driven manner, thereby acquiring business data from the shared memory area. In step S209, a classification caching strategy is executed based on the data type of the business data (e.g., urgent data, regular data, log data, etc.), storing different types of data in memory, SSD, or HDD, improving data storage efficiency and access speed. In step S210, combined with the current network status of the robot system (e.g., signal strength, bandwidth, latency, etc.), a dynamic decision is made on whether to upload the cached data to the server in real time or temporarily store it locally. This method achieves low latency data acquisition, refined cache management, and intelligent control of data upload, effectively improving the data communication efficiency and operational stability of the robot system.

[0085] like Figure 4 As shown, Figure 4 This is a schematic diagram of a data communication device for a robot system provided in an embodiment of this application. The robot system is configured with a shared memory region and integrates a data acquisition agent module. The data communication device 30 for the robot system includes: The business data acquisition module 31 is used to acquire business data from the shared memory area when the data acquisition agent module detects that business data is being written to the shared memory area; the cache processing module 32 is used to cache the business data according to the data type; the data transmission module 33 is used to acquire the network status of the robot system and upload the cached business data to the server or store it locally according to the network status and the data type.

[0086] The data communication device 30 for the robot system described above can be a software module. The software module includes several instructions, which are stored in a memory. The processor can access the memory, call the instructions, and execute them to complete the data communication method for the robot system described in the above embodiments.

[0087] In some embodiments, the data communication device 30 for the robot system described above can also be constructed from hardware devices. For example, the data communication device 30 for the robot system can be constructed from one or more chips, and the chips can work together to complete the data communication method for the robot system described in the various embodiments above. As another example, the data communication device 30 for the robot system can also be constructed from various logic devices, such as general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), microcontrollers, ARM (Acorn RISC Machine) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or any combination of these components.

[0088] It should be noted that the data communication device 30 for robot systems described above can execute the data communication method for robot systems provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in the embodiments of the data communication device 30 for robot systems can be found in the data communication method for robot systems provided in the embodiments of this application.

[0089] like Figure 5 As shown, Figure 5 This is a schematic diagram of the structure of a robot provided in an embodiment of this application. The robot 40 includes one or more processors 41 and a memory 42. The memory 42 is connected to one or more processors 41, for example, via a bus.

[0090] Processor 41 is configured to support the robot 40 in performing the corresponding functions in the methods described in the above-described method embodiments. Processor 41 may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0091] Memory 42 is used to store program code, etc. Memory 42 may include volatile memory (VM), such as random access memory (RAM); memory may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 42 may also include combinations of the above types of memory.

[0092] The memory 42 can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the data communication method for robot systems in the embodiments of this application. The processor 41 executes the various functional applications and data processing of the data communication method for robot systems and the data communication device for robot systems by running the non-volatile software programs, instructions, and modules stored in the memory 42, that is, it realizes the functions of the various modules or units of the data communication method for robot systems and the data communication device for robot systems provided in the above method embodiments.

[0093] The memory 42 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and application programs required for at least one function. The data storage area may store data created based on the use of the data communication device for the robot system. In some embodiments, the memory 42 may include memory remotely located relative to the processor 41, and this remote memory may be connected to the data communication device for the robot system via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0094] The one or more modules are stored in the memory 42. When executed by the one or more processors 41, they execute the data communication method for robot systems in any of the above method embodiments. For example, they execute the method steps described in the above method embodiments to realize the functions of the modules described in the above device embodiments.

[0095] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 5 One of the processors 41 can enable the above one or more processors to execute the data communication method for robot systems in any of the above method embodiments, for example, to execute the method steps described in the above method embodiments and to implement the functions of the modules described in the above device embodiments.

[0096] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions, which, when executed by the robot, enable the robot to perform the data communication method for robot systems in any of the above method embodiments. For example, it can execute the method steps described in the above method embodiments to achieve the functions of the modules described in the above device embodiments.

[0097] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0098] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data communication method for robot systems, characterized in that, The robot system includes a shared memory region and a data acquisition agent module, and the method includes: When the data acquisition agent module detects that business data is being written to the shared memory area, it retrieves the business data from the shared memory area. The business data is cached according to its data type; The network status of the robot system is obtained, and the cached business data is uploaded to the server or stored locally based on the network status and the data type of the business data.

2. The method according to claim 1, characterized in that, The robot system further includes a data recording service module, and after obtaining the business data from the shared memory area, the method further includes: The business data is submitted to the data recording service module, which then preprocesses the business data to obtain preprocessed business data. The preprocessing includes data filtering and format conversion.

3. The method according to claim 1, characterized in that, Before retrieving the service data from the shared memory region, the method further includes: When the robot system starts up, a control structure is created to manage the state of the shared memory region; Based on the parameters corresponding to the control structure, a physical memory region of a preset size is requested, which is used to accept access from multiple business processes; The physical memory area is divided into a metadata area and a data area. The metadata area is used to store the parameters corresponding to the control structure, and the data area is used to store the business data. Establish an access interface, which is used to support business processes to write and read operations on the shared memory region; The control structure, the physical memory region, and the access interface are registered with the communication middleware to obtain a shared memory region for unified management and access.

4. The method according to claim 3, characterized in that, The method further includes: When the business data is detected to be generated, the business process requests write space from the shared memory area. According to the application's write space, the business process writes the business data into the data area through the access interface, and updates the content of the metadata area when the business data writing is completed; When the data acquisition agent module detects that business data is being written to the shared memory region, the process of retrieving the business data from the shared memory region includes: When the data acquisition agent module detects a change in the change flag or data status in the metadata area, it determines that business data has been written to the shared memory area and retrieves the business data from the data area through the access interface.

5. The method according to any one of claims 1 to 4, characterized in that, The data types include emergency data, regular data, and log data; wherein, emergency data refers to data that needs to be processed or transmitted immediately during the operation of the robot system, regular data refers to data that is periodically or continuously collected and recorded in the robot system, and log data is data used to record the operation history and operation records during the operation of the robot system; the caching of business data according to the data type of the business data includes: When the data type of the business data is the emergency data, the business data is stored in the memory cache; When the data type of the business data is the regular data, the business data is stored in a solid-state drive; When the data type of the business data is log data, the business data is stored in the hard disk drive.

6. The method according to claim 5, characterized in that, After caching the business data according to its data type, the method further includes: The cached business data is compressed and encrypted to obtain compressed and encrypted cached data; The compressed and encrypted cached data is hashed to obtain the hash value corresponding to the compressed and encrypted cached data; The hash value is stored in the blockchain.

7. The method according to claim 5, characterized in that, The step of obtaining the network status of the robot system and, based on the network status and the data type of the business data, uploading the cached business data to the server or storing it locally includes: Obtain the network signal strength, bandwidth parameters, and delay parameters of the robot system; The network status of the robot system is determined based on the network signal strength, the bandwidth parameter, and the delay parameter. If the network condition meets the high-quality transmission requirements and the data type of the service data is the urgent data, the cached service data will be transmitted and uploaded to the server through a fourth-generation mobile communication technology or a fifth-generation mobile communication technology channel. If the network condition meets the high-quality transmission requirements and the data type of the service data is the regular data, the cached service data will be transmitted and uploaded to the server through the wireless LAN channel. When the network condition meets the high-quality transmission requirements and the data type of the service data is log data, the cached service data is stored in the local disk, and the service data in the local disk is uploaded to the server when the robot system is idle.

8. The method according to claim 7, characterized in that, The method further includes: If the network condition does not meet the high-quality transmission conditions, when caching the service data according to the data type of the service data, the amount of cached data corresponding to the service data shall be reduced.

9. A data communication device for robot systems, characterized in that, The robot system includes a shared memory region and a data acquisition agent module, and the device includes: The business data acquisition module is used to acquire the business data from the shared memory region when the data acquisition agent module detects that business data is being written to the shared memory region. A cache processing module is used to cache the business data according to the data type of the business data; The data transmission module is used to obtain the network status of the robot system, and upload the cached business data to the server or store it locally according to the network status and the data type of the business data.

10. A robot, characterized in that, include: The memory is coupled to the robot system; A processor, the memory being connected to the processor, the processor being configured to execute one or more computer programs stored in the memory, the processor, when executing the one or more computer programs, causing the robot to implement the data communication method for a robot system as described in any one of claims 1-8 based on a robot system coupled to the memory.

Images