Method of testing a robot, controller, system and robot

Abstract

The application discloses a kind of robot testing method, controller, system and robot, it is related to robot testing and simulation technical field.The method comprises: by obtaining sensor data generated when robot executes test task in digital simulation environment, and sensor data and algorithm module are applied to the running process of robot in the digital simulation environment, various test scenes are preposed to virtual environment and are carried out, and development cost is reduced;And by using the connection between digital simulation environment and algorithm module, the internal running state of robot is captured, the internal state visualization of algorithm is realized, and the algorithm defects can be quickly positioned;In addition, the simulation data of sensor is calibrated based on noise calibration file, the " reality gap " between simulation and physical object is greatly reduced, and the actual performance of entity robot can be directly predicted by simulation test conclusion.

Description

Technical Field

[0001] This application relates to the field of robot testing and simulation technology, and more specifically, to a robot testing method, controller, system, and robot. Background Technology

[0002] Testing of quadruped robots mainly relies on physical robot testing or pure software simulation testing. Pure software simulation physical models are too idealized and deviate significantly from real working conditions, so the simulation results cannot be effectively adapted to physical robots. On the other hand, physical robot testing is costly, has limited testing scenarios, and makes it difficult to simultaneously observe the internal state of the algorithm and the external physical state of the robot. Summary of the Invention

[0003] In view of this, embodiments of this application propose a robot testing method, controller, system, and robot, which can effectively adapt simulation results to physical robots, reduce testing costs, and simultaneously observe the internal state of the algorithm and the external physical state of the robot to quickly locate algorithm defects.

[0004] The following technical solution is adopted in this application.

[0005] In a first aspect, embodiments of this application provide a method for testing a robot. The method includes: acquiring sensor data generated when the robot performs a test task in a digital simulation environment; applying the sensor data and an algorithm module to the robot's operation in the digital simulation environment; the algorithm module includes at least one algorithm required for the robot's overall operation; during the operation, capturing the robot's internal operating state using a physical or logical communication link between the digital simulation environment and the algorithm module; the internal operating state is used to indicate the intermediate value of any one of the at least one algorithms executed by the robot.

[0006] In some embodiments, before applying the sensor data and algorithm module to the operation of the robot in the digital simulation environment, the method further includes: acquiring a noise calibration file for the sensor; and calibrating the sensor data according to the noise calibration file.

[0007] In some embodiments, when the digital simulation environment and the algorithm module are connected via a physical communication link, capturing the internal operating state of the robot includes: a first carrier equipped with the digital simulation environment transmitting sensor data to a second carrier on which the algorithm module is deployed via the physical communication link; the second carrier calling the algorithm in the algorithm module to perform calculations based on the sensor data and obtaining intermediate values ​​generated during the calculations; and determining the internal operating state of the robot based on the intermediate values.

[0008] In some embodiments, when the digital simulation environment and the algorithm module are connected via a logical communication link, capturing the internal operating state of the robot includes: compiling the algorithm module into a dynamic library; loading the dynamic library onto a first carrier carrying the digital simulation environment via the logical communication link; the first carrier calling the algorithm in the algorithm module to perform calculations based on the sensor data and obtaining intermediate values ​​generated during the calculations; and determining the internal operating state of the robot based on the intermediate values.

[0009] In some embodiments, based on the second carrier calling the algorithm in the algorithm module, or the first carrier calling the algorithm in the algorithm module, after capturing the internal operating state of the robot, the method further includes: generating control instructions for the robot based on the sensor data; driving the robot to operate in the digital simulation environment according to the control instructions, and acquiring the external physical state of the robot.

[0010] In some embodiments, after acquiring the external physical state of the robot, the method further includes: synchronizing the sensor data, the internal operating state, and the external physical state in time; obtaining test results of the robot performing a test task in the digital simulation environment based on the time-synchronized sensor data, the internal operating state, and the external physical state; the test results include one or more combinations of key events, internal event features, and event causal relationships.

[0011] In some embodiments, the test tasks include one or more of the following: single-function verification, multi-algorithm joint verification, full-scenario testing, sensor fault testing, and robot joint fault testing.

[0012] Secondly, embodiments of this application provide a robot testing device, comprising: a first acquisition module for acquiring sensor data generated by the robot when performing a test task in a digital simulation environment; a simulation module for applying the sensor data and an algorithm module to the robot's operation in the digital simulation environment; the algorithm module comprising at least one algorithm required for the overall operation of the robot; and a second acquisition module for capturing the robot's internal operating state during the operation by utilizing a physical or logical communication link between the digital simulation environment and the algorithm module; the internal operating state indicating the intermediate value of any one of the at least one algorithms executed by the robot.

[0013] Thirdly, a controller is provided, comprising: a processor and a memory; the memory storing instructions or programs, the processor being configured to: implement the method of the first aspect when the instructions or programs are executed.

[0014] Fourthly, a testing system is provided, comprising: a cloud server and a controller as described in the third aspect; the cloud server stores a robot model library and noise calibration files, and the cloud server is used to provide the controller with digital model parameters of the robot and noise calibration files of the sensors.

[0015] Fifthly, a robot is provided, comprising: a robot body and a controller as described in the third aspect, the controller being disposed within the robot body.

[0016] In a sixth aspect, a computer-readable storage medium is provided, wherein program code is stored therein, the program code being invoked by a processor or electronic device to execute the method of the first aspect.

[0017] In a seventh aspect, a computer program product or computer program is also provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the method of the first aspect.

[0018] The technical solution provided in this application has at least the following beneficial effects: By acquiring sensor data generated when the robot performs test tasks in a digital simulation environment, and applying the sensor data and algorithm modules to the robot's operation in the digital simulation environment, high-risk boundary scenarios and fault tests can all be carried out in the virtual environment in advance. This avoids wear and tear or damage caused by using physical robots and significantly reduces development costs.

[0019] During operation, the connection between the digital simulation environment and the algorithm module is used to capture the robot's internal operating state, that is, the intermediate value of the robot's algorithm execution. Based on the automated large-scale scene traversal, the internal state of the algorithm is visualized, which can quickly locate algorithm defects and achieve full coverage of extreme environments and fault conditions, thus enhancing the robustness of the algorithm.

