Low-delay vehicle control test method, device and equipment and storage medium

Abstract

The invention discloses a low-delay vehicle control test method, device and equipment and a storage medium, and relates to the technical field of vehicle test. According to the method, the ROS test message is generated on the test platform, the system time is synchronized, the real-time connection with the Ubuntu system of the controlled vehicle is established by using the ROS relay node, and the vehicle control data in the CAN format is directly sent through the Simulink vehicle control model to test and optimize the vehicle control program. According to the method, real-time simulation is supported, rapid execution and feedback of the control instruction are ensured, so that the efficiency of vehicle control code testing is improved, the controlled vehicle can monitor data on the CAN bus in real time and return a control result after executing the vehicle control instruction, and the testing process is more direct and rapid. According to the test method, the duration of compiling and deploying codes is shortened, the test reliability is improved through real-time data exchange, and a more efficient and convenient test means is provided.

Description

Technical Field

[0001] The present application relates to the field of vehicle testing technology, and in particular to a low-latency vehicle control testing method, device, equipment and storage medium. Background Art

[0002] With the rapid development of the automotive industry, the intelligence and networking of vehicles have become an important trend in the development of future transportation. Modern cars are equipped with a large number of sensors and actuators, which are managed by advanced electronic control units (ECUs) to achieve a safer, more efficient and more environmentally friendly driving experience. These systems not only need to process a large amount of data, but also be able to respond quickly to various driving situations. Therefore, higher requirements are placed on the development and testing of vehicle control systems, and more accurate and efficient testing methods are needed to verify and optimize control algorithms.

[0003] In the development process of vehicle control systems, software and hardware integration testing is a key link. Traditional testing methods usually involve complex code compilation, loading and real vehicle testing processes, which are not only time-consuming but also require the collaboration of multiple professional teams, such as software engineers, hardware engineers and test engineers. In addition, each code update and optimization requires recompilation and deployment, which greatly limits development efficiency and testing frequency. With the increasing number of automotive functions, the control logic has become more complex, and traditional testing methods have been unable to meet the needs of rapid iteration and verification.

[0004] Existing vehicle control test methods face many challenges, especially in terms of real-time and test efficiency. How to achieve fast code testing and verification, reduce compilation and deployment time, and ensure data synchronization and real-time during the test process have become technical issues that need to be solved urgently. Summary of the invention

[0005] The main purpose of this application is to provide a low-latency vehicle control test method, device, equipment and storage medium, aiming to solve the technical problem of how to simplify the test process of existing vehicle control codes to improve the efficiency of debugging and optimization.

[0006] To achieve the above object, the present application provides a low-latency vehicle control test method, the method comprising the following steps: Generate ROS test messages according to the test tasks; Transmitting the ROS test message to the controlled vehicle to obtain control result data returned by the controlled vehicle; The execution quality of the test task is obtained according to the control result data to complete the closed-loop test of the vehicle control code.

[0007] Optionally, before generating a ROS test message according to the test task, the method further includes: Based on the NTP network time protocol, the system time of the Simulink vehicle control model of the test platform and the Ubuntu system time of the controlled vehicle are synchronized; A ROS relay node is created in the Ubuntu system, and a connection is established by submitting registration information to the Simulink vehicle control model on the test platform.

[0008] Optionally, generating a ROS test message according to the test task includes: The test task is parsed through a Simulink vehicle control model to obtain vehicle control data, where the data type of the vehicle control data is in CAN format; The vehicle control data is encapsulated according to the ROS message format to obtain the ROS test message.

[0009] Optionally, the Ubuntu system of the controlled vehicle supports a real-time kernel, and the Simulink vehicle control model on the test platform supports real-time simulation.

[0010] Optionally, the low-latency vehicle control test method is applied to a controlled vehicle, and the low-latency vehicle control test method includes: Receiving the ROS test message, where the ROS test message is sent by the test platform; Parsing the ROS test message to obtain vehicle control instructions; Execute the vehicle control command, monitor and obtain the control result data on the CAN bus; The control result data is returned to the test platform.

