A method, system, and robot for upgrading multi-MCU programs

Abstract

This invention discloses a multi-MCU program upgrade method, system, and robot. Upon receiving an MCU upgrade command from a user, the system controls the robot's limb components to adjust its current posture to a preset stable posture and interrupts power supply to the load. Based on the upgrade priority, program upgrade data is sent sequentially to each MCU. After confirming the current MCU upgrade is complete and without errors, the next MCU upgrade is performed sequentially. By controlling the robot to enter a preset stable posture and cutting off power to non-core loads before the upgrade, the MCUs are solely responsible for the upgrade task, reducing the impact of load fluctuations on the upgrade. Simultaneously, the upgrade order of each MCU is coordinated before the upgrade, and during the upgrade of each MCU, collaborative linkage with other MCUs is maintained to avoid problems such as system command conflicts and posture loss of control during the upgrade process.

Description

Technical Field

[0001] This invention relates to the field of program update technology, and in particular to a method, system and robot for upgrading multi-MCU programs. Background Technology

[0002] With the rapid development of embodied intelligence, humanoid robots, quadruped robots, and other mobile intelligent robots, thanks to their ability to adapt to complex terrain, are increasingly being used in fields such as industrial inspection, disaster relief, and scientific research. The need for program stability and functional iteration of their core control units, including power management MCUs and payload management MCUs, is becoming increasingly urgent. In practical applications, intelligent robots often face scenarios such as changes in customer functional requirements (e.g., gait optimization, payload adaptation adjustment), and bug fixing in field conditions (e.g., power fluctuation adaptation issues in extreme environments). All of these require MCU program upgrades and updates.

[0003] Robot MCUs have distinct application-specific characteristics, and their program upgrades face unique challenges not present in ordinary equipment: First, MCU load fluctuates significantly, requiring the robot's posture to remain stable during the upgrade process to prevent joint lock-up or accidental power cut-off due to upgrade interruption; second, multiple MCUs work collaboratively, with intelligent robots typically equipped with multiple MCUs responsible for controlling different joints, power supplies, and loads. Upgrading only one MCU can easily affect the normal operation of other modules, leading to system-wide malfunctions. Existing technologies that utilize open interfaces for MCU program upgrades are mostly applicable to simple scenarios such as fixed equipment and consumer electronics, lacking adaptation design for the aforementioned unique challenges of intelligent mobile robots. Directly applying these solutions can result in problems such as loss of device posture control during the upgrade process, high upgrade failure rates, and system-wide malfunctions, failing to meet the reliable upgrade requirements of various robot types. Summary of the Invention

[0004] This invention addresses the shortcomings of existing technologies by providing a multi-MCU program upgrade method for upgrading the programs of multiple MCUs in a robot, comprising the following steps:

[0005] Upon receiving the MCU upgrade command sent by the user, the robot controls the movement of its limb components to adjust the current robot posture to a preset stable posture and interrupts the power supply to the load.

[0006] After sending upgrade instructions to each MCU and receiving upgrade ready signals from each MCU, the system queries a preset multi-MCU upgrade scheduling configuration, which includes the upgrade priority order of each MCU.

[0007] Based on the upgrade priority, program upgrade data is sent to each MCU in sequence. After confirming that the current MCU upgrade job is completed and there are no abnormalities, the next MCU upgrade job is performed in sequence. If an MCU upgrade fails, the subsequent MCU upgrades are paused and the currently failed MCU is transferred to the emergency backup area program, while the remaining MCUs to be upgraded retain their original normal programs. If all MCU upgrade jobs are completed, a system synchronization command is sent to each MCU, and the system is restarted after confirming that the status of each MCU is consistent.

[0008] Preferably, the MCU used for program upgrades in the robot includes a power management MCU for controlling the robot's power supply and multiple joint control MCUs for controlling different joints.

[0009] Preferably, upon receiving an MCU upgrade command from the user, the robot's limb components are controlled to move, adjusting the current robot posture to a preset stable posture and interrupting the load power supply. Specifically, this includes:

[0010] The system verifies the legitimacy of MCU program upgrade data sent from external terminals to adapt to the current robot operating conditions and stores it in a secure storage area.

[0011] The system detects whether the robot's current posture is in a preset stable posture and whether the current load is in an unloaded state. If the robot's current posture is not in a preset stable posture, the system controls the movement of the robot's limb components to adjust the robot's current posture to the preset stable posture. If the current load is not in an unloaded state, the system unloads the current non-core load or issues a load removal prompt message.

[0012] Preferably, the multi-MCU program upgrade method also includes:

[0013] If the robot is unable to adjust its current posture to a preset stable posture or is unable to unload non-core loads, it will be prevented from entering the full MCU upgrade mode, which is configured to upgrade the power management MCU and the joint control MCUs.

[0014] If the robot cannot adjust its current posture to a preset stable posture but its current state meets the minimum safe state, an upgrade command is sent to each of the first-category MCUs that do not directly participate in joint movement and posture balance, and the upgrade command is refused to be sent to each of the second-category MCUs that participate in joint movement and posture balance. The first-category MCUs include power management MCUs or communication and status monitoring MCUs, and the second-category MCUs include each joint control MCU that controls the movement or posture balance of the robot's limb components.

