A humanoid robot testing method and related apparatus

Abstract

The embodiment of the application provides a kind of humanoid robot test method and related equipment, belong to humanoid robot technical field, this method is applied to cloud platform, this method includes: receiving the historical operation associated parameter uploaded by several robot terminals;According to the historical operation associated parameter uploaded by several robot terminals, obtain several scene working conditions and the working condition information corresponding to each scene working condition and construct scene working condition database are calculated;Receive the test request information of test platform;Determine output data based on test request information and scene working condition database, and send output data to test platform, to test robot to be measured is carried out.This embodiment method is based on robot interconnection data to construct scene working condition database, can automatically design test scene working condition and output test related data, to test robot, to improve the effectiveness of humanoid robot test.

Description

Technical Field

[0001] This application relates to the field of humanoid robot technology, and in particular to a humanoid robot testing method and related equipment. Background Technology

[0002] In related technologies, before humanoid robots leave the factory or undergo iterative upgrades, their operational performance, structural reliability, and operational accuracy must be comprehensively tested to identify potential faults in advance. Currently, robot testing mainly relies on manually designed scenarios, such as building simulated industrial handling platforms or household walking environments in laboratories, and conducting tests through preset trajectories and tasks.

[0003] However, testing robots through manually designed scenarios makes it difficult to reproduce interference in the real environment, which can lead to a large discrepancy between the test results and the actual usage effect, thus affecting the validity of the test. On the other hand, testing robots through manually designed scenarios requires a lot of manpower and time.

[0004] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0005] The main objective of this application is to propose a humanoid robot testing method and related equipment. This method constructs a scenario and working condition database based on robot interconnection data, and can automatically design test scenario and working conditions and output test-related data to test the robot, thereby improving the testing effectiveness of humanoid robots.

[0006] To achieve the above objectives, one aspect of this application proposes a humanoid robot testing method, which is applied to a cloud platform; the method includes: Receive historical operation-related parameters uploaded by several robot terminals; Based on the historical operation-related parameters uploaded by several robot terminals, several scenario conditions and the corresponding condition information for each scenario condition are obtained through calculation. A scenario working condition database is constructed based on several scenario working conditions and the working condition information corresponding to each scenario working condition. Receive test request information from the test platform; determine output data based on the test request information and the scenario working condition database, and send the output data to the test platform to test the robot under test.

[0007] In some embodiments, the step of calculating several scenario conditions and corresponding condition information for each scenario condition based on historical operation association parameters uploaded by several robot terminals includes: Based on a preset clustering algorithm, the historical operation-related parameters uploaded by several robot terminals are clustered, and several scenario conditions are determined based on the clustering results. Based on the historical operation-related parameters uploaded by several robot terminals and several scenario conditions, a set of historical operation-related parameters corresponding to each scenario condition is obtained. The operating condition information corresponding to each of the aforementioned operating conditions is obtained by calculating the historical operation-related parameter set corresponding to each of the aforementioned operating conditions.

[0008] In some embodiments, the historical operation-related parameter set includes joint angle datasets, joint velocity datasets, end-effector force datasets, and end-effector torque datasets; the operating condition information corresponding to each scenario is obtained in the following manner: The average value of the joint angle data collected at the same time in the joint angle dataset corresponding to the scene condition is calculated to obtain the joint angle sequence. The average value of the joint velocity data collected at the same time in the joint velocity dataset corresponding to the scene condition is calculated to obtain the joint velocity sequence. The average value of the end force values ​​collected at the same time in the end force value dataset corresponding to the scenario is calculated to obtain the end force value sequence. The average value of the end torque data collected at the same time in the end torque dataset corresponding to the scenario is calculated to obtain the end torque sequence; The motion parameters corresponding to the scene condition are determined based on the joint angle sequence and the joint velocity sequence corresponding to the scene condition. The operating parameters corresponding to the scenario are determined based on the end force value sequence and the end torque sequence corresponding to the scenario. Based on the motion parameters and operation parameters corresponding to the scenario conditions, determine the working condition information corresponding to the scenario conditions.

[0009] In some embodiments, the method further includes: receiving test feedback data from the robot under test; The preset clustering algorithm is updated based on the analysis results, based on the analysis of the test feedback data and the output data.

[0010] To achieve the above objectives, another aspect of this application proposes a humanoid robot testing method, which is applied to a testing platform; the method includes: Send a test request to the cloud platform and receive output data sent by the cloud platform; the output data includes the test scenario conditions of the robot under test and the corresponding condition information of the test scenario conditions. Obtain the structural parameters of the robot under test; The robot under test is tested based on the working condition information corresponding to the working condition of the scenario under test and the structural parameters of the robot under test.

[0011] In some embodiments, testing the robot under test based on the working condition information corresponding to the working condition of the test scenario and the structural parameters of the robot under test includes: Based on the working condition information corresponding to the working condition of the test scenario and the structural parameters of the robot under test, the environmental resistance parameters corresponding to the working condition of the test scenario are determined. Based on the motion parameters and environmental resistance parameters corresponding to the test scenario and the structural parameters of the robot under test, determine the torque test information corresponding to the test scenario. The robot under test is tested based on the torque test information corresponding to the working conditions of the test scenario.