[0011] Optionally, parsing the ROS test message to obtain a vehicle control instruction includes: Parsing the ROS test message to obtain a data frame of a preset field type, wherein the field type includes an arbitration segment, a control segment, and a data segment; Obtaining substantial control data according to the data frame of the preset field type; A vehicle control instruction is obtained according to the substantial control data.

[0012] Optionally, executing the vehicle control instruction and monitoring and acquiring control result data on the CAN bus includes: Sending the vehicle control command to a vehicle electronic control unit, so that the vehicle electronic control unit executes the vehicle control command; After the controlled vehicle responds to the vehicle control command, monitoring and parsing CAN transmission data on the CAN bus; If the CAN transmission data includes vehicle control feedback data, the vehicle control feedback data is packaged as control result data.

[0013] In addition, to achieve the above-mentioned purpose, the present application also provides a low-latency vehicle control test device, the low-latency vehicle control test device comprising: The test data generation module is used to generate ROS test messages according to the test tasks; A data transmission module, used for transmitting the ROS test message to the controlled vehicle, and obtaining the control result data returned by the controlled vehicle; The test result analysis module is used to obtain the execution quality of the test task according to the control result data to complete the closed-loop test of the vehicle control code.

[0014] In addition, to achieve the above-mentioned objectives, the present application also provides a low-latency vehicle control test device, which includes: a memory, a processor, and a low-latency vehicle control test program stored on the memory and executable on the processor, wherein the low-latency vehicle control test program is configured to implement the steps of the low-latency vehicle control test method as described above.

[0015] In addition, to achieve the above-mentioned objectives, the present application also provides a storage medium, on which a low-latency vehicle control test program is stored. When the low-latency vehicle control test program is executed by a processor, the steps of the low-latency vehicle control test method described above are implemented.

[0016] The present application generates a ROS test message according to a test task; transmits the ROS test message to a controlled vehicle to obtain control result data returned by the controlled vehicle; and obtains the execution quality of the test task according to the control result data to complete a closed-loop test of the vehicle control code.

[0017] In summary, this application generates ROS test messages on the test platform and synchronizes the system time, uses the ROS relay node to establish a real-time connection with the Ubuntu system of the controlled vehicle, and directly sends the vehicle control data in CAN format through the Simulink vehicle control model to test and optimize the vehicle control program. This method supports real-time simulation, ensures the accurate execution and rapid feedback of control instructions, and thus significantly improves the efficiency of vehicle control code testing. After executing the vehicle control instructions, the controlled vehicle can monitor the data on the CAN bus in real time and return the control results, making the test process more direct and rapid. This testing method not only reduces the time consumption of compiling and deploying code in traditional testing, but also improves the accuracy and reliability of the test through real-time data exchange, providing a more efficient and convenient testing method. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 This is a flow chart of the first embodiment of the low-latency vehicle control test method of the present application; Figure 2 This is a flow chart of a second embodiment of a low-latency vehicle control test method of the present application; Figure 3 This is a flow chart of a third embodiment of a low-latency vehicle control test method of the present application; Figure 4 This is a flow chart of a fourth embodiment of a low-latency vehicle control test method of the present application; Figure 5 This is a schematic diagram of the functional modules of the low-latency vehicle control test device of this application; Figure 6 It is a structural diagram of a terminal device in the hardware operating environment involved in the embodiment of the present application.

[0021] The realization of the purpose, functional features and advantages of this application will be further explained in conjunction with embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0022] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0023] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0024] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a low-latency vehicle control test device, etc. The following takes the low-latency vehicle control test device as an example to illustrate this embodiment and the following embodiments.

[0025] The present application embodiment provides a low-latency vehicle control test method, referring to Figure 1 , Figure 1This is a flow chart of the first embodiment of the present application.