[0020] In addition, the simulation of sensors and dynamics is driven by real data. The simulation model does not rely on pure theoretical parameters, but calibrates the simulated data of the sensors through noise calibration files, which greatly reduces the "reality gap" between simulation and physical objects. The simulation test results can directly predict the actual performance of physical robots.

[0021] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0022] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0023] Figure 1 This is a schematic diagram of a testing system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the testing method for the first robot provided in the embodiments of this application; Figure 3 This is a schematic diagram of a data flow provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the second robot testing method provided in this application embodiment; Figure 5 This is a flowchart illustrating the third robot testing method provided in the embodiments of this application; Figure 6 This is a flowchart illustrating the fourth robot testing method provided in this application embodiment; Figure 7 This is a schematic diagram of a visual interface for fault root cause localization provided in an embodiment of this application; Figure 8 This is a flowchart illustrating the fifth robot testing method provided in this application embodiment; Figure 9 This is a schematic diagram of the structure of a robot testing device provided in an embodiment of this application; Figure 10 This is a schematic diagram of the structure of a controller provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of a robot provided in an embodiment of this application.

[0024] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept of this application in any way, but rather to illustrate the concept of this application to those skilled in the art through specific embodiments. Detailed Implementation

[0025] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0026] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0027] In typical technologies, each iteration of an algorithm module requires deployment on a physical robot dog for road testing. This not only leads to lengthy testing cycles, but frequent physical testing can also cause hardware wear and tear or even damage, such as motor overload or drop impacts. Furthermore, physical testing is limited by the scale, terrain type, and safety of the physical testing field, making it difficult to reproduce extreme, dangerous, or low-probability scenarios, such as extremely smooth surfaces, dense dynamic obstacles, or strong electromagnetic interference. This results in the algorithm's robustness under boundary conditions not being fully verified.

[0028] Furthermore, when anomalies occur during physical testing (such as gait instability or obstacle avoidance failure), it is difficult to distinguish whether the root cause is a flaw in the algorithm logic, sensor noise, actuator latency, or a mismatch in model parameters. The lack of means to simultaneously observe the algorithm's internal states (such as state estimation covariance, controller cost function values, and feature tracking states) and external physical responses leads to low algorithm debugging efficiency. In addition, it is difficult for different testing teams or different versions of algorithm modules to conduct objective comparisons in completely consistent virtual environments and test cases; currently, the industry still lacks standardized, reproducible, and unified testing benchmarks.

[0029] However, while pure software simulations such as open-source robot simulators (Gazebo) and multi-joint dynamics with contact (MuJoCo) have the advantages of safety and efficiency, the physical models, sensor noise models, and actuator dynamic models they use are often too idealized. This leads to a serious performance drop when many algorithms that perform well in simulation environments are deployed to physical robots.

[0030] Therefore, there are four core problems in the current testing process: First, testing relies on physical hardware, which brings high costs and significant risks; second, the testing scenarios are relatively simple and the overall coverage is insufficient; third, it is difficult to observe the internal state of the tested object, and the problem localization is not clear and accurate enough; and fourth, there is a "reality gap" between the simulation environment and the physical object.

[0031] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0032] Figure 1 This is a schematic diagram of a testing system provided in an embodiment of this application. Figure 1 As shown, the testing system 100 may include a cloud server 110 and a controller 1000; the cloud server 110 is used to provide the controller 1000 with the robot's digital model parameters and the sensor's noise calibration file, and the controller 1000 is used to perform testing methods on the robot according to the robot's digital model parameters and the sensor's noise calibration file.

[0033] Optionally, the cloud server 110 and the controller 1000 can communicate via a wired or wireless connection. The wired connection may include, but is not limited to, a bus, fiber optic cable, or network cable. Wireless connections may include, for example, transmission control protocol / internet protocol (TCP / IP), wireless local area network protocol (WLAN), and remote direct memory access (RDMA) over converged ethernet (RoCE) network protocol.

[0034] The following is combined Figure 1The illustrated implementation environment provides an exemplary description of the robot testing method provided in this application embodiment: The cloud server 110 stores a robot model library and noise calibration files, and also stores at least dynamic parameters, environmental interference simulation parameters, and sensor fault simulation parameters. First, the controller 1000 obtains the sensor noise calibration files, dynamic parameters, environmental interference simulation parameters, and sensor fault simulation parameters from the cloud server 110, and obtains the robot's digital model parameters from the robot model library of the cloud server 110 to construct a digital simulation environment. Second, based on the constructed digital simulation environment, the controller 1000 obtains sensor data generated by the robot when performing test tasks. Utilizing the connection between the digital simulation environment and the algorithm module, the controller applies the sensor data and the robot control commands generated by the algorithm module to the digital simulation environment to obtain the robot's external physical state, while simultaneously capturing the robot's internal operating state. Finally, the controller 1000 obtains the test results of the robot performing test tasks in the digital simulation environment based on the time-synchronized sensor data, internal operating state, and external physical state.

[0035] Figure 1 The testing system in [the document] can be used to implement the following: Figure 2 The described testing method for the robot, such as Figure 2 The flowchart of the first robot testing method shown is illustrated. In a specific embodiment, this robot testing method can be applied to, for example... Figure 9 The robot testing device 600 shown and the controller 1000 configured with the robot testing device 600 are shown. Figure 10 The following will address... Figure 2 The process shown is described in detail. The robot testing method may specifically include the following steps 210 to 230.

[0036] Step 210: Obtain sensor data generated when the robot performs test tasks in a digital simulation environment.

[0037] In this embodiment, the digital simulation environment runs on a high-performance computing server and includes a dynamics and terrain engine unit, a sensor noise and fault simulation unit, a test environment simulation unit, and a robot parameterized digital model library.