[0012] In some embodiments, the method further includes: Obtain motion parameters corresponding to several test scenarios and determine the runtime corresponding to each test scenario based on the motion parameters corresponding to each test scenario. The target runtime is determined based on the design life of the robot under test; The total runtime is determined based on the runtime corresponding to several of the test scenarios. The number of cyclic test rounds is determined based on the total runtime and the target runtime. The robot under test is subjected to cyclic testing based on the cyclic test rounds, several test scenarios, and torque test information and runtime corresponding to each test scenario.

[0013] To achieve the above objectives, another aspect of this application proposes a humanoid robot testing system, the system comprising a cloud platform, a testing platform connected to the cloud platform, and a plurality of robot terminals; wherein, The cloud platform is used to implement the above methods; The robot terminal is used to upload historical operation-related parameters to the cloud platform; The testing platform is used to implement the above-described methods.

[0014] To achieve the above objectives, another aspect of this application provides a humanoid robot testing device, the device comprising: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor performs the method described above.

[0015] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a humanoid robot testing method, system, device, and storage medium. The solution collects historical operational parameter data from multiple robots, calculates and extracts several scenario conditions and corresponding condition information for each, and constructs a scenario condition database. This allows for targeted testing based on robot testing requests, achieving a closed loop of "interconnected data → database construction → precise testing." On one hand, this method constructs a scenario condition database using interconnected data uploaded from robot terminals, and reproduces interference in real-world scenarios using historical operational parameter data from each robot terminal. The constructed test scenarios are more reliable than manually designed scenarios, thus improving the effectiveness of humanoid robot testing. On the other hand, this method automatically collects interconnected data and designs test scenarios, reducing the costs associated with manual data collection and scenario design. Attached Figure Description

[0017] Figure 1 This is a flowchart of a humanoid robot testing method provided in an embodiment of this application; Figure 2 This is another flowchart of a humanoid robot testing method provided in the embodiments of this application; Figure 3 This is a structural block diagram of a humanoid robot testing system provided in an embodiment of this application; Figure 4 This is a structural block diagram of a humanoid robot testing device provided in an embodiment of this application. Detailed Implementation

[0018] 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 of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0021] 1) Operational related parameters: These refer to a series of core variables within the robot that interact with each other and jointly determine its behavior and performance, such as motion parameters and operational parameters.

[0022] 2) Environmental drag parameters: These are key variables used to quantify the resistance exerted by the external environment on the robot's movement. It is not a single value, but a comprehensive set of parameters primarily used to simulate complex physical interactions in the real world during simulations and field tests.

[0023] 3) Torque test information: This is a core component used to accurately measure and evaluate the output torque of robot joints, transmission systems, or axles. It is far more than a simple "force" measurement; rather, it is a systematic evaluation process designed to verify the robot's dynamic performance, structural strength, and control accuracy.

[0024] Before humanoid robots leave the factory or undergo upgrades, they must be comprehensively tested for operational performance, structural reliability, and operational accuracy to identify potential faults in advance. Currently, robot testing mainly relies on manually designed scenarios, such as building simulated industrial handling platforms or home walking environments in laboratories, and conducting tests through preset trajectories and tasks.

[0025] However, existing technologies have significant drawbacks: First, insufficient scenario coverage; manually designed scenarios cannot reproduce dynamic disturbances in real environments (such as ground unevenness fluctuations and random load changes), resulting in test results deviating from actual usage effects by more than 30%; second, inefficient data utilization; due to the dispersed deployment of humanoid robots and the lack of a unified interconnected data collection mechanism, actual operational data is severely fragmented and cannot be integrated into effective test data; third, low testing efficiency; designing scenarios and collecting data requires a large amount of manpower, making it difficult to adapt to the rapid iteration needs of robots.

[0026] In view of this, this application provides a humanoid robot testing method, system, device, and storage medium. This solution collects historical operational parameter data from multiple robots, calculates and extracts several scenario conditions and corresponding condition information for each scenario condition, and constructs a scenario condition database. This allows for targeted testing based on the robot's testing requests, achieving a closed loop of "interconnected data → database construction → precise testing." On one hand, this method constructs a scenario condition database using interconnected data uploaded by robot terminals, and reproduces interference in real-world scenarios using historical operational parameter data from each robot terminal. The constructed test scenarios are more reliable than manually designed scenarios, thus improving the effectiveness of humanoid robot testing. On the other hand, this method automatically collects interconnected data and designs test scenarios, reducing the cost associated with manual data collection and scenario design.

[0027] The humanoid robot testing method provided in this application relates to the field of humanoid robot technology. The humanoid robot testing method provided in this application can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the humanoid robot testing method, but is not limited to the above forms.

