Redundant data processing and transmission methods and systems for FPGA-ROS

Abstract

This invention provides a method and system for redundant data processing and transmission in FPGA-ROS, relating to the field of robot operating system communication. The method executes input and output processing flows in parallel within the FPGA: in the input flow, newly received ROS topics are compared with historical topics; if the content differs, it is stored in main memory; otherwise, it is discarded. In the output flow, topics are read from main memory and sent according to a preset mode. In the non-timing mode, a second comparison is performed before transmission to filter redundancy, and topics oriented towards the executor can be translated into instruction format. This invention implements dual redundancy filtering and instruction conversion in hardware, significantly reducing storage and bandwidth overhead and improving system processing efficiency and compatibility.

Description

Technical Field

[0001] This invention relates to the field of robot operating system communication technology, and in particular to a method and system for redundant data processing and transmission in FPGA-ROS. Background Technology

[0002] Robot Operating Systems (ROS), as a modular and highly flexible open-source architecture, have been widely used in automation, robotics, and embedded systems. On heterogeneous multi-core hardware platforms, such as those composed of a central processing unit and a field-programmable gate array (FPGA), ROS can implement complex functions such as posture control, autonomous navigation, data processing, and multi-platform collaboration.

[0003] However, in many embedded applications with high real-time requirements and limited hardware resources, especially storage space and processing power, traditional robot operating system communication architectures face severe challenges. The system may contain a large number of repetitive or unchanging robot operating system topics generated by sensors or upper-layer application nodes. The continuous transmission and storage of these redundant topics not only quickly depletes valuable storage resources but also continuously occupies communication bus bandwidth, increases data transmission latency, and burdens the main processor.

[0004] Existing technologies utilize field-programmable gate arrays (FPGAs) to accelerate robot operating system communication, such as by implementing protocol parsing and data routing in hardware to improve forwarding speed. However, these solutions primarily focus on the rapid transmission of data packets and do not delve into the data content level for processing, failing to fundamentally address the data storm problem caused by content redundancy. Therefore, current technologies still lack an effective means to proactively identify and filter redundant robot operating system content, thereby comprehensively optimizing storage, bandwidth, and processing efficiency in resource-constrained environments. Summary of the Invention

[0005] In view of the deficiencies in the prior art, the purpose of this invention is to provide a method and system for redundant data processing and transmission in FPGA-ROS.

[0006] According to the present invention, a redundant data processing and transmission method for FPGA-ROS is provided, wherein the method is executed in a hardware accelerator implemented by FPGA, including main memory, first cache and second cache;

[0007] The method includes parallel input processing and output processing flows: The input processing flow includes: Receive new ROS topics from ROS publisher nodes; The new ROS topic is compared with the previous historical ROS topic for the same target stored in the first cache. If the content is inconsistent, the new ROS topic is written to the main memory, and the historical ROS topic in the first cache is updated with the new ROS topic; if the content is consistent, the new ROS topic is discarded. The output processing flow includes: According to the preset sending pattern for the target, read the ROS topic from the main memory; When the sending mode is a non-timed sending mode, before sending, the content of the ROS topic to be sent is compared with the previous historical ROS topic stored in the second cache that has been sent to the same target. If the content is consistent, the sending is canceled. If the sending is not cancelled, the sending step is executed, which includes: If the target of the ROS topic is an executor, then the format of the ROS topic is translated into an execution instruction format that the executor can recognize, and the translated execution instructions are sent to the executor. If the target of the ROS topic is a ROS subscriber node, then the ROS topic is sent to that ROS subscriber node. Furthermore, after sending, the previous historical ROS topic for the same target in the second cache is updated using the ROS topic sent this time.

[0008] Furthermore, the content comparison includes: The first level involves validating the metadata of the ROS topic. Furthermore, at the second level, provided that the metadata verification is consistent, the core data portion of the ROS topic is verified using a hash verification algorithm.

[0009] Furthermore, the hash verification algorithm is the Cyclic Redundancy Check (CRC32) algorithm.

[0010] Furthermore, the preset sending mode includes a timed sending mode and a non-timed sending mode; Furthermore, the method also includes: Based on the preset differentiated configurations for different targets, the corresponding sending mode and / or sending frequency are used for transmission.