[0038] In one example, the dynamics and terrain engine unit employs a high-order physics engine that integrates flexible joint characteristics, contact surface friction mechanisms, and contact dynamics. For instance, it may use the MuJoCo physics engine or a custom-developed Bullet Physics engine to accurately simulate the robot's joint flexibility deformation, motion friction loss, and rigid-to-flexible body contact collisions. Simultaneously, this unit is equipped with a high-precision 3D terrain library. This library not only contains 3D geometric mesh models for various scenarios but also matches exclusive physical material properties for each terrain, including core physical parameters such as friction coefficient, collision elasticity, and force deformation models. It can simulate various complex and realistic terrains such as mud, sand, grass, ice, stairs, and gravel roads, accurately reproducing the robot's walking force, slippage, deformation, and other physical behaviors under different terrains, providing a realistic and comprehensive simulation environment for testing the robot's algorithm modules.

[0039] Furthermore, the sensor noise and fault simulation unit is configured with a virtual sensor model whose parameters have been calibrated using a noise calibration file. Based on the calibration parameters, it reproduces the inherent noise characteristics of a real sensor, simulating typical sensing errors such as bias and white noise of the Inertial Measurement Unit (IMU), camera lens distortion and motion blur, ranging noise and beam model of the LiDAR, and signal loss and multipath interference of the Global Positioning System (GPS). Simultaneously, this unit supports the injection of various sensor fault conditions, simulating fault modes such as partial camera occlusion, LiDAR ranging failure at a specified angle, and complete sensor failure. This allows for the construction of multiple sensing anomaly test scenarios in a simulation environment, fully verifying the robustness of the algorithm module under non-ideal sensing conditions.

[0040] Furthermore, the test environment simulation unit can construct diverse external environmental disturbance conditions to simulate wind, rain, and snow weather conditions, and reproduce the disturbance of meteorological factors on robot dynamic performance and sensor observation data. At the same time, it can also simulate dynamic obstacle scenarios, control the movement of pedestrians and vehicles through random strategies or preset scripts, and simulate scenarios such as gradual changes in lighting and strong light glare, restore the impact of optical interference on visual sensors, and realize multi-dimensional verification of the adaptability of robot perception algorithms and motion control algorithms under complex external disturbances.

[0041] Furthermore, the robot parametric digital model library can store digital model parameters for multiple different models of quadruped robots, including high-precision 3D models, mass and inertia parameters, joint transmission ratios and torque limits, motor and reducer models, battery discharge characteristic curves, and other multi-dimensional body parameters. At the same time, the model library supports users to import the robot's measured calibration parameters, quickly complete the initialization and configuration of the robot's digital twin, eliminate the need to build a simulation model from scratch, and improve the deployment efficiency of multi-model algorithm testing.

[0042] After the digital simulation environment is built, testers initiate test tasks, select and configure hierarchical test cases, or automatically batch configure test cases through an automated script engine and scene generator to drive the robot to execute preset test tasks in the digital simulation environment and ultimately obtain the robot's sensor data.

[0043] In one implementation, the test task includes one or more of the following: single-function verification, multi-algorithm joint verification, full-scenario testing, sensor fault testing, and robot joint fault testing.

[0044] In this embodiment of the application, the hierarchical test case library includes unit-level tests, integration-level tests, and scenario-level tests.

[0045] Among them, unit-level testing is used for single-function verification such as single-leg impedance control and state estimator convergence; integration-level testing is used for joint verification of multiple algorithms such as visual-inertial odometry (VIO) and corridor positioning drift testing; and scenario-level testing is used for full-scenario verification of crossing dynamic pedestrians and completing the ascent of stairs in rainy weather.

[0046] This includes pressure and fault injection tests, which verify the system's degraded operation capability by sequentially failing multiple sensors and joints.

[0047] Step 220: Apply the sensor data and algorithm module to the operation of the robot in the digital simulation environment; the algorithm module includes at least one algorithm required for the overall operation of the robot.

[0048] In this embodiment of the application, the algorithm module has a built-in algorithm to be tested. The algorithm to be tested is at least one functional algorithm required for the operation of the robot as a whole. Specifically, it may include any one or more combinations of algorithms such as multi-sensor fusion perception algorithm, attitude calculation algorithm, motion control algorithm, trajectory planning algorithm, and obstacle avoidance algorithm.

[0049] In one example, sensor data and an algorithm module, after noise calibration, are integrated into a digital simulation environment. The robot operates according to the control logic of the algorithm under test. During the simulation, the digital simulation environment continuously outputs simulated sensor data that conforms to real physical characteristics and transmits the sensor data to the algorithm module in real time. The algorithm module performs iterative calculations in real time based on the received sensor data, continuously outputs control commands for the robot, and transmits the control commands to the digital simulation environment, thereby driving the robot in the digital simulation environment to complete the corresponding motion actions.

[0050] Step 230: During the operation, the internal operating state of the robot is captured by using the physical or logical communication link between the digital simulation environment and the algorithm module; the internal operating state is used to indicate the intermediate value of the robot executing any one of the at least one algorithms.

[0051] In this embodiment, during the simulation operation, the internal operating state of the robot can be captured by relying on the connection channel between the digital simulation environment and the algorithm module. Specifically, through hardware-in-the-loop link or software-in-the-loop link, intermediate variables in the operation process of various algorithms such as perception fusion, motion control, and trajectory planning can be collected in real time. These intermediate variables include state estimation covariance, cost function output value, feature observation information, attitude calculation intermediate quantities, trajectory planning intermediate nodes, and other computational data, thus completely recording the entire process data of algorithm iteration.

[0052] Based on the collected intermediate values ​​of the algorithm operation, we can conduct in-depth analysis of the algorithm's internal operation behavior, providing complete and reliable data support for subsequent work such as timing alignment, fault tracing, and algorithm performance evaluation in conjunction with external physical conditions.

[0053] Among them, such as Figure 3 The diagram shows a data flow, which is the connection channel between the digital simulation environment and the algorithm module. It can flexibly switch between hardware-in-the-loop and software-in-the-loop data interaction modes according to the deployment mode of the algorithm module, so as to adapt to different algorithm testing needs.

