Fault diagnosis methods, devices, domain controllers, and robots based on domain controllers

Abstract

This application relates to a fault diagnosis method, apparatus, domain controller, and robot based on a domain controller. The method includes: receiving a test instruction triggered by a test item and obtaining a test configuration file corresponding to the test item; loading the test configuration file through a test service program on the domain controller and testing the robot according to the test configuration file to obtain a test result; in response to the test result being a test failure, generating a fault diagnosis request context corresponding to the test item; and performing fault diagnosis on the robot based on a fault diagnosis model and the diagnosis request context to obtain a diagnosis result. This method can improve the efficiency of fault diagnosis.

Description

Technical Field

[0001] This application relates to the field of robotics technology, and in particular to a fault diagnosis method, apparatus, domain controller, and robot based on a domain controller. Background Technology

[0002] Before robots leave the factory, their hardware undergoes rigorous pre-shipment testing. Currently, the industry commonly uses manual or semi-automatic script-based testing. Manual testing is inefficient, inconsistent, prone to errors and omissions in result recording, and heavily reliant on the experience of the testers. Existing automated testing tools often have limited functionality, lack a unified management platform and problem diagnosis capabilities. When tests fail, production line workers struggle to quickly pinpoint the root cause, leading to lengthy troubleshooting processes that severely impact production cycle time and first-pass yield. Summary of the Invention

[0003] Based on this, this application provides a fault diagnosis method, apparatus, domain controller, and robot based on a domain controller to improve the efficiency of robot fault diagnosis.

[0004] Firstly, a fault diagnosis method based on a domain controller is provided, which diagnoses faults in a robot through a domain controller. This method includes: Receive test instructions generated based on test items, and obtain the test configuration file corresponding to the test items; The test configuration file is loaded by the test service program on the domain controller, and the robot is tested according to the test configuration file to obtain the test results; In response to the test result being a test failure, a fault diagnosis request context corresponding to the test item is generated. Based on the fault diagnosis model and the diagnosis request context, the robot is subjected to fault diagnosis, and the diagnosis result is obtained.

[0005] Secondly, a fault diagnosis device based on a domain controller is provided, which performs fault diagnosis on a robot through a domain controller. The device includes: The receiving module is used to receive test instructions generated based on test items and obtain the test configuration file corresponding to the test items; The testing module is used to load the test configuration file through the test service program on the domain controller, and to test the robot according to the test configuration file to obtain test results; The context generation module is used to generate a fault diagnosis request context corresponding to the test item in response to the test result being a test failure. The diagnostic module is used to perform fault diagnosis on the robot based on the fault diagnosis model and the diagnostic request context, and obtain the diagnostic results.

[0006] In some embodiments, the context generation module includes: The information acquisition submodule is used to acquire the device identification information, hardware information, fault information and time information corresponding to the test item; The encapsulation submodule is used to encapsulate the device identification information, the hardware information, the fault information, and the time information to obtain the fault diagnosis request context corresponding to the test item.

[0007] In some embodiments, the apparatus further includes: The data acquisition module is used to acquire historical test data, debugging data, and fault analysis data. The case construction module is used to process the historical test data, the debugging data, and the fault analysis data to construct fault cases; The training module is used to train the preset fault diagnosis model based on the fault cases to obtain the fault diagnosis model.

[0008] In some embodiments, the test module includes: The parsing submodule is used to parse the test configuration file to determine the hardware under test, multiple test cases, test order, and protocol adaptation layer interface corresponding to the test item. The execution submodule is used to call the protocol adaptation layer interface, execute the multiple test cases on the hardware under test according to the test order, and obtain the test results.

[0009] In some embodiments, the apparatus further includes: A protocol determination module is used to determine the communication protocol corresponding to the hardware under test. The test case determination module is used to determine multiple test cases corresponding to the hardware under test according to the communication protocol.

[0010] In some embodiments, the apparatus further includes: The suggestion generation module is used to generate troubleshooting suggestions based on the fault diagnosis model. The display module is used to display the troubleshooting suggestions via a host computer.

[0011] In some embodiments, the apparatus further includes: The storage module is used to upload the test results, the diagnostic request context, and the diagnostic results to a cloud server for storage.

[0012] Thirdly, a domain controller is provided, on which a computer program is stored, the domain controller being used to execute the computer program to implement the fault diagnosis method described above.

