Ddss types based ros2 communication testing method and system

Abstract

The application relates to the technical field of electronic communication testing, and discloses a ROS 2 communication testing method and system based on DDS XTypes, wherein the method comprises the following steps: based on a DDS discovery protocol, a target ROS 2 communication domain is joined by subscribing to a built-in topic; all topics and endpoint information in the target ROS 2 communication domain are discovered online; through a type lookup mechanism of DDS Xtypes, a type object request is initiated to a target endpoint, type information of a target topic corresponding to the target endpoint is dynamically acquired; complete definitions of all dependent types contained in a complete type object are recursively pulled, and type structure information with a hierarchical structure is constructed; according to a test case requirement, a memory sample is dynamically constructed based on the type structure information, a target ROS 2 communication domain is injected through a data writer created dynamically, a business scenario is simulated to perform communication testing, and a communication testing result is output.

Description

Technical Field

[0001] This invention relates to the field of electronic communication testing technology, and in particular to a ROS 2 (Robot Operating System 2) communication testing method and system based on DDS XTypes (Data Distribution Service Extensible Types). Background Technology

[0002] On resource-constrained embedded computing platforms, such as low-speed mining truck autopilot systems, the underlying distributed communication domain still largely relies on the ROS2 system. Currently, mainstream middleware performance verification methods primarily depend on the system's native toolchain (such as ros2 topic, rclpy, rclcpp, etc.) for communication testing, which has the following drawbacks in practical applications: First, native testing toolchains are primarily designed for the Linux operating system. Deploying them on other operating systems such as Windows presents challenges due to extremely complex installation and compilation processes and poor environment compatibility. Furthermore, because native toolchains contain numerous runtime dependency libraries and pre-compiled message packages, their overall software size can reach gigabyte levels. This bloated architecture not only consumes valuable storage space and computing resources but also prevents lightweight portability of testing tools, hindering the efficiency of automated testing under complex operating conditions.

[0003] Secondly, running the aforementioned native testing tools requires that the test environment must have pre-compiled message support packages (type support code generated by compiling .msg files) for the corresponding message types in advance. During the development phase of vehicle systems such as smart mining trucks with frequent iterations, once the data structure of a certain topic is slightly adjusted, the test environment must be reconfigured, compiled, and deployed synchronously, resulting in extremely high maintenance costs.

[0004] Third, native testing tools must interact indirectly with the underlying Data Distribution Service (DDS) middleware through the ROS Middleware Wrapper (RMW) layer. This limits the testing tools to the specific wrapper implementation they choose (such as the CycloneDDS middleware wrapper (rmw_cyclonedds) or the FastDDS middleware wrapper (rmw_fastdds)). When testing needs to verify heterogeneous communication compatibility across different middleware implementations or requires agile switching between different communication domains, the entire testing environment must be completely refactored, resulting in a severe lack of testing flexibility. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a ROS 2 communication testing method and system based on DDS XTypes to address the above-mentioned deficiencies of the prior art. This solves the problems of complex deployment process, large resource consumption, high maintenance cost and insufficient testing flexibility of the existing ROS 2 native testing toolchain application in resource-constrained embedded computing platforms.

[0006] To solve the above-mentioned technical problems, the technical solution proposed by this invention is as follows: Firstly, a ROS 2 communication testing method based on DDS XTypes includes the following steps: Based on the DDS discovery protocol, join the target ROS 2 communication domain by subscribing to built-in topics. Built-in topics include global publisher built-in topics and global subscriber built-in topics in the data center publish-subscribe model. Discover all topics in the target ROS 2 communication domain online, as well as the endpoint information of the data writers or data readers corresponding to the topics. The endpoint information includes at least the topic name and type name. Based on endpoint information, a type object request is initiated to the target endpoint through the type lookup mechanism of DDS Xtypes. The target endpoint returns a type lookup response, dynamically obtaining the type information of the target topic corresponding to the target endpoint. The type information includes at least a type identifier hash and a complete type object. Based on the type identifier hash, the complete definitions of all dependent types contained in the complete type object are recursively retrieved. Based on the complete type object and the complete definitions of dependent types, a hierarchical type structure information is constructed. Based on the test case requirements, memory samples are dynamically constructed using type structure information and assigned values. The assigned memory samples are then serialized into CDR encoded data and injected into the target ROS 2 communication domain through a dynamically created data writer to simulate business scenarios for communication testing. Output the communication test results.

[0007] In one implementation, based on type structure information, a data reader subscribes to a target topic, and obtains the CDR encoded data of the target topic constructed by the DDS protocol stack; the CDR encoded data of the target topic is dynamically deserialized to output structured data; the original CDR serialized data of the target topic is obtained synchronously and the encoding type identifier is extracted. The structured data is compared with the original CDR serialized data, and the CDR encoded data is analyzed in conjunction with the encoding type identifier to verify the correctness of the protocol stack encoding.

[0008] In one implementation, based on type structure information, a data reader subscribes to a target topic, obtains the source timestamp in the original network packet of the target topic, which is automatically filled by the DDS protocol stack of the sending end; obtains the receiving timestamp of the data reader receiving the original network packet; uses the difference between the receiving timestamp and the source timestamp as the end-to-end transmission delay, compares the calculated end-to-end transmission delay with a preset delay threshold, and determines the timeliness of the target topic data transmission.