[0054] In the first example, such as Figure 3 As shown, the algorithm module is deployed on physical hardware carriers such as airborne industrial control computers and embedded boards. It interacts with high-performance computing servers with digital simulation environments in real time through hardware-in-the-loop interfaces. The hardware-in-the-loop interfaces can be physical communication links such as Ethernet, Controller Area Network (CAN), and RS232 serial port (Recommended Standard 232) to accurately reproduce the hardware communication mechanism of sensor data transmission and control command feedback of real robots, and highly replicate the communication conditions of physical airborne equipment.

[0055] In the second example, please continue reading. Figure 3 The algorithm module is pure software code, which can compile the algorithm code under test into standard dynamic libraries such as .so and .dll, and load it into the process of the digital simulation environment through the software-in-the-loop interface. Since both the dynamic library and the digital simulation environment are deployed on high-performance computing servers, high-speed data interaction is achieved through local process calls and shared memory mechanisms, without the need for physical communication media, and the running logic and computing performance of the original algorithm code are preserved to the maximum extent.

[0056] It is important to note that the hardware-in-the-loop interface and the software-in-the-loop interface are two independent optional channels, and only one of them will be used for the same test task. The two interfaces share the same digital simulation environment and multi-dimensional analysis module, and the system architecture is fully compatible, enabling a single system to cover both physical hardware testing and pure software simulation testing.

[0057] Optionally, in the process of capturing the robot's internal operating state by connecting the digital simulation environment and the algorithm module, the timing synchronization and real-time assurance unit can be used to uniformly align the simulation environment's operating steps with the algorithm module's computation cycle, accurately reproduce the algorithm calculation delay and link communication delay of the real device, and ensure that the runtime sequence in both software-in-the-loop and hardware-in-the-loop test modes conforms to the operating characteristics of the real robot, thereby improving the realism of the simulation test.

[0058] In this embodiment, the internal operating state of the algorithm module is directly acquired through a semi-physical interface, which allows for real-time observation of the controller cost function, optimization iteration process, and filter state uncertainty. Combined with synchronous observation of the external physical state, this significantly reduces the difficulty of locating algorithm defects.

[0059] In addition, the simulation of sensors and dynamics is driven by real data. The simulation model does not rely on pure theoretical parameters. Instead, it calibrates the virtual motor by collecting motor load current curves and constructs a noise model by collecting static data from long-term inertial measurement units (IMUs). This greatly reduces the "reality gap" between simulation and physical objects. The simulation test results can directly predict the actual performance of the physical robot.

[0060] Meanwhile, by systematically injecting various faults such as sensor failure, actuator saturation, and communication interruption, the algorithm's fault-tolerant logic is automatically tested in batches, and the system's degraded operation strategy is quantitatively evaluated, which can meet the development needs of high-reliability robots.

[0061] Building upon the above, this application provides an optional implementation method for capturing the internal operating state of the robot by connecting the digital simulation environment and the algorithm module via a physical communication link, such as... Figure 4The flowchart of the second robot testing method shown may specifically include the following steps 310 to 370.

[0062] Step 310: Obtain sensor data generated when the robot performs test tasks in a digital simulation environment.

[0063] Step 320: Apply the sensor data and algorithm module to the operation of the robot in the digital simulation environment; the algorithm module includes at least one algorithm required for the overall operation of the robot.

[0064] Step 330: The first carrier equipped with the digital simulation environment transmits sensor data to the second carrier equipped with the algorithm module through the physical communication link.

[0065] In one implementation, the first carrier is a high-performance computing server, on which the digital simulation environment runs; the second carrier is the robot dog's onboard computer, on which the algorithm module to be tested is deployed; the high-performance computing server and the robot dog's onboard computer interact with sensor data and control commands through an Ethernet hardware channel.

[0066] Step 340: The second carrier calls the algorithm in the algorithm module to perform calculations based on the sensor data and obtains intermediate values ​​generated during the calculation process.

[0067] For example, the robot dog's onboard computer loads perception fusion algorithms, motion control algorithms, etc., from the algorithm module, and receives virtual sensor data forwarded via a physical communication link, sequentially performing continuous operations such as feature extraction, state estimation, and balance solving. Furthermore, based on data capture nodes set up in the algorithm operation link, it continuously collects various intermediate values ​​output during the algorithm iteration process, including filter state estimation covariance, cost function output value, feature observation information, attitude calculation intermediate quantities, trajectory planning intermediate nodes, etc.

[0068] Step 350: Determine the internal operating state of the robot based on the intermediate value.

[0069] For example, the collected intermediate values ​​of various algorithms are structured and encapsulated to form an internal operating state that can characterize the internal operating logic of the algorithm, so as to ensure that the internal convergence, estimation bias and threshold triggering events of the perception fusion and motion control algorithms can be intuitively reflected.

[0070] Step 360: Generate control commands for the robot based on the sensor data.

[0071] For example, the algorithm module completes closed-loop calculations based on virtual sensor data, combines the robot's (robot dog's) current motion constraints and dynamic limitations, outputs joint control commands in the form of target positions and target torques for each joint, and transmits the control commands back to the first carrier running the digital simulation environment via a physical communication link, so as to drive the robot digital model in the digital simulation environment to perform corresponding actions.

[0072] Step 370: Drive the robot to run in the digital simulation environment according to the control command, and obtain the external physical state of the robot.

[0073] For example, the digital simulation environment running on the first carrier receives control commands transmitted back from the second carrier and applies the control commands to the parameterized digital model of the robot (such as a robot dog); the simulation environment relies on the built-in high-order dynamics engine to solve the contact dynamics and joint motion response between the robot and the terrain and obstacles, and drives the digital model to generate corresponding motion behavior.

[0074] Meanwhile, during the simulation operation of the robot (such as a robot dog), the digital simulation environment collects the physical state of the robot (such as a robot dog) digital model in real time. The external physical state includes the robot body pose, actual joint angles, joint output torque, foot contact force, movement speed, and the spatial relative position of the robot body with the surrounding environment.