[0015] Preferably, the minimum safe configuration is set such that the robot body tilt angle is less than a preset angle, the power supply is stable, the joint positions are locked, and the current load state is free from overload.

[0016] Preferably, the upgrade priority is configured such that the power management MCU is upgraded before each joint control MCU. Specifically, sending program upgrade data to each MCU based on this priority order includes: first sending the corresponding program upgrade data to the power management MCU; and then, after confirming that the power management MCU upgrade is complete and without abnormalities, sending the corresponding program upgrade data to each joint control MCU in sequence. Furthermore, while executing a program upgrade for one joint control MCU, a pause linkage command is sent to other joint control MCUs. This pause linkage command is configured to prevent the joint control MCU receiving the command from driving the joint motor to perform movement.

[0017] Preferably, the MCU is configured to automatically erase the upgrade flag bit after receiving the upgrade command, jump to the Bootloader program and reside there, and feed back an upgrade ready signal; and after the upgrade operation is completed and there are no abnormalities, it rewrites the upgrade flag bit after confirming that the status of each MCU is consistent based on the received system synchronization command.

[0018] Preferably, the multi-MCU program upgrade method also includes:

[0019] If the robot application fails to start due to a malfunction, an emergency upgrade trigger command is sent to the MCU, and the robot limb components are controlled to perform a posture unlocking action. The posture unlocking action is used to drive the robot's joints to a relaxed, unlocked state.

[0020] After detecting that an MCU needs to be upgraded and has returned an upgrade ready signal, the upgrade priority order of each MCU to be upgraded is generated based on the preset multi-MCU upgrade scheduling configuration.

[0021] This invention also discloses a multi-MCU program upgrade system, comprising:

[0022] The robot control module is used to control the movement of the robot's limb components after receiving the MCU upgrade command sent by the user, so as to adjust the current robot posture to a preset stable posture and interrupt the power supply to the load.

[0023] The scheduling management module is used to send upgrade instructions to each MCU and, after receiving the upgrade ready signal from each MCU, query the preset multi-MCU upgrade scheduling configuration, which includes the upgrade priority order of each MCU.

[0024] The program upgrade module is used to send program upgrade data to each MCU in sequence according to the upgrade priority. After confirming that the current MCU upgrade job is completed and there are no abnormalities, the next MCU upgrade job is performed in sequence. If an MCU upgrade fails, the subsequent MCU upgrades are suspended and the currently failed MCU is transferred to the emergency backup area program, while the remaining MCUs to be upgraded retain their original normal programs. If all MCU upgrade jobs are completed, a system synchronization command is sent to each MCU, and the system is restarted after confirming that the status of each MCU is consistent.

[0025] The present invention also discloses a robot, including a body on which robot limb components are installed, a host computer and a plurality of MCUs controlling the various components of the robot are installed on the body, the host computer includes a controller and a memory, the memory is used to store computer programs executable by the processor, wherein the processor is configured to execute the computer programs in the memory to implement the multi-MCU program upgrade method as described above.

[0026] This invention discloses a multi-MCU program upgrade method, system, and robot. Upon receiving an MCU upgrade command from a user, the robot controls its limb components to adjust its current posture to a preset stable posture and interrupts power supply to the load. Based on the upgrade priority, program upgrade data is sent sequentially to each MCU. Only after confirming the current MCU upgrade is complete and without errors is the next MCU upgrade performed. By controlling the robot to enter a preset stable posture and cutting off power to non-core loads before the upgrade, the MCUs are solely responsible for the upgrade task, reducing the impact of load fluctuations on the upgrade. Simultaneously, the upgrade order of each MCU is coordinated before the upgrade, and during the upgrade of each MCU, collaborative linkage with other MCUs is maintained, avoiding problems such as system command conflicts and posture loss of control during the upgrade process.

[0027] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0028] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this application, illustrate exemplary embodiments of the invention and, together with their description, serve to explain the invention and do not constitute an undue limitation thereof. In the drawings:

[0029] Figure 1 This is a schematic diagram of the communication connection between a robot SOC and multiple MCUs disclosed in an embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram illustrating the specific process of a multi-MCU program upgrade method disclosed in an embodiment of the present invention.

[0031] Figure 3This is a schematic diagram of the specific process of step S1 disclosed in an embodiment of the present invention.

[0032] Figure 4 This is a schematic diagram of the structure of a multi-MCU program upgrade system disclosed in an embodiment of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0034] Unless otherwise defined, the technical or scientific terms used herein shall have the ordinary meaning as understood by one of ordinary skill in the art to which this invention pertains. The terms “first,” “second,” and similar terms used in the specification and claims of this patent application do not indicate any order, quantity, or importance, but are merely used to distinguish different components. Similarly, the terms “an” or “a” and similar terms do not indicate a limitation of quantity, but rather indicate the presence of at least one.

