Humanoid robot OTA automatic upgrading method and system

Abstract

The present application relates to a kind of humanoid robot OTA automatic upgrading method and system, it relates to the field of robot software maintenance, it includes: based on robot state information to determine target robot set;Batch upgrade task is issued to target robot set, and is installed and upgraded with silent installation method;Current battery capacity of robot is collected;If current battery capacity is lower than upgrade maintenance threshold, determine the nearest target charging area according to current robot position;Based on current robot position to determine idle robot, and control idle robot to carry current robot to target charging area and charge, while completing silent installation process in target charging area;After installation upgrade is completed, automatically run self-checking program to verify core function, when upgrade self-checking result meets the preset self-checking requirement result, mark the version information after upgrade as upgrade success and report to cloud management platform.The present application has the effect of improving the upgrading efficiency of robot.

Description

Technical Field

[0001] This invention relates to the field of robot software maintenance, and in particular to a method and system for OTA automated upgrades of humanoid robots. Background Technology

[0002] Over-the-Air (OTA) automated upgrades for humanoid robots refer to the process of remotely, in batches, and automatically downloading, installing, and activating the robot's operating system, application software, algorithm models, and configuration files via a wireless network connection.

[0003] Currently, software upgrades for humanoid robots primarily rely on manual intervention using computer terminals to establish a connection with each robot via wired or dedicated wireless channels, manually triggering and monitoring the entire upgrade process. In existing technologies, this method requires maintenance personnel to operate on-site or remotely, ensuring robot tasks are paused, connections are stable, and manual intervention is necessary in case of anomalies. This rigid upgrade process, entirely dependent on manual operation, makes it difficult to avoid upgrade failures due to human error or unstable connections, thus reducing upgrade efficiency and requiring improvement. Summary of the Invention

[0004] To improve the efficiency of robot upgrades, this invention provides a method and system for automated over-the-air (OTA) upgrades of humanoid robots.

[0005] In a first aspect, the present invention provides a method for OTA automated upgrade of a humanoid robot, which adopts the following technical solution:

[0006] A method for OTA automated upgrade of a humanoid robot includes:

[0007] Collect robot status information;

[0008] Determine the target robot set based on robot state information;

[0009] The system controls the preset cloud management platform to send batch upgrade tasks to the target robot set, and controls the robots to collect OTA upgrade packages through a secure channel and perform the installation and upgrade using a preset silent installation method.

[0010] During the silent installation process, the robot's current battery level is collected;

[0011] Determine whether the current battery level is below the preset upgrade maintenance threshold;

[0012] If the current battery level is lower than the upgrade maintenance threshold, collect the current robot position;

[0013] Based on the robot's current location, determine the nearest target charging area from a pre-set list of charging facility locations;

[0014] Based on the current robot's position, an idle robot is identified, and the idle robot is controlled to move the current robot to the target charging area for charging, while the silent installation process is completed in the target charging area.

[0015] After the installation and upgrade are completed, a preset self-test program will be run automatically to verify the core functions and collect the upgrade self-test results and the upgraded version information.

[0016] When the upgrade self-test results meet the preset self-test requirements, the upgraded version information will be marked as a successful upgrade and reported to the cloud management platform.

[0017] By adopting the above technical solution, the system collects the status information of each robot and accurately selects the target robot set that meets the upgrade conditions. Then, a cloud management platform uniformly and automatically issues batch upgrade tasks to this cluster, and controls the robots to silently install the upgrade package via a secure channel. After installation, the system automatically runs a preset self-test program to verify functionality and collects the verification results and version information. When the self-test passes, the system automatically marks the upgrade as successful and reports it to the cloud. Through this closed-loop logic of status-driven cluster selection, centralized cloud management, silent installation, and automatic verification, the system completely eliminates the reliance on manual, one-by-one operations, achieving synchronous, efficient, and reliable automated upgrade management of large-scale robot clusters and improving robot upgrade efficiency.

[0018] Optional, also includes:

[0019] Based on robot state information, extract real-time task status, current physical posture, and environmental safety indicators;

[0020] Select upgradable robots based on real-time task status;

[0021] The selected upgradeable robots are integrated to obtain the initial set of robots;

[0022] Based on the current physical posture and environmental safety indicators, upgradeable robots are screened a second time to identify robots that are in a safe posture and safe area.

[0023] The robots after secondary screening are integrated to obtain the target robot set.

[0024] Optionally, the silent installation method includes:

[0025] Local verification rules are determined based on OTA upgrade packages;

[0026] Collect the robot's real-time status parameters;

[0027] The local verification rules are compared with the real-time status parameters to determine whether the preset silent installation conditions are met.

[0028] When the conditions for silent installation are met, control the robot to enter the safety upgrade mode and perform the silent installation operation.

[0029] If the conditions for silent installation are not met, the installation and upgrade will be performed using the preset alternating upgrade method.

[0030] Optionally, the alternating upgrade method includes:

[0031] The current task status is analyzed based on the robot's state information;

[0032] Determine non-task critical functional modules based on the current task status;

[0033] For non-mission-critical functional modules, generate phased upgrade tasks;

[0034] Combine phased upgrade tasks and OTA upgrade packages to generate sub-module upgrade packages;

[0035] Modular upgrade instructions are generated based on the submodule upgrade package;

[0036] Control the robot to execute modular upgrade instructions and maintain the execution of core tasks during the upgrade process.

[0037] Optionally, the control robot executing modular upgrade instructions includes:

[0038] Collect data on the robot's joint motion and sensor operating status;

[0039] Idle joint subsets and idle sensor subsets are identified based on joint motion state and sensor operating state;

[0040] Match and map the submodule upgrade package with the subsets of idle joints and idle sensors to determine the combination of upgrade tasks;

[0041] Generate parallel loading instructions based on the upgrade task combination;

[0042] The robot is controlled to simultaneously load and verify multiple sub-module upgrade packages based on parallel loading instructions. During the parallel upgrade process, the robot continuously monitors changes in joint motion and sensor operating status and dynamically adjusts the upgrade task combination.

[0043] Optional methods also include robotic handling:

[0044] Collect robot posture information and weight distribution parameters of the robot to be transported;

[0045] The robot's current orientation is determined based on its posture information;

[0046] The optimal approach path for the idle robot is determined by combining the robot's current orientation, current position, and target charging area.

[0047] The location of the handling support point is determined based on the weight distribution parameters;

