Robot state data processing method and device, controller and storage medium

Abstract

The invention relates to a robot state data processing method and device, a controller and a storage medium. The method comprises the steps that a first health management module in a central control unit receives robot state data of a robot; health data of the robot are constructed according to the state data of the robot, and the health data are sent to a diagnosis module in the central control unit; obtaining a fault state code associated with the health data through a diagnosis module; and when it is detected that the fault state code is updated, the fault state code and health data associated with the fault state code are written into a health recording module in the central control unit and uploaded through the health recording module. By adopting the method, the intelligent degree of robot state data processing can be improved.

Description

Robot state data processing methods, devices, controllers, and storage media Technical Field

[0001] This application relates to the field of robotics technology, and in particular to a method, apparatus, controller, computer-readable storage medium, and computer program product for processing robot state data. Background Technology

[0002] With the development of robotics technology, a technology has emerged to monitor and manage the status data of robots. Robots can perceive, accurately diagnose, and reliably report their own hardware and software status in real time to ensure the healthy and stable operation of the robots.

[0003] In traditional technologies, robot state data processing involves different sub-modules of the robot independently reporting state logs and issuing alarms when faults occur. However, this method results in fragmented health information due to different sub-modules using proprietary formats to record states, making it difficult to build a global view. Furthermore, some implementations couple different functions such as data acquisition, diagnosis, and recording, increasing the burden on embedded nodes, causing loss of diagnostic context, and affecting the accuracy of root cause analysis. Therefore, current robot state data processing is not intelligent enough. Summary of the Invention

[0004] Based on this, this application addresses the aforementioned technical problems by providing an improved robot state data processing method, apparatus, controller, computer-readable storage medium, and computer program product.

[0005] In a first aspect, this application provides a robot state data processing method, applied to the central control unit of a robot, comprising:

[0006] The robot status data is received through the first health management module in the central control unit;

[0007] Based on the robot's status data, the robot's health data is constructed, and the health data is sent to the diagnostic module in the central control unit;

[0008] The diagnostic module obtains the fault status code associated with the health data;

[0009] If an update to the fault status code is detected, the fault status code and the associated health data are written into the health record module in the central control unit and uploaded through the health record module.

[0010] In one embodiment, the robot status data includes: self-test data and the robot's operational status data during operation; receiving the robot status data includes: receiving the self-test data sent by the self-test module in the central control unit; receiving the operational status data sent by each of the robot's second health management modules; each of the second health management modules is located in a sub-control unit of the robot other than the central control unit.

[0011] In one embodiment, before receiving the self-test data sent by the self-test module in the central control unit, the method further includes: upon receiving the robot's start signal, performing a self-test on the central control unit through the self-test module to obtain first self-test data of the central control unit; sending a self-test request to each of the second health management modules, so that each of the second health management modules receives second self-test data obtained after the self-test processing of each of the sub-control units, and returns the second self-test data to the self-test module; receiving the second self-test data through the self-test module, and generating the self-test data based on the first self-test data and the second self-test data.

[0012] In one embodiment, after receiving the second self-test data through the self-test module, the process includes: performing communication verification on the second self-test data, and adding a fault status identifier to the second self-test data if the communication verification fails.

[0013] In one embodiment, constructing the robot's health data based on the robot's state data and sending the health data to the diagnostic module in the central control unit includes: obtaining the data source, data acquisition time, and data type of each robot state data; encapsulating each robot state data according to the data source, data acquisition time, and data type to obtain each health data; caching each health data, obtaining the sending priority of each health data according to the data type in the cached health data, and sending each health data to the diagnostic module according to the sending priority.

[0014] In one embodiment, the operating status data includes: periodic operating data of each sub-control unit and fault event data of each sub-control unit; the step of obtaining the transmission priority of each health data according to the data type in the cached health data, and sending each health data to the diagnostic module according to the transmission priority, includes: when the data type indicates that the health data is the self-test data or the fault event data, setting the transmission priority to a first transmission priority and immediately sending the cached health data to the diagnostic module; when the data type indicates that the health data is the periodic operating data, setting the transmission priority to a second transmission priority, and sending the cached health data to the diagnostic module when a preset transmission period is met.

[0015] In one embodiment, caching the health data includes: sorting the health data according to the data collection time of each health data to obtain the time sequence corresponding to each health data; and caching each health data to a message list that matches the data source of each health data according to the time sequence corresponding to each health data.

[0016] In one embodiment, the diagnostic module pre-stores the association between fault diagnosis results and fault status codes; obtaining the fault status code associated with the health data through the diagnostic module includes: performing diagnostic processing on the health data according to a preset diagnostic logic through the diagnostic module to obtain the fault diagnosis result of the health data; and generating the fault status code associated with the health data based on the fault diagnosis result and the association.

[0017] In one embodiment, the uploading via the health record module includes: constructing a data upload task corresponding to the fault status code and the health data associated with the fault status code; during the data upload task, if a communication failure is detected, stopping the execution of the data upload task and obtaining the task progress of the data upload task; and if the communication failure is resolved, continuing the execution of the data upload task based on the task progress.

[0018] Secondly, this application also provides a robot state data processing device, applied to the central control unit of a robot, comprising:

[0019] The status data receiving module is used to receive the robot status data of the robot through the first health management module in the central control unit;

[0020] A health data sending module is used to construct the robot's health data based on the robot's status data and send the health data to the diagnostic module in the central control unit;

[0021] A fault code generation module is used to obtain the fault status code associated with the health data through the diagnostic module;

[0022] The health data upload module is used to write the fault status code and the associated health data into the health record module in the central control unit when an update of the fault status code is detected, and then upload it through the health record module.

[0023] Thirdly, this application also provides a controller, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0024] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0025] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the above aspects.