[0035] This embodiment discloses a multi-MCU program upgrade method for upgrading the programs of multiple MCUs of a robot. The robot can be a quadruped robot, a humanoid robot, or other intelligent robots. The following embodiment will use a quadruped robot as an example for detailed explanation; however, the content of the following embodiment can be applied to humanoid robots and other types of intelligent machines and devices.

[0036] In the following embodiments, based on an application scenario of a quadruped robot, such as one SOC host computer (e.g., RK3588), 12 joint control MCUs, and one power management MCU, the implementation process of the MCU program upgrade method is described in detail. In the design of the quadruped robot, such as... Figure 1 As shown, the SOC host computer, as the core scheduling unit, establishes communication connections with external devices such as computers and tablets through network ports and serial ports. On the other hand, it establishes data interaction links with 13 MCUs, namely 12 joint control MCUs and 1 power management MCU, through the EtherCAT bus. The SOC host computer can be equipped with built-in upgrade scheduling modules, attitude control modules, load management modules, etc., so as to realize attitude locking, load unloading, and multi-MCU collaborative scheduling during the upgrade process, solving the unique problems of robot upgrade.

[0037] Unlike ordinary equipment, a robot's MCU does not operate in isolation but is closely linked to joint motors, sensors, and power modules. Therefore, the MCU upgrade program can first be stored in a secure storage area on the host computer to prevent data loss during field operations. The host computer then completes preparatory work such as attitude calibration and load detection before the upgrade. Upgrading the power management MCU and all joint control MCUs is only permitted when the robot is in a horizontal, stationary posture (tilt angle ≤ 5°), all joints are in their normal positions, and non-core loads are completely unloaded. If only stable power supply is met but the attitude / load does not meet safety conditions, only the power management MCU can be upgraded, and the joint control MCU upgrade is prohibited to avoid attitude loss of control caused by the upgrade. After completing the preparatory work, the upgrade program is then transmitted to the target MCU via the EtherCAT bus to avoid affecting the overall stability of the robot during the upgrade process.

[0038] In this embodiment, to meet the safety upgrade requirements of the robot, the MCU adopts a four-region Flash storage architecture, and the functional optimization design of each region is as follows:

[0039] Bootloader program area: In addition to the regular startup and guidance functions, it adds load status monitoring, power supply voltage monitoring, and posture verification interfaces. It can read robot joint load and power supply voltage data in real time. If an abnormality is detected, such as voltage fluctuation exceeding ±10% or load sudden change, the upgrade will be paused immediately and an emergency mechanism will be triggered. At the same time, it has a built-in anti-interference communication protocol to support bidirectional status feedback with the SOC host computer.

[0040] APP Program Area: Stores the MCU's main application program, such as joint control algorithms, power management logic, and upgrade status flags. The upgrade status flags include adaptation fields such as "attitude lock complete" and "load unloading complete" to ensure that upgrades are only initiated in a safe state.

[0041] Parameter configuration area: In addition to storing version records and verification values, it also contains robot posture calibration parameters. If an anomaly occurs during the upgrade process, the parameters can be quickly recalled to restore the device posture.

[0042] Emergency Backup Area: This area is specifically designed to store the previously working APP program and posture calibration parameters. In the event of an upgrade failure or interruption, the Bootloader can directly jump to this area to start the program, preventing issues such as robot joint lock-up and inability to stand properly, thus resolving safety hazards associated with robot upgrades.

[0043] In this embodiment, as Figure 2 As shown, the multi-MCU program upgrade method may specifically include the following steps.

[0044] Step S1: After receiving the MCU upgrade command sent by the user, control the movement of the robot's limb components to adjust the current robot posture to a preset stable posture and interrupt the load power supply. The MCU used for program upgrade in the robot may include a power management MCU for controlling the robot's power supply and multiple joint control MCUs for controlling different joints.

[0045] Specifically, the user connects the external terminal to the quadruped robot's open communication interface, such as a network port, using an anti-interference shielded cable to ensure a stable communication link. The external terminal transmits the MCU upgrade firmware, including joint control optimization algorithms and power adaptation logic, adapted to the quadruped robot's operating conditions, to the SOC host computer. The host computer performs firmware verification, including software and hardware version matching, firmware integrity, and device compatibility verification. The SOC host computer sends a pre-check command to detect whether the robot's current posture meets the upgrade requirements. If it is tilted, a posture lock command is sent to control the robot to retract its limbs and enter a prone posture, i.e., the preset stable posture. At the same time, the power supply to non-core loads, such as joint motor drives and auxiliary sensors, is cut off, leaving only the MCU, communication link, and core power supply powered. The preset stable posture can be pre-configured according to the robot's own shape; for example, the quadruped robot is in a prone posture in this embodiment, while the humanoid robot can be in a squatting posture, ensuring shape stability during the robot upgrade process.

[0046] In this embodiment, as Figure 3 As shown, step S1 may also include the following:

[0047] Step S11: Verify the legality of the MCU program upgrade data sent by the external terminal to adapt to the current robot operating conditions, and store it in the secure storage area.