[0048] Generate robotic arm grasping trajectory parameters based on the location of the handling support point;

[0049] The idle robot is controlled to perform a grasping operation based on the grasping trajectory parameters of the robotic arm, and after the grasping is completed, it moves to the target charging area according to the optimal approach path.

[0050] Optional, also includes:

[0051] Once the robot moves to the target charging area, its real-time posture data is collected.

[0052] Based on real-time attitude data, determine whether the preset charging safety attitude conditions are met;

[0053] When the charging safety posture conditions are not met, the posture adjustment angle is calculated based on real-time posture data and the charging safety posture conditions.

[0054] Adjust the angle based on the attitude to generate attitude correction parameters;

[0055] The idle robot is controlled to perform attitude adjustment operations on the current robot based on attitude correction parameters.

[0056] Optionally, anti-tipping mutual assistance methods within the target charging area may also be included:

[0057] The number of charging robots in the target charging area is collected.

[0058] When the number of charging robots exceeds the preset mutual assistance standard, the current charging power of each charging robot is collected.

[0059] Calculate the difference in power level between each robot based on the current charging power level;

[0060] Establish robot pairing relationships based on differences in battery power;

[0061] Based on the robot mutual assistance pairing relationship, the paired robots are controlled to adjust their posture to a preset anti-tipping mutual assistance posture to form a stable support structure, and then continue to perform the charging and upgrade process after the support structure is formed.

[0062] Secondly, this application provides an OTA automated upgrade system for humanoid robots, which adopts the following technical solution:

[0063] A humanoid robot OTA automated upgrade system includes:

[0064] The data acquisition module is used to collect robot status information, OTA upgrade packages, upgrade self-test results, and upgraded version information.

[0065] A memory for storing a program that implements an OTA (Over-The-Air) automated upgrade method for a humanoid robot;

[0066] The processor is used to load and execute programs stored in memory.

[0067] In summary, this application includes at least one of the following beneficial technical effects:

[0068] 1. Through a closed-loop logic of state-driven cluster screening, centralized cloud management, silent installation, and automatic verification, the reliance on manual operation is completely eliminated, realizing synchronous, efficient, and reliable automated upgrade management of large-scale robot clusters and improving robot upgrade efficiency.

[0069] 2. Based on the robot's status information, its current task status is accurately analyzed, and non-critical functional modules that do not affect the execution of core tasks are identified. Then, phased upgrade tasks are intelligently generated for these modules, and corresponding sub-module upgrade packages and modular upgrade instructions are generated according to task requirements and the complete upgrade package. By controlling the robot to execute these instructions, the core tasks can be maintained while upgrading non-critical modules. This breaks the limitation of traditional upgrades requiring the interruption of all tasks, achieving parallel processing of task execution and software upgrades. Version iteration is completed while ensuring the continuity of robot operation, further improving the online rate and operational efficiency of the robot system. 3. The robot's real-time joint motion status and sensor working status are first collected, and the currently idle subset of joints and sensors is accurately identified. Then, the sub-module upgrade packages to be upgraded are intelligently matched and mapped with these idle hardware resources to determine the optimal combination of parallel upgrade tasks and generate corresponding parallel loading instructions. By controlling the robot to simultaneously load and verify multiple sub-module upgrade packages based on this instruction, and continuously monitoring hardware status changes and dynamically adjusting task combinations during the upgrade process, the system resource utilization and the adaptability of the upgrade process are improved. Attached Figure Description

[0070] Figure 1 This is a flowchart of a method for OTA (Over-The-Air) automated upgrade of a humanoid robot.

[0071] Figure 2 This is a flowchart of the alternating upgrade method. Detailed Implementation

[0072] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0073] Reference Figure 1 This application discloses an OTA (Over-The-Air) automated upgrade method for a humanoid robot, comprising the following steps:

[0074] S10: Collect robot status information.

[0075] Robot status information refers to the collective term for various dynamic parameters used to determine whether a robot is currently suitable for OTA upgrades.

[0076] The robot's status information is periodically collected by the data acquisition agent program deployed on the robot body and encapsulated into data packets, which are then sent to the designated data receiving interface of the cloud management platform through the wireless network transmission module.

[0077] S11: Determine the target robot set based on robot state information.

[0078] The target robot set refers to the subset of robots selected from all online robots based on a preset screening method that are currently suitable for upgrades.

[0079] The specific screening method for the target robot set will be explained in detail in subsequent sections S20 to S24, and will not be repeated here.

[0080] S12: Control the preset cloud management platform to send batch upgrade tasks to the target robot set, and control the robots to collect OTA upgrade packages through a secure channel and install and upgrade using a preset silent installation method.

[0081] A cloud management platform refers to a software system deployed on a remote server for centralized monitoring, task management, and software distribution of robot clusters. The cloud management platform is pre-configured by those skilled in the art and will not be elaborated upon here.

[0082] An OTA (Over-The-Air) update package is a software update package containing a new version of the robot's operating system, applications, or firmware files. This update package undergoes digital signature and integrity verification before release to ensure its credible origin and lack of tampering.

[0083] OTA upgrade packages are published through a cloud management platform and stored in a cloud storage service. Once the cloud management platform identifies the target robot set, it assigns an encrypted download token to each target robot and sends out batch upgrade task instructions containing the token and the OTA upgrade package download address through a secure channel.

[0084] A secure channel is a network link established based on Transport Layer Security (TLS) or other encrypted communication protocols to ensure the secure transmission of instructions and data between the cloud management platform and the robot, preventing eavesdropping and tampering.

[0085] Silent installation refers to a technical method that automatically installs OTA upgrade packages in the background without the user's awareness or with minimal impact on the robot's main business functions. Specific details of the silent installation method will be explained in S30 to S34 later, and will not be elaborated upon here.

[0086] Once the target robot set is known, the cloud management platform needs to issue batch upgrade tasks to the target robot set, and control the robots to collect OTA upgrade packages through a secure channel and perform the installation and upgrade using a silent installation method.

[0087] S13: After the installation and upgrade are completed, the preset self-test program will be run automatically to verify the core functions and collect the upgrade self-test results and the upgraded version information.

[0088] A self-test program refers to a series of pre-written automated test scripts stored within the robot, used to quickly verify the proper functioning of critical hardware and software modules after a system update. Self-test programs include checking the status of core system services, reading data from key sensors, and performing simple joint motion tests. These programs are pre-programmed by those skilled in the art and will not be elaborated upon here.