[0011] Furthermore, the differentiated configuration includes: configuring high-frequency timed transmission of 10Hz-100Hz for high-priority targets, configuring regular timed transmission of 1Hz-10Hz for regular targets, and configuring non-timed transmission for non-real-time targets.

[0012] Furthermore, the main memory includes the SRAM built into the FPGA and external non-volatile memory as persistent storage.

[0013] Furthermore, the communication interface between the FPGA and the ROS publisher node, executor, or ROS subscriber node supports multi-protocol adaptation, including at least one of Ethernet / IP, PCIe, CAN FD, and UART.

[0014] Furthermore, the communication process employs hardware-level flow control and / or AES-128 algorithm for data encryption.

[0015] A redundant data processing and transmission system for FPGA-ROS provided by the present invention includes an FPGA accelerator, wherein the FPGA accelerator comprises: Main memory; First cache; Second cache; The input processing module is used to receive new ROS topics from the ROS publisher node; ROS topic comparator is used to compare the content of the new ROS topic with the previous historical ROS topic for the same target stored in the first cache. A memory read / write controller is configured to write the new ROS topic to the main memory when the content comparison result is inconsistent, and to update the historical ROS topic in the first cache with the new ROS topic; The output ROS topic controller is used to read ROS topics from the main memory according to the preset sending mode for the target, and when the sending mode is a non-timed sending mode, instruct the ROS topic comparator to compare the ROS topic to be sent with the historical ROS topics stored in the second cache. If the contents are consistent, the sending is canceled. If the sending is not canceled, the sending module is instructed to send, and after the sending, the second cache is updated with the ROS topic sent this time. A ROS topic converter, used to translate the format of the ROS topic into an execution instruction format recognizable by the executor when the target of the ROS topic is an executor; and The sending module is used to send the execution instructions translated by the ROS topic converter to the executor when the target of the ROS topic is the executor; and to send the ROS topic to the ROS subscriber node when the target of the ROS topic is the ROS subscriber node.

[0016] Furthermore, the system also includes: ROS publisher node; And executor and / or ROS subscriber nodes; The device is configured to connect to the ROS publisher node and the executor and / or ROS subscriber node to process ROS topics sent by the ROS publisher node, send translated execution instructions to the executor, and send ROS topics read from the main memory to the ROS subscriber node.

[0017] Compared with the prior art, the present invention has the following beneficial effects: By implementing redundant filtering at the input end in the FPGA hardware, only ROS topics whose content changes are stored in the main memory, thus avoiding the storage of a large amount of duplicate data from the source and significantly reducing storage pressure.

[0018] By employing redundant filtering and flexible transmission strategies at the output end, data transmission is ensured only when content is updated or on demand, effectively reducing invalid data traffic on the bus or network, thereby lowering communication bandwidth usage and end-to-end data transmission latency.

[0019] By offloading heavy and repetitive data comparison and filtering tasks from the main processor to parallel processing on the FPGA, the main processor can focus on higher-level decision-making and computing tasks, significantly improving the hardware utilization efficiency and real-time response capability of the entire heterogeneous system.

[0020] With its built-in hardware instruction translation function, the standard ROS system can seamlessly control various non-ROS native hardware actuators, expanding the system's application scope and integration flexibility. Attached Figure Description

[0021] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A system structure framework diagram provided for embodiments of the present invention; Figure 2 This is a schematic diagram of the method flow provided in an embodiment of the present invention; Figure 3 The signaling interaction timing diagram provided for embodiments of the present invention.

[0022] Among them: 100-FPGA accelerator; 101-Input ROS topic queue buffer; 102-ROS topic comparator; 103-ROS topic buffer to be compared; 104-Memory read / write controller; 105-Output ROS topic controller; 106-Output ROS topic buffer; 107-ROS topic converter. Detailed Implementation

[0023] The present invention will now be described in detail with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0024] Example 1 This invention provides a method and system for redundant data processing and transmission in FPGA-ROS. As an optional implementation, this solution uses hardware acceleration to perform dual filtering of redundant robot operating system topics at the beginning of data inflow into the system and before data outflow, and achieves flexible transmission control. It aims to significantly reduce storage overhead, communication bandwidth usage, and data transmission latency in embedded environments with limited hardware resources.