[0028] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0029] Figure 1 This is an optional flowchart of a humanoid robot testing method provided in an embodiment of this application. This method is applied to a cloud platform. Figure 1 The method may include, but is not limited to, steps S100 to S400.

[0030] Step S100: Receive historical operation-related parameters uploaded by several robot terminals.

[0031] The historical operation parameters uploaded by multiple robots to the cloud platform are obtained as the data basis for subsequent aggregation to obtain scene conditions and corresponding scene condition information; among them, the operation parameters include at least joint motion parameters (joint angle, joint speed) and operation interaction parameters (end effector force value, torque).

[0032] Step S200: Calculate based on the historical operation correlation parameters uploaded by several robot terminals to obtain several scene conditions and the corresponding condition information for each scene condition.

[0033] Calculations are performed based on the acquired interconnected data to determine several scenario conditions and their corresponding condition information, which serve as the data foundation for data construction.

[0034] Step S300: Construct a scenario working condition database based on several scenario working conditions and the working condition information corresponding to each scenario working condition.

[0035] Based on the calculated scenario conditions and corresponding condition information, a database is constructed to serve as the condition information database for testing the robot under test.

[0036] Step S400: Receive test request information from the test platform; determine the output data based on the test request information and the scenario working condition database, and send the output data to the test platform for testing the robot under test.

[0037] The system obtains test request information sent by the test platform, matches the obtained scenario condition database with the test request information, determines the output data for robot testing, and sends it to the test platform.

[0038] In some embodiments, step S200, the process of calculating several scenario conditions and the corresponding condition information for each scenario condition based on historical operation association parameters uploaded by several robot terminals, may include, but is not limited to, steps S210 to S230: Step S210: Cluster the historical operation-related parameters uploaded by several robot terminals based on a preset clustering algorithm, and determine several scenario conditions based on the clustering results.

[0039] The K-nearest neighbor algorithm is used to cluster the historical operation parameters uploaded by multiple robots to obtain N scenario conditions. The value of N is determined by the elbow rule. The sum of squared clustering errors corresponding to different N values ​​(2≤N≤20) is calculated, and the minimum N value with an error reduction rate of <10% is taken as the optimal value.

[0040] Traditional testing relies on manually designed scenarios, which suffers from low scenario coverage and significant deviations from real-world conditions. This invention addresses this by accessing actual operational data from deployed humanoid robots (covering dynamic loads, terrain changes, and operational interactions in industrial and household scenarios) and using clustering algorithms to directly extract highly realistic and comprehensive scenario conditions (such as occasional conditions like "heavy-load handling + emergency stop" in industrial scenarios, and complex conditions like "carpet + threshold + tilted placement" in household scenarios). This method eliminates the need for manually pre-setting scenarios, saving on scenario design costs and covering complex real-world conditions that are difficult for human experience to predict, thus increasing the matching rate between test scenarios and actual use to over 90%.

[0041] In some embodiments, the process of clustering historical operational correlation parameters uploaded by multiple robots using the K-nearest neighbor algorithm to obtain N scenario conditions includes: Step S1: Determine the optimal N value. Calculate the sum of squared clustering errors (SSE) for different N values ​​(2≤N≤20) using the elbow rule, and take the smallest N value with an SSE decrease rate of <10% (e.g., N=6 for industrial scenarios and N=4 for home scenarios).

[0042] Step S2: Set initial cluster centers. Based on prior scene features, such as initial centers for industrial heavy object handling conditions (joint speed < 0.5 rad / s, end torque > 100 N). m), the initial center of gravity for home walking is (continuous gait cycle ≥ 100 steps, joint angle fluctuation range ± 0.2 rad).

[0043] Step S3: Sample partitioning. Divide the parameters into multiple samples according to time (each group contains joint / terminal parameters at the same time point), calculate the Euclidean distance between the sample and the cluster center, and assign the sample to the set corresponding to the nearest center.

[0044] Step S4: Iterative optimization. Recalculate the cluster center of each set. If the distance between the new center and the original center is greater than the threshold (e.g., 0.1), repeat sub-step S3 until the distance is less than or equal to the threshold, thus obtaining N stable scenario conditions.

[0045] Step S220: Summarize the historical operation-related parameters uploaded by several robot terminals and several scenario conditions to obtain the historical operation-related parameter set corresponding to each scenario condition.

[0046] For each scenario, the operational parameters associated with that scenario are summarized to construct a set of historical operational parameters corresponding to that scenario, which is then used to calculate the operational information corresponding to that scenario.

[0047] Step S230: Calculate the operating condition information corresponding to each scenario based on the historical operation associated parameter set corresponding to each scenario.

[0048] For each scenario, the operating condition information is obtained by summarizing the historical operational parameters corresponding to that scenario. These operational parameters may include, but are not limited to, joint angles, joint speeds, end effector force values, end effector torques, environmental terrain parameters, and parameter acquisition time.