[0009] In one implementation, the time difference between two adjacent received timestamps is calculated, and multiple consecutive time differences are statistically analyzed through a preset sliding window. The reciprocal of the average time difference is used as the average publishing frequency, the reciprocal of the minimum time difference is used as the maximum publishing frequency, and the reciprocal of the maximum time difference is used as the minimum publishing frequency. The calculated average publishing frequency, maximum publishing frequency, and minimum publishing frequency are compared with a preset frequency stability threshold to determine the stability of the target topic's publishing frequency.

[0010] In one implementation, the message rate and size distribution are statistically analyzed based on the number of bytes in the original CDR serialized data, and this is used as the message throughput. The statistically obtained message rate and size distribution are compared with a preset throughput threshold to determine the compliance of the target topic communication load.

[0011] In one implementation, for memory samples, a structured text format is used to describe the assignment information of each data field in the memory sample; the nesting level in the structured text format is parsed, the corresponding nested structure is identified, and dynamic multi-level assignment is performed on the nested structure according to the nesting level.

[0012] In one implementation, after joining the target ROS 2 communication domain, all topics within the target ROS 2 communication domain and the endpoint information of the corresponding data writers or data readers are discovered online. The endpoint information also includes a quality of service policy. Based on the quality of service policy, the corresponding data writers are dynamically configured and created.

[0013] In one implementation, the type information of the target topic corresponding to the target endpoint is dynamically obtained, and the complete type object is serialized into a type definition file in the target format and cached in the local directory. In subsequent tests, if the online acquisition of type information times out, the system automatically falls back to the local directory and loads the cached type definition file. In an offline testing environment without a network publishing terminal, the type definition file in the local directory is directly specified through external configuration parameters.

[0014] Secondly, a ROS 2 communication testing system based on DDS XTypes is provided, including: a host computer subsystem and a ROS 2 subsystem under test; The host computer subsystem includes a test tool module and a test framework module; The testing tool module includes at least a domain discovery unit, a type resolution unit, a data injection unit, a report generation unit, and a tool generation unit. The domain discovery unit is used to join the target ROS 2 communication domain by subscribing to built-in topics based on the DDS discovery protocol. Built-in topics include global publisher built-in topics and global subscriber built-in topics in the data center publish-subscribe model. It can discover all topics in the target ROS 2 communication domain online, as well as the endpoint information of the data writers or data readers corresponding to the topics. The endpoint information includes at least the topic name and type name. The type resolution unit is used to initiate a type object request to the target endpoint based on the endpoint information and through the type lookup mechanism of DDS Xtypes. The target endpoint returns a type lookup response and dynamically obtains the type information of the target topic corresponding to the target endpoint. The type information includes at least a type identifier hash and a complete type object. Based on the type identifier hash, it recursively retrieves the complete definitions of all dependent types contained in the complete type object. Based on the complete type object and the complete definitions of dependent types, it constructs a hierarchical type structure information. The data injection unit is used to dynamically construct memory samples based on type structure information according to test case requirements, and assign values ​​to the memory samples; the assigned memory samples are serialized into CDR encoded data, and injected into the target ROS 2 communication domain through dynamically created data writers to simulate business scenarios for communication testing; The report generation unit is used to output communication test results; The tool generation unit is used to build the domain discovery unit, type resolution unit, data injection unit, and report generation unit into a single executable file using static compilation, and to compile the DDS protocol stack, dynamic type library, and system library into a single executable file; The test framework module is used to define global test parameters, including at least DDS domain ID and network interface binding; define the test lifecycle, start a single executable file when the communication test begins, and clean up the process after the communication test ends; call the single executable file to execute the communication test, and through a parameterized configuration mechanism, transform multiple target topics and various business scenarios into a test parameter matrix to execute batch automated tests of multiple topics and multiple scenarios; The host computer subsystem connects to the computing platform where the ROS 2 subsystem under test is located via a network interface. A single executable file is bound to the network interface through network interface parameters and added to the DDS communication domain of the ROS 2 subsystem under test. The ROS 2 subsystem under test includes multiple ROS 2 node modules. Each ROS 2 node module is used to publish and subscribe to topics within the target ROS 2 communication domain via the DDS-RTPS protocol.

[0015] In one implementation, the testing tool module further includes a data verification unit, used to dynamically create a data reader subscription target topic based on type structure information, obtain CDR encoded data of the target topic constructed by the DDS protocol stack; dynamically deserialize the CDR encoded data of the target topic to output structured data; synchronously obtain the original CDR serialized data of the target topic and extract the encoding type identifier; compare the structured data with the original CDR serialized data, and analyze the CDR encoded data in conjunction with the encoding type identifier to verify the correctness of the protocol stack encoding; dynamically create a data reader subscription target topic based on type structure information, obtain the source timestamp in the original network packet of the target topic, which is automatically filled by the DDS protocol stack of the sending end; obtain the receiving timestamp of the data reader receiving the original network packet; and use the difference between the receiving timestamp and the source timestamp as... End-to-end transmission delay: The calculated end-to-end transmission delay is compared with a preset delay threshold to determine the timeliness of data transmission for the target topic. The time difference between two adjacent received timestamps is calculated, and multiple consecutive time differences are statistically analyzed using a preset sliding window. The reciprocal of the average time difference is used as the average publication frequency, the reciprocal of the minimum time difference is used as the maximum publication frequency, and the reciprocal of the maximum time difference is used as the minimum publication frequency. The calculated average, maximum, and minimum publication frequencies are compared with a preset frequency stability threshold to determine the stability of the target topic's publication frequency. Based on the number of bytes in the original CDR serialized data, the message rate and size distribution are statistically analyzed and used as the message throughput. The statistically analyzed message rate and size distribution are compared with a preset throughput threshold to determine the compliance of the target topic's communication load. The report generation unit is used to output a visual report of communication test results, which includes at least the communication test pass rate, detailed logs of failed test cases, correctness of protocol stack coding, statistical charts of communication timing indicators, latency distribution, frequency stability, and throughput data.