[0025] Please see Figure 1 This diagram illustrates the system architecture framework of a robot operating system (ROS) according to an embodiment of the present invention. Figure 1 As shown, the system may include a ROS publisher node, an FPGA accelerator 100 as the core processing unit, a main memory, one or more executors, and one or more ROS subscriber nodes.

[0026] In this system, ROS publisher nodes act as data sources, such as cameras, LiDAR, inertial measurement units, or central processing units running higher-level algorithms. They generate and publish ROS topics according to the ROS communication protocol. Actors are the physical action units of the system, such as motors, servos, and flywheel systems. These units typically do not directly support the ROS protocol but need to receive control commands to perform specific actions. ROS subscriber nodes are the data consumers in the system, such as nodes used for data display, logging, or further algorithmic processing. They subscribe to and receive ROS topics of interest.

[0027] The core of this embodiment lies in the FPGA accelerator 100, which serves as the data processing hub between ROS publisher nodes and executor / ROS subscriber nodes. This FPGA accelerator 100 achieves efficient data stream processing through hardware logic circuits, offloading the heavy data comparison and filtering tasks traditionally performed by the central processing unit (CPU), thereby freeing up CPU resources. Figure 1 As shown, the FPGA accelerator 100 integrates a series of functional modules to collaboratively complete the technical solution of this invention. These modules may include: The input ROS topic queue cache 101 can be configured as a first-in-first-out hardware cache to temporarily store new ROS topics received from the ROS publisher node, thereby smoothing out the input data flow.

[0028] The ROS topic comparator 102, as a core hardware logic unit, is responsible for high-speed comparison of the contents of two ROS topics. In one implementation of the present invention, this comparator can be reused for redundant judgments at the input and output ends.

[0029] The ROS topic cache 103, also known as the first cache, is used to store historical ROS topics that serve as the comparison benchmark during the input processing flow. Specifically, for each target identified by its target ID or name, this cache stores the previous ROS topic that was determined to be valid (i.e., non-redundant in content).

[0030] The memory read / write controller 104 is responsible for managing the data exchange between the FPGA accelerator 100 and the external main memory. Based on the judgment result of the ROS topic comparator 102, it controls whether to write new ROS topics into the main memory and is responsible for reading topics to be sent from the main memory in the output process.

[0031] The output ROS topic controller 105 serves as the control core for the output data stream. Based on the pre-configured transmission strategy, this module determines when and how to read data from the main memory and initiate the transmission process. It supports multiple transmission modes, including timed transmission and non-timed transmission.

[0032] The output ROS topic cache 106, also known as the second cache, is used to store historical ROS topics used as comparison benchmarks in the output processing flow. Specifically, this cache stores the last successfully sent ROS topic for each different target.

[0033] ROS Topic Converter 107 is responsible for protocol conversion. When the target of a ROS topic is an executor, the converter translates the standard ROS topic format (e.g., a structured message containing information such as speed and position) into the underlying hardware instruction format (e.g., a specific format of CAN bus message or PWM signal parameters) that the specific executor can recognize and execute before sending.

[0034] The following will combine Figure 2 The flowchart shown illustrates the working method of this embodiment in detail. This method executes the input processing flow and the output processing flow in parallel within the FPGA accelerator 100.

[0035] The input processing flow aims to achieve redundancy filtering before data storage. Specifically, in step S101, when the FPGA accelerator 100 receives a new ROS topic from a ROS publisher node through its communication interface (e.g., Ethernet interface or PCIe interface), it temporarily stores it in the input ROS topic queue cache 101. Correspondingly, the ROS topic comparator 102 retrieves the new topic from the input ROS topic queue cache 101 and, based on its target identifier (e.g., the target node name contained in the topic name), reads the previous historical ROS topic for the same target from the comparison ROS topic cache 103. In step S102, the ROS topic comparator 102 performs a hardware comparison of the core data content of the new ROS topic and the historical ROS topic. In step S103, a judgment is made based on the comparison result. If the two contents are completely identical, the new ROS topic is determined to be a redundant topic, and the FPGA accelerator 100 will directly discard it without any further processing. This method prevents redundant data from entering the main memory at the source. Conversely, if the contents of the two are inconsistent, the new ROS topic is determined to be a valid topic. In the case of inconsistent contents, the process proceeds to step S104, where the memory read / write controller 104 writes this valid new ROS topic into the main memory via the bus for storage. At the same time, this new ROS topic will also be used to update the historical ROS topic record of the corresponding target in the ROS topic cache 103 to be compared, so as to serve as the benchmark for the next comparison.