[0048] Step S12: Detect whether the robot's current posture is in a preset stable posture and whether the current load is in an unloaded state; if the robot's current posture is not in a preset stable posture, control the movement of the robot's limb components to adjust the robot's current posture to the preset stable posture; if the current load is not in an unloaded state, unload the current non-core load or issue a load removal prompt message.

[0049] Because mobile intelligent robots such as quadruped robots need to consider the impact of MCU load changes on upgrades, for example, if a quadruped robot is upgraded while still powered on, such as during an emergency upgrade in the field, the MCU must simultaneously handle the upgrade task, joint posture maintenance, and power supply stability control. Load fluctuations can easily cause the upgrade program to freeze or be interrupted, and may even lead to safety hazards such as joint locking or robot tipping over. Therefore, this step involves controlling the robot to enter a safe posture, such as a prone position, and cutting off power to non-core loads before the upgrade, so that the MCU only handles the upgrade task, reducing the impact of load fluctuations on the upgrade. At the same time, during the upgrade process, the SOC host computer monitors the load status in real time. If a sudden change in load occurs due to an emergency, the upgrade is immediately paused and the joint posture is locked to prevent the robot from tipping over.

[0050] Step S2: Send upgrade instructions to each MCU and, after receiving upgrade ready signals from each MCU, query the preset multi-MCU upgrade scheduling configuration, which includes the upgrade priority order of each MCU.

[0051] Specifically, upon receiving the upgrade command, each MCU automatically erases the upgrade flag, actively jumps to the Bootloader program and resides there, and sends back an upgrade ready signal. The SOC host computer initiates the multi-MCU upgrade scheduling process, which can be performed in the order of power management MCU first, followed by joint control MCU; in the quadruped robot scenario of this embodiment, the upgrade priority can also be ordered as power management MCU, left front joint control MCU, right front joint control MCU, left rear joint control MCU, and right rear joint control MCU.

[0052] In this embodiment, for scenarios where the robot cannot enter a safe posture under special circumstances, this embodiment supports hierarchical priority upgrades for each MCU based on the current posture or load status and the core problem to be solved. Specifically, it may include the following steps.

[0053] Step S101: If the robot cannot adjust its current posture to a preset stable posture or cannot unload non-core loads, then it is prevented from entering the full MCU upgrade mode. The full MCU upgrade mode is configured to upgrade the power management MCU and the joint control MCU.

[0054] Step S102: If the robot cannot adjust its current posture to a preset stable posture but the current robot state meets the minimum safe state, then an upgrade command is sent to each of the first category MCUs that do not directly participate in joint movement and posture balance, and the upgrade command is refused to be sent to each of the second category MCUs that participate in joint movement and posture balance. The first category MCUs include power management MCUs or communication and status monitoring MCUs, and the second category MCUs include each joint control MCU that controls the movement or posture balance of the robot's limb components.

[0055] The minimum safe configuration is defined as follows: the robot body tilt angle is less than a preset angle, the power supply is stable, the positions of each joint are locked, and the current load state is free from overload.

[0056] Specifically, the tiered priority upgrade configuration can be set as follows: If there are no extreme abnormal scenarios such as a body tilt angle of 15°~30° or joints not returning to their original position, meaning there is no direct risk of tipping over or overload, then a full upgrade of all MCUs is prohibited. Instead, priority is given to upgrading the MCUs that match the problem to be solved. For example, for power management bugs, only the power management MCU is upgraded; for joint jamming, only the corresponding joint control MCU is upgraded. During the upgrade, the SOC host computer sends a local attitude lock command to lock the joint corresponding to the target MCU to its current position, while the other joints maintain a supporting posture. Only the "problem-fixing module" is allowed to be upgraded; upgrades to programs that are prone to sudden load changes, such as global gait and power control, are prohibited. During the upgrade process, the SOC host computer monitors the joint attitude and current associated with the target MCU in real time. If abnormalities such as positional shift or sudden current increase occur, the upgrade is immediately paused and the program is restored to its state before the upgrade. This solves the core problem while avoiding the risk of robot attitude loss of control, meeting the needs of emergency upgrades in the field while ensuring the safety of the robot's attitude and structure.

[0057] In this embodiment, step S2 may further include the following power-on emergency upgrade. This method addresses scenarios where the quadruped robot's APP program fails to start normally due to field conditions such as impact damage, and includes a posture unlocking and emergency recovery mechanism, as detailed below.

[0058] If the robot application fails to start due to a malfunction, an emergency upgrade trigger command is sent to the MCU, and the robot limb components are controlled to perform a posture unlocking action. The posture unlocking action is used to drive the robot's joints into a relaxed, unlocked state.

[0059] Specifically, the first step is to perform power-on startup and anti-brick detection. After the device is powered on, all MCUs prioritize starting the Bootloader program and remain in a resident state for 0.5 seconds by default. During this period, if the SOC host computer sends a pause command, i.e., an emergency upgrade trigger command, the MCU immediately erases the upgrade flag bit, keeps it in the Bootloader program, and sends back an emergency upgrade ready signal. At the same time, the Bootloader automatically executes the posture unlocking program to ensure that the robot's limbs are in a relaxed state and to avoid joint lock-up.