[0013] Fourthly, a robot is provided, comprising: a domain controller storing a computer program, the domain controller being used to execute the computer program to implement the fault diagnosis method as described above.

[0014] The aforementioned fault diagnosis method, apparatus, domain controller, and robot based on a domain controller can decouple test logic from hardware parameters by setting test configuration files and test service programs, thereby reducing test costs. Furthermore, in the event of a test failure, a fault diagnosis request context corresponding to the test item is generated. Based on the fault diagnosis model and the diagnostic request context, fault diagnosis is performed on the robot to obtain a diagnostic result, thus improving the efficiency of fault diagnosis. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the robot provided in an embodiment of the present invention; Figure 2 A schematic flowchart of the fault diagnosis method provided in an embodiment of the present invention; Figure 3 A schematic diagram of a scenario for the fault diagnosis method provided in an embodiment of the present invention; Figure 4 This is another scenario diagram illustrating the fault diagnosis method provided in the embodiments of the present invention; Figure 5 This is a structural block diagram of the fault diagnosis device provided in an embodiment of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0017] This application provides an embodiment of a robot. For example... Figure 1 As shown, the robot includes a host computer, a domain controller, and hardware components.

[0018] The domain controller is the core test executor of the robot system. It stores computer programs that it executes to implement fault diagnosis methods. These computer programs may include test service programs. These programs embed test logic for testing hardware components such as the head and neck motors, torso motors, robotic arm, gripper, and camera. The test service programs can also directly call the underlying driver interfaces of each hardware component to perform control, communication, and data acquisition operations. A graphical user interface program based on the QT framework runs on a host computer. The host computer can connect to the domain controller via a wired network and communicate with the test service programs using the HTTP (Hypertext Transfer Protocol) protocol, such as sending test commands and receiving test results. This provides users with one-click test control, real-time progress display, and intuitive result presentation.

[0019] In one embodiment, such as Figure 2 As shown, a fault diagnosis method based on a domain controller is provided. This method is applied to... Figure 1 Taking a domain controller as an example, the following steps are included: Step S101: Receive the test instruction generated based on the test item trigger, and obtain the test configuration file corresponding to the test item; A test item is the smallest task unit for testing the robot's components. The components to be tested can be the functionality, performance indicators, or control parameters of the robot's hardware components. For example, a test item could be testing the accuracy of motor position, whether the motor torque meets the standard, or the accuracy of joint repeatability. Test items uniquely identify the detection content corresponding to the current diagnosis, enabling precise classification and localization of fault scenarios.

[0020] Test items can be displayed on the robot's host computer. These test items can be displayed as buttons. When a test item is pressed, a test instruction is generated to test that specific test item on the robot. The display format of the test items is not specifically limited here. In some embodiments, a "Start Full Test" button can be set to integrate all test items. When the "Start Full Test" button is pressed, a test instruction is generated to test all test items on the robot. Specifically, the host computer can send test instructions to the domain controller via an HTTP request.

[0021] The test configuration file defines information such as the test objective, test methods, and test pass / fail criteria. For example, the test objective is the hardware under test. The test methods include test items, test order, control parameters, communication parameters, etc. The test pass / fail criteria include pass / fail thresholds, etc.

[0022] In some embodiments, the test configuration file includes a hardware topology mapping area. This hardware topology mapping area can define all test targets in list form. Each entry may include, but is not limited to: the logical name of the hardware component, hardware type, bus identifier, node identifier (ID), Internet Protocol (IP) address: port, etc. For example, the logical name of the hardware component may be neck_pitch_motor, the hardware type may be canopen_motor, the bus identifier may be can0, and the node ID may be 0x02. By setting the hardware topology mapping area, the test logic and the hardware physical address are separated.

[0023] The test configuration file also includes a test order definition area. This area defines the execution order of test items, supporting sequential, parallel, and grouped execution. Furthermore, preconditions and post-test actions can be set for each test item. For example, a precondition could be: execute only after the network communication test passes. A post-test action could be: return the motor to the zero position after the test is completed.