[0036] The output processing flow runs in parallel and independently with the input processing flow, responsible for retrieving data from the main memory according to a strategy and sending it efficiently. This flow is led by the output ROS topic controller 105. In step S201, the controller first determines the preset transmission mode for the current target, which can be preset by the upper-layer software through a configuration interface. In the "timed transmission mode," the output ROS topic controller 105 will periodically instruct the memory read / write controller 104 to read the latest ROS topic of the target from the main memory according to a specific transmission frequency (e.g., 100Hz) configured for the target. The read topic will directly enter the subsequent transmission steps (S204 to S206). It can be understood that this mode ensures the real-time updating of the target's data; even if the content has not changed, the latest status will be sent periodically. In the "non-timed transmission mode," the controller only initiates a transmission process when it detects a new topic to be sent in the main memory (e.g., a flag is generated when a new topic is written by the input flow). In step S202, the ROS topic to be sent is read from the main memory. The key is that a redundancy filter is performed at the output end before the actual transmission. Specifically, in step S203, the output ROS topic controller 105 instructs the ROS topic comparator 102 to compare the content of the topic to be transmitted, read from the main memory, with the previous historical ROS topic successfully transmitted to the same target, stored in the output ROS topic cache 106. If the comparison result shows that the content is consistent, it means that although the data in the memory has been updated, it is unchanged from the data previously sent to the target. Therefore, this transmission is determined to be redundant and canceled, thereby avoiding the repeated transmission of the same data on the communication bus.

[0037] The process continues only in timed transmission mode or when the comparison result in inconsistent content (i.e., transmission is not cancelled) in non-timed transmission mode. In step S204, the target type of the ROS topic is determined. If the target is an executor, the process proceeds to step S205, where the ROS topic is sent to the ROS topic converter 107. The converter translates the topic into an execution instruction recognizable by the executor according to preset conversion rules. For example, a ROS Twist topic containing linear velocity and angular velocity fields may be translated into a CAN bus message containing a specific ID and data bytes. In step S206, the translated execution instruction or the original ROS topic (when the target is a ROS subscriber node) is sent to the corresponding target. It should be noted that after each successful transmission (regardless of whether it has been translated), the transmitted ROS topic is used to update the historical record of the corresponding target in the output ROS topic cache 106, preparing for redundant comparisons in the next non-timed transmission mode.

[0038] Please see Figure 3 This demonstrates the signaling interaction timing in a specific scenario of this embodiment. Initially, a ROS publisher node publishes a new topic with the content "Theme_A". After receiving it, the FPGA accelerator 100 determines that it is a valid topic through internal content comparison and performs a write-to-mem operation. Subsequently, depending on its output configuration for different targets, the FPGA accelerator 100 can execute multiple sending tasks simultaneously: for example, it sends a control command translated from "Theme_A" (send_cmd(Cmd_A)) to an executor in a high-frequency timing mode (such as 100Hz loop); at the same time, due to the change in content, it sends the original topic (send_theme(Theme_A)) to a ROS subscriber node in a non-timing mode (event-triggered). Later, when the ROS publisher node publishes another topic with content identical to Theme_A (publish(Theme_A_redundant)), the FPGA accelerator 100 determines it to be redundant during content comparison in the input processing flow and immediately discards it. As shown in the timing diagram, this publication of the redundant topic did not trigger any writes to main memory, nor did it trigger any sending to the executor or ROS subscriber nodes, thus verifying the beneficial effects of this solution in filtering redundant data and saving storage and bandwidth.

[0039] Example 2 This embodiment, based on embodiment 1, improves upon the "content comparison" logic implemented internally by the ROS topic comparator 102 (such as...). Figure 2 Steps S102 and S203 in the above steps provide a more specific and efficient preferred solution. In order to perform content comparison of potentially very large ROS topics (such as high-definition images, LiDAR point clouds) with extremely low latency in the FPGA, this embodiment employs a two-level verification mechanism.