[0060] After detecting that an MCU needs to be upgraded and has returned an upgrade ready signal, the upgrade priority order of each MCU to be upgraded is generated based on the preset multi-MCU upgrade scheduling configuration.

[0061] Specifically, after the anti-brick detection is completed, the Bootloader checks the upgrade flag status. If the flag exists, there is no upgrade requirement. The Bootloader calls the attitude calibration parameters in the parameter configuration area, guides the MCU to start the APP program, and the robot enters normal working state after completing the attitude self-check. If the flag does not exist, there is an upgrade requirement. The Bootloader sends a feedback to wait for the upgrade signal, and the SOC host computer starts the upgrade scheduling process, prioritizing the upgrade of the power management MCU.

[0062] Step S3: Based on the upgrade priority, program upgrade data is sent to each MCU in sequence. After confirming that the current MCU upgrade job is completed and there are no abnormalities, the next MCU upgrade job is performed in sequence. If an MCU upgrade fails, the subsequent MCU upgrades are paused and the currently failed MCU is transferred to the emergency backup area program, while the remaining MCUs to be upgraded retain their original normal programs. If all MCU upgrade jobs are completed, a system synchronization command is sent to each MCU, and the system is restarted after confirming that the status of each MCU is consistent.

[0063] To address signal attenuation under the sealed enclosure and electromagnetic interference in the field, a mechanism of segmented transmission, CRC-32 dual verification, and adaptive retransmission is adopted. The upgrade firmware is divided into multiple 1KB segmented data packets, each carrying a unique identifier, checksum, and transmission timestamp. After the SOC host computer sends the data packet, it waits for confirmation feedback from the target MCU. If the target MCU does not receive feedback within the timeout period, it automatically retransmits, thus adapting to signal attenuation under the sealed enclosure and electromagnetic interference in the field. After the bootloader receives the verified data packet, it immediately writes it to the APP program area of ​​the Flash memory. At the same time, it monitors the MCU power supply voltage, lithium battery total voltage, MCU CPU utilization, Flash write time, and other load statuses in real time. If any of the above parameters continuously triggers the threshold, or if a single high-risk anomaly such as a sudden voltage change or unloaded load is detected, the upgrade is immediately paused, and the system jumps to the emergency backup area to start the previous version of the program. The SOC simultaneously controls the robot's posture lock to ensure that the robot can stand normally.

[0064] After all data packets have been transmitted and verified, the Bootloader sends an upgrade completion feedback to the host computer. The host computer then instructs the MCU to write the upgrade flag and save the attitude calibration parameters. Subsequently, the Bootloader guides the robot to the APP program, and the robot enters normal working state after completing the attitude self-check.

[0065] In this embodiment, the upgrade priority is configured such that the power management MCU is upgraded before each joint control MCU. This step S3 may include the following.

[0066] The corresponding program upgrade data is sent to the power management MCU first. After confirming that the power management MCU upgrade operation is completed and there are no abnormalities, the corresponding program upgrade data is sent to each joint control MCU in sequence. When executing the program upgrade process of one joint control MCU, a pause linkage command is sent to other joint control MCUs. The pause linkage command is configured to prevent the joint control MCU that receives the command from driving the joint motor to perform movement.

[0067] Specifically, based on the preset upgrade priority, the host computer first sends the upgrade firmware to the power management MCU. After the power management MCU upgrade is completed and confirmed to be without any abnormalities, the joint control MCUs are upgraded in sequence. When upgrading a single joint control MCU, a pause linkage command is sent to other joint control MCUs to prevent them from executing motion commands and avoid linkage failure.

[0068] In this embodiment, the upgrade scheduling module of the SOC host computer performs upgrade tasks sequentially according to the preset upgrade priority order: power management MCU, left front joint control MCU, right front joint control MCU, left rear joint control MCU, and right rear joint control MCU. The host computer first sends the upgrade firmware to the power management MCU. After completing the power management MCU upgrade and confirming there are no abnormalities, it then upgrades each joint control MCU sequentially. When upgrading a single joint control MCU, a pause linkage command is sent to other joint control MCUs to prevent them from executing movement commands and avoid linkage failures. Preferably, a pause linkage command can also be sent to all other MCUs, including the power management MCU, to prevent them from executing joint movement, power adjustment, and other commands. After a single MCU upgrade is completed, a status synchronization command is sent. The upgrade process for the next MCU is started only after other MCUs confirm there are no abnormalities, avoiding command conflicts.

[0069] In this embodiment, after the bootloader of each MCU receives the firmware data packet, it performs multiple verifications and real-time writing operations, which is consistent with the process in the power-on emergency upgrade. If the upgrade of a certain MCU fails, the host computer immediately suspends the overall upgrade process, triggers the fault rollback, and the MCU jumps to the emergency backup area program. Other MCUs maintain their original normal programs to ensure that the robot can leave the work site normally.