[0049] In some embodiments, step S230, the operating condition information corresponding to each scenario is obtained in the following way: Step S231: Calculate the average value of the joint angle data at the same acquisition time in the joint angle dataset corresponding to the scene condition to obtain a joint angle sequence; calculate the average value of the joint velocity data at the same acquisition time in the joint velocity dataset corresponding to the scene condition to obtain a joint velocity sequence; calculate the average value of the end force data at the same acquisition time in the end force dataset corresponding to the scene condition to obtain an end force sequence; calculate the average value of the end torque data at the same acquisition time in the end torque dataset corresponding to the scene condition to obtain an end torque sequence.

[0050] For each scenario, the operation-related parameters belonging to that scenario are used, and the average values ​​of joint angle, joint velocity, end force, and end torque at the same acquisition time are taken to obtain joint angle sequence, joint velocity sequence, end force sequence, and end torque sequence, respectively.

[0051] In this process, the joint angles and velocities at the same acquisition time are averaged to form a joint angle sequence. and joint velocity sequence Where n is the number of joints; the end force and torque values ​​collected at the same acquisition time are averaged to form an end force value sequence. and end torque sequence .

[0052] In this regard, averaging the joint angle, joint velocity, end-effector force, and end-effector torque at the same acquisition time has the following main significance and beneficial effects: 1) Eliminate individual fluctuations and enhance the stability of operating condition information. Although multiple deployed robots belong to the same type of scenario, due to individual differences (such as installation accuracy, slight sensor deviations, instantaneous load changes, etc.), the operational parameters at the same data collection point may fluctuate to some extent (for example, the end effector forces of three robots in "industrial precision assembly" at the same moment may be 52N, 48N, and 50N). By taking the average value, the impact of this individual fluctuation on the parameters can be reduced, resulting in more stable and universally applicable parameter characteristics for this scenario. This allows the scenario information to represent the typical state of "a type of scenario" rather than the specific state of a single robot.

[0053] 2) Enhance the typical representativeness of the scenario conditions. Taking the average value allows us to focus on the "mainstream characteristics" of the scene's operating conditions, avoiding interference from outliers (such as sudden value jumps caused by temporary sensor malfunctions or instantaneous parameters under extreme loads). For example, if a robot's joint angles are momentarily abnormally large due to small obstacles on the ground while "walking on a household floor," taking the average value can filter out such occasional anomalies, allowing the generated joint angle sequences, end-effector torque sequences, etc., to more accurately reflect the "normal and frequently occurring" motion and operation patterns in that scene, ensuring the typicality of the operating condition information.

[0054] 3) Improve the repeatability and consistency of testing the robot under test. Based on the averaged parameters, "motion parameter sequences" and "operation parameter sequences" are generated. When the robot under test executes the test according to these sequences, it can more stably reproduce the target scene conditions. At the same time, different batches and models of robots under test are tested according to the same set of averaged parameters, which can reduce the deviation of test results caused by parameter fluctuations, make the test results comparable across robots, and facilitate accurate evaluation of whether the performance of the robot under test meets the design requirements.

[0055] In summary, taking the average value can make the "characterization of the scenario conditions more accurate, the reproducibility of the test better, and the comparability of the results stronger", thus ensuring the scientific nature and reliability of the test from the data perspective.

[0056] Step S232: Determine the motion parameters corresponding to the scene condition based on the joint angle sequence and joint velocity sequence; determine the operation parameters corresponding to the scene condition based on the end-effector force sequence and end-effector torque sequence. Based on the motion parameters and operation parameters corresponding to the scene condition, determine the condition information corresponding to the scene condition.

[0057] The corresponding motion parameters are determined based on the joint angle sequence and joint velocity sequence corresponding to the scene conditions; the operation parameters are determined based on the end force sequence and end torque sequence corresponding to the scene conditions; and finally, the working condition information corresponding to the scene conditions is determined.

[0058] The scenario conditions are categorized based on task characteristics and load characteristics, including at least one of the following: industrial scenario heavy object handling conditions (load > 50kg, joint torque > 100N). m), industrial scenario precision assembly condition (positioning accuracy ≤ 0.1mm, end force < 50N), household scenario ground walking condition (continuous gait cycle ≥ 100 steps), household scenario item retrieval and placement condition (operation height 0.5-1.5m). The working condition information may include motion parameters and operating parameters, wherein the motion parameters include joint angle sequences and joint velocity sequences, and the operating parameters include end-effector force sequences and end-effector torque sequences.

[0059] In some embodiments, the method of this application further includes the following steps: Receive test feedback data from the robot under test; The pre-defined clustering algorithm is updated based on the analysis results, based on the test feedback data and output data.