[0016] The beneficial effects of this invention are: 1. This invention is based on the DDS (Data Distribution Service) discovery protocol. It allows users to directly join the target ROS2 communication domain by subscribing to built-in topics. The testing tool is statically compiled into a single executable file (approximately 1.8MB), eliminating the need to install a full ROS 2 distribution (several gigabytes in size) or any dependent components. It can be run simply by copying, achieving zero-dependency deployment of the testing environment. This reduces deployment costs and resource consumption, making it particularly suitable for scenarios with limited embedded computing resources, such as low-speed mining cards. Furthermore, this invention is not limited by the testing framework system; the single executable file can be stably installed and run on both Windows and Linux operating systems.

[0017] 2. This invention utilizes the DDS XTypes TypeLookup (Data Distribution Service Extensible Type Lookup Service) mechanism to dynamically obtain the CompleteTypeObject of a Topic from the network peer at runtime and recursively parse all dependent types. The entire process requires no local IDL file (Interface Definition Language file) or pre-compiled message packages, and there is no need to synchronously update the test environment when the message type definition changes. This decouples the test methods and systems from the project code version, improves the reusability and adaptability of the test methods and systems, and reduces maintenance costs.

[0018] 3. This invention is based on the OMG DDS XTypes (Extensible Type Specification for Data Distribution Services) standard protocol and is decoupled from specific ROS 2 middleware wrapper (RMW) layer implementations. It can interoperate with any RMW implementation that implements the DDS-RTPS (Real-time Publish-Subscribe Protocol for Data Distribution Services) and XTypes specification (such as CycloneDDS, Fast DDS, RTI Connext, etc.), and has general testing capabilities across platforms and RMW implementations.

[0019] 4. This invention can both passively monitor and verify the data streams of all topics within the domain, and also has active testing capabilities. It can actively construct memory samples to inject messages of any topic, simulate various business scenarios for communication testing, and provide a complete testing loop.

[0020] 5. Regarding verifying the correctness of protocol stack encoding, the native ROS 2 toolchain sends and receives data through application layer APIs such as rclcpp / rclpy, and cannot directly access underlying information such as the original CDR encoded data of the DDS protocol layer. That is, it only supports verifying application layer business data, not the middleware protocol stack itself. This invention operates directly at the DDS RTPS protocol layer, obtaining underlying information such as the original CDR encoded data and encoding type identifier. It supports comparing structured data with the original CDR serialized data, significantly improving the depth of testing and verification.

[0021] 6. Regarding transmission latency, the native ROS 2 toolchain calculates the time interval between the receiver acquiring data packets, without considering the sender's perspective. This invention, however, calculates the time interval between the sender and receiver acquiring data packets. Existing technologies typically involve manually adding a timestamp field to the message structure and modifying the business logic, which is highly intrusive and complex to deploy. This invention, on the other hand, dynamically creates data readers to subscribe to target topics, obtains the source timestamp from the original network packets of the target topic, and receives the receive timestamp of the original network packets. The method proposed in this invention is less intrusive, easier to deploy and implement, and better reflects the protocol stack's transmission capabilities.

[0022] 7. This invention supports an online mode that dynamically obtains types through DDS XTypes TypeLookup, as well as an offline mode that loads type definitions from local cache files. In an offline environment without a network publishing terminal, type parsing and data publishing can still be completed independently, meeting the flexible needs of different testing scenarios.

[0023] 8. This invention integrates and drives the entire testing process through a testing framework, enabling the organization and management of test cases, parameterized batch execution, and automated report generation. The testing process is repeatable and traceable, meeting the automated testing needs in a continuous integration (CI) environment. Attached Figure Description

[0024] The invention will now be further described with reference to the accompanying drawings.

[0025] Figure 1 This is a flowchart of a ROS 2 communication testing method based on DDS XTypes according to an embodiment of the present invention.

[0026] Figure 2 This is a schematic diagram of the structure of a ROS 2 communication test system based on DDS XTypes according to an embodiment of the present invention. Detailed Implementation