[0024] The test configuration file also includes a test procedure and parameter area. This area defines detailed steps and parameters for each test item. Taking the CANopen motor position test as an example, parameters may include: control word sequence (control_word), target position (target_position), allowable position error threshold (position_tolerance), settling_time_ms time window for position stabilization determination, and single-step test timeout (timeout_ms). The control word sequence can be: 0x0006 (ready to start), 0x0007 (start), 0x000F (run). In some embodiments, the test sequence definition area and test steps, together with the parameter area, define the test method.

[0025] The test configuration file also includes a decision logic area. This decision logic area defines how to determine if the test passes, i.e., defines the test pass criteria. In some embodiments, this decision logic area supports both simple threshold comparisons and complex logic combinations, such as: (average error < 0.2) && (maximum error < 0.5) && (no fault alarm).

[0026] In some embodiments, the test configuration file also includes a communication parameter area. The communication parameter area centrally defines global parameters for various buses, such as the bitrate of the CAN bus, the distributed clock configuration of EtherCAT, and the heartbeat timeout of TCP.

[0027] In summary, these test configuration files define the list of hardware under test, the test order of each test item, specific control parameters (such as motor rotation angle), communication parameters (such as CAN ID and IP address), judgment thresholds (such as allowable position error range and image quality standards), and the mapping relationship between hardware components and logical channels. These test configuration files can thus drive the behavior of the test service program in the domain controller. The test configuration files can be in YAML or JSON format; no specific restrictions are placed on the format here.

[0028] In this embodiment, by modifying the test configuration file instead of the program code, different robot models, hardware variants, or test standards can be flexibly adapted, thereby improving the maintainability and scalability of the system.

[0029] Step S102: Load the test configuration file through the test service program on the domain controller, and test the robot according to the test configuration file to obtain the test results; Assume the test configuration file defines the test targets as a head and neck CANopen motor, a robotic arm, a gripper, and a USB camera. Test items include testing the position control accuracy of the head and neck CANopen motor, the communication stability of the torso EtherCAT motor, the network communication connectivity of the robotic arm, joint position feedback, gripper opening and closing command response, and USB camera recognition, image acquisition, and image quality detection. The test sequence is: head and neck motor → torso motor → robotic arm → gripper → USB camera. Control parameters include: target rotation angle, gripper action commands, and image acquisition resolution. Communication parameters include: communication protocol, CAN node ID, and communication rate. Test pass criteria include: the error between the feedback position value and the target angle ≤ 0.2, and a Ping test success rate ≥ 100%.

[0030] Based on the above test configuration file, the domain controller tested the robot, and the test results are as follows: 1. CANopen head and neck motor: Control rotation to 10°, read feedback value 9.5°, error 0.5° > threshold 0.2°, mark as "failure".

[0031] 2. Torso EtherCAT motor: Test passed.

[0032] 3. Robotic arm: Ping the controller and successfully read the joint position; test passed.

[0033] 4. Gripper: The test passed after sending the opening / closing command and receiving a successful feedback.

[0034] 5. USB camera: Successfully captured images without any screen distortion or green screen abnormalities; test passed.

[0035] In some embodiments, the step of testing the robot according to a test configuration file and obtaining test results includes: (A1) Parse the test configuration file to determine the hardware under test, multiple test cases, test order, and protocol adaptation layer interface corresponding to the test items; (A2) Call the protocol adaptation layer interface to execute multiple test cases on the hardware under test in the test order and obtain the test results.

[0036] The domain controller loads the test configuration file through the test service program, parses the test configuration file, and determines the hardware under test (DUT) corresponding to each test item, multiple test cases, test order, and protocol adaptation layer interfaces. The DUT refers to the hardware components tested in the robot, such as motors, cameras, and grippers. The test order is the sequence of the test items within the test flow. For example, if there are three test items A, B, and C, the test order can be set as follows: first execute test item A, then test item B, and finally test item C.

[0037] Test cases define the specific execution logic, control flow, and judgment rules for implementing the corresponding test item detection. A pre-defined association can be established between test items and test cases. For example, for the test item "Testing the closed-loop position of a motor," the test case could be set as: Enable the driver -> Set the target position -> Continuously read the actual position and calculate the error -> Determine if the error is within the threshold and if a timeout has occurred -> De-enable the driver. As another example, for the test item "Testing the image quality of a camera," the test case could be set as: Acquire N frames of images -> Perform pixel statistics, sharpness calculation, and color space analysis on each frame -> Comprehensively determine if there are any signal anomalies. In some embodiments, a test case library can be established to store the above test cases.