[0060] To address this, during the testing process, real-time test feedback data from the robot under test (such as actual joint torque, motion error, energy consumption, etc.) is collected and compared with the "theoretical test information generated based on clustering conditions" in the output data to calculate the deviation (such as torque deviation rate, motion trajectory error). If the deviation exceeds a threshold (such as torque deviation > 10%), the parameters for subsequent tests are dynamically adjusted (such as correcting environmental resistance parameters and optimizing the calculation model for torque test information). The "corrected parameters and scenario conditions" are then fed back to the robot interconnection system to update the training data of the clustering algorithm, realizing a closed loop of "test → feedback → optimization → retest". This overcomes the limitations of "static testing relying solely on historical data" and enables the testing process to have self-optimization capabilities. It not only improves the accuracy of a single test (timely correction of the deviation between theory and reality) but also continuously enriches the "scenario condition library" of the robot interconnection system through data feedback, making subsequent tests more closely match the dynamic changes of real-world scenarios.

[0061] In some embodiments, the scenario and operating condition database constructed in this application can be updated in the following ways: (1) Periodically acquire the operation-related parameters of multiple robots uploaded to the robot interconnection system to obtain the operation-related parameter dataset; the upload period can be dynamically adjusted: 10ms / time for industrial high-precision scenarios and 50ms / time for household walking scenarios; (2) Preprocess the periodically acquired operational correlation parameter dataset; wherein, the preprocessing method includes, but is not limited to, removing sensor outliers (such as torque > 300N). (Instantaneous jump value of m), and multi-sensor data aligned based on timestamps (time difference ≤ 5ms).

[0062] Preprocessed data is "cleaner and more collaborative," enabling subsequent steps (clustering scenario conditions, calculating environmental resistance, generating torque test information, etc.) to be more accurate. For example, the scenario conditions obtained from clustering are closer to the "typical characteristics" of real scenarios than data noise. When the robot under test conducts tests based on "accurate working condition information," it can more realistically reproduce the motion and force processes in actual scenarios, making the test results (such as structural reliability and torque output accuracy) more valuable for reference and avoiding "disconnect between testing and actual application" due to data errors.

[0063] (3) Perform cluster analysis on the preprocessed running correlation parameter dataset, and update the scenario working condition database based on the results of the cluster analysis.

[0064] The application scenarios for humanoid robots are rapidly evolving (e.g., "human-robot collaborative assembly" in industrial scenarios and "pet interaction services" in home scenarios), making it difficult for traditional static testing methods to keep up. This invention relies on the continuous data collection of a robot interconnection system. As more robots upload new operational parameters, the clustered scenario conditions are dynamically updated, allowing the "scenario library" used for testing to continuously expand and iterate.

[0065] In actual operation, sensors are prone to abnormal fluctuations (such as sudden torque fluctuations exceeding 300 N·m, far exceeding the normal load range of the scenario) due to electromagnetic interference, transient hardware failures, etc. These outliers do not reflect the robot's "true operating state" in the scenario. Retaining them could lead to misclassification of these outliers as "extreme conditions" during subsequent clustering, causing the extracted scenario conditions to deviate from the true characteristics of the scenario. This would disrupt the statistical regularity of the data and reduce the accuracy of the clustering algorithm in identifying "typical conditions." By removing outliers, the operational parameters can more closely reflect the robot's stable and true operating state in the scenario.

[0066] In this system, parameters such as joint angles, joint velocities, end effector forces, and torques of the humanoid robot are collected separately by different sensors (joint encoders, force sensors, torque sensors, etc.). There is a slight time difference in the triggering and transmission processes of each sensor (e.g., joint encoder data arrives first, while force sensor data is delayed by 10ms). Without time alignment, multi-dimensional parameters at the same "physical moment" will be misaligned (e.g., "joint angle at time t" and "end effector force at t+10ms" are incorrectly associated), making it impossible to accurately recreate the robot's "comprehensive operating state at a certain moment" (e.g., "how the joint angle / velocity at time t coordinates with the end effector force / torque at time t"). By aligning timestamps (controlling the time difference to ≤5ms), it is ensured that the data from multiple sensors are strictly matched in the time dimension, accurately depicting the robot's "overall operating state at a certain moment," so that the generated "motion parameter sequence (joint angle / velocity)" and "operation parameter sequence (end effector force / torque)" can realistically reproduce the "dynamic process of multi-parameter coordination" in the scene.

[0067] Figure 2 This is another optional flowchart of a humanoid robot testing method provided in this application embodiment. This method is applied to a testing platform. Figure 2 The method may include, but is not limited to, steps S500 to S700: Step S500: Send test request information to the cloud platform and receive output data sent by the cloud platform; the output data includes the working conditions of the scenario under test and the corresponding working condition information.

[0068] Based on the test request, the test scenario conditions and corresponding working condition information of the robot to be tested are determined from the cloud platform, and information matching with the database is achieved.

[0069] Step S600: Obtain the structural parameters of the robot under test.

[0070] Obtain the structural parameters of the robot under test, which will serve as a data reference for subsequent targeted testing of the robot.

[0071] Step S700: Test the robot under test according to the working condition information corresponding to the working condition of the scene under test and the structural parameters of the robot under test.

[0072] The operating condition information corresponding to the working condition of the scenario under test is obtained from the cloud platform database by clustering the operation-related parameter data of multiple robots. It needs to be adaptively adjusted in combination with the structural parameters of the robot under test in order to achieve "targeted testing" of the robot under test.