[0027] like Figure 1 As shown, this embodiment proposes a ROS 2 communication testing method based on DDS XTypes, including the following steps: S1, based on the DDS discovery protocol, joins the target ROS 2 communication domain by subscribing to built-in topics. Built-in topics include global publisher built-in topics and global subscriber built-in topics in the data center publish-subscribe model; discovers online all topics in the target ROS2 communication domain and the endpoint information of the data writers or data readers corresponding to the topics. The endpoint information includes at least the topic name and type name. Specifically, based on the DDS discovery protocol (SEDP, Simple Endpoint Discovery Protocol), by subscribing to the DDS built-in topics DCPSPublication (global publisher built-in topic) and DCPSSubscription (global subscriber built-in topic), the system joins the target ROS 2 communication domain (the DDS domain ID is specified via the -d parameter, defaulting to 0). Within a specified discovery waiting time (specified via the -w parameter, 2000ms by default in this example), the system discovers all active topics within the domain and their corresponding DataWriter / DataReader endpoint information online. This step only reads existing SEDP traffic and does not trigger any TypeLookup RPC (Remote Procedure Call), resulting in no additional network overhead. The discovery results are output in list form, including Topic name and type name; it can also include the number of publishers, the number of subscribers, the publisher GUID, and the subscriber GUID.

[0028] S2, based on endpoint information, initiates a type object request to the target endpoint through the type lookup mechanism of DDS Xtypes. The target endpoint returns a type lookup response, dynamically obtaining the type information of the target topic corresponding to the target endpoint. The type information includes at least a type identifier hash and a complete type object. Based on the type identifier hash, recursively retrieves the complete definitions of all dependent types contained in the complete type object. Based on the complete type object and the complete definitions of dependent types, constructs a hierarchical type structure information. Specifically, for target topics requiring data interaction, a TypeObject request (TypeLookup_Request) is initiated to the target endpoint via the DDS XTypes TypeLookup (Data Distribution Service Extensible Types Type Lookup Service) mechanism. The endpoint then returns a TypeLookup_Reply, obtaining the TypeInformation (including the TypeID hash) for that topic. The CompleteTypeObject (a complete type object containing the complete definitions of all dependent types) is recursively retrieved using the TypeID hash, constructing the complete type structure information locally. This process is unicast communication, interacting only with a specific participant (node) and not affecting other nodes within the domain. After successful type resolution, this embodiment visualizes the complete type definition in a tree structure, including struct nesting levels, enum literals and values, array dimensions, sequence boundaries, string boundaries, @key annotations, and other information. Simultaneously, the TypeObject is automatically serialized into an XML type definition file and cached in the local directory (~ / .cache / dds_xtypes_tool / ) for subsequent offline use.

[0029] In one implementation, the type information of the target topic corresponding to the target endpoint is dynamically obtained, the complete type object is serialized into a type definition file in the target format, and cached in the local directory. In subsequent tests, if the online acquisition of type information times out, the system automatically falls back to the local directory and loads the cached type definition file. In an offline testing environment without a network publishing terminal, the type definition file in the local directory is directly specified through external configuration parameters.

[0030] Supports online mode (automatically discovers types via TypeLookup) and offline mode (--type-xml loads type definitions from a local XML file).

[0031] Taking the Pose6DOF (six-degree-of-freedom pose) topic, commonly found in low-speed mining truck autopilot systems, as an example, the type resolution result is displayed as follows: Pose6DOF(struct) contains object_id(uint32,@key), position (a nested Point3 struct containing three float64 fields: x, y, and z), orientation (a nested Quaternion struct containing four float64 fields: x, y, z, and w), and timestamp_ns(uint64). For the EventRecord Topic, the type resolution result is displayed as follows: EventRecord(struct) contains event_id(uint64,@key), level (an EventLevel enumeration type containing five literals from LEVEL_DEBUG=0 to LEVEL_CRITICAL=4), message(string), and timestamp_ns(int64).

[0032] S3, based on the test case requirements, dynamically construct memory samples based on type structure information and assign values ​​to the memory samples; serialize the assigned memory samples into CDR encoded data, and inject them into the target ROS2 communication domain through dynamically created data writers to simulate business scenarios for communication testing; Specifically, based on the test case requirements (such as simulating abnormal temperature values, injecting boundary data, and simulating sensor failures), memory samples are dynamically constructed based on the parsed type structure.

[0033] In one implementation, for memory samples, a structured text format is used to describe the assignment information of each data field in the memory sample; the nesting level in the structured text format is parsed, the corresponding nested structure is identified, and dynamic multi-level assignment is performed on the nested structure according to the nesting level.

[0034] Specifically, field values ​​are described in JSON format, supporting nested struct assignment (e.g., position:{x:1.0,y:2.0,z:0.5}), array assignment (e.g., values:[1.0,2.0,3.0]), string assignment, and enumeration value assignment (supporting numeric or literal names). Memory samples are serialized into Common Data Representation (CDR) encoded data using the dtl_scan_sample interface (dynamic sample scanning interface) of dyntypelib (dynamic type library), and injected into the ROS 2 communication domain via dds_create_writer (dynamic data writer creation interface).

[0035] In one implementation, after joining the target ROS 2 communication domain, all topics within the target ROS 2 communication domain and the endpoint information of the corresponding data writers or data readers are discovered online. The endpoint information also includes a quality of service policy. Based on the quality of service policy, the corresponding data writers are dynamically configured and created.

[0036] Specifically, it supports overriding the default QoS policy (Quality of Service policy) (--qos-reliability, --qos-durability, --qos-history, --qos-depth) via command-line parameters.