[0075] For a detailed description of steps 310 and 320, please refer to steps 210 and 220, which will not be repeated here.

[0076] In this embodiment, the internal operating state of the robot during algorithm execution is captured by the physical communication link between the digital simulation environment and the algorithm module. Based on automated large-scale scene traversal, the internal state of the algorithm is visualized, which can quickly locate algorithm defects.

[0077] Building upon the above, this application provides an optional implementation method for capturing the internal operating state of the robot by connecting the digital simulation environment and the algorithm module via a logical communication link, such as... Figure 5 The flowchart of the third robot testing method shown may specifically include the following steps 410 to 480.

[0078] Step 410: Obtain sensor data generated when the robot performs test tasks in a digital simulation environment.

[0079] Step 420: Apply the sensor data and algorithm module to the operation of the robot in the digital simulation environment; the algorithm module includes at least one algorithm required for the overall operation of the robot.

[0080] Step 430: Compile the algorithm module into a dynamic library.

[0081] For example, the algorithm module under test is pure software program code, which does not depend on any physical onboard computer. The system compiles and encapsulates the complete source code of the perception, control, and planning algorithms to generate .so or .dll dynamic link library files that can be directly called by the simulation process, facilitating dynamic loading and real-time calling in the digital simulation environment.

[0082] Step 440: Load the dynamic library into the first carrier carrying the digital simulation environment through the logical communication link.

[0083] For example, the compiled algorithm dynamic library is directly loaded into the process of the high-performance computing server running the digital simulation environment, so that the algorithm module and the simulation engine are deployed in the same computing device and the same process space. Data interaction is completed through software interfaces, function calls and shared memory, achieving zero physical transmission latency.

[0084] Step 450: The first carrier calls the algorithm in the algorithm module to perform calculations based on the sensor data and obtains intermediate values ​​generated during the calculation process.

[0085] For example, the simulation process of the high-performance computing server locally calls the complete algorithm logic within the dynamic library, outputs noisy virtual sensor data based on the digital simulation environment, and continuously performs operations such as multi-sensor fusion, state estimation, trajectory solving, and motion closed-loop control. Throughout the entire algorithm iteration calculation process, the system captures the intermediate computation data of the algorithm in real time, including filter state estimation covariance, cost function output value, feature observation information, attitude calculation intermediate quantities, trajectory planning intermediate nodes, etc.

[0086] Step 460: Determine the internal operating state of the robot based on the intermediate value.

[0087] Step 470: Generate control commands for the robot based on the sensor data.

[0088] Step 480: Drive the robot to run in the digital simulation environment according to the control command, and obtain the external physical state of the robot.

[0089] For a detailed description of steps 410 and 420, please refer to steps 210 and 220. For a detailed description of steps 460 and 480, please refer to steps 350 and 370. They will not be repeated here.

[0090] In this embodiment, the algorithm module is compiled into a dynamic library and loaded into the simulation process of the running digital simulation environment through a logical communication link between the digital simulation environment and the algorithm module. This captures the internal running state of the robot, realizes visualization of the internal state of the algorithm with zero physical transmission delay, and enhances the robustness of the algorithm.

[0091] Building upon the above, after capturing the robot's internal operating state, this application provides an optional implementation method for obtaining the test results of the robot performing test tasks in a digital simulation environment, such as... Figure 6 The flowchart of the fourth robot testing method shown may specifically include the following steps 510 to 590.

[0092] Step 510: Obtain sensor data generated when the robot performs test tasks in a digital simulation environment.

[0093] Step 520: Obtain the noise calibration file for the sensor.

[0094] For example, the noise calibration file stores the noise model parameters obtained from the calibration of real sensors, including the noise characteristic coefficients corresponding to various sensors such as IMU, camera, LiDAR, and GPS, which are used for the configuration of virtual sensor model parameters.

[0095] Step 530: Calibrate the sensor data according to the noise calibration file.

[0096] For example, the parameters in the noise calibration file are used to process the ideal sensor data generated by the simulation, and the inherent noise of various sensors is superimposed to restore the real sensing error. Fault data such as partial occlusion of sensors and ranging failure can also be injected as needed to generate sensing data that closely resembles the real working conditions, which can be used to test the operating performance of the algorithm module under abnormal sensing conditions.

[0097] Step 540: Apply the sensor data and algorithm module to the operation of the robot in the digital simulation environment; the algorithm module includes at least one algorithm required for the overall operation of the robot.

[0098] Step 550: During the operation, the internal operating state of the robot is captured by using the physical or logical communication link between the digital simulation environment and the algorithm module; the internal operating state is used to indicate the intermediate value of the robot executing any one of the at least one algorithms.

[0099] The specific steps of steps 510, 540 and 550 can be found in steps 210 to 230, and will not be repeated here.

[0100] Step 560: Generate control commands for the robot based on the sensor data.

[0101] Step 570: Drive the robot to run in the digital simulation environment according to the control command, and obtain the external physical state of the robot.

[0102] For a detailed description of steps 560 and 570, please refer to steps 350 and 370, which will not be repeated here.

[0103] Step 580: Synchronize the sensor data, the internal operating status, and the external physical status in time.

[0104] For example, relying on the system's built-in multi-source data synchronization recorder and playback device, the same timestamp mechanism is used, with the simulation clock as the time reference, to perform time-series alignment of sensor data, the internal operating state representing the algorithm's computation process, and the external physical state representing the robot's dynamic response; and to synchronously store the simulation true value, the sensor's original observation data, the robot's joint motion state, the input and output signals of the algorithm module under test, as well as all internal variables of the algorithm, such as filter covariance, visual feature points, and expected foot force.

[0105] Step 590: Based on the time-synchronized sensor data, the internal operating state, and the external physical state, obtain the test results of the robot performing the test task in the digital simulation environment; the test results include one or more combinations of key events, internal features of events, and causal relationships of events.