[0026] The aforementioned robot state data processing method receives robot state data through a first health management module in the central control unit; constructs robot health data based on the robot state data and sends the health data to a diagnostic module in the central control unit; obtains fault status codes associated with the health data through the diagnostic module; and, upon detecting an update to the fault status code, writes the fault status code and its associated health data into a health record module in the central control unit and uploads it. This application allows the first health management module in the central control unit to aggregate robot state data, construct health data, and send it to the diagnostic module. The diagnostic module can then perform a diagnosis based on the health data to obtain the fault status code associated with the health data. Furthermore, upon detecting an update to the fault status code, it can write the fault status code and its associated health data into the health record module, which then uploads it. This method allows the central control unit to centrally process robot state data, thus avoiding fragmentation of health information. Simultaneously, by decoupling different functions such as data acquisition, diagnosis, and recording through different modules in the central control unit, it avoids increasing the burden on embedded nodes and causing loss of diagnostic context. Therefore, this implementation method improves the intelligence level of robot state data processing. Attached Figure Description

[0027] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0028] Figure 1 is a schematic diagram of an optional flowchart of a robot state data processing method in one embodiment;

[0029] Figure 2 is a schematic diagram of an optional process for receiving robot status data in one embodiment;

[0030] Figure 3 is a schematic diagram of an optional process for generating self-test data in one embodiment;

[0031] Figure 4 is a schematic diagram of an optional process for sending health data in one embodiment;

[0032] Figure 5 is a schematic diagram of an optional process for obtaining the fault status code in one embodiment;

[0033] Figure 6 is a schematic diagram of an optional architecture of a robot hierarchical health management system in one embodiment;

[0034] Figure 7 is a schematic diagram of an optional process of a robot hierarchical health management method in one embodiment;

[0035] Figure 8 is a schematic diagram of an optional structure of a robot state data processing device in one embodiment;

[0036] Figure 9 is a schematic diagram of an optional internal structure of the controller in one embodiment. Detailed Implementation

[0037] 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 for illustrative purposes only and are not intended to limit the scope of this application.

[0038] The terms "first," "second," etc., used in this application may be used to describe various elements, but these elements are not limited by these terms. These terms are used only to distinguish the first element from the second element. The terms "comprising" and "having," and any variations thereof, used in this application, are intended to cover non-exclusive inclusion. The term "multiple" used in this application refers to two or more. The term "and / or" used in this application refers to one of the embodiments, or any combination of multiple embodiments.

[0039] In one embodiment, as shown in Figure 1, a robot state data processing method is provided. This embodiment illustrates the application of this method to the central control unit of a robot. In this embodiment, the method includes the following steps:

[0040] Step S101: Receive robot status data from the first health management module in the central control unit.

[0041] Robot status data can refer to robot operation-related data. This robot operation-related data can be obtained by the robot's actuators, such as the robot's various control units other than the central control unit, which send the data to the central control unit. The first health management module is a module used by the central control unit to summarize the robot status data sent by each control unit.

[0042] Specifically, the central control unit can receive and aggregate the operational data generated by the robot during operation through the first health management module, which serves as the robot's status data.

[0043] Step S102: Construct the robot's health data based on the robot's status data, and send the health data to the diagnostic module in the central control unit.

[0044] The robot's health data is sent to the diagnostic module in the central control unit. This data can be obtained by the first health management module after encapsulating the robot's status data. The diagnostic module is used to analyze and diagnose the robot's health status. In this embodiment, the first health management module is only used to collect robot status data and does not involve the analysis of the robot status data. The analysis and diagnosis of the robot status data can be performed by the diagnostic module, thus implementing data collection and analysis in a layered manner through different modules.

[0045] Specifically, after the central control unit completes the collection of robot status data through the first health management module, it can first construct the robot's health data based on the robot status data, and then send the health data to the diagnostic module in the central control unit for health diagnosis and analysis.

[0046] Step S103: Obtain the fault status code associated with the health data through the diagnostic module.

[0047] A fault status code can refer to a Diagnostic Trouble Code (DTC). This is a standardized code generated by the vehicle's electronic control system (ECU) when it detects an anomaly. It identifies the specific fault type and location, helping repair personnel quickly pinpoint the problem. Specifically, after the central control unit's diagnostic module receives health data from the first health management module, it analyzes and processes the health data to generate a fault status code associated with that data.

[0048] Step S104: If an update to the fault status code is detected, the fault status code and the associated health data are written into the health record module in the central control unit and uploaded through the health record module.

[0049] The health record module is a module in the central control unit used to store and upload health data. If the diagnostic module detects an update to the fault status code, such as the addition or deletion of a fault status code, the central control unit can also send the fault status code and the associated health data, such as the associated health data context of the fault status code, to the health record module through the diagnostic module and the first health management module. The health record module records the above data and uploads the recorded fault status code and the associated health data.

[0050] In the aforementioned robot state data processing method, the robot state data is received by the first health management module in the central control unit; robot health data is constructed based on the robot state data and sent to the diagnostic module in the central control unit; the fault status code associated with the health data is obtained through the diagnostic module; and when an update to the fault status code is detected, the fault status code and the associated health data are written into the health record module in the central control unit and uploaded through the health record module. This application allows the first health management module in the central control unit to aggregate robot state data, construct health data, and send it to the diagnostic module. The diagnostic module can then perform a diagnosis based on the health data to obtain the fault status code associated with the health data. Furthermore, when an update to the fault status code is detected, the fault status code and the associated health data can be written into the health record module and uploaded. This method allows the central control unit to centrally process the robot state data, thus avoiding fragmentation of health information. Simultaneously, by decoupling different functions such as data acquisition, diagnosis, and recording through different modules in the central control unit, the burden on embedded nodes and the loss of diagnostic context are not increased. Therefore, this implementation method can improve the intelligence level of robot state data processing.

[0051] In one embodiment, the robot status data includes: self-test data and robot operation status data during operation; as shown in Figure 2, step S101 may further include:

[0052] Step S201: Receive self-test data sent by the self-test module in the central control unit.

[0053] In this embodiment, the robot status data may consist of two parts: self-test data when the robot starts, and operating status data generated during the robot's operation after startup. The self-test data can be provided by the self-test module in the central control unit. Specifically, after completing the robot's self-test, the self-test module can collect the self-test data and send it to the first health management module in the central control unit.

[0054] Step S202: Receive the operating status data sent by each of the robot's second health management modules; each of the second health management modules is set in each of the robot's sub-control units other than the central control unit.

[0055] The second health management module is used to collect operational status data from each sub-control unit during robot operation. This second health management module can be set in each sub-control unit, such as the motor driver, inertial control unit (IMU module), and power management unit. Specifically, each second health management module set in a different sub-control unit can collect the operational status data of its respective sub-control unit and return this operational status data to the first health management module for aggregation.