[0026] In this embodiment, the low-latency vehicle control test method is applied to a test platform, and the method includes: Step A10: Generate a ROS test message according to the test task.

[0027] It should be noted that the technical idea of ​​this embodiment is to select test software with a low-latency system clock as the software basis for the test for upgrading and transformation, and then directly connect the CAN bus on the vehicle to be tested to the test PC through hardware means, and establish a Simulink vehicle control simulation model on the test PC to generate CAN signals that can directly control the vehicle without compilation, thereby reducing the compilation time and delay. Combined with the advantages of direct connection, it is convenient for timely optimization of the code and feedback on the effect, thereby realizing the testing of low-latency vehicle control code. It should be emphasized that since the vehicle-side real-time kernel component related to this solution has only been released recently, and the Simulink vehicle control simulation model needs to be patched with a real-time simulation program to achieve real-time vehicle control, before the component and patch are released, directly transmitting CAN signals through the PC to control the vehicle cannot meet the required communication delay requirements.

[0028] It is understandable that in vehicle control, the actuator has strict requirements on the response time of the received CAN message. This is because many safety and performance-related functions, such as braking systems, steering assistance and engine management systems, rely on accurate and timely control signals. If the communication time error of three consecutive frames of messages exceeds 50%, the actuator will report a fault, which may cause the vehicle to stop running. This design is to ensure the safety and reliability of the vehicle system. Therefore, in this application, the development and deployment work is carried out under the Ubuntu22.04 system, which is the first Ubuntu system to support the real-time kernel. It can improve the most basic and stable system-level clock, and can reduce the delay of the final CAN signal sent by the present invention at the system clock level, and improve stability; the simulation model uses the Linux version of Matlab2023b, which is also the first version of Matlab under Linux that supports real-time simulation. It can perform simulation cycles according to system time with stable and realistic time; in summary, the test vehicle and test platform are required in this application to ensure support for the real-time kernel, and the vehicle simulation model needs to support real-time simulation. In addition, it should be noted that Simulink is a graphical multi-domain simulation and model-based design platform that is widely used in dynamic simulation and analysis of complex systems. In the field of vehicle control, Simulink vehicle control simulation model can simulate various control logics and behaviors of the vehicle.

[0029] It is understandable that the process of generating ROS test messages is a key step in converting test requirements into specific executable instructions. This involves extracting key parameters from the test task, such as the goals, conditions, and expected responses of vehicle control, and mapping these parameters to the format of ROS messages. ROS messages usually contain a header (including timestamp and frame identifier), type, subject, and message body (payload), where the message body is where the test data is stored.

[0030] It should be understood that after the test platform interprets the test task, the CAN information of the corresponding vehicle control task can be obtained, and its ID, length (DLC) and data (Data) can be encapsulated according to the ROS message to obtain the ROS test message.

[0031] In one embodiment, before generating a ROS test message according to the test task, the method further includes: synchronizing the system time of the Simulink vehicle control model of the test platform and the Ubuntu system time of the controlled vehicle based on the NTP network time protocol; creating a ROS relay node in the Ubuntu system, and establishing a connection by submitting registration information to the Simulink vehicle control model on the test platform.

[0032] It should be noted that this synchronization operation is critical to ensure the accuracy and reliability of the test. Since vehicle control tests often require accurate timestamps to evaluate the order of data and events, time synchronization between the test platform and the vehicle system can eliminate potential errors caused by time differences. In addition, synchronizing time through the NTP protocol is a common network operation that can provide high-precision time synchronization services to ensure consistent device time in distributed systems.

[0033] It is understandable that creating a ROS relay node and establishing a connection is a necessary step to achieve effective communication between the test platform and the vehicle. The relay node acts as a bridge for message transmission, ensuring that test instructions and control data can be seamlessly transmitted between the test platform and the vehicle. Submitting registration information to the Simulink vehicle control model is a key step in establishing this communication bridge, which allows the Simulink model to recognize and respond to messages from the ROS relay node, thereby triggering corresponding vehicle control actions.