[0038] It should be noted that one test item can correspond to one or more test cases. Test cases can be loaded and executed by the domain controller. The test result of a test item is determined based on the execution results of the corresponding test cases. In some embodiments, after each test case is executed, a structured result object is generated, containing the test item ID, execution status (pass / fail / timeout / error), measurement value, expected threshold, original data snapshot, timestamp, and standardized error code. Finally, these results are summarized and reported to the host computer in real time in JSON format via HTTP / HTTPS protocol.

[0039] In this embodiment of the application, driver encapsulation modules with different communication protocols and protocol adaptation layer interfaces can also be used to assist in the execution of test cases.

[0040] For example, the CANopen / EtherCAT adapter module encapsulates the standard CiA 402 driver protocol stack. During motor testing, this module not only sends target position commands but also handles: 1) configuring driver parameters, such as mode and gain, via Service Data Objects (SDOs); 2) issuing and reading feedback values ​​in real-time and periodically via Process Data Objects (PDOs); and 3) monitoring the driver's status word in real-time to detect states such as "fault," "in position," and "enabled," ensuring the test is conducted within a safe and controllable state machine.

[0041] The TCP / IP Socket adapter module is used to communicate with network-based devices such as robotic arm controllers and independent sensors. This module manages the lifecycle of the Socket connection, encapsulates specific application layer protocols (such as Modbus TCP and custom JSON commands), and implements command assembly, transmission, reception, and decompression.

[0042] USB / UVC adapter module: Used to control the camera. This module enumerates and opens the device through the libusb or V4L2 framework, sets parameters such as resolution and frame rate, and stably captures the image stream.

[0043] In some embodiments, before parsing the test configuration file and determining the hardware under test corresponding to the test item, multiple test cases, test order, and protocol adaptation layer interface steps, the method further includes: (B1) Determine the communication protocol corresponding to the hardware under test; (B2) Based on the communication protocol, determine multiple test cases corresponding to the hardware under test.

[0044] The communication protocol is a standardized communication rule defined between the hardware under test (DUT) and the domain controller, including data format, command definition, transmission timing, and interaction mechanism. Different types of DUTs use a compatible communication protocol to issue control commands and acquire data.

[0045] For example, the communication protocol for a servo motor is CANopen / EtherCAT, and a test case can be set up to "control the motor to rotate to a preset position (e.g., 10°), read the feedback position, and determine whether the error is within the allowable range (e.g., ±0.2°)". The communication protocol for a robotic arm is Ethernet-based, and a test case can be set up to "first test network communication via Ping, then send basic control commands and verify the feedback". The communication protocol for a camera is USB, and a test case can be set up to "check the USB device node, acquire images, and use OpenCV algorithms for basic image quality analysis (e.g., detecting screen tearing or black screen)".

[0046] Step S103: In response to the test result being a test failure, generate a fault diagnosis request context corresponding to the test item; In some embodiments, the step of generating a fault diagnosis request context corresponding to a test item includes: (C1) Obtain the device identification information, hardware information, fault information, and time information corresponding to the test item; (C2) Encapsulate the device identification information, hardware information, fault information and time information to obtain the fault diagnosis request context corresponding to the test item.

[0047] The device identification information can be the robot's serial number, used to uniquely identify the device and avoid confusion between multiple devices. Hardware information includes the hardware type, communication protocol, and node ID of the faulty hardware. Time information can be a timestamp, representing the absolute time of the fault occurrence, ensuring traceability, sortability, and reproducibility. Fault information can include command values, feedback values, actual errors, allowable thresholds, error codes, and error descriptions. Fault information is used to quantify the fault and explain why an alarm was triggered, and is the core of the entire diagnostic process. In some embodiments, the fault information may also include: auxiliary environmental data related to the fault. This auxiliary environmental data can reconstruct the entire fault scene for in-depth analysis of the fault's cause. The auxiliary environmental data may include: current, speed, temperature, voltage, bus status, historical test results, and sampling sequences.