[0056] For example, the sub-control unit may include: a motor driver, an IMU module, and a power management unit. The second health management module located in the motor driver can collect the operating status data of the motor driver, the second health management module located in the IMU module can collect the operating status data of the IMU module, and the second health management module located in the power management unit can collect the operating status data of the power management unit. Furthermore, each of the above-mentioned second health management modules can return the collected operating status data to the first health management module, so that the first health management module can summarize the operating status data of the motor driver, the IMU module, and the power management unit.

[0057] In this embodiment, the robot status data may include self-test data collected by the self-test module and operating status data of each sub-control unit collected by the second health management module set in each sub-control unit. This method can improve the data integrity of the robot status data.

[0058] Additionally, as shown in Figure 3, before step S201, the following may also be included:

[0059] Step S301: Upon receiving the robot's start signal, the central control unit is subjected to a self-test by the self-test module to obtain the first self-test data of the central control unit.

[0060] The first self-test data is the self-test data obtained by the self-test module performing self-tests on the central control unit. Specifically, when the robot starts, a start signal can be sent to the robot's central control unit. At this time, the central control unit can perform self-tests on itself through its self-test module, such as performing self-tests on critical operating system services, basic operating environment, and core hardware resources, thereby obtaining the first self-test data.

[0061] Step S302: Send a self-test request to each of the second health management modules so that each of the second health management modules can receive the second self-test data obtained after the self-test processing of each sub-control unit and return the second self-test data to the self-test module.

[0062] The second self-test data is the self-test data obtained after the sub-control unit performs self-test processing. After the central control unit completes its self-test, it can also send self-test requests to each of the second health management modules, for example, by sending a self-test command through the internal bus. After receiving the self-test request command, the second health management module can make the sub-control unit perform self-test processing according to the self-test request command, collect the second self-test data, and return it to the self-test module.

[0063] Step S303: Receive second self-test data through the self-test module, and generate self-test data based on the first self-test data and the second self-test data.

[0064] The self-test module can receive the second self-test data mentioned above, and then use the first self-test data and the second self-test data to generate self-test data. For example, the first self-test data and the second self-test data can be summarized to obtain self-test data.

[0065] In this embodiment, the self-test module can also summarize the self-test data of the central control unit and each sub-control unit, thereby improving the data integrity of the self-test data.

[0066] Furthermore, after receiving the second self-test data through the self-test module, the function may also include: performing communication verification on the second self-test data, and adding a fault status indicator to the second self-test data if the communication verification fails.

[0067] Communication verification can refer to verifying the format, integrity, and timeout of received data. Specifically, after receiving the second self-test data, the self-test module can verify the format, integrity, and timeout of the second self-test data. If communication fails, an anomaly flag will be added to the second self-test data. Therefore, the self-test data received by the first health management module can contain an anomaly flag, which can further improve the integrity of the self-test data.

[0068] In this embodiment, after receiving the second self-test data, the self-test module can also perform communication verification on the data, and if the verification fails, it can also add an anomaly flag to the self-test data. This method can further improve the integrity of the self-test data.

[0069] In one embodiment, as shown in FIG4, step S102 may further include:

[0070] Step S401: Obtain the data source, data acquisition time, and data type of each robot status data.

[0071] The data source can represent the control unit that provides the robot's status data, the data acquisition time refers to the time when the robot's status data is acquired, and the data type is used to represent the type of robot status data, such as self-test data or normal operating status data, etc.

[0072] Specifically, after receiving the robot status data, the first health management module can also obtain the data source, data collection time, and data type of the robot status data.

[0073] Step S402: Based on the data source, data collection time, and data type, encapsulate and process the robot status data to obtain the health data.

[0074] After obtaining the data source, data collection time, and data type corresponding to each robot's status data, the data source, data collection time, and data type can be used to encapsulate each robot's status data into a standardized message containing the data source, data collection time, data type, and robot status data content, which serves as the health data corresponding to each robot's status data.

[0075] Step S403: Cache each health data, obtain the sending priority of each health data according to the data type in the cached health data, and send each health data to the diagnostic module according to the sending priority.

[0076] Sending priority can be used to characterize the priority of each health data being sent to the diagnostic module. This priority can be obtained based on the data type of each health data. Specifically, after the health data is encapsulated, the health data can be cached first. Then, the sending priority of each cached health data can be obtained according to the data type of the cached health data, and each health data can be sent to the diagnostic module according to the sending priority.

[0077] In this embodiment, the health data can be standardized and encapsulated according to the data source, data collection time, and data type of the robot status data. Furthermore, the sending priority of the health data can be obtained according to the data type, and the health data can be sent according to the sending priority. This method can improve the accuracy of health data encapsulation and transmission.

[0078] Furthermore, the operating status data includes: periodic operating data of each sub-control unit, and fault event data of each sub-control unit; step S403 may further include: when the data type characterizing health data is self-test data or fault event data, setting the transmission priority to the first transmission priority, and immediately sending the cached health data to the diagnostic module; when the data type characterizing health data is periodic operating data, setting the transmission priority to the second transmission priority, and sending the cached health data to the diagnostic module when the preset transmission period is met.

[0079] In this embodiment, the operating status data sent by each second health management module may include the following two parts: periodic operating data of each sub-control unit, which may refer to the operating data collected by the health management module according to a set period, such as temperature, voltage, load rate, etc.; and fault event data reported by each sub-control unit, that is, event-driven abnormal or fault reports reported by each sub-control unit, such as sensor offline, communication timeout, etc.

[0080] Specifically, if the data type of the cached health data indicates that the health data is self-test data or fault event data, the first health management module can set the sending priority of the health data to the first sending priority, which indicates high priority, and can immediately send the cached health data to the diagnostic module.

[0081] If the data type of the cached health data represents the periodic operation data of each sub-control unit, the first health management module can set the sending priority of the health data to the second sending priority, which represents the low priority, and can send the cached health data to the diagnostic module in batches according to the preset sending cycle.

[0082] In this embodiment, the sending priority of health data can also be set according to the data type. For high-priority health data, it can be sent to the diagnostic module immediately, while for low-priority health data, it can be synchronized in batches according to a preset period. This method can ensure the real-time nature of critical events while effectively controlling the communication load and avoiding high-frequency data interference with core control tasks.