[0073] In step S500 of some embodiments, the test scenario conditions for the robot under test can be determined in the following ways: 1) Reading design documents and configuration files During the R&D phase, the design documents (such as requirements specifications and technical solutions) of the robot under test will clearly define the core application scenarios (e.g., "heavy parts handling in automobile factories" and "item retrieval and cleaning in households"). At the same time, the configuration files stored inside the robot (written by the manufacturer during production, containing scenario type identifiers, such as "industrial handling" and "household service") can also be directly read by the testing system to obtain the target scenario type.

[0074] 2) Feature parameter extraction and scene library matching If direct annotation is lacking, the core performance / structural parameters of the robot under test can be extracted and compared with a preset "scene type feature library": Extract parameters such as load capacity, maximum joint torque, end effector type, and motion flexibility (gait cycle, etc.). Scene library feature examples: Industrial material handling: Load > 50kg, joint torque > 100N·m, end effector is "heavy-duty gripper"; Home service type: load < 20kg, gait cycle ≥ 100 steps, end effector is "dexterous hand"; Matching method: Calculate the similarity (such as cosine similarity) between the parameters of the robot under test and the features of each scene, and select the scene type with the highest similarity as the target type.

[0075] 3) User manually specifies Before testing, testers can manually specify the target scenario type (such as "industrial precision assembly scenario" or "household ground walking scenario") according to the actual application needs of the robot through the interactive interface of the testing system (such as the software operation panel).

[0076] In some embodiments, in step S500, the test scenario conditions and corresponding condition information of the robot under test can be obtained in the following ways: By using "cosine similarity of feature vectors", the "target scene type of the robot under test" is matched with "several clustered application scene conditions" in the scene condition database. If the matching degree is insufficient (similarity < 0.8), the two closest scene types are merged to generate test conditions (such as merging "household ground walking condition" and "household item picking and placing condition" to obtain a composite task of "picking and placing items while walking"). This solves the problem in the existing technology that "single scene test cannot cover composite tasks", making the test more in line with the "multi-task collaboration" requirements of actual robot applications.

[0077] In some embodiments, in step S600, the structural parameters of the robot under test are obtained in the following manner: 1) Internal Storage Retrieval: During the manufacturing phase, the robot under test stores its core structural design parameters (such as joint moment of inertia, link mass, joint reduction ratio, transmission efficiency, and overall dimensions) in its internal storage units (such as EEPROM and Flash memory). The testing system can send parameter retrieval commands to the robot via its communication interface (such as CAN bus, Ethernet interface, or serial port) to directly retrieve these structural design parameters from the internal storage module.

[0078] 2) Importing external configuration files: Before testing, testers can organize the structural design parameters of the robot under test into standardized configuration files (such as XML or JSON format files), and import the configuration files into the testing device through the input interface of the testing system (such as USB interface, network upload function, etc.) for use during the testing process.

[0079] In some embodiments, step S700 involves testing the robot under test based on the working condition information corresponding to the working condition of the scene under test and the structural parameters of the robot under test, including but not limited to steps S710 to S730: Step S710: Determine the environmental resistance parameters corresponding to the working conditions of the scene under test based on the working condition information and the structural parameters of the robot under test.

[0080] The operating condition information corresponding to the test scenario in the database is used to adjust the parameters of the robot under test in combination with the structural parameters of the robot under test, thereby determining the targeted environmental resistance parameters.

[0081] In some embodiments, for each scenario, environmental resistance parameters are calculated using a dynamic model by combining scenario information and the corresponding robot's structural design parameters (joint rotational inertia J, link mass m, end effector size, etc.). The process includes: Industrial heavy object handling conditions: ; Household floor walking conditions: ; Other scenarios: Dynamically adjust according to task characteristics (e.g., consider the contact resistance between the robotic arm and the workpiece in assembly scenarios).

[0082] Step S720: Determine the torque test information corresponding to the working conditions of ...

[0083] Since the working condition information corresponding to the scene conditions in the database is obtained by clustering interconnected data of robots with different configurations, the structural design differences of robots with different configurations (such as joint rotational inertia, transmission efficiency, and link mass) will lead to test deviations. Therefore, this invention combines the structural parameters of the robot under test and targeted environmental resistance parameters, and uses dynamic formulas to accurately calculate the torque test information corresponding to the working condition of the scene under test.

[0084] When the structural design of the robot under test (such as the number of joints, link length, and transmission ratio) differs from that of the "source robot in the clustered working conditions of the robot interconnection system," a mapping model of "source robot structural parameters → robot under test structural parameters" can be established using the principle of dynamic similarity. For example, for joint torque parameters, a "structural similarity coefficient" is introduced to adaptively scale the torque working condition information obtained from clustering, generating torque test information adapted to the structure of the robot under test.

[0085] In some embodiments, the structural design parameters of the robot under test (joint reduction ratio i, transmission efficiency η, etc.) are obtained, and the dynamic formula for calculating the joint torque test value is calculated by combining the motion parameters of the scene and the environmental resistance parameters:

[0086] in: The joint torque test value (unit: N•m); The moment of inertia of the joint (unit: kg•m²). This is the joint angular acceleration (unit: rad / s², obtained by differentiating the joint velocity sequence). Damping coefficient (unit: N•m•s / rad); Joint angular velocity (unit: rad / s, derived from motion parameters); For gravity (unit: N•m, relative to joint angle) Related, ; Environmental resistance parameter (unit: N•m).

[0087] Step S730: Test the robot under test according to the torque test information corresponding to the working conditions of the test scenario.

[0088] Based on the relevant data obtained, the robot under test was tested.

[0089] In some embodiments, the above method further includes: Step S810: Obtain motion parameters corresponding to several test scenarios and determine the runtime corresponding to each test scenario based on the motion parameters corresponding to each test scenario.

[0090] The runtime of each test scenario is determined based on the motion parameters corresponding to that scenario, and used as a data reference for subsequent calculation of the number of test cycles.

[0091] Step S820: Determine the target runtime based on the design life of the robot under test; determine the total runtime based on the runtime corresponding to several test scenarios; determine the number of cyclic test rounds based on the total runtime and the target runtime.

[0092] The number of cyclic test rounds is determined based on the total runtime corresponding to several different operating scenarios and the design life of the robot under test.

[0093] In determining the total runtime, this application's method also considers the scene switching interval to determine the effective runtime for each scene condition. By eliminating the scene switching interval, test resources (such as test time, robot wear and tear costs, etc.) can be more efficiently focused on "simulating real-world operating conditions," avoiding ineffective test consumption during transition phases and improving the relevance of testing and resource utilization efficiency.

[0094] Step S830: Based on the number of cyclic test cycles, several test scenarios and their corresponding torque test information and runtime, perform cyclic tests on the robot under test.

[0095] The robot under test is controlled to run according to the torque test information for each working condition, and the test cycles are repeated to simulate long-term use and test reliability.

[0096] In summary, the embodiments of this application include, but are not limited to, the following beneficial effects: 1. Comprehensive data-driven approach: By integrating the actual operating data of ≥100 deployed robots through the robot interconnection system, it covers real working conditions in industrial / household scenarios, increasing the test scenario coverage rate by more than 60%; 2. Accuracy of scene adaptation: It reproduces high-load and high-precision extreme working conditions for industrial scenes and covers complex terrain features for home scenes. The test results match the actual scene with a degree of over 90%. 3. Practicality of efficiency improvement: No need for manual scenario design, testing efficiency is increased by 50%, and the test conditions are continuously optimized through periodic data updates to adapt to the needs of robot iteration.

[0097] Please see Figure 3 This application also provides a humanoid robot testing system that can implement the above-described method. The system includes a cloud platform, a testing platform connected to the cloud platform, and several robot terminals; wherein... A cloud platform is used to implement the methods described above; The robot terminal is used to upload historical operation parameters to the cloud platform; A testing platform is used to implement the methods described above.

[0098] In some embodiments, the test platform may be part of the robot under test.

[0099] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0100] Please see Figure 4 This application also provides a humanoid robot testing device that can implement the above-described method. The device includes: At least one processor; At least one memory for storing at least one program; When at least one program is executed by at least one processor, the at least one processor performs the method described above.

[0101] It is understood that the content of the above method embodiments is applicable to the present device embodiments. The specific functions implemented by the present device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0102] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0103] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0104] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0105] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0106] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0107] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0108] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0109] This application provides a humanoid robot testing method, system, device, and storage medium. The solution collects historical operational parameter data from multiple robots, calculates and extracts several scenario conditions and corresponding condition information for each, and constructs a scenario condition database. This allows for targeted testing based on robot testing requests, achieving a closed loop of "interconnected data → database construction → precise testing." First, the method constructs a scenario condition database using interconnected data uploaded from robot terminals. By reproducing interference in real-world scenarios using historical operational parameter data from each robot terminal, the constructed test scenarios are more reliable than manually designed scenarios, thus improving the effectiveness of humanoid robot testing. Second, the method automatically collects interconnected data to construct and update the scenario condition database. This reduces costs associated with manual data collection and scenario design, and allows for iterative optimization to ensure the database always covers the latest scenarios, adapting to the rapid iteration of humanoid robot technology. Finally, the method can update training data for interconnected data clustering based on test feedback data, achieving a closed loop of "testing → feedback → optimization → retesting."