[0037] For example, simulating a sensor malfunction scenario in a low-speed mining truck: injecting abnormal SensorReading data with sensor_id of 99 and temperature of 150.0 (out of normal range) via the pub command to verify whether the vehicle control module can correctly identify and filter abnormal temperature values ​​and trigger the corresponding safety protection logic.

[0038] In one implementation, S4, data verification, is also included: S4-1, In one implementation, based on type structure information, a data reader subscribes to a target topic, and obtains the CDR encoded data of the target topic constructed by the DDS protocol stack; the CDR encoded data of the target topic is dynamically deserialized to output structured data; the original CDR serialized data of the target topic is obtained synchronously and the encoding type identifier is extracted. The structured data is compared with the original CDR serialized data, and the CDR encoded data is analyzed in conjunction with the encoding type identifier to verify the correctness of the protocol stack encoding.

[0039] Specifically, based on the parsed type structure, a dynamic DataReader (dds_create_reader) is created to subscribe to the target Topic. The received CDR-encoded data is dynamically deserialized (via the dyntypelib dtl_print_sample interface, a dynamic sample printing interface), outputting structured data in JSON format. Simultaneously, the raw CDR serialized data is obtained via the dds_takecdr() interface (raw byte stream acquisition interface), the encoding type identifier is extracted (supporting CDR, CDR2, PL_CDR, PL_CDR2, and D_CDR2), and the hexadecimal dump and JSON data are displayed side-by-side to verify the correctness of the protocol layer data encoding.

[0040] S4-2, In one implementation, based on type structure information, a data reader subscribes to a target topic dynamically, obtains the source timestamp in the original network packet of the target topic, which is automatically filled by the DDS protocol stack of the sending end; obtains the receiving timestamp of the data reader receiving the original network packet; uses the difference between the receiving timestamp and the source timestamp as the end-to-end transmission delay, compares the calculated end-to-end transmission delay with a preset delay threshold, and determines the timeliness of the target topic data transmission.