[0083] In addition, step S403 may further include: sorting each health data according to the data collection time of each health data to obtain the time sequence corresponding to each health data; and caching each health data to a message list that matches the data source of each health data according to the time sequence corresponding to each health data.

[0084] In this embodiment, the caching of each health data point can be based on its data collection time and source. Specifically, after obtaining the health data, it can be sorted according to its data collection time, for example, by sorting the timestamps in ascending order to obtain the time sequence of each health data point. Then, the health data can be cached in a message list matching its data source according to the time sequence. This caching method allows for subsequent diagnostic queries based on the time index and data source index, thereby improving the efficiency of health data retrieval.

[0085] In this embodiment, each health data can be cached based on its data collection time and data source. This allows for the retrieval of health data based on time and data source indexes during subsequent diagnosis, thereby improving the efficiency of health data retrieval.

[0086] In one embodiment, the diagnostic module pre-stores the association between fault diagnosis results and fault status codes; as shown in Figure 5, step S103 may further include:

[0087] Step S501: The health data is processed by the diagnostic module according to the preset diagnostic logic to obtain the fault diagnosis result of the health data.

[0088] Diagnostic logic refers to pre-configured diagnostic rules, which are defined in a configurable form (such as JSON or rule engine scripts) and cover complex conditions such as threshold judgment, state combination, and time series patterns. Furthermore, the diagnostic logic does not depend on the data source. Health data from different data sources are all parsed through the same set of rule engines, thereby ensuring the consistency and maintainability of diagnostic behavior.

[0089] Furthermore, the diagnostic module supports two different diagnostic modes: remote diagnostic mode and local diagnostic mode. In remote diagnostic mode, diagnostic requests can be generated and sent from the cloud, while in local diagnostic mode, diagnostic requests are sent by communicating directly with external diagnostic devices.

[0090] Specifically, the diagnostic module can receive a diagnostic request from the cloud or an external diagnostic device, and then process the health data according to a preset diagnostic logic to obtain the fault diagnosis results of the health data.

[0091] Step S502: Based on the fault diagnosis results and correlations, generate fault status codes associated with health data.

[0092] Simultaneously, the diagnostic module can pre-store the association between fault diagnosis results and fault status codes. This association can be a global fault code (DTC) status table, centrally managing the lifecycle of all fault codes, including activation / deactivation determination, storage, clearing, severity level marking, and associated snapshot data binding. Specifically, after obtaining the fault diagnosis results of the health data, the diagnostic module can combine the fault diagnosis results with the aforementioned stored association to generate the fault status codes associated with the health data.

[0093] In this embodiment, the correlation between fault diagnosis results and fault status codes can be pre-stored in the diagnostic module. After the health data is diagnosed and processed by the preset diagnostic logic to obtain the fault diagnosis result, the above correlation can be combined to generate the fault status code associated with the health data. In this way, the diagnosis result can be obtained by the preset diagnostic logic, and the fault status code can be obtained by combining the correlation, thus improving the consistency and maintainability of fault diagnosis.

[0094] Furthermore, step S104 may further include: constructing a fault status code and a data upload task corresponding to the health data associated with the fault status code; during the data upload task, if a communication failure is detected, stopping the execution of the data upload task and obtaining the task progress of the data upload task; and if the communication failure is resolved, continuing to execute the data upload task based on the task progress.

[0095] The data upload task can be generated by the health record module after organizing, compressing, and packaging the data to be uploaded, namely fault status codes and the health data associated with those fault status codes, resulting in an upload task with a unique task ID. Specifically, when uploading fault status codes and their associated health data, the fault status codes and their associated health data can be used as the data to be uploaded to construct the corresponding upload task.

[0096] The health record module can then perform the aforementioned data upload task and monitor the progress of the data upload task in real time. If a communication failure occurs during the data upload process, such as communication interruption or timeout leading to failure, the health record module can also record the current data upload task progress as a breakpoint. This allows the transmission to continue based on the task progress after the communication failure is resolved, thus avoiding duplicate uploads or data loss.

[0097] In this embodiment, an upload task for the data to be uploaded can be constructed, and the progress of the upload task can be monitored in real time. Thus, when the communication failure is recovered, the upload task can continue to be processed based on the task progress at the time of the communication failure. This method can avoid duplicate data uploads or data loss.

[0098] In one embodiment, a robot hierarchical health management system and method are also provided. This system can be deployed in a robot control system, covering the entire process of power-on, operation, and remote maintenance. It enables hierarchical collection, centralized management, unified diagnosis, and external reporting of hardware and software status, fault information, and operational data. The system adopts a four-layer hierarchical architecture:

[0099] (1) Self-test layer: Performs initialization tests on the control unit and peripherals during the power-on phase;

[0100] (2) Health Management System: During operation, collect and integrate multi-source status and abnormal data in a unified manner;

[0101] (3) Diagnostic layer: Based on unified rules, perform fault judgment, DTC management and diagnostic service response on health data;

[0102] (4) Health record and reporting layer: Classify, store and reliably upload diagnostic results, logs and scenario data.

[0103] Each layer interacts through standardized interfaces, with decoupled responsibilities and scalability. The central control unit serves as the core, centrally deploying self-testing modules, the main health management module, the diagnostic module, and the health record module. It also collaborates with distributed health management sub-modules through underlying communication links, forming a complete closed loop of "collection—aggregation—analysis—recording—delivery".

[0104] Figure 6 shows the overall system architecture and the collaborative relationships between its functional units. The system comprises five core functional units:

[0105] (1) Self-test module: At startup, it coordinates each unit to complete the self-test and generates an initial health baseline;

[0106] (2) Main Health Management Module (First Health Management Module): Aggregates all health data, constructs a unified data view, and does not participate in judgment;

[0107] (3) Health management module (second health management module): deployed in a non-master control unit (sub-control unit), periodically or event-driven to collect local status and report it;

[0108] (4) Diagnostic module: Executes unified diagnostic logic, manages fault codes (DTC), and supports local / remote diagnostic requests;

[0109] (5) Health record module: records status, logs, faults and context data throughout the entire life cycle, and supports encrypted storage.