[0048] The fault diagnosis request context can be presented in the following form: { "robot_sn": "RBT20240407001", "test_item": "left_shoulder_pitch_motor_position_accuracy", "hardware": {"type": "motor", "protocol": "CANopen", "node_id": 3}, "failure_context": { "command": 10.0, "feedback": 9.2, "error": 0.8, "threshold": 0.2, "error_code": "0x80F1", "error_message": "Position following error exceeded" }, "related_data": { "motor_current": [ / * Current sampling sequence* / ], "motor_velocity": [ / * velocity sampling sequence* / ], "network_status": "OK", "recent_tests": [ / * Results of the most recent tests on the same item* / ] }, "timestamp": "2024-04-07T10:23:45Z" } Step S104: Based on the fault diagnosis model and the diagnosis request context, perform fault diagnosis on the robot and obtain the diagnosis results.

[0049] The diagnostic request context can be combined with preset system prompts (such as "You are a robot hardware testing and diagnostic expert...") and sent to the fault diagnosis model. The model identifies key entities in the diagnostic request context, such as CANopen, motor, error code 0x80F1, and error 0.8. Then, the relevant fault mode memory is activated in the model parameters. Possible causes are ranked based on probability. For example, based on historical data, the probability of "cable connection problem" is much higher than "driver hardware failure," so the former will be ranked first, resulting in the diagnostic result.

[0050] In some embodiments, prior to the step of performing fault diagnosis on the robot based on a fault diagnosis model and a diagnosis request context to obtain the diagnosis result, the following steps are included: (D1) Acquire historical test data, debugging data, and fault analysis data; (D2) Process historical test data, debugging data, and fault analysis data to construct fault cases; (D3) Train the preset fault diagnosis model based on fault cases to obtain the fault diagnosis model.

[0051] like Figure 3As shown, the process begins with multi-source data acquisition, including historical test data, debugging data, and fault analysis data. Historical test data can be the complete context of each test recorded by the system, such as machine serial number, test time, raw test data, error codes and descriptions of failures, operator corrective actions, and retest results after correction. Debugging data can include embedded software logs, controller error codes, engineer debugging notes, and solutions. Fault analysis data can include structured hardware interface documents, electrical schematics, and manually written common fault tree (FTA) analysis documents.

[0052] Next, the collected multi-source data can be cleaned and aligned. For example, the raw logs can be parsed to extract key entities such as error codes, hardware modules, testing phases, and measurement values.

[0053] Then, construct a failure case. Reconstruct a complete "failure occurrence-analysis-repair-verification" event into a coherent narrative. For example, extract from the log: "10:23:45, ERROR, Left shoulder motor (0x03) position error 0.8°>0.2°, error code 0x80F1" and the subsequent "10:30:12, INFO, Operator checked and re-tightened X2 connector, retest passed" and merge them into a failure case.

[0054] Next, construct training samples for the pre-defined fault diagnosis model. Transform the fault cases into a standardized format required for fine-tuning the large language model. Each sample may include the following: A command (Structure) is a structured query used to summarize the fault phenomenon. For example: [Fault Diagnosis] Hardware: Left shoulder pitch motor; Protocol: CANopen; Test item: Position control accuracy; Phenomenon: Command 10.0°, feedback 9.2°, error 0.8° exceeding the threshold of 0.2°; Error code: 0x80F1 (Position following error exceeds limit). Please provide possible causes and troubleshooting steps.

[0055] Expected Output. The expected output is a structured, actionable diagnostic report. For example: [Possible Causes] 1. Loose or poor contact in the motor encoder cable (X2 connector). 2. The proportional gain of the driver position loop is set too low. 3. There is jamming in the mechanical transmission components. [Troubleshooting Steps] 1. Physical Connection Check: First, disconnect the power, locate the X2 connector inside the rear cover plate of the robot's left shoulder, and confirm that it is fully inserted and locked. 2. Parameter Check: Connect to the driver via the host computer, check the fluctuation of the object dictionary 0x6061 (actual position value), and check whether 0x60F9 (position loop P gain) is set to the recommended value. 3. Manual Check: It is recommended to check in the order of 1->2->3.

[0056] The above method transforms unstructured data into structured "command-response" pairs that can be used to train a pre-defined fault diagnosis model. Finally, the pre-defined fault diagnosis model is trained using these training sample pairs to obtain the fault diagnosis model. In some embodiments, the structured training samples can be stored in a vector database or a relational database for easier version management, retrieval, and subsequent incremental learning.