[0089] The upgrade self-test result refers to the structured report generated after the self-test program runs, which records the pass / fail status of each test and detailed diagnostic information.

[0090] The upgrade self-test results are generated and stored through the robot's local log system. After the self-test program is completed, it encapsulates the output test status and diagnostic data into a report file in a specific format (such as JSON or XML) and writes it into the robot's non-volatile memory for subsequent querying and reporting.

[0091] Upgraded version information refers to the specific version numbers of the various software components running on the robot after the upgrade is completed. This information is obtained by calling the version query interface of the software module.

[0092] S14: When the upgrade self-test result meets the preset self-test requirements, the upgraded version information will be marked as a successful upgrade and reported to the cloud management platform.

[0093] The self-test requirement result refers to a predefined standard used to determine whether a self-test is satisfactory. This standard is set by the system administrator; for example, it may require all critical test items to pass, or allow a small number of warnings for non-critical test items.

[0094] When the robot's local upgrade daemon determines that the self-test results meet the requirements, it marks the upgrade as "successful" locally and encapsulates this status along with the upgraded version information into a confirmation message. Finally, this confirmation message is proactively reported to the cloud management platform via a secure channel. Upon receiving the message, the cloud management platform updates the corresponding robot's software version status and upgrade history in its database.

[0095] Also includes:

[0096] S20: Extract real-time task status, current physical posture, and environmental safety indicators based on robot state information.

[0097] Real-time task status refers to the execution context information currently recorded by the robot task scheduling system. This information clearly describes whether the robot is currently executing a task, what kind of task it is executing, and the stage of task execution.

[0098] Current physical posture refers to the quantitative data describing the pose of various parts of the robot's body in three-dimensional space, obtained through the fusion calculation of the robot's body sensors.

[0099] Real-time task status and current physical pose are obtained by parsing the corresponding data fields from the robot's state information. The specific parsing method is common knowledge in this field and will not be elaborated here.

[0100] Environmental safety labels are Boolean labels used to indicate whether the physical environment around a robot meets the safety conditions for high-risk operations (such as system restarts).

[0101] The environmental safety label is generated by comparing the robot's reported real-time location coordinates with a pre-defined digital map of safe zones. This digital map, pre-defined by the system administrator and stored in the cloud or on the robot's local machine, marks safe geographical areas where upgrades and other operations are permitted (such as charging rooms and maintenance areas). When the robot's location coordinates fall within any of the safe zone polygons, the system sets its environmental safety label to "safe"; otherwise, it is set to "unsafe." The generation logic for this label is executed by the location service module of the cloud management platform or the robot's local environmental perception software. The specific comparison algorithm is common knowledge in the field and will not be elaborated upon here.

[0102] S21: Select upgradable robots based on real-time task status.

[0103] An upgradeable robot is a robot whose current task attributes meet the condition of "upgradeable task can be inserted".

[0104] Upgradeable robots are determined by comparing their real-time task status with preset upgrade admission rules. These preset rules are set in advance by the system administrator; for example, the rule may require the robot's current real-time task status to be "idle" or its task priority to be lower than a preset interruptible priority threshold. The system iterates through all robots, applying this rule to the real-time task status of each robot. If the status matches the rule, the robot is marked as an "upgradeable robot." The specific comparison and marking logic is common knowledge to those skilled in the art and will not be elaborated upon here.

[0105] S22: Integrate the selected upgradeable robots to obtain the initial robot selection set.

[0106] The initial robot selection set refers to the set of unique robot identifiers formed after the initial screening based on task status. This set contains all robots that are theoretically eligible for upgrades and serves as the input pool for subsequent, more rigorous screening based on physical and environmental conditions.

[0107] S23: Based on the current physical posture and environmental safety indicators, a second screening is conducted on the upgradeable robot to determine the robot that is in a safe posture and safe area.

[0108] A secondary screening process is conducted by performing a deep safety assessment on each robot in the initial selection set, specifically including safe posture and safe area:

[0109] The determination of a safe posture is based on the robot's current physical posture data. The system checks whether the robot's torso tilt angle is less than the set stable angle threshold (e.g., both pitch and roll angles are less than 10 degrees), whether the angles of each joint are within the preset safe posture range, and whether data from foot force sensors indicates stable support. If all posture checks meet the preset safe posture conditions, the robot is determined to be in a "safe posture".

[0110] The determination of a safe zone is based on the robot's environmental safety label. Only robots with an environmental safety label indicating "safe" are considered to be in a "safe zone".

[0111] The logic of the secondary screening is as follows: for an upgradeable robot, it will be ultimately determined as a robot "within a safe posture and a safe area" if and only if it simultaneously meets both the conditions of "safe posture" and "safe area". If either condition is not met, the robot will be excluded from the upgrade candidate list for this round.

[0112] This secondary screening process is executed by the screening engine of the cloud management platform or the robot's local safety assessment module. The specific threshold settings and judgment logic can be configured by those skilled in the art according to the robot model and application scenario, and will not be elaborated here.

[0113] S24: Integrate the robots after the second screening to obtain the target robot set.

[0114] The unique identifiers of the robots that are "in a safe posture and within a safe area" that have passed the secondary screening in step S23 are summarized to form the final "target robot set".

[0115] Silent installation methods include:

[0116] S30: Determine local verification rules based on OTA upgrade packages.

[0117] Local verification rules refer to the set of mandatory conditions parsed from the OTA upgrade package and used for pre-installation verification on the robot's local machine. These rules are predefined and encapsulated by the upgrade package publisher when creating the upgrade package. After receiving the OTA upgrade package, the upgrade management program on the robot's side will call a dedicated parsing function to read the information within the package, thereby extracting the various verification standards required for this upgrade.

[0118] S31: Collect the robot's real-time status parameters.

[0119] Real-time status parameters refer to various data that reflect the current system resources and operating status, obtained in real time by calling the status query interface provided by the robot's operating system and hardware.

[0120] S32: Compare the local verification rules with the real-time status parameters to determine whether the preset silent installation conditions are met.

[0121] Silent installation conditions refer to a ready state reached when the robot's current state fully meets all the requirements of the local verification rules. The system determines whether the robot is in a working state by comparing each data point in the real-time status parameters with the corresponding requirements of the local verification rules. If all comparison items meet the rules, the robot is not in a working state, the system determines that the silent installation conditions are met, and allows the execution of subsequent step S33. If any comparison item does not meet the rules, it indicates that the robot is in a working state, and the silent installation conditions are not met, thus proceeding to the alternating upgrade process in S34. This comparison process is automatically executed by the upgrade management program; the specific comparison logic is set by those skilled in the art according to business rules and will not be elaborated here.