[0110] This embodiment can be combined with the functional unit division to provide a detailed explanation of the specific implementation methods of each module. This embodiment solves the technical problems existing in traditional robot health management systems, such as startup blocking, data fragmentation, diagnostic lag, and global failure caused by local faults, through mechanisms such as layered decoupling, responsibility isolation, raw data transmission, and non-blocking collaboration.

[0111] 1. Specific implementation of the self-test module:

[0112] The self-test module is deployed in the robot's central control unit. As the first-level health management execution unit during the system startup phase, it aims to solve the problems in traditional solutions where the entire machine's startup is blocked due to the failure of local peripherals, and the loss of diagnostic context due to premature judgment of self-test results. Before the system enters the runnable state, this module performs unified and autonomous status detection on key software and hardware infrastructure, and is strictly decoupled from business functions—the system is prohibited from entering motion control or task scheduling states before the self-test is completed, thus preventing "operation with defects" from the architectural perspective.

[0113] The module is automatically triggered by the startup management process after the operating system and basic services are initialized. Internally, it maintains a self-check configuration strongly bound to the system firmware version. This configuration is generated during compilation and fixed in read-only storage, and cannot be modified during runtime, ensuring consistent behavior across different devices with the same firmware version. The self-check process is executed sequentially, and each stage is managed by an internal state machine to ensure the determinism and traceability of the process.

[0114] The self-test first covers the central control unit itself, including critical operating system services (such as the scheduler and memory management), basic operating environment (such as the file system and network stack), and core hardware resources (such as the CPU, RAM, and RTC). The module obtains its status through the underlying probe interface and performs integrity verification (such as CRC) on the returned data to prevent misjudgments due to communication or memory anomalies.

[0115] Subsequently, the module sends self-test commands with session identifiers and timestamps concurrently to each peripheral control unit (sub-control unit) via an internal bus (such as CAN FD or EtherCAT), clearly indicating that the current self-test phase has begun. Each peripheral then performs its local self-test accordingly (such as motor driver continuity test, sensor zero-bias calibration, and battery SOC consistency check), and encapsulates the results in a predefined format (such as TLV) and returns them.

[0116] The self-test module performs format, integrity, and timeout checks on received data. If a unit responds abnormally or times out, its status is simply marked as "failed" or "communication abnormal," without interrupting the overall process, thus tolerating single points of failure. After summarizing all results, a complete self-test set containing the original status code, timestamp, and anomaly identifier is generated and directly transmitted to the main health management module. No fault arbitration or decision-making is performed at this layer, ensuring that subsequent diagnoses obtain a complete and undistorted initial health baseline.

[0117] The specific tests performed by the self-test module are explicitly defined by a static configuration table, which is shown in Table 1.

[0118] Table 1 Example of Self-Test Module Detection Item Configuration

[0119]

[0120] 2. Specific implementation of the main health management module (the first health management module):

[0121] The main health management module is deployed in the robot's central control unit. As the core coordination unit of the hierarchical health management system, it operates continuously after the system enters the operational phase and remains synchronized with the entire robot's lifecycle. This module aims to solve technical problems in traditional health systems, such as inconsistent multi-source data formats, premature decision-making by intermediate processing layers leading to loss of diagnostic context, and a lack of complete spatiotemporal correlation in fault analysis. Its core design principle is "aggregation only, no judgment"—that is, transparently receiving, standardizing, encapsulating, and orderly forwarding all health information without performing any fault arbitration, state fusion, or operational decisions, thereby providing a raw, complete, and traceable data foundation for upper-level diagnostics.

[0122] During operation, the main health management module receives three types of input through multiple logical interfaces: first, the raw self-test results (self-test data) from the self-test module during the startup phase; second, periodic operational status data (such as temperature, voltage, and load rate) from each health management slave module; and third, event-driven anomaly or fault reports (such as sensor offline or communication timeout) from sub-modules, i.e., fault event data. Once all input data arrives, it immediately enters a unified data access process and is encapsulated into a standardized message (health data) containing a data source identifier (source_id), a high-precision timestamp (timestamp_ns), a data type identifier (data_type), and the original content (payload). This encapsulation process does not parse or modify the payload content; it only adds metadata to ensure consistency and traceability of data during its internal flow within the system.

[0123] To efficiently support subsequent diagnostic needs, the module maintains an internal health data caching mechanism that supports dual indexing by time order and data source. This mechanism is implemented collaboratively by two logical views: the time index (time_index) organizes all system health events in strict ascending order using nanosecond-level timestamps, reflecting the global time series; the source index (source_index) uses the device's unique identifier as the key, with each key corresponding to a message list sorted by reception time, used to quickly aggregate the historical trajectory of a specific unit. Both share the same message entity, storing only references to avoid memory redundancy.

[0124] The core write logic of this dual-index structure can be illustrated as follows:

[0125] function AddMessage(msg):

[0126] / / Insert ordered sequence according to global time

[0127] time_index.insert_sorted(msg, key=msg.timestamp_ns)

[0128] / / Stored by source

[0129] if msg.source_id not in source_index:

[0130] source_index[msg.source_id] = []

[0131] source_index[msg.source_id].append(msg)

[0132] / / Implement a retention policy to prevent memory overflow.

[0133] apply_retention_policy()

[0134] This design offers significant advantages in real-world diagnostic scenarios. For example, when the diagnostic module detects an overcurrent alarm in motor driver_01 at t=10:05:23.456, it can first quickly retrieve the driver's most recent status data (such as bus voltage, winding temperature, and current waveform) through the source index to analyze its local degradation trend. Simultaneously, it extracts the health data of all other units within t±2 seconds (such as whether the IMU detected a severe impact or whether the power module output suddenly dropped) through the time index to determine if there are any system-level causes (such as a collision causing a sudden surge in load). This cross-device, cross-time dimension correlation analysis capability relies on the efficient data organization and retrieval capabilities provided by the dual-index mechanism.

[0135] In terms of data distribution, the health management main module continuously provides asynchronous data push services to the diagnostic module. When a new message is written to the cache, the module determines the push priority based on its data_type (data type): if it is a self-test result, a fault code (DTC), or a high-severity alarm, it is pushed immediately; routine status data is synchronized in batches according to a preset period. This strategy ensures the real-time nature of critical events while effectively controlling communication load and avoiding high-frequency data interference with core control tasks.