[0106] For example, the system's multi-dimensional analysis module completes the calculation of metrics and fault root cause localization for time-series aligned data. The automatic performance metric calculation unit distinguishes between motion control metrics, perception fusion metrics, and general metrics. Motion control metrics include trajectory tracking error, velocity tracking error, energy efficiency ratio, disturbance recovery time, and maximum stable tilt angle. Perception fusion metrics include absolute trajectory error (ATE), relative pose error (RPE), target detection recall and precision, and map integrity. Map integrity measures the degree to which the reconstructed map output by the robot reproduces the effective area of ​​the real or simulated ground truth environment. For example, it can be evaluated by comparing the reconstructed results with environmental elements such as objects, walls, windows, terrain, and obstacles in the simulated ground truth environment. General metrics include processor usage, memory usage, module communication latency, and fault detection response latency.

[0107] In addition, the system is equipped with causal analysis and root cause localization tools. When anomalies occur during testing or tasks fail, it supports replaying the complete time-series data stream before and after the fault occurs, simultaneously comparing changes in external sensor inputs, fluctuations in internal algorithm variables, and the robot's external physical motion response. By setting data breakpoints, the root cause of the fault can be quickly identified. Ultimately, the system extracts key events during the testing process, the corresponding internal algorithm features, and the causal relationships between sensor inputs, algorithm decisions, and abnormal robot motion, forming a complete test result.

[0108] In a more specific embodiment, such as Figure 3 As shown, the testing system is deployed on a high-performance workstation. The high-fidelity digital twin simulation environment, test case management and automated execution module, and multi-dimensional analysis module run on this workstation.

[0109] When using a physical communication interface connection, the hardware-in-the-loop interface of the semi-physical interface adapter module of the module under test is connected to a real machine dog onboard computer via Ethernet. The motion control module to be tested is running on this computer.

[0110] By selecting a model from the digital model library that matches the physical robot dog, and importing the dynamic parameters and sensor noise parameters, a high-fidelity digital twin of the robot dog can be constructed.

[0111] For yet another more specific embodiment, please refer to [link / reference needed]. Figure 3 The test was conducted on a tightly coupled odometer module based on lidar and IMU.

[0112] At this point, a logical communication interface is used to connect and the code of the odometer module under test is compiled into a dynamic library through the software-in-the-loop interface, loaded into the simulation environment, and a complex scene including a corridor, a spiral staircase and an open plaza is constructed.

[0113] A "Corridor + Spiral Staircase Positioning Drift Test" test case was created in the test case library. The robot dog's walking speed was configured, and IMU random walk noise and LiDAR view occlusion fault simulations were injected. After the preparation work was completed, the test was started by the automated script engine. The test status monitor monitored the pose and odometry output of the digital twin in real time. The multi-source data synchronization recorder recorded the simulation true pose, odometry estimated pose, number of feature points inside the module, optimization residuals, and IMU bias estimates throughout the process.

[0114] After the test, the performance calculator automatically calculates the absolute trajectory error (ATE) and relative attitude error (RPE). Then, the testers use a causal analysis tool to replay the test process to the moment the error suddenly increases, combining this with... Figure 7The fault root cause localization visualization interface shown has a timeline on the left side that records each time point of the entire task process, marking three key events: a sudden drop in the number of visual features, a localization error exceeding the threshold, and task failure. The middle area of ​​the interface synchronously displays the curves showing the change in the number of simulated real-world and VIO feature points. The right area of ​​the interface is for root cause inference, which can automatically associate causal relationships such as environmental interference, sensor failure, and divergence of internal algorithm variables, and finally outputs the defect localization conclusion and optimization suggestions.

[0115] correspond Figure 7 In the scenario shown, the output defect localization conclusions include LiDAR being geometrically obstructed by stairs, missing LiDAR point cloud, failure of visual feature tracking, degraded VIO observation quality, divergent state estimation covariance, and large localization error. The main root cause is the insufficient robustness of the perception module in feature-scarce scenarios. The optimization suggestion is to predict the weights of the real and fake IMUs in the short term or to activate the backup sensor.

[0116] In this embodiment, by systematically injecting various faults such as sensor failure, actuator saturation, and communication interruption, the fault-tolerant logic of the algorithm can be automatically tested in batches, and the system's degraded operation strategy can be quantitatively evaluated, thus meeting the development requirements of high-reliability robots. Simultaneously, the testing system uses software communication middleware such as Robot Operating System 2 (ROS 2), which is shared with the physical robot. The simulated and verified modules can be directly deployed to the physical robot, and the ROS Bag data packets collected by the physical robot can be transmitted back to the digital simulation environment to reproduce real-world faults, forming a two-way closed loop of "virtual simulation - physical testing".

[0117] Based on the foregoing, this application also provides an optional implementation method, such as... Figure 8 The flowchart of the fifth robot testing method shown may include the following:

[0118] In one example, the system is divided vertically into four parallel operating units: a test management unit, a high-fidelity digital twin simulation environment, the module under test, and a multi-dimensional analysis module. These units interact through standardized time-series data streams to achieve a closed-loop test encompassing fault injection, anomaly capture, automated performance evaluation, and algorithm root cause localization. The overall process is as follows: Figure 8 As shown.

[0119] The test management unit (test engineer / management system) serves as the task scheduling entry point, executing full lifecycle management of tests. It initiates test tasks (2.1), where testers or the automated management system select and configure hierarchical test cases. Fault injection strategies, such as those for sensor failures and actuator malfunctions, can be configured as needed. Instructions are then sent to the high-fidelity digital twin simulation environment. After one round of simulation testing is completed, a standardized review report and root cause analysis (output 4) are received from the analysis unit. Based on the review report and root cause analysis, algorithm iteration optimization and product deployment decisions are made, completing a single test iteration (4.3).

[0120] Furthermore, a parameterized quadruped robot digital model (1.2) and overall dynamic parameters (2.4) are loaded to construct a robot dog digital twin model; and a simulation scene (3.1) containing terrain, dynamic obstacles, and rain and snow interference elements is loaded; at the same time, a hardware measured noise calibration file is imported to support the superposition of fault models such as sensor noise, signal distortion, and sensor disconnection onto the sensor data stream, thus constructing a high-fidelity digital twin simulation environment.