[0122] S33: When the conditions for silent installation are met, control the robot to enter the safety upgrade mode and perform the silent installation operation.

[0123] Once the conditions for silent installation are met, the upgrade management program will trigger a process that puts the robot into "safe upgrade mode," where the silent installation operation will be performed.

[0124] S34: When the conditions for silent installation are not met, the installation and upgrade will be performed using the preset alternating upgrade method.

[0125] The alternating upgrade method refers to a gradual upgrade strategy employed when the robot cannot perform a full silent installation because its real-time status fails to meet the conditions for silent installation. The specific alternating upgrade method will be explained in detail in subsequent sections S40 to S45, and will not be elaborated upon here.

[0126] Reference Figure 2 Alternating upgrade methods include:

[0127] S40: Analyze the current task status based on the robot's status information.

[0128] The current task status refers to the detailed stage and attribute description of the work being performed, specifically parsed from the status information reported by the robot. For example, for a "moving items" task, the current task status can be parsed into specific sub-stages such as "moving to the shelf", "visually recognizing the target item", "performing the grasping action", "carrying the item to the target point", and "placing the item".

[0129] The current task status is obtained by parsing specific task-related data fields from the robot's status information. Robot status information typically includes structured data such as task ID, task type, and execution step index. The current task status can be determined by querying this data and matching it with a pre-defined task status mapping table. This task status mapping table is designed and maintained in advance by the system developers based on the robot's task framework, defining the specific status descriptions for various task types under different execution steps. The construction and maintenance of this table is routine work performed by those skilled in the art based on specific task designs and will not be elaborated upon here.

[0130] S41: Determine non-task critical functional modules based on the current task status.

[0131] Non-mission-critical functional modules refer to software / firmware functional units that are temporarily not invoked and are in an idle state during a specific phase of the current task execution. The temporary suspension or update of these modules will not affect the continuity and security of the current core task.

[0132] Non-task-critical functional modules are determined by querying a pre-defined task module dependency table. This table, established and maintained in advance by the system developers, records the dependencies of various system functional modules under different task states (or task stages). For a given current task state, the system retrieves all functional modules marked as "non-dependent" or "low-dependent" in this state by searching the table; the set of these modules is then defined as the "non-task-critical functional modules." The logic for constructing and retrieving the dependency table is defined by those skilled in the art based on the system architecture and business logic, and will not be elaborated upon here.

[0133] S42: Generate phased upgrade tasks for non-mission-critical functional modules.

[0134] A phased upgrade task refers to an execution plan that includes multiple ordered upgrade steps. This plan, based on a set of non-critical functional modules and considering inter-module dependencies (e.g., the base library module must be upgraded before the application module), plans independent upgrade sub-tasks for each module or group of modules.

[0135] By querying a pre-defined inter-module dependency table, the upgrade order constraints of each module are clarified. Then, based on the upgrade package size, estimated installation time, and system resource consumption, multiple small modules without dependency conflicts or capable of parallel processing are packaged into a subtask. Finally, each subtask is assigned a unique execution sequence number, and its execution time window is estimated, thus forming a complete phased upgrade plan containing multiple ordered subtasks. The logic for generating this plan is set by those skilled in the art based on module characteristics and system resource scheduling strategies, and will not be elaborated here.

[0136] S43: Combine phased upgrade tasks and OTA upgrade packages to generate submodule upgrade packages.

[0137] A submodule upgrade package refers to an independent data package extracted from a complete OTA upgrade package according to the requirements of the phased upgrade task, containing only the update content of a specific module.

[0138] Before being released to the cloud, the complete OTA upgrade package has been structurally divided and differentially processed according to functional modules, generating corresponding module lists and differential data blocks. Once a phased upgrade task is determined, the system extracts the update data blocks of the corresponding modules from the module list of the OTA upgrade package based on the target module information specified in the task, and repackages them into an independent compressed package containing necessary verification information, i.e., the sub-module upgrade package. This generation process is executed by the differential release service of the cloud management platform or the robot's local package management tool. The specific module division and differential techniques are common knowledge in the field and will not be elaborated upon here.

[0139] S44: Generate modular upgrade instructions based on the submodule upgrade package.

[0140] A modular upgrade command is a control command specifically designed to update a particular functional module. This command includes the target module's unique identifier, the local storage path of the corresponding sub-module upgrade package on the robot, and the dedicated installation or flashing command parameters specific to that module type.

[0141] The system determines the unique identifier of the target module based on the metadata included in the submodule upgrade package. Simultaneously, the system records the complete storage path of the downloaded submodule upgrade package on the robot's local machine. Then, by querying a pre-defined module command mapping table, the system retrieves the pre-defined path to the dedicated installation script or flashing tool call parameters for the target module type (e.g., "dynamic link library," "kernel driver," "firmware image," "configuration file," etc.). Finally, the above information is packaged according to a predetermined instruction format to form a complete modular upgrade instruction. The module command mapping table is created and maintained in advance by the system developers according to the installation or flashing specifications of various modules in the robot system. The table establishes the correspondence between module types and specific operation commands. The construction and maintenance of this table is routine work performed by those skilled in the art based on module management requirements and will not be elaborated upon here.

[0142] S45: Controls the robot to execute modular upgrade instructions and maintains the execution of core tasks during the upgrade process.

[0143] Upon receiving the modular upgrade instruction, the robot must be controlled to execute the modular upgrade instruction and maintain the execution of core tasks during the upgrade process.

[0144] Controlling the robot to execute modular upgrade instructions includes:

[0145] S50: Collects data on the robot's joint motion status and sensor operating status.

[0146] Joint motion state refers to a set of data describing the real-time motion status of each active joint of a robot (such as shoulder joint, elbow joint, hip joint, knee joint, etc.).

[0147] The joint motion state is periodically read and summarized from each joint actuator through the robot's internal high-speed real-time communication network.

[0148] Sensor operating status refers to the status information describing the current operating mode and data availability of each major sensor module on the robot. For example: whether the vision camera is currently in streaming mode, single-frame capture mode, or standby mode; whether the LiDAR is performing a scan and its scan frequency; the data output frequency and self-test status of the inertial measurement unit (IMU); and the zero-point status and data validity flags of the force / torque sensors. This status information is obtained through the corresponding device drivers for each sensor.