[0034] Step A20: Transmit the ROS test message to the controlled vehicle to obtain control result data returned by the controlled vehicle.

[0035] It should be noted that this process involves the application of the ROS (Robot Operating System) system in vehicle control testing, where ROS test messages are a set of signals used to trigger specific control logic on the vehicle. These messages are published to the network through the ROS system, received by the corresponding ROS nodes and converted into control instructions for the vehicle hardware. These instructions may include control of the vehicle engine, braking system, steering system or other key subsystems.

[0036] It is understandable that in order to achieve this process, the corresponding ROS nodes and hardware interfaces need to be deployed on the vehicle so that they can receive ROS messages from the test console and send them to the vehicle's electronic control units (ECUs) through the vehicle's CAN bus or other communication protocols. At the same time, after the vehicle's control system executes these instructions, it will generate corresponding feedback signals, which are then converted into ROS messages and sent back to the test console.

[0037] It should be understood that this process requires a high degree of synchronization and real-time performance to ensure the accuracy and reliability of the test. Any delay or communication error may lead to inaccurate test results and even affect the safe operation of the vehicle. Therefore, it is usually necessary to implement an efficient communication mechanism and error handling strategy on the vehicle's ROS node to ensure that the test message can be received and executed by the vehicle in a timely and accurate manner, while effectively returning the control result data to the test console. In actual applications, this process may also include monitoring and logging of ROS messages for data analysis and fault diagnosis after the test is completed. In this way, test engineers can evaluate the performance of the vehicle control system, identify potential problems, and optimize the control algorithm to improve the overall performance and safety of the vehicle.

[0038] Step A30: Obtain the execution quality of the test task according to the control result data to complete the closed-loop test of the vehicle control code.

[0039] It should be noted that by conducting in-depth analysis of the control result data returned by the controlled vehicle, it is possible to evaluate whether the execution effect of the test task meets expectations, including real-time monitoring, recording and post-processing analysis of the data, and comparison with preset performance indicators. The control result data may include the vehicle's operating status, sensor readings, actuator response time, etc., which are important bases for judging the performance of the vehicle control code.

[0040] It is understandable that the purpose of completing closed-loop testing is not only to verify the correctness of the code, but also to identify potential problems and opportunities for improvement. By analyzing the control result data, engineers can understand the performance of the vehicle control code in actual operation, including key performance indicators such as system stability, response speed, and processing accuracy. If the test results show deviations or anomalies, this will trigger further debugging and optimization of the control code to ensure that the system ultimately deployed on the vehicle can reliably perform its intended tasks.

[0041] The present application generates a ROS test message according to a test task; transmits the ROS test message to a controlled vehicle to obtain control result data returned by the controlled vehicle; and obtains the execution quality of the test task according to the control result data to complete a closed-loop test of the vehicle control code.

[0042] In summary, this application generates ROS test messages on the test platform and synchronizes the system time, uses the ROS relay node to establish a real-time connection with the Ubuntu system of the controlled vehicle, and directly sends the vehicle control data in CAN format through the Simulink vehicle control model to test and optimize the vehicle control program. This method supports real-time simulation, ensures the accurate execution and rapid feedback of control instructions, and thus significantly improves the efficiency of vehicle control code testing. After executing the vehicle control instructions, the controlled vehicle can monitor the data on the CAN bus in real time and return the control results, making the test process more direct and rapid. This testing method not only reduces the time consumption of compiling and deploying code in traditional testing, but also improves the accuracy and reliability of the test through real-time data exchange, providing a more efficient and convenient testing method.

[0043] Reference Figure 2 , Figure 2 This is a flow chart of the second embodiment of the low-latency vehicle control test method of the present application. Based on the above-mentioned first embodiment, the second embodiment of the low-latency vehicle control test method of the present application is proposed.

[0044] In this embodiment, the step A10 includes: Step A101: parse the test task through the Simulink vehicle control model to obtain vehicle control data, where the data type of the vehicle control data is in CAN format.