[0121] Among them, the real-time simulation loop (A) in the high-fidelity digital twin simulation environment receives the joint control commands issued by the module under test, calculates the physical motion state of the robot as a whole, and generates virtual sensor data by superimposing preset noise and fault disturbances; the real-time simulation loop sends the virtual sensor data to the module under test, and continuously builds the real-time digital closed-loop interaction between the robot body and the algorithm under test.

[0122] Furthermore, the high-fidelity digital twin simulation environment has built-in status monitoring logic to continuously monitor the robot's posture, task execution progress, and program running status, forming an anomaly judgment branch: when an anomaly is judged (fall, task timeout, algorithm running error, etc.), step 16.9 is triggered to automatically capture a full-time-series data snapshot before and after the anomaly moment and write it to the multi-source data synchronization recorder; when a normal operation is judged, the real-time simulation loop is continuously maintained until the current test case runs out.

[0123] Furthermore, the module under test is the robot's onboard control module to be verified. A bidirectional data flow channel (B) is established between the module and the real-time simulation loop to achieve semi-physical interaction through software and hardware collaboration. Specifically, the module under test completes initialization upon power-up and continuously receives virtual sensor data from the real-time simulation loop. Internally, the module under test performs core algorithms for perception, localization, path planning, and motion control based on the virtual sensor data, generating joint control commands that are then sent back to the real-time simulation loop, completing one round of bidirectional interaction.

[0124] The module under test continuously executes the above calculation process in a loop, forming a complete real-time closed loop with the inner loop of the digital twin simulation.

[0125] Furthermore, the multi-dimensional dynamic synchronous analysis module enables unified storage of test data, automated calculation of indicators, and fault causal localization. Specifically, it collects simulation environment status, internal operating status of the module under test, and time-series snapshot data through a multi-source data synchronization recorder. After all test cases are executed, step 2.6 is automatically executed to automatically quantify and calculate key performance indicators such as ATE, RPE positioning error, and anti-disturbance recovery time based on the full-time-series dataset, generating visual reports and key event timelines. Among these, heat and power (power consumption and temperature rise indicators) assessment is added to perform thermal management and energy consumption optimization in advance. In addition, step 4.1 is automatically triggered to start the causal analysis tool, allowing testers to retrieve fault snapshots and full-time-series data to complete the root cause localization of algorithm anomalies and overall system failures. The analysis results and quantitative indicators are summarized into a standardized test report and pushed upward to the top-level test management unit for review and decision-making.

[0126] Step 4.1 includes: test task initiation and iteration completion nodes; standard automated test steps; calculation node for ATE / RPE positioning accuracy quantitative evaluation index; and statistics node for algorithm stable recovery time after fault disturbance.

[0127] In a more specific embodiment, the performance of the entire navigation stack (perception, positioning, planning, and control modules) under sensor failure is tested. First, a passage scenario containing dynamic pedestrian obstacles is built. During the test, a fault is injected through the sensor noise and fault simulation unit to simulate the condition that the forward main LiDAR completely fails.

[0128] During the test, the status monitor will monitor the navigation output and robot posture in real time. At the same time, the multi-dimensional analysis module will record quantitative data such as fault detection delay, sensor switching decision process, obstacle avoidance success rate before and after switching, and positioning error.

[0129] The verification objective is to determine whether the system can automatically switch to the binocular vision backup sensor or reduce its operating speed to enter a pure odometer degradation mode. The relevant fault tolerance logic can be fully quantitatively evaluated through this system.

[0130] The algorithm module, which has been fully simulated and verified by this system, has a software framework and communication middleware that are completely consistent with the physical robot dog. Only a few parameter fine-tunings are needed to deploy it to the physical robot dog to complete the field verification, thus forming a complete R&D closed loop of "virtual semi-physical simulation - physical whole machine testing".

[0131] In this embodiment, the top-level control unit issues test tasks, and the high-fidelity digital twin simulation environment and the module under test are initialized in parallel, initiating real-time semi-physical closed-loop simulation. During the simulation, anomalies are monitored in real time and fault snapshots are automatically saved. After the test, performance indicators are automatically calculated and causal analysis is performed. Testers conduct root cause analysis based on the analysis report and ultimately output iteration or deployment decisions. This achieves automated digital twin semi-physical testing for legged robot modules, supporting fault injection, quantitative evaluation, and algorithm iteration verification. Simultaneously, it achieves a unified virtual test benchmark and quantitative indicators, adapts to CI / CD continuous integration and continuous deployment processes, and can automatically execute regression testing to ensure iteration quality.

[0132] To achieve the functions described in the above embodiments, the robot testing method includes hardware structures and / or software modules corresponding to each function. Those skilled in the art should readily recognize that, based on the units and method steps of the examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed through hardware or computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0133] exist Figures 2 to 8 Based on the robot testing method shown, this application also provides a robot testing apparatus in its embodiments, such as... Figure 9 The schematic diagram of the robot testing device shown is shown. The robot testing device 600 includes: a first acquisition module 610, a simulation module 620, and a second acquisition module 630.

[0134] The first acquisition module 610 is used to acquire sensor data generated by the robot when performing test tasks in a digital simulation environment; wherein, the first acquisition module 610 may include, for example, Figure 1 The test system 100 shown contains the controller 1000.

[0135] Simulation module 620 is used to apply the sensor data and algorithm module to the operation of the robot in the digital simulation environment; the algorithm module includes at least one algorithm required for the overall operation of the robot; wherein, simulation module 620 may include, for example, Figure 1 The test system 100 shown contains the controller 1000.

[0136] The second acquisition module 630 is configured to capture the internal operating state of the robot during the operation by utilizing a physical or logical communication link between the digital simulation environment and the algorithm module; the internal operating state is used to indicate the intermediate value of any one of the at least one algorithms executed by the robot; wherein, the second acquisition module 630 may include, for example, Figure 1 The test system 100 shown contains the controller 1000.