[0149] The specific device drivers are pre-defined by those skilled in the art and will not be elaborated upon here.

[0150] S51: Identify idle joint subsets and idle sensor subsets based on joint motion state and sensor operating state.

[0151] The idle joint subset refers to the set of all joints that are not currently involved in maintaining the robot's posture or performing task actions, are in "zero torque output" or "position holding" control modes, and whose temperature and current parameters are within safe ranges. For example, when a robot is performing fine operations using only its right arm, all joints of its left arm and most joints of its legs may be identified as idle.

[0152] By extracting the joint's control mode, the error between the actual and target positions, output current, and temperature parameters from the joint's motion state, and comparing them with preset idle joint determination rules, a subset of idle joints can be identified. The idle joint determination rules are pre-defined by the system developers. For example, the rules might state that when a joint's control mode is "zero torque" or "position hold," the position error is within the allowable tolerance range, and its real-time current and temperature are both below their respective safety thresholds, the joint is determined to be idle. The set of all joints determined to be idle constitutes the idle joint subset.

[0153] The idle sensor subset refers to the set of sensors that are not currently relied upon by any running core algorithm or task logic as a primary data source, are in low-power standby mode, or are collecting data but not consuming it. For example, when a robot relies solely on its front-facing camera for navigation, its side and rear-facing cameras may be identified as idle; when a robot is in a stationary planning state, its LiDAR may be in idle or low-frequency scanning mode.

[0154] By extracting the sensor's operating mode, data consumption status, and task-occupied declaration information from the sensor's operating status and comparing it with preset idle sensor determination rules, an idle sensor subset can be identified. The idle sensor determination rules are pre-defined by the system developers. For example, a rule might stipulate that a sensor is considered idle when its operating mode is "standby," or when its output data in operating mode is not read by any task module within a certain time window and is not marked as "occupied" by the task scheduler. The set of all sensors determined to be idle constitutes the idle sensor subset. Specific determination rules and threshold settings are determined by those skilled in the art based on actual application scenarios and will not be elaborated upon here.

[0155] S52: Match and map the submodule upgrade package with the idle joint subset and the idle sensor subset to determine the upgrade task combination.

[0156] An upgrade task package refers to an optimized parallel upgrade execution plan that specifies which sub-module upgrade packages can be executed simultaneously on currently available hardware resources.

[0157] By querying a pre-defined module hardware dependency table, the specific hardware required by each submodule upgrade package is matched with resources in the currently available subsets of joints and sensors. The upgrade task is bound to these available hardware components to form an executable unit only if all dependent hardware components of a submodule are within their corresponding available subsets. The set of all successfully bound executable units constitutes the upgrade task combination. The module hardware dependency table is designed and maintained in advance by the system developers based on the robot's software and hardware architecture. The table records the correspondence between different software modules or firmware and the specific physical hardware necessary for their installation and operation. The construction and maintenance of this table is routine work performed by those skilled in the art based on system design and will not be elaborated upon here.

[0158] The specific matching mapping algorithm and dependency table are designed by those skilled in the art based on the system architecture, and will not be elaborated here.

[0159] S53: Generate parallel loading instructions based on the upgrade task combination.

[0160] Parallel loading instructions are a set of specific hardware programming or software update commands that can be executed concurrently by the robot control system.

[0161] The system analyzes each executable task unit within the upgrade task set. For each unit, based on the specific submodule upgrade package it's bound to and its dependent hardware resources (joints or sensors), the following operations are performed: First, based on the type of the submodule upgrade package (e.g., firmware, driver, software library), the corresponding standard loading command template is retrieved from a pre-defined type command mapping table. Second, placeholders in the command template are replaced with the specific hardware identifier bound to the task unit and the actual local storage path of the submodule upgrade package. Finally, the generated specific command is appended with the necessary execution context information and encapsulated as an independent "loading instruction unit." After all task units have completed the above transformations, the system packages all generated "loading instruction units" and appends a parallel execution scheduling strategy, collectively forming the final parallel loading instruction to be issued and executed. The type command mapping table is created and maintained in advance by the system developers according to the loading specifications of various submodules. The table establishes the correspondence between module types and specific loading command templates. The construction and maintenance of this table is routine work performed by those skilled in the art based on module loading requirements and will not be elaborated upon here.

[0162] The specific command templates, replacement rules, and encapsulation formats are designed by those skilled in the art based on the system control interface specifications, and will not be elaborated here.

[0163] S54: Control the robot to simultaneously load and verify multiple sub-module upgrade packages based on parallel loading instructions. During the parallel upgrade process, continuously monitor the changes in joint motion status and sensor working status, and dynamically adjust the upgrade task combination.

[0164] The robot controls the loading and verification of multiple sub-module upgrade packages simultaneously based on the obtained parallel loading instructions. During the parallel upgrade process, it is necessary to continuously monitor the changes in joint motion state and sensor working state in order to dynamically adjust the upgrade task combination (i.e., repeat S50 to S54 until the upgrade is completed).

[0165] Also includes:

[0166] S60: During the silent installation process, collect the robot's current battery level.

[0167] The current battery charge refers to the real-time remaining percentage of the power battery pack during the robot's silent installation operation.

[0168] The current battery level is monitored in real time by the battery management system on the robot.

[0169] S61: Determine whether the current battery level is below the preset upgrade maintenance threshold based on the current battery level.

[0170] The upgrade maintenance threshold refers to the critical percentage of battery power used to determine whether the battery has sufficient power to support the completion of the subsequent silent installation and restart process.

[0171] The upgrade maintenance threshold is set in advance by those skilled in the art and will not be elaborated here.

[0172] By determining whether the current battery level is below the upgrade maintenance threshold, we can determine whether the robot can complete the upgrade without recharging.

[0173] S62: If the current battery level is lower than the upgrade maintenance threshold, collect the current robot position.

[0174] The current robot position refers to the precise coordinates of the robot in its working environment's global map coordinate system when a low battery alarm is triggered. The current robot position is obtained through a pre-set GPS positioning chip on the robot.

[0175] If the current battery level is lower than the upgrade maintenance threshold, it means that the robot's current battery level is insufficient to sustain the subsequent silent installation process. The robot's current position needs to be collected first for subsequent steps.

[0176] S63: Determine the nearest target charging area from the preset list of charging facility locations based on the current robot position.