[0045] It should be noted that in the Simulink model, the test task is usually defined as a series of input conditions, expected outputs and performance indicators. When the model parses these test tasks, it generates vehicle control data that conforms to the CAN protocol format.

[0046] Step A102: Encapsulate the vehicle control data according to the ROS message format to obtain the ROS test message.

[0047] It is understandable that the reason for performing this step is that the original CAN data cannot be directly transmitted in the ROS node of Simulink and needs to be packaged here.

[0048] It should be noted that the specific packaging process includes: creating a standard Uint32MultiArray ROS message through the 'Blank Message' module, whose data type is a multidimensional array that supports Uint32; secondly, setting its length (CurrentLength) in the 'BusAssignment' module to 10. According to the structural characteristics of the original CAN message, the ID occupies 1 bit, the length (DLC) occupies 1 bit, and the data (Data) occupies 8 bits; finally, the length (DLC) and data (Data) of the CAN data in the previous steps are both forced to be converted to uint32 type. Since these two quantities are both smaller than the length of uint32, this conversion will not cause data loss and are entered into the data field (Data) of this standard ROS message.

[0049] In this embodiment, the test task is first parsed through a Simulink vehicle control model to obtain vehicle control data, where the data type of the vehicle control data is in CAN format; the vehicle control data is packaged according to the ROS message format to obtain the ROS test message.

[0050] In summary, by directly parsing the test task in the Simulink vehicle control model and generating vehicle control data in CAN format, the process from test design to execution is simplified. This method of directly generating control data reduces the need for traditional manual coding and configuration, thereby speeding up the implementation of test tasks and encapsulating vehicle control data into ROS message format to ensure accurate data transmission between Simulink and ROS nodes. This encapsulation method ensures the integrity and consistency of data during transmission, reduces the delay caused by format mismatch or data conversion errors, and speeds up signal transmission.

[0051] The present application embodiment provides a low-latency vehicle control test method, referring to Figure 3 , Figure 3 This is a flow chart of the third embodiment of the present application.

[0052] In this embodiment, the low-latency vehicle control test method is applied to a controlled vehicle, and the method includes: Step B10: Receive the ROS test message.

[0053] It can be understood that the ROS test message here is sent by the test platform to the controlled vehicle.

[0054] Step B20: Parse the ROS test message to obtain vehicle control instructions.

[0055] It should be noted that in this step, the data and instructions contained in the ROS test message are converted into a format that can be understood and executed by the vehicle electronic control units (ECUs).

[0056] It can be understood that after receiving the Uint32MultiArray type message sent by Simulink, it is interpreted according to the packaging process and order, that is, the first bit of the data is the ID of the CAN message, the second bit of the data is the length of the CAN message (DLC), and the third to tenth bits of the data are the data of the CAN message (Data).

[0057] Step B30: Execute the vehicle control command, monitor and obtain the control result data on the CAN bus.

[0058] It should be noted that this step transmits the control instruction to the CAN bus to let the corresponding ECU execute the test task, which is equivalent to actually triggering the vehicle's control action, and continues to monitor the CAN bus to obtain the execution result after the signal is sent.

[0059] In one embodiment, executing the vehicle control instruction, monitoring and obtaining the control result data on the CAN bus, includes: sending the vehicle control instruction to a vehicle electronic control unit, and having the vehicle electronic control unit execute the vehicle control instruction; after the controlled vehicle responds to the vehicle control instruction, monitoring and parsing CAN transmission data on the CAN bus; if the CAN transmission data contains vehicle control feedback data, packaging the vehicle control feedback data as control result data.

[0060] It is understandable that after receiving the command, the ECU performs corresponding actions according to the built-in control algorithm, such as adjusting engine parameters, activating a safety system, or changing the driving state of the vehicle. During the execution of the command, the data exchange on the CAN bus is continuously monitored to capture the feedback signals and status information generated by the execution action. For example, the control result data captured from the CAN bus usually includes sensor readings, system status flags, error codes, etc. These data are crucial for evaluating the execution effect of the command. The acquired control result data is fed back to the test control system to evaluate the execution quality of the test task and serve as the basis for optimizing the control strategy.