[0136] 3. Specific implementation of health management from the module (second health management module):

[0137] Health management modules are deployed within the non-master control units (i.e., sub-control units, such as motor drivers, IMU modules, and power management units) of the robot system. These modules act as local sensing agents for the health status of their respective units, responsible for periodically and autonomously collecting data on their own operational status and connected peripherals. Each module corresponds strictly one-to-one with its corresponding control unit and serves as the sole outlet for that unit to output health information to the system, ensuring clear data sources and eliminating redundant reporting.

[0138] During system operation, the health management module autonomously initiates data acquisition tasks at preset intervals (e.g., 100 ms), without requiring scheduling or polling intervention from the central control unit. The acquired information includes three categories: first, internal operating parameters of the control unit (e.g., CPU load, watchdog status, task scheduling delay); second, peripheral connection status (e.g., sensor online / offline, communication link quality); and third, local resource information (e.g., bus voltage, temperature, current). All acquisition operations are completed through the unit's local registers, driver interfaces, or dedicated diagnostic APIs, relying entirely on local resources, without introducing main control dependencies, and without affecting the execution of real-time control tasks.

[0139] After data acquisition, the module encapsulates the raw data according to a system-defined structure and adds two key pieces of information: a high-precision timestamp generated by the local real-time clock (RTC) and a globally unique identifier for this control unit (e.g., "motor_driver_01"). The encapsulated message is then sent to the health management main module in a non-blocking manner via the underlying communication link (e.g., CAN FD or EtherCAT). If communication is busy, the data is temporarily stored in a local circular buffer and automatically retransmitted when the link becomes idle, ensuring that the control loop of this unit is not affected.

[0140] To clearly define the encapsulated content and exception identification method, the output message structure is shown in Table 2:

[0141] Table 2. Health Management Module Output Message Structure Table

[0142]

[0143] The health management module does not contain any fault diagnosis, status arbitration, or operational decision-making logic. Its function is strictly limited to "collection-encapsulation-transmission," without attempting to interpret the meaning of data or triggering local alarms. This lightweight, stateless design is suitable for resource-constrained embedded environments and ensures a clear separation of responsibilities from the main health management module—the main module grasps the entire system context and performs unified diagnostics, while the slave module only provides raw facts.

[0144] When the module detects sensor readings exceeding limits, register access failures, or communication verification errors or buffer fullness during data acquisition, it will set `data_valid` or `comm_error_flag` to `false` / `true` and upload it along with the data. Based on this, the main health management module can distinguish between "real device malfunctions" and "data acquisition / communication anomalies," avoiding misjudgments and thus improving the robustness and accuracy of the overall diagnostic system.

[0145] 4. Specific implementation of the diagnostic module:

[0146] The diagnostic module is deployed in the robot's central control unit, serving as a unified service hub between the health management system and internal and external diagnostic tools. It aims to solve problems in traditional solutions such as the separation of local and remote diagnostic logic, fragmented fault code management, and inconsistent diagnostic behavior. This module continuously monitors the system during operation and supports both remote diagnostics (via the cloud) and local diagnostics (via handheld devices or debugging terminals), ensuring that the exact same diagnostic logic is executed in both modes, differing only in the communication path.

[0147] The module receives a full stream of health data from the main health management module via a standard interface, including self-check results, periodic operational status, and abnormal event reports. All input data is processed according to preset diagnostic rules (diagnostic logic). These rules are defined in configurable formats (such as JSON or rule engine scripts) and cover complex conditions such as threshold judgments, status combinations, and time-series patterns. Crucially, the diagnostic logic is independent of the data source—regardless of whether the data comes from self-checks, the module, or external requests, it is parsed using the same rule engine, ensuring consistency and maintainability of the diagnostic behavior.

[0148] In remote diagnostic mode, the diagnostic module receives standardized diagnostic requests (such as UDS or custom protocols) from the cloud via a communication proxy module. The module parses the target logical address (e.g., "motor driver_01") and diagnostic commands (e.g., "read DTC") in the request, converts them into low-level diagnostic messages recognizable by the corresponding control unit, and distributes them via an internal bus (e.g., CANFD). In local diagnostic mode, the module communicates directly with external diagnostic devices, acting as a diagnostic gateway to handle request forwarding, response aggregation, and result encapsulation. Both modes share the same diagnostic execution engine, differing only in the entry adaptation layer, significantly reducing maintenance complexity.

[0149] To support unified diagnostic capabilities, the module maintains a global fault code (DTC) status table (corresponding to fault diagnosis results and fault status codes), centrally managing the lifecycle of all fault codes, including activation / deactivation determination, storage, clearing, severity level marking, and binding of associated snapshot data. When a diagnostic rule triggers a new fault or an existing fault recovers, the module updates the DTC status and synchronously pushes the change event to the health record module for persistent storage and subsequent analysis.

[0150] The diagnostic process described above, which is "pattern-independent and rule-driven," can be illustrated as follows:

[0151] function ProcessDiagnosis(input_data, source_type):

[0152] / / 1. Uniform rule matching (regardless of source)

[0153] matched_rules = match_rules_against(input_data)

[0154] / / 2. Perform diagnostic actions (generate / clear DTCs, etc.)

[0155] for rule in matched_rules:

[0156] if rule.condition_met():

[0157] apply_diagnostic_action(rule.action) / / Such as set_DTC("P0123", ACTIVE)

[0158] / / 3. If it is an external request (local / remote), construct the response.

[0159] if source_type in {REMOTE_REQUEST, LOCAL_REQUEST}:

[0160] return build_diagnostic_response(current_DTCs, snapshots

[0161] / / 4. Synchronize DTC status changes to the health record module

[0162] if DTC_state_changed():

[0163] notify_health_record_module()

[0164] Through this design, the diagnostic module not only achieves seamless integration of local and remote diagnostics, but also ensures centralized fault code management and the evolvability of diagnostic logic, providing robots with highly reliable and easily scalable unified diagnostic service capabilities.

[0165] 5. Specific implementation of the health record module:

[0166] The health record module is deployed in the robot's central control unit and is responsible for the unified recording, classification, storage, and reliable external uploading of various health-related information generated during system operation. This module runs continuously throughout the system's entire lifecycle, maintaining real-time data interaction with the main health management module and the diagnostic module to ensure that critical health events are traceable, retrospective, and deliverable.

[0167] The module supports recording four types of core data: system operation logs, periodic status snapshots, fault codes (DTCs) and their associated contexts, and specific operational scenario data (such as task IDs and environmental parameters). Differentiated storage strategies are adopted for different data types: regular logs use a cyclic overwrite method to save space; fault-related data is permanently retained and bound to status snapshots within a time window; scenario data is archived at the task level for easy subsequent job-based backtracking analysis. All data is encrypted with AES-256 and digitally signed before being written, meeting security and compliance requirements.

[0168] Data uploads are driven by three triggering mechanisms: periodic uploads (e.g., every 30 minutes), uploads triggered by fault events (e.g., new DTC activation), and uploads requested by external requests (e.g., remote maintenance commands). Regardless of the triggering method, the module calls the log management subsystem to organize, compress, and package the data to be uploaded, generating an upload task with a unique task ID, and submitting it to the communication agent module.

[0169] To address the common network instability issues faced by mobile robots, the health record module implements a breakpoint resume mechanism: during each upload process, the module continuously maintains the task progress status (such as the number of bytes sent and the verification result); if the upload fails due to communication interruption or timeout, the current breakpoint position is recorded; when the link is restored and bandwidth is available, the transmission automatically resumes from the breakpoint to avoid duplicate uploads or data loss.

[0170] More importantly, when the diagnostic module reports a new fault or a change in fault status, the health record module dynamically prioritizes the collection and uploading of relevant data sources according to a preset strategy. For example, if a motor overheating fault is detected, the module can temporarily increase the status collection frequency of the drive from 1Hz to 10Hz and trigger an immediate upload of a complete context data packet containing 30 seconds before and after the fault, ensuring that no critical information is missed.

[0171] As shown in Figure 7, the process flow of the robot's hierarchical health management method is as follows:

[0172] 1. Self-inspection phase (initial startup):

[0173] The self-test module first performs startup checks on the central control unit and peripherals. Each peripheral is self-tested by its local health management module, and the results are returned in a standardized format. The self-test module aggregates all raw results (without making any judgments), delivers them to the main health management module in one go, and then exits the program, no longer participating in subsequent processes.

[0174] 2. Operational Phase (Normal Operating Period):

[0175] Each health management module periodically collects local status data (such as voltage, temperature, and communication status) from its respective control unit and continuously uploads the data to the main health management module. If a submodule detects an abnormal event, it also reports it directly to the main module.

[0176] 3. Data aggregation and distribution:

[0177] The health management main module acts as the central hub, uniformly receiving and caching all health data (including self-check results, periodic status, and abnormal events). It only performs source identification, timestamp alignment, and structured storage, without performing any fault judgment or status ruling. It asynchronously forwards the raw data to the diagnostic module according to preset strategies (such as immediate push of critical events and batch synchronization of routine data).

[0178] 4. Diagnosis and treatment:

[0179] Based on the received full health data, the diagnostic module executes unified diagnostic rules to generate, update, or clear fault codes (DTCs). All fault code status changes are synchronized to the health record module in real time. This module also responds to requests from cloud-based or local diagnostic devices, reusing the same diagnostic logic to ensure consistent behavior.

[0180] 5. Recording and Uploading:

[0181] The health record module retrieves data from the main health management module and the diagnostic module, and stores it categorized by type. When upload conditions are met (such as periodicity arrival, fault triggering, or external requests), the data is packaged and uploaded to the cloud via a communication proxy. The upload process supports resuming interrupted uploads, ensuring the complete and reliable delivery of critical health information even in cases of network instability.

[0182] The above embodiments, with "collection-aggregation-analysis-recording-delivery" as the main process line, do not rely on subsystem private interfaces or log formats, effectively solving problems such as fragmented health data, inconsistent diagnosis, and untraceable anomalies. They are suitable for single-machine multi-peripheral and multi-robot collaborative operation and maintenance scenarios, significantly improving the system's reliability, maintainability, and compatibility.

[0183] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0184] Based on the same inventive concept, this application also provides a robot state data processing apparatus for implementing the robot state data processing method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more robot state data processing apparatus embodiments provided below can be found in the limitations of the robot state data processing method described above, and will not be repeated here.

[0185] In one embodiment, as shown in FIG8, a robot state data processing device is provided, applied to the central control unit of a robot, including: a state data receiving module 801, a health data sending module 802, a fault code generation module 803, and a health data uploading module 804, wherein:

[0186] The status data receiving module 801 is used to receive the robot status data of the robot through the first health management module in the central control unit;

[0187] The health data sending module 802 is used to construct the robot's health data based on the robot's status data and send the health data to the diagnostic module in the central control unit;

[0188] The fault code generation module 803 is used to obtain the fault status code associated with the health data through the diagnostic module;

[0189] The health data upload module 804 is used to write the fault status code and the associated health data into the health record module in the central control unit when the fault status code is detected to be updated, and then upload it through the health record module.

[0190] In one embodiment, the robot status data includes: self-test data and the robot's operating status data during operation; the status data receiving module 801 is further configured to receive the self-test data sent by the self-test module in the central control unit; and to receive the operating status data sent by each of the robot's second health management modules; each of the second health management modules is configured in each of the robot's sub-control units other than the central control unit.

[0191] In one embodiment, the robot state data processing device further includes: a self-test module, configured to perform a self-test on the central control unit upon receiving a start signal from the robot, to obtain first self-test data of the central control unit; send a self-test request to each of the second health management modules, so that each of the second health management modules receives second self-test data obtained after the self-test of each of the sub-control units, and returns the second self-test data to the self-test module; and receive the second self-test data through the self-test module, and generate the self-test data based on the first self-test data and the second self-test data.

[0192] In one embodiment, the self-test module is further configured to perform communication verification on the second self-test data, and add a fault status identifier to the second self-test data if the communication verification fails.

[0193] In one embodiment, the health data sending module 802 is further configured to acquire the data source, data acquisition time, and data type of each robot status data; encapsulate each robot status data according to the data source, data acquisition time, and data type to obtain each health data; cache each health data, and acquire the sending priority of each health data according to the data type in the cached health data, and send each health data to the diagnostic module according to the sending priority.