[0177] The charging facility location list is a structured data list storing the geographical information of all available charging stations in the working environment. Each record in the list typically contains a unique ID of the charging facility, its coordinates in a map coordinate system, and the facility's status (e.g., idle, occupied, faulty). By calculating the geometric distance (e.g., Euclidean distance) between the current robot position and the coordinates of each charging facility in the list, the nearest available charging facility can be identified, and the physical location corresponding to that facility is determined as the target charging area. The charging facility location list is pre-defined by those skilled in the art and will not be elaborated upon here.

[0178] S64: Determine an idle robot based on the current robot position, and control the idle robot to move the current robot to the target charging area for charging, while completing the silent installation process in the target charging area.

[0179] An idle robot refers to another robot individual that is within the effective collaboration range of the current low-power robot, is under the same management network as the current robot, can be uniformly scheduled by the cloud management platform, and whose status is marked as "idle".

[0180] Idle robots are identified by querying a global robot status list maintained on the cloud management platform. This list records the working status, location, and battery information of each robot in real time. Based on the current robot location, the system filters robots within a certain geographical range that are in an "idle" state and have sufficient battery power as candidate idle robots. The specific filtering scope and judgment criteria are set by those skilled in the art based on the cluster deployment and will not be elaborated here.

[0181] Once an idle robot is available, it is necessary to control the idle robot to move the current robot to the target charging area for charging, so that the current robot can complete the silent installation process in the target charging area.

[0182] It also includes robotic handling methods:

[0183] S70: Collects robot posture information and weight distribution parameters of the robot to be transported.

[0184] Robot pose information refers to the precise pose data of the robot to be transported (i.e., the current robot mentioned above) in its own coordinate system and / or global coordinate system. This information includes the 6-DOF pose (position and orientation) of the robot's torso, the configuration of each major limb (such as arms and legs), and the spatial position and orientation of the dedicated gripping interfaces (such as back handles and slots on the sides of the torso) pre-set for transport operations. The robot pose information is provided by the robot to be transported through its internal state estimation and sensor system.

[0185] Weight distribution parameters refer to the total mass of the robot to be transported, and the proportion of that mass distributed among the main parts of the robot's main structure (such as the torso, left arm, right arm, and leg system).

[0186] The weight distribution parameters are obtained by querying the pre-stored configuration database of the robot to be transported. This database stores the standard total mass of this robot model and reference values ​​for the mass distribution of each part under different standard postures (such as standing with arms folded). The system selects the distribution parameters corresponding to the closest posture based on the currently collected robot posture information (such as whether the arms are extended). The specific methods for obtaining and estimating these parameters are determined by those skilled in the art based on the robot design documents and will not be elaborated here.

[0187] S71: Obtain the robot's current orientation based on the robot's posture information.

[0188] The robot's current orientation refers to the yaw angle of the robot's main body relative to a preset reference direction (such as the north direction in the world coordinate system or the front direction of the charging pile, which is set in advance by those skilled in the art and will not be elaborated here).

[0189] The robot's current orientation can be obtained by extracting data components describing the torso's orientation from the robot's posture information and performing coordinate transformations and angle calculations based on a preset reference direction. Specific extraction and calculation methods are determined by those skilled in the art based on the way robot posture information is expressed (e.g., quaternions, Euler angles, rotation matrices, etc.), and will not be elaborated upon here.

[0190] S72: Combine the robot's current orientation, current robot position, and target charging area to determine the optimal approach path for the idle robot.

[0191] The optimal approach path refers to the trajectory that an idle robot should follow to safely and efficiently move from its current position to the best position where it can effectively grasp the robot to be transported.

[0192] First, based on the robot's current orientation, the front, back, and side orientations of the robot to be handled are determined. To avoid collisions and facilitate grasping, the optimal approach direction for the idle robot is usually chosen to be the side-rear of the robot to be handled. Second, based on the current robot position and the target charging area's location, a general guiding path is planned on the environmental map from the idle robot's current position to the target charging area. Finally, based on the guiding path and the optimal side-rear approach direction of the robot to be handled, a path planning algorithm (such as A* algorithm, Dijkstra's algorithm, or other well-known algorithms in the field) is used, under the constraints of the environmental map, to calculate the specific trajectory of the idle robot moving from its current position to the side-rear grasping position of the robot to be handled. This trajectory is the optimal approach path. The specific path planning algorithm and environmental map representation method are selected by those skilled in the art based on the actual application scenario and will not be elaborated here.

[0193] S73: Determine the location of the handling support point based on the weight distribution parameters.

[0194] The location of the transport support point refers to one or more preferred three-dimensional coordinate points where the end effector of the idle robot's robotic arm contacts the body of the robot to be transported and provides the main support force.

[0195] First, based on the weight distribution parameters and the robot's current posture information, the approximate three-dimensional position of the robot's center of gravity in the global coordinate system is estimated. Second, according to the robot's physical structure design, several candidate support points located near the center of gravity projection and capable of bearing force are selected on its body. Finally, considering the workspace and kinematic constraints of the idle robot arm, one or more points that are easiest to manipulate and can provide stable force support are selected from the candidate support points as the final transport support point locations. The specific methods for center of gravity estimation, candidate point selection, and final determination are determined by those skilled in the art based on the robot model and transport task requirements, and will not be elaborated here.

[0196] S74: Generate robotic arm grasping trajectory parameters based on the position of the handling support point.

[0197] The robotic arm grasping trajectory parameters refer to the detailed motion control data required to control the idle robotic arm to complete a series of actions, including moving from the ready position to the support point, performing grasping, and then lifting the load to the carrying height.

[0198] First, based on the current state of the idle robotic arm and the determined position of the transport support point, a trajectory planning algorithm is used to calculate the sequence of joint space or Cartesian space trajectory points from the current position to the grasping preparation point without collision. Second, trigger conditions and execution parameters are defined for the grasping action itself. Finally, a lifting trajectory is planned to safely lift the load from the grasping point to the preset transport height. All trajectory point sequences, motion velocities, acceleration curves, and grasping action parameters are integrated and encapsulated to form complete robotic arm grasping trajectory parameters. The specific planning algorithm and parameter encapsulation format are set by those skilled in the art according to the robotic arm model and control interface specifications, and will not be elaborated here.

[0199] S75: Controls the idle robot to perform grasping operations based on the robotic arm's grasping trajectory parameters, and moves to the target charging area according to the optimal approach path after grasping.