[0070] In another preferred embodiment, when faced with a scenario where the MCU upgrade fails, differentiated processing can be performed based on the MCU functional association level and the robot's current posture. By judging the degree of association between each MCU, a fault rollback logic is formed that requires rollback for strong associations, pauses for medium associations, and does not process for weak associations. The specific content is as follows.

[0071] Upon receiving feedback of an MCU upgrade failure, the association level information of each MCU in the upgrade scheduling configuration is obtained. The information of the MCUs that have completed the upgrade is determined according to the upgrade priority sorting. Based on the association level information of each MCU, the association level between each MCU that has completed the upgrade and the MCU that failed the upgrade is determined.

[0072] If any of the upgraded MCUs has a strongly associated MCU with the currently failed upgrade MCU, the program for that strongly associated MCU will be rolled back to the version before the upgrade. If any of the upgraded MCUs has a medium-level associated MCU with the currently failed upgrade MCU, the upgrade for that associated MCU will be paused. If any of the upgraded MCUs has a weak-level associated MCU with the currently failed upgrade MCU, no action will be taken on it.

[0073] In a specific embodiment, during the program upgrade of multiple MCUs of a quadruped robot, if an upgrade failure message is received for one MCU, the system determines whether to perform a rollback operation on the MCUs that have already been upgraded and the operation on the MCUs that are to be upgraded, based on the association between the MCU and other MCUs that have been upgraded and those that are to be upgraded later. Specifically, this may include the following:

[0074] Step S201: If an upgrade failure message for an MCU is received, obtain the information of the failed MCU.

[0075] Step S202: If the MCU that failed to upgrade is a joint control MCU, then determine whether there are other joint control MCUs that have been successfully upgraded before the joint control MCU.

[0076] In step S203, if there are no other successfully upgraded joint control MCUs, the upgraded power management MCU will not be rolled back, but all subsequent upgrades of joint control MCUs will be suspended until the current failed upgrade MCU is repaired and upgraded successfully.

[0077] Specifically, the power management MCU and the joint control MCU are linked. If the power management MCU upgrade is successful, but the upgrade of the left front joint control MCU fails, the power management MCU will not be rolled back, but all joint control MCU upgrades will be suspended to ensure stable power supply.

[0078] For example, if the upgrade of the left front joint control MCU fails, the SOC only sends a pause command to the other joint control MCUs, namely right front / left rear / right rear, to prevent them from starting the upgrade; the power management MCU keeps the upgraded version, and the power supply logic does not affect the basic standing position; however, the power output power is limited to ≤50% to reduce load fluctuations; the upgrade of the other joint control MCUs will only continue after the left front joint control MCU is repaired and upgraded successfully; if the left front joint control MCU cannot be repaired, the power MCU can use the upgraded version independently, that is, the connection is not completely unified.

[0079] Step S204: If other successfully upgraded joint control MCUs already exist, determine whether they belong to the same group of joint control MCUs. If they are in the same group, roll them back to the previous version. If they are not in the same group, do not roll back. For other joint control MCUs awaiting upgrade, pause the upgrade process until the currently failed MCU is repaired and the upgrade is successful. Joint control MCUs located on the same side of the quadruped robot are considered to be in the same group. For example, the left and right front joint control MCUs, which are both front leg joints, are in the same group; similarly, the left and right rear joint control MCUs, which are both rear leg joints, are in the same group.

[0080] Specifically, for ipsilateral joint control MCUs that are strongly associated, i.e., for the two front leg joints that are strongly associated, if the strong association MCU upgrade fails (e.g., the left front joint control MCU succeeds but the right front joint control MCU fails), the successfully upgraded strong association MCU (i.e., the left front joint control MCU) must be rolled back to the previous version to ensure that the versions of the two front leg joints are consistent.

[0081] For example, if the upgrade of the right anterior joint control MCU fails, the SOC immediately sends a "strong association rollback command" to the left anterior joint control MCU; the left anterior MCU triggers the bootloader, jumps to the Flash emergency backup area, and restores the APP version before the upgrade; after the rollback is completed, the left and right anterior joint control MCUs simultaneously send a "version consistency confirmation" to the SOC, suspending all upgrade tasks for the front legs; the SOC records the reason for the failure, such as right anterior MCU communication timeout or Flash write error, and prompts "the front leg joint version needs to be unified, and the upgrade will be carried out again after the fault is repaired".

[0082] If the MCUs controlling the opposite joints are weakly associated, and the upgrade of the weakly associated MCU fails (e.g., the left anterior joint control MCU succeeds but the right posterior joint control MCU fails), the successfully upgraded left anterior joint control MCU will not be rolled back; only the upgrade of the right posterior joint control MCU will be paused, and the upgrades of the remaining MCUs will continue according to their original priorities.

[0083] For example, if the upgrade of the right rear joint control MCU fails, the SOC will mark "right rear upgrade failed", but the left front joint control MCU will remain in the upgraded version. The version difference between the left and right rear joint control MCUs will not affect the robot's basic postures, such as left front support and right rear pause. After the right rear joint control MCU is repaired, it can be upgraded separately without adjusting the version of the left front joint control MCU.