[0057] In this embodiment, a large language model (LLM) with strong general capabilities and suitable for fine-tuning instructions can be selected as the preset fault diagnosis model, such as the GPT series, LLaMA series, ChatGLM, etc. The fault diagnosis model obtained after training the preset fault diagnosis model can learn the proper nouns, fault modes, and error code meanings of robot hardware (motors, sensors, buses, etc.); it can understand the reasoning chain from "phenomenon" to "cause" and the principle of "easy to difficult, external to internal" that should be followed in the troubleshooting steps; and it can generate clear and distinct structured text containing "possible causes" and "troubleshooting steps".

[0058] In some embodiments, after the step of performing fault diagnosis on the robot based on the fault diagnosis model and the diagnosis request context to obtain the diagnosis result, the method further includes: (E1) Generate troubleshooting suggestions through the fault diagnosis model; (E2) Display troubleshooting suggestions through the host computer.

[0059] A fault suggestion request can be generated, with the following format: {“Hardware”: “Neck Motor 1”, “Test Item”: “Position Accuracy”, “Protocol”: “CANopen”, “Phenomenon”: “Command 10°, Feedback 9.5°, Error 0.5°”, “Error Code”: “0x80F1”}. The fault diagnosis model returns the following diagnostic results: “

Possible Causes

Troubleshooting Steps

[0060] The host computer displays this diagnostic suggestion in the diagnostic panel. Following step 1, the worker checked and found a loose cable connection. After reconnecting it securely, the worker retested the item separately on the interface, and the test passed.

[0061] In some embodiments, after the step of performing fault diagnosis on the robot based on the fault diagnosis model and the diagnosis request context to obtain the diagnosis result, the method further includes: The test results, diagnostic request context, and diagnostic results are uploaded to the cloud server for storage.

[0062] like Figure 4 As shown, the cloud server can receive and store all test result data uploaded from the host computer, including serial number, test time, pass / fail status of each item, detailed error logs, etc., realizing cloud-based, structured storage and full lifecycle traceability of test data, providing a data foundation for quality analysis and process optimization.

[0063] In the above fault diagnosis method, by setting a test configuration file and a test service program, the test logic can be decoupled from the hardware parameters, reducing testing costs. Furthermore, in the case of a test failure, a fault diagnosis request context corresponding to the test item is generated. Based on the fault diagnosis model and the diagnostic request context, fault diagnosis is performed on the robot to obtain a diagnostic result, thus improving the efficiency of fault diagnosis.

[0064] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0065] In one embodiment, such as Figure 5 As shown, a fault diagnosis device based on a domain controller is provided, which performs fault diagnosis on a robot through the domain controller. The device 20 includes: a receiving module 201, a testing module 202, a context generation module 203, and a diagnosis module 204. The receiving module 201 is used to receive test instructions generated based on test items and obtain the test configuration file corresponding to the test items; the testing module 202 is used to load the test configuration file through a test service program on the domain controller and perform tests on the robot according to the test configuration file to obtain test results; the context generation module 203 is used to generate a fault diagnosis request context corresponding to the test item in response to the test result being a test failure; the diagnosis module 204 is used to perform fault diagnosis on the robot based on a fault diagnosis model and the diagnosis request context to obtain diagnostic results.

[0066] In some embodiments, the context generation module 203 includes an information acquisition submodule and an encapsulation submodule. The information acquisition submodule acquires device identification information, hardware information, fault information, and time information corresponding to the test item; the encapsulation submodule encapsulates the device identification information, hardware information, fault information, and time information to obtain the fault diagnosis request context corresponding to the test item.

[0067] In some embodiments, the device 20 further includes a data acquisition module, a case construction module, and a training module. The data acquisition module acquires historical test data, debugging data, and fault analysis data; the case construction module processes the historical test data, the debugging data, and the fault analysis data to construct fault cases; and the training module trains a preset fault diagnosis model based on the fault cases to obtain the fault diagnosis model.

[0068] In some embodiments, the test module 202 includes a parsing submodule and an execution submodule. The parsing submodule parses the test configuration file to determine the hardware under test corresponding to the test item, multiple test cases, the test order, and the protocol adaptation layer interface. The execution submodule calls the protocol adaptation layer interface to execute the multiple test cases on the hardware under test according to the test order, thereby obtaining the test results.