[0040] As an optional implementation, the two-level verification mechanism can be implemented by the hardware logic of the ROS topic comparator 102, which specifically includes a first-level verification and a second-level verification.

[0041] The first level of verification is metadata verification. When the ROS topic comparator 102 needs to compare a new ROS topic and a historical ROS topic, it first extracts and compares the metadata fields of the two topics, rather than directly comparing the massive data load. This metadata is usually located in the header of the ROS topic message, with a fixed and short length, making it very suitable for fast parallel comparison by hardware. In this embodiment, metadata verification specifically includes comparing the following items: 1. Target Identifier: Compare whether the target identifiers of the two topics are consistent. This identifier can be the hash value of the target's ROS node name string, or a unique integer ID assigned to each target during system configuration. 2. Data Type Definition: Compare whether the message types of the two topics are consistent, for example, whether they are both "sensor_msgs / Image" or "geometry_msgs / Twist". This step is usually achieved by comparing the message type name string or its MD5 hash value. 3. Data Structure Definition Hash: Compare the message definition hash values ​​of the two topics. The ROS system generates a unique hash value for each message definition. If the hash values ​​of the two topics are different, it means that their data structures are incompatible, and the content must be different.

[0042] Only when all the aforementioned metadata fields are completely identical are the two topics considered potentially identical, and the process proceeds to the second level of verification. If any metadata field does not match, the ROS topic comparator 102 will immediately determine that the two topics are inconsistent and end the comparison process. This design can quickly eliminate the vast majority of obviously different topics, greatly reducing the number of heavyweight comparisons required.

[0043] The second level of verification is the core data hash verification. It's important to note that this second level verification is only triggered after the first level of metadata verification has passed. It verifies the actual core data payload within the ROS topic. To avoid slow, byte-by-byte serial comparisons of potentially megabytes of data, this embodiment employs a highly efficient hash verification algorithm.

[0044] Specifically, the ROS topic comparator 102 integrates a hardware-implemented hash calculation engine. In this preferred embodiment, the engine implements the Cyclic Redundancy Check (CRC32) algorithm. When a second-level check is required, the core data payload of the new ROS topic and the core data payload of the historical ROS topic are streamed into the CRC32 calculation engine, and their respective 32-bit hash values ​​(i.e., checksums) are calculated in parallel. Subsequently, the hardware comparator only needs to compare these two 32-bit hash values. If the two hash values ​​are exactly the same, the core data content of the two ROS topics is determined to be consistent with a very high probability (and a very low probability of collision); if the hash values ​​are different, the content is determined to be inconsistent.

[0045] Taking a specific workflow as an example: A camera node with a publishing frequency of 30Hz continuously publishes image topics with a resolution of 1920x1080. When a new image topic arrives at the FPGA accelerator 100, the ROS topic comparator 102 first performs a first-level verification, checking its target and message type metadata. After passing the verification, it proceeds to the second-level verification. The hardware CRC32 engine begins processing the approximately 6MB data load of the image topic, calculating a 32-bit hash value within microseconds, and comparing it with the pre-stored CRC32 hash value of the previous valid image frame read from the ROS topic cache 103. By comparing these two 32-bit integers, the consistency of the content can be determined instantly. Compared to the milliseconds required for the central processing unit to perform a byte-by-byte comparison of 6MB of memory data, the FPGA's hardware hash verification method greatly improves the comparison speed and efficiency, ensuring that the system can handle high-frequency, large-volume ROS topic streams without creating a processing bottleneck.

[0046] Understandably, by adopting this two-level verification mechanism, this embodiment achieves extremely high comparison performance while ensuring comparison accuracy, giving full play to the advantages of FPGA parallel computing, and providing a solid foundation for the high throughput and low latency characteristics of the entire technical solution.

[0047] Example 3 This embodiment, building upon Embodiment 1, elaborates in detail how the output ROS topic controller 105 implements differentiated and refined transmission strategies. In complex robotic applications, different target nodes have vastly different real-time data requirements. For example, motor control commands require extremely high update frequency and determinism, while status information used for log recording can be updated at a lower frequency. This embodiment aims to meet these diverse needs while maximizing the utilization of bandwidth resources.