[0061] Step B40: Return the control result data to the test platform.

[0062] It should be noted that this step ensures that the control result data collected from the vehicle control system can be effectively transmitted back to the test platform. Returning the control result data to the test platform is equivalent to completing the last data transmission. After data analysis on the test platform, the actual effect of the vehicle control program can be obtained, thereby determining the subsequent optimization direction and completing the closed loop of the test.

[0063] This embodiment receives the ROS test message, which is sent by the test platform; parses the ROS test message to obtain a vehicle control instruction; executes the vehicle control instruction, monitors and obtains control result data on the CAN bus; and returns the control result data to the test platform.

[0064] In summary, when receiving ROS test messages and parsing them into vehicle control commands, the converted data are commands that the ECU can understand, that is, the data is only processed and converted once in the process and can be sent to the CAN bus for execution. This process not only reduces manual intervention, but also speeds up the test execution. While executing vehicle control commands, the data on the CAN bus is monitored in real time, and the feedback signals of control actions are captured in time, providing instant response and adjustment capabilities for the test, and returning the control result data to the test platform, so that test engineers can analyze based on actual data, providing data support for the optimization of vehicle control programs.

[0065] Reference Figure 4 , Figure 4 This is a flow chart of the fourth embodiment of the low-latency vehicle control test method of the present application. Based on the above-mentioned third embodiment, the fourth embodiment of the low-latency vehicle control test method of the present application is proposed.

[0066] In this embodiment, the step B20 includes: Step B201: Parse the ROS test message to obtain a data frame of a preset field type.

[0067] It should be noted that the CAN data frame is the basic unit for transmitting information in the CAN communication protocol. It consists of seven key segments: the start of frame (SOF) marks the beginning of the frame; the arbitration segment is used to determine the priority of the frame, where the difference between the standard frame and the extended frame lies in the different lengths of the ID code; the control segment indicates the data length and reserved bits; the data segment carries the actual transmitted data, which can be 0 to 8 bytes in length; the CRC segment is used to detect errors during frame transmission; the ACK segment is used by the receiver to confirm that the message is received normally; and finally, the end of frame (EOF) marks the end of the frame. These segments together ensure the structuring of the CAN data frame and the reliability of transmission.

[0068] It is understandable that, during the CAN data transmission process, it is only necessary to ensure that the ID, DLC and Data of the CAN message can be accurately transmitted to the execution end, and other auxiliary check fields such as arbitration and control will be automatically adapted by the driver end. The processing of CAN data in this embodiment also only includes adapting the ID, DLC and Data.

[0069] Step B202: Obtaining substantial control data according to the data frame of the preset field type.

[0070] It should be noted that since the ID, DLC and Data fields obtained in the above steps contain key information for actually controlling the vehicle, the actual control data here usually includes specific parameters and commands required for vehicle control, such as engine speed setting, brake pressure adjustment or steering angle change.

[0071] It is understandable that the ID, DLC, and Data fields in the data frame need to be decoded and mapped to specific control commands. For example, the ID field may identify a specific vehicle system or function, the DLC field indicates the length of the subsequent data field, and the Data field contains the actual control value or parameter. Through this mapping, the vehicle's control system can understand and execute the instructions parsed from the ROS test message to achieve specific control operations on the vehicle.

[0072] Step B203: Obtain vehicle control instructions according to the actual control data.

[0073] It can be understood that after obtaining the actual control data, the CAN messages are packaged and sent through a set of APIs for operating the CAN bus provided in the Linux kernel: SocketCAN. The specific steps include: opening the nested word and initializing the CAN device (Kavaser), binding the nested word to the CAN device; setting the filter conditions (only sending data / sending data and receiving data), and then assigning the CAN data given by the ROS node to the data structure of SocketCAN, and finally sending the CAN message to the car CAN bus.