[0084] By using the above method, after one MCU upgrade fails, other MCUs can be selectively rolled back or maintained based on the degree of correlation between different MCUs, which effectively improves the efficiency and reliability of MCU upgrades.

[0085] The MCU is configured to automatically erase the upgrade flag bit after receiving the upgrade command, jump to the Bootloader program and stay there, and send back an upgrade ready signal; and after the upgrade operation is completed and there are no abnormalities, it will rewrite the upgrade flag bit after confirming that the status of each MCU is consistent based on the received system synchronization command.

[0086] After all MCUs have been upgraded, the host computer sends a system synchronization command. Once each MCU confirms that its status is consistent, it writes the upgrade flag. Subsequently, the system automatically restarts, each MCU starts the new version of the APP program, and the robot returns to normal working status after completing posture calibration.

[0087] The multi-MCU program upgrade method disclosed in the above embodiments controls the robot to enter a preset stable posture and cuts off the power supply to non-core loads before the upgrade, so that the MCUs only undertake the upgrade task, reducing the impact of load fluctuations on the upgrade. At the same time, the upgrade order of each MCU is coordinated before the upgrade, and the MCUs maintain coordinated linkage with other MCUs during the upgrade process, avoiding problems such as system command conflicts and posture loss of control during the upgrade process.

[0088] In another embodiment, such as Figure 4 As shown, a multi-MCU program upgrade system is also disclosed, including a robot control module 1, a scheduling management module 2, and a program upgrade module 3. The robot control module 1, upon receiving an MCU upgrade command from a user, controls the movement of the robot's limb components to adjust the current robot posture to a preset stable posture and interrupts the load power supply. The scheduling management module 2 sends upgrade commands to each MCU and, upon receiving upgrade ready signals from each MCU, queries a preset multi-MCU upgrade scheduling configuration, which includes the upgrade priority order of each MCU. The program upgrade module 3 sends program upgrade data to each MCU sequentially based on the upgrade priority order. After confirming that the current MCU upgrade operation is complete and without errors, it proceeds to the next MCU upgrade operation. If an MCU upgrade fails, subsequent MCU upgrades are paused, and the currently failed MCU is transferred to the emergency backup program, while the remaining MCUs awaiting upgrade maintain their original normal programs. If all MCU upgrade operations are completed, a system synchronization command is sent to each MCU, and the system is restarted after confirming that the states of each MCU are consistent.

[0089] The functions of the multi-MCU program upgrade system described above basically correspond to the steps of the multi-MCU program upgrade system method disclosed in the previous embodiments. Therefore, they will not be described in detail here. For details, please refer to the embodiments of the multi-MCU program upgrade system method disclosed in the previous embodiments. It should be noted that the embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other.

[0090] In another embodiment, a robot is also disclosed, comprising a body on which robot limb components are mounted. A host computer and multiple microcontrollers (MCUs) controlling the various components of the robot are mounted on the body. The host computer includes a controller and a memory, the memory storing computer programs executable by the processor. The processor is configured to execute the computer programs in the memory to implement the multi-MCU program upgrade method disclosed in various embodiments. The robot can be a quadruped robot, a humanoid robot, a wheeled robot, or other types of intelligent robots.

[0091] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

[0092] In summary, the above description is only a preferred embodiment of the present invention. All equivalent changes and modifications made within the scope of the claims of the present invention should be covered by the present invention.

Claims

1. A method for upgrading the program of multiple MCUs in a robot, characterized in that, Includes the following steps: Upon receiving the MCU upgrade command sent by the user, the robot controls the movement of its limb components to adjust the current robot posture to a preset stable posture and interrupts the power supply to the load; the preset stable posture is a posture pre-configured according to the robot's own shape to ensure the stability of the robot's shape during the upgrade process; After sending upgrade instructions to each MCU and receiving upgrade ready signals from each MCU, the system queries a preset multi-MCU upgrade scheduling configuration, which includes the upgrade priority order of each MCU. Based on the upgrade priority, program upgrade data is sent to each MCU in sequence. After confirming that the current MCU upgrade job is completed and there are no abnormalities, the next MCU upgrade job is then performed in sequence. If an MCU upgrade fails, subsequent MCU upgrades will be paused and the currently failed MCU will be redirected to the emergency backup program, while the remaining MCUs awaiting upgrade will retain their original normal programs; if all MCU upgrades are completed, a system synchronization command will be sent to each MCU, and the system will be restarted after confirming that the status of each MCU is consistent. If the robot is unable to adjust its current posture to a preset stable posture or is unable to unload non-core loads, it will be prevented from entering the full MCU upgrade mode, which is configured to upgrade the power management MCU and the joint control MCUs. If the robot cannot adjust its current posture to a preset stable posture, but the current robot state meets the minimum safe state, which is that the robot body tilt angle is less than a preset angle, the power supply is stable, the joint positions are locked, and the current load state is without overload, then an upgrade command is sent to each of the first category MCUs that do not directly participate in joint movement and posture balance, and an upgrade command is refused to be sent to each of the second category MCUs that participate in joint movement and posture balance. The first category MCUs include power management MCUs or communication and status monitoring MCUs, and the second category MCUs include each joint control MCU that controls the movement or posture balance of the robot's limb components.