[0048] The core of this solution lies in outputting a configurable routing and scheduling table maintained internally by the ROS topic controller 105. This table is typically implemented using block random access memory within the FPGA, and its contents can be programmed by the main processor via a dedicated configuration bus (such as the AXI-Lite bus) during system startup or runtime. Correspondingly, upper-layer application software can easily define transmission strategies in a high-level format (such as a JSON file), which are then parsed by the driver and written into the FPGA's routing table.

[0049] Each row in this routing table corresponds to a transmission target and contains a series of parameters defining the transmission behavior of that target. A typical table structure may include the following fields: 1. Target ID: A unique identifier used to index a specific executor or ROS subscriber node. 2. Transmission Enable Bit: Used to globally enable or disable transmission to this target. 3. Transmission Mode Field: Used to select "timed transmission mode" or "non-timed transmission mode". 4. Transmission Frequency Parameter: When the mode is "timed transmission", this field defines the transmission frequency. For example, it can be a frequency divider count value, and the reference clock in the FPGA will generate periodic transmission trigger signals based on this count value. 5. Output Redundancy Filtering Enable Bit: Used to determine whether to perform a comparison with the output ROS topic buffer 106 in non-timed transmission mode. In some special applications, if it is desired to force the transmission of the first message triggered by the event even if the content has not changed, this function can be disabled.

[0050] Based on the configurable routing table described above, the output ROS topic controller 105 can execute drastically different sending strategies for different targets. The following section illustrates its operation using a specific vehicle-mounted autonomous navigation scenario: In a specific application scenario, the following transmission strategy can be defined in the configuration file before system startup and loaded into the FPGA accelerator 100: 1. High-priority executor configuration: The target is the vehicle's steering motor controller (motor_A) and drive motor controller (motor_B). Given their extremely high real-time requirements, to ensure smooth and precise motion control of the vehicle, they are configured with a high-frequency timed transmission mode, with a transmission frequency set to 100Hz. Correspondingly, in the routing table, the transmission mode field in the corresponding entries for motor_A and motor_B is set to "timed," with a transmission frequency parameter of 100Hz. 2. Regular ROS subscriber node configuration: The target is a monitoring node (path_visualizer) for path planning visualization and a log node (logger_node) for recording system status. These nodes require near real-time updates but are not critical to control; therefore, they are configured with a regular timed transmission mode, with a transmission frequency set to 10Hz. 3. Non-real-time requirement node configuration: The target is a status display node (status_display) used to display the vehicle's current mode (e.g., "Autonomous Driving" or "Manual Mode") on the human-machine interface. Since the vehicle mode does not usually change frequently, it is configured to send data in a non-timed mode to save bandwidth.

[0051] During system operation, the internal scheduling logic of the output ROS topic controller 105 serves each target in parallel: for motor_A and motor_B, an independent timer within the controller can be configured to generate a trigger signal every 10 milliseconds. Each trigger instructs the memory read / write controller 104 to read the latest vehicle control topic from main memory, then instructs the ROS topic converter 107 to translate it into the CAN bus message required by the motor controller and send it immediately, ensuring that the motor control commands are refreshed at a deterministic frequency of 100Hz. For path_visualizer and logger_node, two additional timers trigger a transmission process every 100 milliseconds, sending out the latest path planning and system status topics. For status_display, the controller does not use a timer, but instead monitors a flag maintained by the input processing flow. This flag is only set when a new topic with non-redundant content and a target of status_display is written to main memory. The controller will initiate a sending process for status_display only after detecting this flag. This process also includes an output redundancy filtering step that compares the output ROS topic cache 106.

[0052] Through this differentiated transmission strategy, this embodiment achieves refined management of system communication resources. It can meet the stringent requirements of high-frequency, deterministic data updates for hard real-time tasks such as motor control, while avoiding unnecessary and bandwidth-wasting frequent data transmissions for non-real-time nodes such as status displays. Thus, while meeting the diverse needs of complex application scenarios, it further optimizes the resource allocation and operating efficiency of the entire system.

[0053] Example 4 Based on Example 1, this embodiment has undergone in-depth optimization of the physical implementation of the system, especially the memory architecture and communication interface, in order to build a hardware system architecture with high throughput, high reliability and high security to adapt to harsh industrial, aviation or autonomous driving application environments.

[0054] First, regarding the memory architecture, this embodiment... Figure 1 The "main memory" shown adopts a "cache-persistent" two-level storage architecture to balance data access speed, storage capacity, and non-volatility.