[0041] Specifically, the end-to-end transmission delay is calculated (based on the time difference between the DDS source_timestamp and the receiving time of dds_take() (sample receiving interface), and the mean, minimum, maximum and standard deviation are statistically calculated using a sliding window. The sliding window sampling value is dynamically adjusted according to the smoothness of the system's real-time response. In this embodiment, 200 samples are used.

[0042] S4-3, In one embodiment, the time difference between two adjacent receiving timestamps is calculated, and multiple consecutive time differences are statistically analyzed through a preset sliding window. The reciprocal of the average time difference is used as the average publishing frequency, the reciprocal of the minimum time difference is used as the maximum publishing frequency, and the reciprocal of the maximum time difference is used as the minimum publishing frequency. The calculated average publishing frequency, maximum publishing frequency, and minimum publishing frequency are compared with a preset frequency stability threshold to determine the stability of the target topic publishing frequency.

[0043] Specifically, in this embodiment, samples are received through a 100ms short polling, and interval statistics are calculated every second.

[0044] S4-4, In one implementation, based on the number of bytes of the original CDR serialized data, the message rate and size distribution are statistically analyzed and used as the message throughput; the statistically obtained message rate and size distribution are compared with a preset throughput threshold to determine the compliance of the target topic communication load.

[0045] For example, data verification is performed on the SensorReading Topic (including sensor_id, temperature, humidity, and active fields) published by the low-speed mining truck sensing module. The verification content includes: (1) whether the temperature field value is within a reasonable range (e.g., -40~125℃); (2) whether the publishing frequency is 5Hz (200ms±10ms cycle); (3) whether the end-to-end transmission delay is less than 1ms (local loopback scenario); (4) whether the field values ​​of the CDR encoded data after deserialization are consistent with the JSON output.

[0046] S5 outputs the communication test results.

[0047] Specifically, all verification results are summarized, including data consistency check results (pass / fail), communication timing metric statistics (frequency mean / minimum / maximum, latency mean / minimum / maximum / standard deviation, throughput mean / message size distribution), and an HTML-formatted visual test report is generated using the Allure test report framework. This report includes a test overview, detailed test case execution results, timing charts, and error logs for failed test cases.

[0048] like Figure 2 As shown, this embodiment also provides a ROS 2 communication test system based on DDS XTypes, including: a host computer subsystem and a ROS 2 subsystem under test; Specifically, the host computer subsystem is a Windows / Linux general-purpose computing platform, and the ROS 2 subsystem under test (running on a low-speed mining card domain controller or embedded computing platform) is connected to the computing platform where the ROS 2 subsystem under test resides via a network interface (Ethernet).

[0049] The host computer subsystem includes a test tool module and a test framework module; The testing tool module includes at least a domain discovery unit, a type resolution unit, a data injection unit, a report generation unit, and a tool generation unit. The domain discovery unit is used to join the target ROS 2 communication domain by subscribing to built-in topics based on the DDS discovery protocol. Built-in topics include global publisher built-in topics and global subscriber built-in topics in the data center publish-subscribe model. It can discover all topics in the target ROS 2 communication domain online, as well as the endpoint information of the data writers or data readers corresponding to the topics. The endpoint information includes at least the topic name and type name. The type resolution unit is used to initiate a type object request to the target endpoint based on the endpoint information and through the type lookup mechanism of DDS Xtypes. The target endpoint returns a type lookup response and dynamically obtains the type information of the target topic corresponding to the target endpoint. The type information includes at least a type identifier hash and a complete type object. Based on the type identifier hash, it recursively retrieves the complete definitions of all dependent types contained in the complete type object. Based on the complete type object and the complete definitions of dependent types, it constructs a hierarchical type structure information. The data injection unit is used to dynamically construct memory samples based on type structure information according to test case requirements, and assign values ​​to the memory samples; the assigned memory samples are serialized into CDR encoded data, and injected into the target ROS 2 communication domain through dynamically created data writers to simulate business scenarios for communication testing; The report generation unit is used to output communication test results; The tool generation unit is used to build the domain discovery unit, type resolution unit, data injection unit, and report generation unit into a single executable file using static compilation, and to compile the DDS protocol stack, dynamic type library, and system library into a single executable file; The test framework module is used to define global test parameters, including at least DDS domain ID and network interface binding; define the test lifecycle, start a single executable file when the communication test begins, and clean up the process after the communication test ends; call the single executable file to execute the communication test, and through a parameterized configuration mechanism, transform multiple target topics and various business scenarios into a test parameter matrix to execute batch automated tests of multiple topics and multiple scenarios; Specifically, in this embodiment, the workflow of the dds_xtypes_tool tool driven by the pytest testing framework is as follows: (1) Define a global configuration fixture in conftest.py, including parameters such as DDS domain ID (domain_id), network interface binding (interface), discovery wait time (wait_ms), and type resolution timeout (timeout_s); (2) Define a tool process management fixture (tool_process) for the dds_xtypes_tool tool, which is responsible for starting the tool background process at the beginning of the test session and cleaning up the process at the end of the test session; (3) Define a Topic discovery fixture (discovered_topics), which calls the dds_xtypes_tool list command to obtain a list of all Topics in the domain; (4) Define a type resolution fixture (topic_type_info), which calls the dds_xtypes_tool The type command obtains the complete type definition of the specified Topic; (5) Write test case functions and use the @pytest.mark.parametrize decorator to implement multi-topic parameterized testing. In the test case, the subprocess.run() calls the echo / hz / bw / delay / pub commands of dds_xtypes_tool to perform specific data verification and data injection operations, captures the command output and asserts the results through the assert statement; (6) The pytest hook (pytest_sessionfinish) automatically calls the Allure command line tool to generate an HTML test report after the test session ends.

[0050] The host computer subsystem connects to the computing platform where the ROS 2 subsystem under test is located via a network interface. A single executable file is bound to the network interface through network interface parameters and added to the DDS communication domain of the ROS 2 subsystem under test. Specifically, the single executable file is dds_xtypes_tool, which is bound to the corresponding network interface via the -i parameter and added to the DDS communication domain of the ROS 2 subsystem.

[0051] The ROS 2 subsystem under test includes multiple ROS 2 node modules. Each ROS 2 node module is used to publish and subscribe to topics within the target ROS 2 communication domain via the DDS-RTPS protocol.

[0052] This embodiment takes sensing nodes, planning nodes, control nodes, and vehicle control nodes as examples.

[0053] In one implementation, the testing tool module further includes a data verification unit, used to dynamically create a data reader subscription target topic based on type structure information, obtain CDR encoded data of the target topic constructed by the DDS protocol stack; dynamically deserialize the CDR encoded data of the target topic to output structured data; synchronously obtain the original CDR serialized data of the target topic and extract the encoding type identifier; compare the structured data with the original CDR serialized data, and analyze the CDR encoded data in conjunction with the encoding type identifier to verify the correctness of the protocol stack encoding; dynamically create a data reader subscription target topic based on type structure information, obtain the source timestamp in the original network packet of the target topic, which is automatically filled by the DDS protocol stack of the sending end; obtain the receiving timestamp of the data reader receiving the original network packet; and use the difference between the receiving timestamp and the source timestamp as... End-to-end transmission delay: The calculated end-to-end transmission delay is compared with a preset delay threshold to determine the timeliness of data transmission for the target topic. The time difference between two adjacent received timestamps is calculated, and multiple consecutive time differences are statistically analyzed using a preset sliding window. The reciprocal of the average time difference is used as the average publication frequency, the reciprocal of the minimum time difference is used as the maximum publication frequency, and the reciprocal of the maximum time difference is used as the minimum publication frequency. The calculated average, maximum, and minimum publication frequencies are compared with a preset frequency stability threshold to determine the stability of the target topic's publication frequency. Based on the number of bytes in the original CDR serialized data, the message rate and size distribution are statistically analyzed and used as the message throughput. The statistically analyzed message rate and size distribution are compared with a preset throughput threshold to determine the compliance of the target topic's communication load. The report generation unit is used to output a visual report of communication test results, which includes at least the communication test pass rate, detailed logs of failed test cases, correctness of protocol stack coding, statistical charts of communication timing indicators, latency distribution, frequency stability, and throughput data.

[0054] In a complete low-speed mining truck ROS 2 communication automation test embodiment, the test process is as follows: First, start the autonomous driving software stack (including ROS 2 nodes such as perception nodes, planning nodes, control nodes, and vehicle control nodes) on the domain controller of the mining truck under test. Each node publishes and subscribes to topics in the DDS domain. Then, execute the pytest test suite on the host computer. pytest automatically completes the following process: (1) Start the dds_xtypes_tool tool process through the fixture configured in conftest.py; (2) Call the list command to find all topics in the domain (such as LidarPointCloud, RadarTrack, GpsPosition, VehicleState, ControlCommand, SensorReading, SystemMetrics, etc.); (3) For each topic under test, call the type command to obtain the type definition and call the echo command. (3) Subscribe to the data stream, call the hz command to measure the publishing frequency, call the delay command to measure the end-to-end latency, and call the bw command to measure the throughput; (4) For data consistency test cases, parse the JSON data output by echo and verify whether the field values ​​are within a reasonable range; (5) For business function test cases, call the pub command to inject specific test data (such as simulated exception control instructions), and then listen to the data changes of the response topic through the echo command to verify whether the system responds correctly; (6) After all test cases are executed, Allure automatically summarizes and generates an HTML test report, which includes the test pass rate, time series indicator statistics charts of each topic, and detailed logs of failed test cases.

Claims

1. A ROS2 communication testing method based on DDSXTypes, characterized in that, Includes the following steps: S1, based on the DDS discovery protocol, joins the target ROS2 communication domain by subscribing to built-in topics. Built-in topics include global publisher built-in topics and global subscriber built-in topics in the data center publish-subscribe model. Discover all topics within the target ROS2 communication domain online, as well as the endpoint information of the corresponding data writers or data readers. The endpoint information includes at least the topic name and the type name. S2, based on endpoint information, initiates a type object request to the target endpoint through the type lookup mechanism of DDSXtypes. The target endpoint returns a type lookup response, dynamically obtaining the type information of the target topic corresponding to the target endpoint. The type information includes at least the type identifier hash and the complete type object. S3, based on type identifier hashing, recursively retrieves the complete definitions of all dependent types contained in the complete type object; Construct hierarchical type structure information based on the complete definitions of the complete type object and its dependent types; S4. Based on the test case requirements, dynamically construct memory samples according to type structure information and assign values ​​to the memory samples; serialize the assigned memory samples into CDR encoded data, and inject them into the target ROS2 communication domain through dynamically created data writers to simulate business scenarios for communication testing. S5 outputs the communication test results; S6. The contents of steps S1-S5 are constructed into a single executable file using static compilation, and the DDS protocol stack, dynamic type library and system library are compiled into the single executable file. S7 defines global test parameters, including at least DDS domain ID and network interface binding; it also defines the test lifecycle, starting a single executable file when the communication test begins and cleaning up the process after the communication test ends. It calls a single executable file to perform communication tests, and through a parameterized configuration mechanism, transforms multiple target topics and various business scenarios into a test parameter matrix to execute batch automated tests of multiple topics and multiple scenarios; The executable file is connected to the computing platform where the ROS2 under test is located via a network interface. The single executable file is bound to the network interface through network interface parameters and added to the DDS communication domain of the ROS2 under test. The ROS2 under test includes multiple ROS2 nodes. Each ROS2 node publishes and subscribes to topics within the target ROS2 communication domain via the DDS-RTPS protocol.

2. The ROS2 communication testing method based on DDSXTypes according to claim 1, characterized in that: Based on type structure information, data readers are dynamically created to subscribe to target topics, and CDR-encoded data of the target topics is obtained through the DDS protocol stack; the CDR-encoded data of the target topics is dynamically deserialized to output structured data; Simultaneously acquire the original CDR serialized data of the target topic and extract the encoding type identifier; The structured data is compared with the original CDR serialized data, and the CDR encoded data is analyzed in conjunction with the encoding type identifier to verify the correctness of the protocol stack encoding.

3. The ROS2 communication testing method based on DDSXTypes according to claim 1, characterized in that: Based on type structure information, dynamically create data readers to subscribe to target topics, obtain the source timestamp in the original network packets of the target topic (which is automatically filled by the DDS protocol stack of the sender), and obtain the receiving timestamp of the data reader receiving the original network packets. The difference between the received timestamp and the source timestamp is used as the end-to-end transmission delay. The calculated end-to-end transmission delay is compared with a preset delay threshold to determine the timeliness of the target topic data transmission.

4. The ROS2 communication testing method based on DDSXTypes according to claim 3, characterized in that: The time difference between two adjacent received timestamps is calculated, and multiple consecutive time differences are statistically analyzed through a preset sliding window. The reciprocal of the average time difference is used as the average publishing frequency, the reciprocal of the minimum time difference is used as the maximum publishing frequency, and the reciprocal of the maximum time difference is used as the minimum publishing frequency. The calculated average publishing frequency, maximum publishing frequency, and minimum publishing frequency are compared with a preset frequency stability threshold to determine the stability of the target topic's publishing frequency.

5. The ROS2 communication testing method based on DDSXTypes according to claim 2, characterized in that: Based on the number of bytes in the original CDR serialized data, the message rate and size distribution are statistically analyzed and used as the message throughput. The statistically obtained message rate and size distribution are compared with the preset throughput threshold to determine the compliance of the target topic's communication load.

6. The ROS2 communication testing method based on DDSXTypes according to claim 1, characterized in that: For memory samples, a structured text format is used to describe the assignment information of each data field in the memory sample; the nesting level in the structured text format is parsed, the corresponding nested structure is identified, and dynamic multi-level assignment is performed on the nested structure according to the nesting level.

7. The ROS2 communication testing method based on DDSXTypes according to claim 1, characterized in that: After joining the target ROS2 communication domain, all topics within the target ROS2 communication domain and the endpoint information of the corresponding data writers or data readers are discovered online. This endpoint information also includes the quality of service policy. Based on the quality of service policy, the corresponding data writers are dynamically configured and created.

8. The ROS2 communication testing method based on DDSXTypes according to claim 1, characterized in that: Dynamically obtain the type information of the target topic corresponding to the target endpoint, serialize the complete type object into a type definition file in the target format, and cache it in the local directory; In subsequent tests, if the online acquisition of type information times out, the system will automatically fall back to the local directory and load the cached type definition file. In offline testing environments without a network publishing terminal, the type definition file in the local directory can be directly specified through external configuration parameters.

9. A ROS2 communication testing system based on DDSXTypes, characterized in that, include: The host computer subsystem and the ROS2 subsystem under test; The host computer subsystem includes a test tool module and a test framework module; The testing tool module includes at least a domain discovery unit, a type resolution unit, a data injection unit, a report generation unit, and a tool generation unit. The domain discovery unit is used to join the target ROS2 communication domain by subscribing to built-in topics based on the DDS discovery protocol. Built-in topics include global publisher built-in topics and global subscriber built-in topics in the data center publish-subscribe model. It can discover all topics in the target ROS2 communication domain online, as well as the endpoint information of the data writers or data readers corresponding to the topics. The endpoint information includes at least the topic name and type name. The type resolution unit is used to initiate a type object request to the target endpoint based on the endpoint information and through the type lookup mechanism of DDSXtypes. The target endpoint returns a type lookup response and dynamically obtains the type information of the target topic corresponding to the target endpoint. The type information includes at least the type identifier hash and the complete type object. Based on the type identifier hash, it recursively retrieves the complete definitions of all dependent types contained in the complete type object. Construct hierarchical type structure information based on the complete definitions of the complete type object and its dependent types; The data injection unit is used to dynamically construct memory samples based on type structure information according to test case requirements, and assign values ​​to the memory samples; the assigned memory samples are serialized into CDR encoded data, and injected into the target ROS2 communication domain through dynamically created data writers to simulate business scenarios for communication testing; The report generation unit is used to output communication test results; The tool generation unit is used to build the domain discovery unit, type resolution unit, data injection unit, and report generation unit into a single executable file using static compilation, and to compile the DDS protocol stack, dynamic type library, and system library into a single executable file; The test framework module is used to define global test parameters, including at least DDS domain ID and network interface binding; define the test lifecycle, start a single executable file when the communication test begins, and clean up the process after the communication test ends; call the single executable file to execute the communication test, and through a parameterized configuration mechanism, transform multiple target topics and various business scenarios into a test parameter matrix to execute batch automated tests of multiple topics and multiple scenarios; The host computer subsystem connects to the computing platform where the ROS 2 subsystem under test is located via a network interface. A single executable file is bound to the network interface through network interface parameters and added to the DDS communication domain of the ROS 2 subsystem under test. The ROS 2 subsystem under test includes multiple ROS 2 node modules. Each ROS 2 node module is used to publish and subscribe to topics within the target ROS 2 communication domain via the DDS-RTPS protocol.

10. A ROS2 communication testing system based on DDSXTypes according to claim 9, characterized in that: The testing tool module also includes a data verification unit, which is used to dynamically create data readers to subscribe to target topics based on type structure information, obtain CDR encoded data of the target topics constructed by the DDS protocol stack, dynamically deserialize the CDR encoded data of the target topics, and output structured data. The original CDR serialized data of the target topic is acquired synchronously and the encoding type identifier is extracted; the structured data is compared with the original CDR serialized data, and the CDR encoded data is analyzed in combination with the encoding type identifier to verify the correctness of the protocol stack encoding. Based on type structure information, dynamically create data readers to subscribe to target topics, obtain the source timestamp in the original network packets of the target topic (which is automatically filled by the DDS protocol stack of the sender), and obtain the receiving timestamp of the data reader receiving the original network packets. The difference between the received timestamp and the source timestamp is used as the end-to-end transmission delay. The calculated end-to-end transmission delay is compared with a preset delay threshold to determine the timeliness of the target topic data transmission. Calculate the time difference between two adjacent received timestamps, and statistically analyze multiple consecutive time differences through a preset sliding window. Use the reciprocal of the average time difference as the average release frequency, the reciprocal of the minimum time difference as the maximum release frequency, and the reciprocal of the maximum time difference as the minimum release frequency. The calculated average posting frequency, maximum posting frequency, and minimum posting frequency are compared with a preset frequency stability threshold to determine the stability of the target topic's posting frequency. Based on the number of bytes in the original CDR serialized data, the message rate and size distribution are statistically analyzed, and this is used as the message throughput. The statistically obtained message rate and size distribution are compared with the preset throughput threshold to determine the compliance of the target topic's communication load. The report generation unit is used to output a visual report of communication test results, which includes at least the communication test pass rate, detailed logs of failed test cases, correctness of protocol stack coding, statistical charts of communication timing indicators, latency distribution, frequency stability, and throughput data.

Images