[0110] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0111] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0112] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0113] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0114] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0115] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0116] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0117] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0118] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0119] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A testing method for a humanoid robot, characterized in that, The method is applied to a cloud platform; the method includes the following steps: Receive historical operation-related parameters uploaded by several robot terminals; Based on the historical operation-related parameters uploaded by several robot terminals, several scenario conditions and the corresponding condition information for each scenario condition are obtained through calculation. A scenario working condition database is constructed based on several scenario working conditions and the working condition information corresponding to each scenario working condition. The system receives test request information from the test platform; determines output data based on the test request information and the scenario working condition database, and sends the output data to the test platform to test the robot under test; the output data includes the scenario working condition under test and the working condition information corresponding to the scenario working condition under test; the working condition information corresponding to the scenario working condition under test is used to test the robot under test in conjunction with the structural parameters of the robot under test. The process of testing the robot under test by combining the working condition information corresponding to the working condition of the test scenario with the structural parameters of the robot under test is achieved in the following way: Based on the working condition information corresponding to the working condition of the test scenario and the structural parameters of the robot under test, the environmental resistance parameters corresponding to the working condition of the test scenario are determined. Based on the motion parameters and environmental resistance parameters corresponding to the test scenario and the structural parameters of the robot under test, the torque test information corresponding to the test scenario is determined. The robot under test is tested based on the torque test information corresponding to the working conditions of the test scenario.

2. The method according to claim 1, characterized in that, The step involves calculating several scenario conditions and corresponding condition information for each scenario condition based on historical operation parameters uploaded by several robot terminals, including: Based on a preset clustering algorithm, the historical operation-related parameters uploaded by several robot terminals are clustered, and several scenario conditions are determined based on the clustering results. Based on the historical operation-related parameters uploaded by several robot terminals and several scenario conditions, a set of historical operation-related parameters corresponding to each scenario condition is obtained. The operating condition information corresponding to each of the aforementioned operating conditions is obtained by calculating the historical operation-related parameter set corresponding to each of the aforementioned operating conditions.

3. The method according to claim 2, characterized in that, The historical operation-related parameter set includes joint angle datasets, joint velocity datasets, end-effector force datasets, and end-effector torque datasets; the operating condition information corresponding to each of the aforementioned scenario conditions is obtained through the following methods: The average value of the joint angle data collected at the same time in the joint angle dataset corresponding to the scene condition is calculated to obtain the joint angle sequence. The average value of the joint velocity data collected at the same time in the joint velocity dataset corresponding to the scene condition is calculated to obtain the joint velocity sequence. The average value of the end force values ​​collected at the same time in the end force value dataset corresponding to the scenario is calculated to obtain the end force value sequence. The average value of the end torque data collected at the same time in the end torque dataset corresponding to the scenario is calculated to obtain the end torque sequence; The motion parameters corresponding to the scene condition are determined based on the joint angle sequence and the joint velocity sequence corresponding to the scene condition. The operating parameters corresponding to the scenario are determined based on the end force value sequence and the end torque sequence corresponding to the scenario. Based on the motion parameters and operation parameters corresponding to the scenario conditions, determine the working condition information corresponding to the scenario conditions.

4. The method according to claim 2, characterized in that, The method further includes: Receive test feedback data from the robot under test; The preset clustering algorithm is updated based on the analysis results, based on the analysis of the test feedback data and the output data.

5. A testing method for a humanoid robot, characterized in that, The method is applied to a testing platform; the method includes: Send a test request to the cloud platform and receive output data sent by the cloud platform; the output data includes the working conditions of the scenario under test and the corresponding working condition information of the scenario under test. Obtain the structural parameters of the robot under test; Based on the working condition information corresponding to the working condition of the scenario under test and the structural parameters of the robot under test, the robot under test is tested; The step of testing the robot under test based on the working condition information corresponding to the working condition of the test scenario and the structural parameters of the robot under test includes: Based on the working condition information corresponding to the working condition of the test scenario and the structural parameters of the robot under test, the environmental resistance parameters corresponding to the working condition of the test scenario are determined. Based on the motion parameters and environmental resistance parameters corresponding to the test scenario and the structural parameters of the robot under test, the torque test information corresponding to the test scenario is determined. The robot under test is tested based on the torque test information corresponding to the working conditions of the test scenario.

6. The method according to claim 5, characterized in that, The method further includes: Obtain motion parameters corresponding to several test scenarios and determine the runtime corresponding to each test scenario based on the motion parameters of each test scenario. The target runtime is determined based on the design life of the robot under test; The total runtime is determined based on the runtime corresponding to several of the test scenarios. The number of cyclic test rounds is determined based on the total runtime and the target runtime. The robot under test is subjected to cyclic testing based on the cyclic test rounds, several test scenarios, and torque test information and runtime corresponding to each test scenario.

7. A humanoid robot testing system, characterized in that, The system includes a cloud platform, a testing platform connected to the cloud platform, and several robot terminals; wherein, The cloud platform is used to implement the method as described in any one of claims 1 to 4; The robot terminal is used to upload historical operation-related parameters to the cloud platform; The testing platform is used to implement the method as described in any one of claims 5 to 6.

8. A humanoid robot testing device, characterized in that, The device includes: At least one processor; At least one memory for storing at least one program; When the at least one program is executed by the at least one processor, the at least one processor performs the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a processor-executable program, characterized in that, The processor-executable program, when executed by the processor, is used to perform the method as described in any one of claims 1 to 6.

Images