[0055] The primary storage can be configured as a high-speed cache located within the FPGA accelerator 100, specifically composed of static random access memory integrated on the FPGA chip, such as block random access memory or very large-scale random access memory. This memory is directly connected to the FPGA's logic circuitry and has extremely low read / write latency in the nanosecond range. In this solution, it is mainly used to store frequently accessed hot data. For example, the output ROS topic controller 105 can cache the latest ROS topics that are about to be sent to the executor in a high-frequency timing mode here, thus avoiding reading from slower external memory each time. Similarly, the two key caches for high-speed comparison, the ROS topic cache 103 to be compared and the output ROS topic cache 106, are also implemented entirely using internal static random access memory.

[0056] Secondary storage is an external non-volatile memory used for persistent storage. It can be a NAND Flash chip soldered onto a circuit board or a solid-state drive connected via a SATA or NVMe interface. Its main function is to permanently store all valid ROS subject data after input redundancy filtering, for complete system status recording, post-event analysis, debugging, or system failure recovery.

[0057] In this embodiment, the memory read / write controller 104 is enhanced, acting as a data scheduler in the secondary storage architecture. It not only writes non-redundant data to secondary storage but also implements a series of I / O optimization mechanisms. For example, it can employ "write merging" technology, merging multiple small data block write requests to secondary storage within a short period into a larger data block in the internal cache before writing it all at once. This significantly improves write efficiency and extends the lifespan of the flash memory. It can also support "read-ahead caching," which, based on the principle of locality of access, speculatively reads adjacent data from secondary storage into the FPGA's internal primary cache before the central processing unit or output controller requests certain data, thereby reducing latency during actual access.

[0058] Secondly, regarding the communication interface, the FPGA accelerator 100 in this embodiment is designed to support multi-protocol adaptation to enhance system connectivity and compatibility. The flexibility of the FPGA allows its I / O pins and internal high-speed transceivers to be programmed to implement various mainstream communication protocol standards. For example, the FPGA accelerator 100 can be configured to communicate with upstream ROS publisher nodes (such as high-performance CPUs or image sensors) using a high-speed PCIe 4.0 interface to meet the bandwidth requirements of large data volumes (such as LiDAR point clouds). Different interfaces can be configured between the FPGA accelerator 100 and downstream actuators, depending on the type of actuator. For motor controllers in industrial or automotive environments, a stable and reliable CAN FD bus interface can be used. For network communication with other ROS subscriber nodes, a gigabit or 10-gigabit Ethernet interface can be used, supporting industrial Ethernet protocols such as Ethernet / IP. A universal UART interface can also be provided for some low-speed configuration or debugging needs.

[0059] To further enhance the reliability and security of communication, this embodiment integrates additional safeguards in the hardware implementation of the communication interface. Firstly, for serial communication, a hardware-level flow control mechanism is employed. Taking UART communication as an example, the FPGA's UART controller hardware can directly handle the handshake logic between the RTS and CTS signals. When the receive buffer is about to fill, the hardware automatically pulls the CTS signal low to notify the other party to pause transmission, thus physically preventing data loss due to untimely processing. Secondly, to ensure the security of sensitive data (such as control commands and confidential sensor data) during transmission, this embodiment integrates a hardware-implemented AES-128 encryption engine on the data transmission path. When the output ROS topic controller 105 sends a topic or command requiring encryption to the communication interface module, the AES engine encrypts it using a preset key before the data is sent to the physical layer. Correspondingly, the receiver also needs decryption capabilities. This hardware-level encryption and decryption process is extremely fast, adding almost no additional transmission delay, providing robust data security for the system.

[0060] In summary, by adopting a two-level storage architecture and a communication interface that supports multiple protocols, high reliability, and high security, this embodiment constructs a powerful and robust hardware platform, enabling the redundancy processing and transmission scheme proposed in this invention to meet the stringent requirements of various advanced application scenarios with demanding performance, stability, and security requirements.

[0061] Specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the specific embodiments described above, and those skilled in the art can make various changes or modifications within the scope of the claims, which do not affect the essence of the present invention. Unless otherwise specified, the embodiments and features of the present invention can be arbitrarily combined with each other.

Claims