[0200] After obtaining the robotic arm's grasping trajectory parameters, the idle robot needs to be controlled to perform a grasping operation on the robot to be transported, and after the grasping is completed, it moves to the target charging area according to the optimal approach path.

[0201] Also includes:

[0202] S80: After moving to the target charging area, collect the robot's real-time posture data.

[0203] Real-time posture data refers to the set of quantitative data describing the precise pose of a robot in three-dimensional space, which is measured and calculated in real time by its onboard sensors after the robot is transported to the target charging area.

[0204] Real-time attitude data is acquired through the robot's attitude perception system. This system integrates data from the inertial measurement unit (IMU), joint encoders, and foot force sensors, and calculates the robot's real-time 6-DOF pose (position and orientation) and joint angles using state estimation algorithms (such as extended Kalman filtering or complementary filtering). This dataset is used to accurately assess the robot's placement within the charging area. Specific sensor fusion and state estimation algorithms are designed by those skilled in the art based on the robot's hardware configuration and will not be elaborated upon here.

[0205] S81: Determines whether the preset charging safety posture conditions are met based on real-time posture data.

[0206] Charging safety posture conditions refer to a set of geometric and physical constraints set for the robot's pose to ensure that the robot's charging interface can safely and accurately dock with the charging pile probe. These charging safety posture conditions are pre-set by those skilled in the art and will not be elaborated upon here.

[0207] By judging whether all parameters in the real-time attitude data meet the thresholds or ranges specified by the charging safety attitude conditions, it can be determined whether the current attitude meets the requirements.

[0208] S82: When the charging safety posture conditions are not met, calculate the posture adjustment angle based on real-time posture data and charging safety posture conditions.

[0209] The attitude adjustment angle refers to the angle by which the robot's torso needs to rotate around the vertical axis and the amount of horizontal translation that may be required in order to adjust the robot from its real-time attitude to a target attitude that meets the charging safety requirements.

[0210] The attitude adjustment angle is obtained by calculating the spatial transformation difference between real-time attitude data and the target attitude specified in the charging safety attitude conditions. The specific calculation method is designed by those skilled in the art based on the principles of spatial geometric transformation and will not be elaborated here.

[0211] When the charging safety posture conditions are not met, the posture adjustment angle must be calculated first for subsequent steps.

[0212] S83: Adjust the angle based on the attitude to generate attitude correction parameters.

[0213] Attitude correction parameters refer to the set of control command parameters that convert the calculated attitude adjustment angle and / or translation amount into a set of control commands that can be used by an idle robot to perform specific attitude adjustment operations.

[0214] By adjusting the posture angle and translation amount, combined with the relative position of the idle robot and the current robot, the kinematic model of the idle robot's robotic arm, and the contact force control strategy, corresponding posture correction parameters are generated. Specifically, these include: the direction and magnitude of the force to be applied by the idle robot's end effector, the spatial coordinates of the point of application, and the motion trajectory and velocity curve of the adjustment action. The parameter generation process is designed by those skilled in the art based on the principles of robot interaction control and will not be elaborated upon here.

[0215] S84: Control the idle robot to perform attitude adjustment operations on the current robot based on attitude correction parameters.

[0216] The idle robot controls its robotic arm or other adjustment mechanism to apply precise force or displacement to specific parts of the current robot (such as the side of the torso or the handle on the back) in a safe and controlled manner based on the received posture correction parameters. This helps the current robot to fine-tune its posture until it is confirmed by real-time posture data collected again that it has met the charging safety posture conditions.

[0217] It also includes anti-tipping mutual assistance methods within the target charging area:

[0218] S90: Collects the number of charging robots in the target charging area.

[0219] The number of charging robots refers to the total number of individual robots currently performing charging operations within the target charging area.

[0220] The number of charging robots is obtained by identifying and counting the robots in the target charging area through a monitoring system (such as cameras combined with visual recognition algorithms) deployed in the area.

[0221] S91: When the number of charging robots exceeds the preset mutual assistance standard number, collect the current charging power of each charging robot.

[0222] The mutual assistance standard number refers to the minimum number of robots required to trigger the anti-tipping mutual assistance mechanism. For example, setting it to 2 means that mutual assistance will only be considered when there are at least 2 robots in the charging area. The specific mutual assistance standard number is set in advance by those skilled in the art and will not be elaborated here.

[0223] The current charging level refers to the real-time remaining percentage of the power battery of each charging robot. This data can be obtained from the charging pile's communication interface while charging.

[0224] When the number of charging robots exceeds the mutual assistance standard, it means that the anti-tipping mutual assistance mechanism can be activated. It is necessary to first collect the current charging power of each charging robot for subsequent steps.

[0225] S92: Calculate the power difference between each robot based on the current charging power.

[0226] The battery capacity difference value refers to the absolute difference in the remaining battery capacity percentage between any two charging robots. By iterating through all robots and calculating the battery capacity difference between each pair, the battery capacity difference value between each robot can be obtained.

[0227] S93: Establish robot mutual assistance pairing relationships based on the difference in power levels.

[0228] Robot mutual assistance pairing refers to establishing a "one-to-one" or "one-to-many" mutual support partnership for robots within a charging area based on the principle of minimizing the difference in power consumption.

[0229] Prioritize pairing robots with similar battery levels (e.g., pairing a robot with 78% battery with one with 80% battery). The aim is to synchronize the battery consumption and recovery progress of both robots as much as possible during subsequent charging and upgrades, thereby establishing a cooperative robot pairing relationship and maintaining the long-term stability of the support structure. The pairing algorithm aims to minimize the average battery level difference across all pairings.

[0230] S94: Based on the robot mutual assistance pairing relationship, the paired robots are controlled to adjust their posture to a preset anti-tipping mutual assistance posture to form a stable support structure, and after the support structure is formed, the charging and upgrade process continues.

[0231] Anti-tipping mutual assistance postures refer to a set of pre-designed static or quasi-static body structures that allow two or more robots to lean against each other through contact of specific body parts, thereby enhancing overall stability. For example, two robots can stand face to face and lean forward slightly, so that their chests or shoulders gently touch; or stand back to back and lean back slightly, so that their backs support each other.