[0069] In some embodiments, the apparatus 20 further includes a protocol determination module and a test case determination module. The protocol determination module is used to determine the communication protocol corresponding to the hardware under test; the test case determination module is used to determine multiple test cases corresponding to the hardware under test based on the communication protocol.

[0070] In some embodiments, the device 20 further includes a suggestion generation module and a display module. The suggestion generation module is used to generate troubleshooting suggestions using the fault diagnosis model; the display module is used to display the troubleshooting suggestions via a host computer.

[0071] In some embodiments, the apparatus 20 further includes a storage module for uploading the test results, the diagnostic request context, and the diagnostic results to a cloud server for storage.

[0072] For specific limitations regarding the fault diagnosis device, please refer to the limitations of the fault diagnosis method above, which will not be repeated here. Each module in the aforementioned fault diagnosis device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or stored in software within the domain controller to facilitate the execution of their corresponding operations.

[0073] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0074] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0075] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A fault diagnosis method based on a domain controller, characterized in that, The method for diagnosing robot faults using a domain controller includes: Receive test instructions generated based on test items, and obtain the test configuration file corresponding to the test items; The test configuration file is loaded by the test service program on the domain controller, and the robot is tested according to the test configuration file to obtain the test results; In response to the test result being a test failure, a fault diagnosis request context corresponding to the test item is generated. Based on the fault diagnosis model and the diagnosis request context, the robot is subjected to fault diagnosis, and the diagnosis result is obtained.

2. The method according to claim 1, characterized in that, The step of generating the fault diagnosis request context corresponding to the test item includes: Obtain the device identification information, hardware information, fault information, and time information corresponding to the test item; The device identification information, hardware information, fault information, and time information are encapsulated to obtain the fault diagnosis request context corresponding to the test item.

3. The method according to claim 1, characterized in that, Before the step of performing fault diagnosis on the robot based on the fault diagnosis model and the diagnosis request context to obtain the diagnosis result, the following steps are included: Acquire historical test data, debugging data, and fault analysis data; The historical test data, the debugging data, and the fault analysis data are processed to construct fault cases; The preset fault diagnosis model is trained based on the fault cases to obtain the fault diagnosis model.

4. The method according to claim 1, characterized in that, The step of testing the robot according to the test configuration file and obtaining the test results includes: The test configuration file is parsed to determine the hardware under test, multiple test cases, test order, and protocol adaptation layer interface corresponding to the test item. The protocol adaptation layer interface is invoked to execute the multiple test cases on the hardware under test in the test order to obtain the test results.

5. The method according to claim 4, characterized in that, Before parsing the test configuration file to determine the hardware under test, multiple test cases, test order, and protocol adaptation layer interface steps corresponding to the test item, the process also includes: Determine the communication protocol corresponding to the hardware under test; Based on the communication protocol, multiple test cases are determined corresponding to the hardware under test.

6. The method according to claim 1, characterized in that, After the step of performing fault diagnosis on the robot based on the fault diagnosis model and the diagnosis request context to obtain the diagnosis result, the method further includes: The fault diagnosis model generates fault troubleshooting suggestions. The troubleshooting suggestions are displayed via a host computer.

7. The method according to claim 1, characterized in that, After the step of performing fault diagnosis on the robot based on the fault diagnosis model and the diagnosis request context to obtain the diagnosis result, the method further includes: The test results, the diagnostic request context, and the diagnostic results are uploaded to a cloud server for storage.

8. A fault diagnosis device based on a domain controller, characterized in that, The device includes: The receiving module is used to receive test instructions generated based on test items and obtain the test configuration file corresponding to the test items; The testing module is used to load the test configuration file through the test service program on the domain controller, and to test the robot according to the test configuration file to obtain test results; The context generation module is used to generate a fault diagnosis request context corresponding to the test item in response to the test result being a test failure. The diagnostic module is used to perform fault diagnosis on the robot based on the fault diagnosis model and the diagnostic request context, and obtain the diagnostic results.

9. A domain controller, characterized in that, The domain controller stores a computer program, which is used to execute the computer program to implement the fault diagnosis method as described in any one of claims 1-7.

10. A robot, characterized in that, include: A domain controller, on which a computer program is stored, the domain controller being used to execute the computer program to implement the fault diagnosis method as described in any one of claims 1-7.

Images