2. The multi-MCU program upgrade method according to claim 1, characterized in that: The MCUs used for program upgrades in robots include a power management MCU for controlling the robot's power supply and multiple joint control MCUs for controlling different joints.

3. The multi-MCU program upgrade method according to claim 2, characterized in that, Upon receiving the MCU upgrade command from the user, the robot controls the movement of its limb components to adjust the current robot posture to a preset stable posture and interrupts the power supply to the load. Specifically, this includes: The system verifies the legitimacy of MCU program upgrade data sent from external terminals to adapt to the current robot operating conditions and stores it in a secure storage area. The system detects whether the robot's current posture is in a preset stable posture and whether the current load is in an unloaded state. If the robot's current posture is not in a preset stable posture, the system controls the movement of the robot's limb components to adjust the robot's current posture to the preset stable posture. If the current load is not in an unloaded state, the system unloads the current non-core load or issues a load removal prompt message.

4. The multi-MCU program upgrade method according to claim 3, characterized in that, The upgrade priority order is configured such that the power management MCU is upgraded before each joint control MCU. Specifically, the program upgrade data is sent to each MCU sequentially based on this upgrade priority order, including: The corresponding program upgrade data is sent to the power management MCU first. After confirming that the power management MCU upgrade operation is completed and there are no abnormalities, the corresponding program upgrade data is sent to each joint control MCU in sequence. When executing the program upgrade process of one joint control MCU, a pause linkage command is sent to other joint control MCUs. The pause linkage command is configured to prevent the joint control MCU that receives the command from driving the joint motor to perform movement.

5. The multi-MCU program upgrade method according to any one of claims 1-4, characterized in that: The MCU is configured to automatically erase the upgrade flag bit after receiving the upgrade command, jump to the Bootloader program and reside there, and feed back an upgrade ready signal; and after the upgrade operation is completed and there are no abnormalities, it rewrites the upgrade flag bit after confirming that the status of each MCU is consistent based on the received system synchronization command.

6. The multi-MCU program upgrade method according to claim 4, characterized in that, Also includes: If the robot application fails to start due to a malfunction, an emergency upgrade trigger command is sent to the MCU, and the robot limb components are controlled to perform a posture unlocking action. The posture unlocking action is used to drive the robot's joints to a relaxed, unlocked state. After detecting that an MCU needs to be upgraded and has returned an upgrade ready signal, the upgrade priority order of each MCU to be upgraded is generated based on the preset multi-MCU upgrade scheduling configuration.

7. A multi-MCU program upgrade system, characterized in that, include: The robot control module is used to control the movement of the robot's limb components after receiving the MCU upgrade command sent by the user, so as to adjust the current robot posture to a preset stable posture and interrupt the power supply to the load; the preset stable posture is a posture pre-configured according to the robot's own shape to ensure the stability of the robot's shape during the upgrade process. The scheduling management module is used to send upgrade instructions to each MCU and, after receiving the upgrade ready signal from each MCU, query the preset multi-MCU upgrade scheduling configuration, which includes the upgrade priority order of each MCU. The program upgrade module is used to send program upgrade data to each MCU in sequence based on the upgrade priority, and then proceed to the next MCU upgrade operation in sequence after confirming that the current MCU upgrade operation is completed and there are no abnormalities. If an MCU upgrade fails, subsequent MCU upgrades are paused, and the currently failed MCU is redirected to the emergency backup program, while the remaining MCUs awaiting upgrade maintain their original normal programs. If all MCU upgrades are completed, a system synchronization command is sent to each MCU, and the system is restarted after confirming that the status of each MCU is consistent. This is also used to prevent the robot from entering the full MCU upgrade mode when the robot cannot adjust its current posture to a preset stable posture or cannot unload non-core loads. The full MCU upgrade mode is configured to upgrade the programs of both the power management MCU and each joint control MCU. When the robot cannot adjust its current posture to a preset stable posture but the current robot state meets the minimum safe state, the minimum safe state is that the robot body tilt angle is less than a preset angle, the power supply is stable, the joint positions are locked, and the current load state is without overload. Upgrade commands are sent to each of the first category MCUs that do not directly participate in joint movement and posture balance, and upgrade commands are refused to be sent to each of the second category MCUs that participate in joint movement and posture balance. The first category MCUs include power management MCUs or communication and status monitoring MCUs, and the second category MCUs include each of the joint control MCUs that control the movement or posture balance of the robot's limb components.

8. A robot, characterized in that: The system includes a body on which robot limb components are mounted, and a host computer and multiple MCUs for controlling the various components of the robot are mounted on the body. The host computer includes a controller and a memory, the memory being used to store a processor-executable computer program, wherein the processor is configured to execute the computer program in the memory to implement the multi-MCU program upgrade method as described in any one of claims 1-6.

Images