[0232] Once a robot cooperative pairing relationship is established, the system sends the specific joint angle target parameters for the anti-tipping cooperative posture to each pair (or group) of robots according to the pairing relationship. Upon receiving the instruction, the paired robots coordinate and synchronously adjust their joint angles to smoothly and controllably transition from the current posture to the target posture until physical contact occurs between the robots at preset contact points (such as chest, shoulder, and back), and a stable contact force is detected by force sensors or joint torque sensors, thus forming a stable mutually supporting structure. After confirming the stable establishment of the support structure, the paired robots, while maintaining this contact force, resume and continue their respective charging operations and background system upgrade processes. The system continuously monitors the magnitude and distribution of the contact force and makes fine adjustments as needed to maintain the stability of the support structure. The specific posture adjustment control, contact force detection, and maintenance fine-tuning strategies are designed by those skilled in the art based on the robot hardware and control capabilities, and will not be elaborated here.

[0233] Based on the same inventive concept, embodiments of the present invention provide a humanoid robot OTA automated upgrade system, comprising:

[0234] The data acquisition module is used to collect robot status information, OTA upgrade packages, upgrade self-test results, upgraded version information, real-time status parameters, joint motion status, sensor working status, current battery level, current robot position, robot posture information, weight distribution parameters, real-time posture data, number of charging robots, and current charging level.

[0235] A memory for storing a program that implements an OTA (Over-The-Air) automated upgrade method for a humanoid robot;

[0236] The processor is used to load and execute programs stored in memory.

[0237] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions within the scope of the present invention are within the protection scope of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principle of the present invention should also be considered within the protection scope of the present invention.

Claims

1. A method for OTA automated upgrade of a humanoid robot, characterized in that, include: Collect robot status information; Determine the target robot set based on robot state information; The system controls the preset cloud management platform to send batch upgrade tasks to the target robot set, and controls the robots to collect OTA upgrade packages through a secure channel and perform the installation and upgrade using a preset silent installation method. During the silent installation process, the robot's current battery level is collected; Determine whether the current battery level is below the preset upgrade maintenance threshold; If the current battery level is lower than the upgrade maintenance threshold, collect the current robot position; Based on the robot's current location, determine the nearest target charging area from a pre-set list of charging facility locations; Based on the current robot's position, an idle robot is identified, and the idle robot is controlled to move the current robot to the target charging area for charging, while the silent installation process is completed in the target charging area. After the installation and upgrade are completed, a preset self-test program will be run automatically to verify the core functions and collect the upgrade self-test results and the upgraded version information. When the upgrade self-test results meet the preset self-test requirements, the upgraded version information will be marked as a successful upgrade and reported to the cloud management platform. It also includes robotic handling methods: Collect robot posture information and weight distribution parameters of the robot to be transported; The robot's current orientation is determined based on its posture information; The optimal approach path for the idle robot is determined by combining the robot's current orientation, current position, and target charging area. The location of the handling support point is determined based on the weight distribution parameters; Generate robotic arm grasping trajectory parameters based on the location of the handling support point; The idle robot is controlled to perform a grasping operation based on the robotic arm's grasping trajectory parameters, and after the grasping is completed, it moves to the target charging area according to the optimal approach path; Also includes: Once the robot moves to the target charging area, its real-time posture data is collected. Based on real-time attitude data, determine whether the preset charging safety attitude conditions are met; When the charging safety posture conditions are not met, the posture adjustment angle is calculated based on real-time posture data and the charging safety posture conditions. Adjust the angle based on the attitude to generate attitude correction parameters; Based on attitude correction parameters, control the idle robot to perform attitude adjustment operations on the current robot; It also includes anti-tipping mutual assistance methods within the target charging area: The number of charging robots in the target charging area is collected. When the number of charging robots exceeds the preset mutual assistance standard, the current charging power of each charging robot is collected. Calculate the difference in power level between each robot based on the current charging power level; Establish robot pairing relationships based on differences in battery power; Based on the robot mutual assistance pairing relationship, the paired robots are controlled to adjust their posture to a preset anti-tipping mutual assistance posture to form a stable support structure, and then continue to perform the charging and upgrade process after the support structure is formed.

2. The method for OTA automated upgrade of a humanoid robot according to claim 1, characterized in that, Also includes: Based on robot state information, extract real-time task status, current physical posture, and environmental safety indicators; Select upgradable robots based on real-time task status; The selected upgradeable robots are integrated to obtain the initial set of robots; Based on the current physical posture and environmental safety indicators, upgradeable robots are screened a second time to identify robots that are in a safe posture and within a safe area. The robots after secondary screening are integrated to obtain the target robot set.

3. The method for OTA automated upgrade of a humanoid robot according to claim 1, characterized in that, The silent installation method includes: Local verification rules are determined based on OTA upgrade packages; Collect the robot's real-time status parameters; The local verification rules are compared with real-time status parameters to determine whether the preset silent installation conditions are met. When the conditions for silent installation are met, control the robot to enter the safety upgrade mode and perform the silent installation operation. If the conditions for silent installation are not met, the installation and upgrade will be performed using the preset alternating upgrade method.

4. The OTA automated upgrade method for a humanoid robot according to claim 3, characterized in that, The alternating upgrade method includes: The current task status is analyzed based on the robot's state information; Determine non-task critical functional modules based on the current task status; For non-mission-critical functional modules, generate phased upgrade tasks; Combine phased upgrade tasks and OTA upgrade packages to generate sub-module upgrade packages; Modular upgrade instructions are generated based on the submodule upgrade package; Control the robot to execute modular upgrade instructions and maintain the execution of core tasks during the upgrade process.

5. The OTA automated upgrade method for a humanoid robot according to claim 4, characterized in that, The control robot executes modular upgrade instructions including: Collect data on the robot's joint motion and sensor operating status; Idle joint subsets and idle sensor subsets are identified based on joint motion state and sensor operating state; Match and map the submodule upgrade package with the subsets of idle joints and idle sensors to determine the combination of upgrade tasks; Generate parallel loading instructions based on the upgrade task combination; The robot is controlled to simultaneously load and verify multiple sub-module upgrade packages based on parallel loading instructions. During the parallel upgrade process, the robot continuously monitors changes in joint motion and sensor operating status and dynamically adjusts the upgrade task combination.

6. A humanoid robot OTA automated upgrade system, characterized in that, include: The data acquisition module is used to collect robot status information, OTA upgrade packages, upgrade self-test results, and upgraded version information. A memory for storing a program that implements the OTA automated upgrade method for a humanoid robot as described in any one of claims 1 to 5; The processor is used to load and execute programs stored in memory.

Images