[0074] In this embodiment, by parsing the ROS test message, a data frame of a preset field type is obtained, and the field type includes an arbitration segment, a control segment, and a data segment; according to the data frame of the preset field type, actual control data is obtained; according to the actual control data, a vehicle control instruction is obtained.

[0075] In summary, this embodiment proposes an efficient vehicle control test method, which obtains the CAN data frame required for vehicle control by parsing the ROS test message, and then generates the vehicle control command. The method first uses the preset fields in the ROS test message, such as the arbitration segment, the control segment, and the data segment, to construct a data frame that conforms to the CAN protocol. Then, key vehicle control parameters, such as engine speed or brake pressure, are extracted from these data frames, and these parameters are mapped to specific vehicle control commands. Finally, through the SocketCAN API, these instructions are packaged and sent to the electronic control unit (ECUs) of the vehicle through the CAN bus to achieve precise control of the vehicle. The advantage of this method is its high degree of automation and accuracy, which reduces human errors, improves test efficiency, and ensures the correct implementation and verification of vehicle control strategies.

[0076] Reference Figure 5 The present application also provides a low-latency vehicle control test device, the low-latency vehicle control test device comprising: The test data generation module 10 is used to generate ROS test messages according to the test tasks; A data transmission module 20, used for transmitting the ROS test message to the controlled vehicle, and obtaining control result data returned by the controlled vehicle; The test result analysis module 30 is used to obtain the execution quality of the test task according to the control result data to complete the closed-loop test of the vehicle control code.

[0077] In one embodiment, the data transmission module 20 is also used to synchronize the system time of the Simulink vehicle control model of the test platform and the Ubuntu system time of the controlled vehicle based on the NTP network time protocol; create a ROS relay node in the Ubuntu system, and establish a connection by submitting registration information to the Simulink vehicle control model on the test platform.

[0078] In one embodiment, the test data generation module 10 is further used to parse the test task through a Simulink vehicle control model to obtain vehicle control data, the data type of the vehicle control data is in CAN format; and encapsulate the vehicle control data according to the ROS message format to obtain the ROS test message.

[0079] An embodiment of the present application also provides a low-latency vehicle control testing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the low-latency vehicle control testing method in the above-mentioned embodiment one.

[0080] Reference below Figure 6 , which shows a schematic diagram of the structure of a low-latency vehicle control test device suitable for implementing the embodiment of the present application. The low-latency vehicle control test device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The low-latency vehicle control test equipment shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0081] like Figure 6 As shown, the low-latency vehicle control test equipment may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the low-latency vehicle control test equipment are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the low-latency vehicle control test equipment to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a low-latency vehicle control test equipment with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0082] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0083] The low-latency vehicle control test equipment provided by the present application adopts the low-latency vehicle control test method in the above-mentioned embodiment, which can solve the technical problem of how to simplify the test process of the existing vehicle control code in the art to improve the efficiency of debugging and optimization. Compared with the prior art, the beneficial effects of the low-latency vehicle control test equipment provided by the present application are the same as the beneficial effects of the low-latency vehicle control test method provided by the above-mentioned embodiment, and the other technical features in the low-latency vehicle control test equipment are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0084] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0085] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0086] The present application also provides a storage medium, on which a low-latency vehicle control test program is stored. When the low-latency vehicle control test program is executed by a processor, the steps of the low-latency vehicle control test method as described in any one of the above are implemented.

[0087] The storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM: RandomAccess Memory), a read-only memory (ROM: Read Only Memory), an erasable programmable read-only memory (EPROM: Erasable Programmable Read Only Memory or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM: CD-Read Only Memory), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, system or device. The program code contained on the storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency: Radio Frequency), etc., or any suitable combination of the above.

[0088] The above-mentioned storage medium may be included in the low-latency vehicle control test equipment; or it may exist independently without being assembled into the low-latency vehicle control test equipment.