1. A method for redundant data processing and transmission in FPGA-ROS, characterized in that, The method is executed in a hardware accelerator implemented by an FPGA, including main memory, a first cache, and a second cache; The method includes parallel input processing and output processing flows: The input processing flow includes: Receive new ROS topics from ROS publisher nodes; The new ROS topic is compared with the previous historical ROS topic for the same target stored in the first cache. If the content is inconsistent, the new ROS topic is written to the main memory, and the historical ROS topic in the first cache is updated with the new ROS topic; if the content is consistent, the new ROS topic is discarded. The output processing flow includes: According to the preset sending pattern for the target, read the ROS topic from the main memory; When the sending mode is a non-timed sending mode, before sending, the content of the ROS topic to be sent is compared with the previous historical ROS topic stored in the second cache that has been sent to the same target. If the content is consistent, the sending is canceled. If the sending is not cancelled, the sending step is executed, which includes: If the target of the ROS topic is an executor, then the format of the ROS topic is translated into an execution instruction format that the executor can recognize, and the translated execution instructions are sent to the executor. If the target of the ROS topic is a ROS subscriber node, then the ROS topic is sent to that ROS subscriber node. Furthermore, after sending, the previous historical ROS topic for the same target in the second cache is updated using the ROS topic sent this time.

2. The method according to claim 1, characterized in that, The content comparison includes: The first level involves validating the metadata of the ROS topic. Furthermore, at the second level, provided that the metadata verification is consistent, the core data portion of the ROS topic is verified using a hash verification algorithm.

3. The method according to claim 2, characterized in that, The hash verification algorithm is the Cyclic Redundancy Check (CRC32) algorithm.

4. The method according to claim 1, characterized in that, The preset sending modes include timed sending mode and non-timed sending mode; Furthermore, the method also includes: Based on the preset differentiated configurations for different targets, the corresponding sending mode and / or sending frequency are used for transmission.

5. The method according to claim 4, characterized in that, The differentiated configurations include: configuring high-frequency timed transmission of 10Hz-100Hz for high-priority targets, configuring regular timed transmission of 1Hz-10Hz for regular targets, and configuring non-timed transmission for non-real-time targets.

6. The method according to claim 1, characterized in that, The main memory includes the SRAM built into the FPGA and external non-volatile memory as persistent storage.

7. The method according to claim 1, characterized in that, The communication interface between the FPGA and the ROS publisher node, executor, or ROS subscriber node supports multi-protocol adaptation, including at least one of Ethernet / IP, PCIe, CAN FD, and UART.

8. The method according to claim 7, characterized in that, The communication process employs hardware-level flow control and / or AES-128 algorithm for data encryption.

9. A redundant data processing and transmission system for FPGA-ROS, characterized in that, Includes an FPGA accelerator, the FPGA accelerator comprising: Main memory; First cache; Second cache; The input processing module is used to receive new ROS topics from the ROS publisher node; ROS topic comparator is used to compare the content of the new ROS topic with the previous historical ROS topic for the same target stored in the first cache. A memory read / write controller is configured to write the new ROS topic to the main memory when the content comparison result is inconsistent, and to update the historical ROS topic in the first cache with the new ROS topic; The output ROS topic controller is used to read ROS topics from the main memory according to the preset sending mode for the target, and when the sending mode is a non-timed sending mode, instruct the ROS topic comparator to compare the ROS topic to be sent with the historical ROS topics stored in the second cache. If the contents are consistent, the sending is canceled. If the sending is not canceled, the sending module is instructed to send, and after the sending, the second cache is updated with the ROS topic sent this time. A ROS topic converter, used to translate the format of the ROS topic into an execution instruction format recognizable by the executor when the target of the ROS topic is an executor; and The sending module is used to send the execution instructions translated by the ROS topic converter to the executor when the target of the ROS topic is the executor; and to send the ROS topic to the ROS subscriber node when the target of the ROS topic is the ROS subscriber node.

10. The system according to claim 9, characterized in that, The system also includes: ROS publisher node; And executor and / or ROS subscriber nodes; The device is configured to connect to the ROS publisher node and the executor and / or ROS subscriber node to process ROS topics sent by the ROS publisher node, send translated execution instructions to the executor, and send ROS topics read from the main memory to the ROS subscriber node.

Images