[0137] In some embodiments, the first acquisition module 610 includes: a first acquisition submodule, configured to acquire a noise calibration file of the sensor; and a calibration module, configured to calibrate the sensor data according to the noise calibration file.

[0138] In some other embodiments, the second acquisition module 630 includes: a transmission module, used for transmitting sensor data from a first carrier carrying the digital simulation environment to a second carrier deploying the algorithm module via the physical communication link; a first processing module, used for the second carrier to call the algorithm in the algorithm module, perform calculations based on the sensor data, and acquire intermediate values ​​generated during the calculations; and a first determination module, used to determine the internal operating state of the robot based on the intermediate values.

[0139] In some other embodiments, the second acquisition module 630 further includes: a compilation module for compiling the algorithm module into a dynamic library; a loading module for loading the dynamic library onto a first carrier carrying the digital simulation environment via the logical communication link; a second processing module for the first carrier to call the algorithm in the algorithm module, perform calculations based on the sensor data, and acquire intermediate values ​​generated during the calculation process; and a second determination module for determining the internal operating state of the robot based on the intermediate values.

[0140] In some other embodiments, the second acquisition module 630 further includes: a generation module, configured to generate control instructions for the robot based on the sensor data; and a drive module, configured to drive the robot to operate in the digital simulation environment based on the control instructions, and acquire the external physical state of the robot.

[0141] In some other embodiments, the second acquisition module 630 further includes: a time synchronization module for synchronizing the sensor data, the internal operating state, and the external physical state; and a test result module for obtaining test results of the robot performing test tasks in the digital simulation environment based on the time-synchronized sensor data, the internal operating state, and the external physical state; the test results include one or more combinations of key events, internal event features, and event causal relationships; and the test tasks include one or more of single-function verification, multi-algorithm joint verification, full-scene testing, sensor faults, and robot joint faults.

[0142] According to one aspect of the embodiments of this application, Figure 10 This is a schematic diagram of a controller provided in an embodiment of this application. Figure 10 As shown, the controller 1000 includes a processor 1010 and one or more memories 1020. The one or more memories 1020 are used to store program instructions executed by the processor 1010. When the processor 1010 executes the program instructions, it implements the robot testing method described above.

[0143] Furthermore, the processor 1010 may include one or more processing cores. The processor 1010 runs or executes instructions, programs, code sets, or instruction sets stored in the memory 1020, and retrieves data stored in the memory 1020. Optionally, the processor 1010 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 1010 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the displayed content; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor and may be implemented using a separate communication chip.

[0144] According to one aspect of the embodiments of this application, Figure 11 This is a schematic diagram of the structure of a robot provided in an embodiment of this application. Figure 11 As shown, robot 1100 includes: robot body 1110 and controller 1000, the controller being disposed inside the robot body.

[0145] According to one aspect of this application, a computer-readable storage medium is also provided, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable storage medium carries computer-readable instructions that, when executed by a processor, implement the methods in any of the above embodiments.

[0146] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. Computer-readable storage media can be, for example, but not limited to: electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0147] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0148] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0149] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0150] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for testing a robot, characterized in that, include: Acquire sensor data generated when the robot performs test tasks in a digital simulation environment; The sensor data and algorithm module are applied to the operation of the robot in the digital simulation environment; The algorithm module includes at least one algorithm required for the overall operation of the robot. During the operation, the internal operating state of the robot is captured by using the physical or logical communication link between the digital simulation environment and the algorithm module; the internal operating state is used to indicate the intermediate value of the robot executing any one of the at least one algorithms.

2. The method according to claim 1, characterized in that, Before applying the sensor data and algorithm module to the operation of the robot in the digital simulation environment, the method further includes: Obtain the sensor's noise calibration file; The sensor data is calibrated according to the noise calibration file.

3. The method according to claim 1, characterized in that, When the digital simulation environment and the algorithm module are connected via a physical communication link, capturing the robot's internal operating state includes: The first carrier equipped with the digital simulation environment transmits the sensor data to the second carrier equipped with the algorithm module through the physical communication link; The second carrier invokes the algorithm in the algorithm module to perform calculations based on the sensor data and obtains intermediate values ​​generated during the calculation process; The internal operating state of the robot is determined based on the intermediate value.

4. The method according to claim 1, characterized in that, When the digital simulation environment and the algorithm module are connected via a logical communication link, capturing the robot's internal operating state includes: Compile the algorithm module into a dynamic library; The dynamic library is loaded onto the first carrier equipped with the digital simulation environment via the logical communication link. The first carrier invokes the algorithm in the algorithm module to perform calculations based on the sensor data and obtains intermediate values ​​generated during the calculation process; The internal operating state of the robot is determined based on the intermediate value.

5. The method according to claim 1, characterized in that, After capturing the internal operating state of the robot, the method further includes: The robot's control commands are generated based on the sensor data. The robot is driven to operate in the digital simulation environment according to the control instructions, and the external physical state of the robot is acquired.

6. The method according to claim 5, characterized in that, After acquiring the external physical state of the robot, the method further includes: The sensor data, the internal operating status, and the external physical status are synchronized in time. Based on the time-synchronized sensor data, the internal operating state, and the external physical state, the test results of the robot performing the test task in the digital simulation environment are obtained; the test results include one or more combinations of key events, internal features of events, and causal relationships of events.

7. The method according to claim 1, characterized in that, The test tasks include one or more of the following: single function verification, multi-algorithm joint verification, full-scenario testing, sensor fault testing, and robot joint fault testing.

8. A controller, characterized in that, include: A processor and a memory; the memory storing instructions or programs, the processor being configured to, when executing the instructions or programs, implement the method of any one of claims 1 to 7.

9. A testing system, characterized in that, include: The cloud server and the controller as described in claim 8; The cloud server stores a robot model library and sensor noise calibration files. The cloud server is used to provide the controller with the robot's digital model parameters and the sensor noise calibration files.

10. A robot, characterized in that, include: The robot body and the controller as described in claim 8, wherein the controller is disposed inside the robot body.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores program code that can be invoked by a processor or electronic device to perform the method as described in any one of claims 1 to 7.

Images