[0089] The computer-readable storage medium carries one or more programs. When the one or more programs are executed by the low-latency vehicle control test device, the low-latency vehicle control test device: Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0090] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0091] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0092] The storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned low-latency vehicle control test method, and can solve the technical problem of how to simplify the test process of the existing vehicle control code to improve the efficiency of debugging and optimization. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the low-latency vehicle control test method provided in the above-mentioned embodiment, and will not be repeated here.

[0093] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A low-latency vehicle control test method, characterized in that: The low-latency vehicle control test method is applied to a test platform, and the low-latency vehicle control test method includes: Generate ROS test messages according to the test tasks; Transmitting the ROS test message to the controlled vehicle to obtain control result data returned by the controlled vehicle; The execution quality of the test task is obtained according to the control result data to complete the closed-loop test of the vehicle control code.

2. The low-latency vehicle control test method according to claim 1, characterized in that: Before generating the ROS test message according to the test task, the method further includes: Based on the NTP network time protocol, the system time of the Simulink vehicle control model of the test platform and the Ubuntu system time of the controlled vehicle are synchronized; A ROS relay node is created in the Ubuntu system, and a connection is established by submitting registration information to the Simulink vehicle control model on the test platform.

3. The low-latency vehicle control test method according to claim 1, characterized in that: The generating of ROS test messages according to the test tasks includes: The test task is parsed through a Simulink vehicle control model to obtain vehicle control data, where the data type of the vehicle control data is in CAN format; The vehicle control data is encapsulated according to the ROS message format to obtain the ROS test message.

4. The low-latency vehicle control test method according to claim 2, characterized in that: The Ubuntu system of the controlled vehicle supports a real-time kernel, and the Simulink vehicle control model on the test platform supports real-time simulation.

5. A low-latency vehicle control test method, characterized in that: The low-latency vehicle control test method is applied to a controlled vehicle, and the low-latency vehicle control test method includes: Receiving the ROS test message, where the ROS test message is sent by the test platform; Parsing the ROS test message to obtain vehicle control instructions; Execute the vehicle control command, monitor and obtain the control result data on the CAN bus; The control result data is returned to the test platform.

6. The low-latency vehicle control test method according to claim 5, characterized in that: The parsing of the ROS test message to obtain the vehicle control instruction includes: Parsing the ROS test message to obtain a data frame of a preset field type, wherein the field type includes an arbitration segment, a control segment, and a data segment; Obtaining substantial control data according to the data frame of the preset field type; A vehicle control instruction is obtained according to the substantial control data.

7. The low-latency vehicle control test method according to claim 5, characterized in that: The executing the vehicle control command and monitoring and acquiring the control result data on the CAN bus includes: Sending the vehicle control command to a vehicle electronic control unit, so that the vehicle electronic control unit executes the vehicle control command; After the controlled vehicle responds to the vehicle control command, monitoring and parsing CAN transmission data on the CAN bus; If the CAN transmission data includes vehicle control feedback data, the vehicle control feedback data is packaged as control result data.

8. A low-latency vehicle control test device, characterized in that: The low-latency vehicle control test device comprises: The test data generation module is used to generate ROS test messages according to the test tasks; A data transmission module, used for transmitting the ROS test message to the controlled vehicle, and obtaining the control result data returned by the controlled vehicle; The test result analysis module is used to obtain the execution quality of the test task according to the control result data to complete the closed-loop test of the vehicle control code.

9. A low-latency vehicle control test device, characterized in that: The low-latency vehicle control test equipment includes: a memory, a processor, and a low-latency vehicle control test program stored in the memory and executable on the processor, wherein the low-latency vehicle control test program is configured to implement the steps of the low-latency vehicle control test method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that: The storage medium stores a low-latency vehicle control test program, which, when executed by a processor, implements the steps of the low-latency vehicle control test method as described in any one of claims 1 to 7.

Images