[0194] In one embodiment, the operating status data includes: periodic operating data of each of the sub-control units, and fault event data of each of the sub-control units; the health data sending module 802 is further configured to, when the data type indicates that the health data is the self-test data or the fault event data, set the sending priority to a first sending priority and immediately send the cached health data to the diagnostic module; when the data type indicates that the health data is the periodic operating data, set the sending priority to a second sending priority and, if a preset sending period is met, send the cached health data to the diagnostic module.

[0195] In one embodiment, the health data sending module 802 is further configured to sort the health data according to the data collection time of each health data to obtain the time sequence corresponding to each health data; and cache each health data to a message list that matches the data source of each health data according to the time sequence corresponding to each health data.

[0196] In one embodiment, the diagnostic module pre-stores the association between fault diagnosis results and fault status codes; the fault code generation module 803 is further configured to perform diagnostic processing on the health data according to a preset diagnostic logic through the diagnostic module to obtain the fault diagnosis result of the health data; and generate the fault status code associated with the health data based on the fault diagnosis result and the association.

[0197] In one embodiment, the health data upload module 804 is further configured to construct the fault status code and the data upload task corresponding to the health data associated with the fault status code; during the data upload task, if a communication failure is detected, the execution of the data upload task is stopped, and the task progress of the data upload task is obtained; if the communication failure is recovered, the data upload task is continued to be executed based on the task progress.

[0198] Each module in the aforementioned robot state data processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the controller in hardware form or independent of it, or stored in the memory of the controller in software form, so that the processor can call and execute the operations corresponding to each module.

[0199] In one exemplary embodiment, a controller is provided, which may be the central control unit of a robot. The internal structure of the controller is shown in Figure 9. The controller includes a processor and a memory. The processor provides computational and control capabilities. The memory includes a non-volatile storage medium storing a computer program. When executed by the processor, the computer program implements a robot state data processing method.

[0200] Those skilled in the art will understand that the structure shown in Figure 9 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device (controller) to which the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0201] In one exemplary embodiment, a controller is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0202] In one exemplary embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method embodiments.

[0203] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0204] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0205] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program mentioned can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

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

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

Claims

1. A method for processing robot state data, characterized in that, A central control unit for a robot, the method comprising: receiving robot status data of the robot through a first health management module in the central control unit; constructing health data of the robot based on the robot status data, and sending the health data to a diagnostic module in the central control unit; obtaining a fault status code associated with the health data through the diagnostic module; and, upon detecting an update to the fault status code, writing the fault status code and the associated health data into a health record module in the central control unit, and uploading it through the health record module.

2. The method according to claim 1, characterized in that, The robot status data includes: self-test data and the robot's operational status data during operation; receiving the robot status data includes: receiving the self-test data sent by the self-test module in the central control unit; receiving the operational status data sent by each of the robot's second health management modules; each of the second health management modules is located in each of the robot's sub-control units other than the central control unit.

3. The method according to claim 2, characterized in that, Before receiving the self-test data sent by the self-test module in the central control unit, the method further includes: upon receiving the robot's start signal, performing a self-test on the central control unit through the self-test module to obtain first self-test data of the central control unit; sending a self-test request to each of the second health management modules, so that each of the second health management modules receives second self-test data obtained after the self-test processing of each of the sub-control units, and returns the second self-test data to the self-test module; receiving the second self-test data through the self-test module, and generating the self-test data based on the first self-test data and the second self-test data.

4. The method according to claim 3, characterized in that, After receiving the second self-test data through the self-test module, the process includes: performing communication verification on the second self-test data, and adding a fault status identifier to the second self-test data if the communication verification fails.

5. The method according to claim 2, characterized in that, The step of constructing the robot's health data based on the robot's state data and sending the health data to the diagnostic module in the central control unit includes: obtaining the data source, data acquisition time, and data type of each robot state data; encapsulating each robot state data according to the data source, data acquisition time, and data type to obtain each health data; caching each health data, obtaining the sending priority of each health data according to the data type in the cached health data, and sending each health data to the diagnostic module according to the sending priority.

6. The method according to claim 5, characterized in that, The operational status data includes: periodic operational data of each sub-control unit and fault event data of each sub-control unit; the step of obtaining the transmission priority of each health data according to the data type in the cached health data, and sending each health data to the diagnostic module according to the transmission priority, includes: when the data type indicates that the health data is the self-test data or the fault event data, setting the transmission priority to a first transmission priority and immediately sending the cached health data to the diagnostic module; when the data type indicates that the health data is the periodic operational data, setting the transmission priority to a second transmission priority, and sending the cached health data to the diagnostic module when a preset transmission period is met.

7. The method according to claim 5, characterized in that, The step of caching the health data includes: sorting the health data according to the data collection time of each health data to obtain the time sequence corresponding to each health data; and caching each health data to a message list that matches the data source of each health data according to the time sequence corresponding to each health data.

8. The method according to claim 1, characterized in that, The diagnostic module pre-stores the association between fault diagnosis results and fault status codes; obtaining the fault status code associated with the health data through the diagnostic module includes: performing diagnostic processing on the health data according to a preset diagnostic logic through the diagnostic module to obtain the fault diagnosis result of the health data; and generating the fault status code associated with the health data based on the fault diagnosis result and the association.

9. The method according to claim 8, characterized in that, The uploading via the health record module includes: constructing a data upload task corresponding to the fault status code and the health data associated with the fault status code; if a communication failure is detected during the data upload task, stopping the execution of the data upload task and obtaining the task progress of the data upload task; and if the communication failure is resolved, continuing the execution of the data upload task based on the task progress.

10. A robot state data processing device, characterized in that, A central control unit for a robot includes: a status data receiving module for receiving robot status data from the robot via a first health management module in the central control unit; a health data sending module for constructing health data of the robot based on the robot status data and sending the health data to a diagnostic module in the central control unit; a fault code generation module for obtaining a fault status code associated with the health data via the diagnostic module; and a health data uploading module for writing the fault status code and the associated health data into a health record module in the central control unit and uploading it via the health record module when an update to the fault status code is detected.

11. A controller comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 9.

Images