Robot fault processing method, robot and server

Abstract

This application provides a robot fault handling method, a robot, and a server. The robot fault handling method is applied to a robot, which includes a processing module. The processing module includes a microcontroller and an application processor. The microcontroller is used to check the hardware heartbeat signal of the application processor. The application processor is used to divide each application function module into a mutually isolated processing resource sandbox. The method includes: determining the fault type of the current fault; and adopting a processing strategy corresponding to the fault type based on the fault type.

Description

Technical Field

[0001] This invention relates to the field of robotics, and in particular to a robot fault handling method, a robot, and a server. Background Technology

[0002] In the actual operation of security patrol robots, such as under the Result as a Service (RaaS) business model, robots often face complex problems such as extreme harsh outdoor environments, network outages, sensor vibration and aging, and the security of controlled commercial assets. Existing patrol robot monitoring solutions often rely on a single polling heartbeat, lacking in-depth edge-side self-checking and hardware-level isolation and self-healing capabilities. When a robot enters a suspended state due to software crashes or hardware transient failures, it often requires manual on-site physical reset, resulting in extremely high maintenance costs. Existing remote locking control mechanisms often directly cut off the power or forcibly lock the driver, which can easily lead to secondary safety accidents such as uncontrolled landslides and collisions with pedestrians in public and semi-structured scenarios (such as bus stops, office buildings, and park ramps).

[0003] Therefore, how to adopt reasonable handling methods for different faults to meet the needs of different fault scenarios, thereby improving the robustness of robots and enhancing user experience, is an urgent technical problem to be solved. Summary of the Invention

[0004] This disclosure provides a robot fault handling method, a robot, and a server.

[0005] According to a first aspect of the present disclosure, a robot fault handling method is provided, applied to a robot, the robot including a processing module, the processing module including a microcontroller and an application processor, the microcontroller being used to check the hardware heartbeat signal of the application processor; the application processor being used to divide each application function module into mutually isolated processing resource sandboxes, the method comprising:

[0006] Determine the type of the current fault;

[0007] Based on the fault type, a processing strategy corresponding to the fault type is adopted.

[0008] In some embodiments, the step of adopting a processing strategy corresponding to the fault type includes:

[0009] In response to a fault type of Type 1, a first fault alert is sent to the user, and the robot continues to move.

[0010] In some embodiments, determining the fault type of the current fault includes:

[0011] In response to the current fault being a fault of at least one application function module, the fault type is determined to be a second type;

[0012] The step of adopting a processing strategy corresponding to the fault type includes:

[0013] In response to the fault type being the second type, the processing resource sandbox corresponding to the application function module that experienced the fault is reset.

[0014] In some embodiments, determining the fault type of the current fault includes:

[0015] In response to a hardware failure in the robot's pose sensing, the failure type is determined to be the third type;

[0016] The step of adopting a processing strategy corresponding to the fault type includes:

[0017] In response to the fault type being type 3, perform at least one of the following:

[0018] The robot is controlled to move to a first safe position, which meets a predetermined safety requirement;

[0019] The robot is positioned in the first safe position, and the robot's driving power is cut off;

[0020] The robot is positioned in a first safe position, and a brake is used to brake the robot.

[0021] Send a second fault notification to the user.

[0022] In some embodiments, determining the fault type of the current fault includes:

[0023] In response to determining that the fault type is a fourth type, the microcontroller fails to detect the hardware heartbeat signal of the application processor within a predetermined period of time, or the robot battery temperature exceeds a temperature threshold.

[0024] The step of adopting a processing strategy corresponding to the fault type includes:

[0025] In response to the fault type being type four, perform at least one of the following:

[0026] The robot is braked using a brake;

[0027] Power is cut off from the positioning module and the alarm module, wherein the positioning module is used to determine the position of the robot, and the alarm module is used to send a third fault prompt to the user.

[0028] In some embodiments, the method further includes at least one of the following:

[0029] Receive the first-stage vehicle locking command sent by the robot's associated server and perform a safe pose adjustment;

[0030] In response to the completion of safe pose adjustment, a safe ready confirmation is sent to the server;

[0031] The robot receives a second-stage locking command from its server and executes a safe locking mechanism.

[0032] In some embodiments, performing safe pose adjustment includes at least one of the following:

[0033] Control the robot to move to a position that meets the flatness requirements;

[0034] Control the robot to move to a position that meets safety requirements;

[0035] Adjust the robot's movement speed to a predetermined speed.

[0036] In some embodiments, performing the safety locking of the vehicle includes at least one of the following:

[0037] Disconnect the circuit of the robot's walking component drive circuit;

[0038] The mechanical braking components are controlled to keep the robot's walking components in a locked state;

[0039] A lock character is written to the read-only physical partition of the associated memory managed by the processing module. The lock character is used to indicate the execution of the security lock.

[0040] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0041] In some embodiments, the method further includes: in response to receiving an authorization credential signed by the private key of the server's CA root certificate sent by the server, clearing the lock character to unlock the vehicle.

[0042] According to a second aspect of the present disclosure, a robot fault handling method is provided, applied to a server associated with a robot, the method comprising:

[0043] Send a first-stage vehicle locking command to the robot, the first-stage vehicle locking command being used to instruct the robot to perform a safe pose adjustment;

[0044] In response to receiving a safety readiness confirmation from the robot, a second-stage locking command is sent to the robot, which instructs the robot to perform a safety locking operation; wherein the safety readiness confirmation is sent by the robot after completing the safety pose adjustment.

[0045] In some embodiments, the robot performs a safety locking operation, including at least one of the following:

[0046] The robot moves to a position that meets the flatness requirements;

[0047] The robot moves to a position that meets safety requirements;

[0048] The robot adjusts its movement speed to a predetermined speed.

[0049] In some embodiments, the robot performing the safety locking of the vehicle includes at least one of the following:

[0050] The robot disconnects the circuit of the walking component drive circuit;

[0051] The robot control mechanical braking component keeps the robot walking component in a locked state;

[0052] A lock character is written to the read-only physical partition of the associated memory managed by the robot's processing module. The lock character is used to indicate the execution of the safety lock.

[0053] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0054] In some embodiments, the method further includes:

[0055] An authorization credential signed by the private key of the server's CA root certificate is sent to the robot, wherein the authorization credential is used to clear the lock character to unlock the vehicle.

[0056] According to a third aspect of the present disclosure, a robot is provided, applied to a robot, the robot including a processing module, the processing module including a microcontroller and an application processor, the microcontroller being configured to check the hardware heartbeat signal of the application processor; the application processor being configured to partition mutually isolated processing resource sandboxes for each application function module, the processing module being configured to:

[0057] Determine the type of the current fault;

[0058] Based on the fault type, a processing strategy corresponding to the fault type is adopted.

[0059] In some embodiments, the processing module is specifically configured to: in response to a fault type of a first type, send a first fault notification to the user and maintain robot movement.

[0060] In some embodiments, the processing module is specifically configured to: in response to the current fault being a fault of at least one application function module, determine the fault type as a second type;

[0061] In response to the fault type being the second type, the processing resource sandbox corresponding to the application function module that experienced the fault is reset.

[0062] In some embodiments, the processing module is specifically used for:

[0063] In response to a hardware failure in the robot's pose sensing, the failure type is determined to be the third type;

[0064] In response to the fault type being type 3, perform at least one of the following:

[0065] The robot is controlled to move to a first safe position, which meets a predetermined safety requirement;

[0066] The robot is positioned in the first safe position, and the robot's driving power is cut off;

[0067] The robot is positioned in a first safe position, and a brake is used to brake the robot.

[0068] Send a second fault notification to the user.

[0069] In some embodiments, the processing module is specifically configured to: determine the fault type as a fourth type in response to determining at least one of the following: the microcontroller has not detected the hardware heartbeat signal of the application processor within a predetermined period of time, or the robot battery temperature exceeds a temperature threshold;

[0070] In response to the fault type being type four, perform at least one of the following:

[0071] The robot is braked using a brake;

[0072] Power is cut off from the positioning module and the alarm module, wherein the positioning module is used to determine the position of the robot, and the alarm module is used to send a third fault prompt to the user.

[0073] In some embodiments, the robot further includes a transceiver module.

[0074] The transceiver module is used to: receive the first-stage vehicle locking command sent by the robot's associated server;

[0075] The processing module is also used to perform a safe posture adjustment in response to the first-stage vehicle locking command;

[0076] The transceiver module is also configured to: send a safety ready confirmation to the server in response to completing the safety pose adjustment;

[0077] The transceiver module is also used to: receive the second-stage vehicle locking command sent by the robot's server;

[0078] The processing module is also used to execute a secure vehicle lock in response to the second-stage vehicle lock command.

[0079] In some embodiments, the processing module specifically includes at least one of the following:

[0080] Control the robot to move to a position that meets the flatness requirements;

[0081] Control the robot to move to a position that meets safety requirements;

[0082] Adjust the robot's movement speed to a predetermined speed.

[0083] In some embodiments, the processing module specifically includes at least one of the following:

[0084] Disconnect the circuit of the robot's walking component drive circuit;

[0085] The mechanical braking components are controlled to keep the robot's walking components in a locked state;

[0086] A lock character is written to the read-only physical partition of the associated memory managed by the processing module. The lock character is used to indicate the execution of the security lock.

[0087] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0088] In some embodiments, the processing module is further configured to:

[0089] Upon receiving an authorization credential signed by the server's CA root certificate private key, the response should clear the lock character to unlock the vehicle.

[0090] According to a fourth aspect of the embodiments of this disclosure, a robot-associated server is provided, the server including a processing module and a transceiver module, wherein...

[0091] The transceiver module is used to: send a first-stage vehicle locking command to the robot, the first-stage vehicle locking command being used to instruct the robot to perform a safe posture adjustment;

[0092] The processing module is configured to: in response to the transceiver module receiving a safety readiness confirmation sent by the robot, send a second-stage locking command to the robot, the second-stage locking command being used to instruct the robot to perform a safety locking operation; wherein the safety readiness confirmation is sent when the robot completes the safety pose adjustment.

[0093] In some embodiments, the robot performs a safety locking operation, including at least one of the following:

[0094] The robot moves to a position that meets the flatness requirements;

[0095] The robot moves to a position that meets safety requirements;

[0096] The robot adjusts its movement speed to a predetermined speed.

[0097] In some embodiments, the robot performing the safety locking of the vehicle includes at least one of the following:

[0098] The robot disconnects the circuit of the walking component drive circuit;

[0099] The robot control mechanical braking component keeps the robot walking component in a locked state;

[0100] A lock character is written to the read-only physical partition of the associated memory managed by the robot's processing module. The lock character is used to indicate the execution of the safety lock.

[0101] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0102] In some embodiments, the transceiver module is further configured to: send an authorization credential signed by the private key of the server's CA root certificate to the robot, wherein the authorization credential is used to clear the lock character to unlock the vehicle.

[0103] According to a fifth aspect of the present disclosure, an electronic device is provided, the electronic device comprising:

[0104] One or more processors;

[0105] The processor is used to invoke instructions to cause the electronic device to execute the robot fault handling method described in the first or second aspect.

[0106] According to a sixth aspect of the present disclosure, a storage medium is provided that stores instructions that, when executed on an electronic device, cause the electronic device to perform the robot fault handling method described in the first or second aspect.

[0107] This disclosure provides a robot fault handling method, a robot, and a server. The robot fault handling method is applied to a robot, which includes a processing module comprising a microcontroller and an application processor. The microcontroller checks the hardware heartbeat signal of the application processor; the application processor partitions each application function module into an isolated processing resource sandbox. The method includes: determining the fault type of the current fault; and adopting a processing strategy corresponding to the fault type. Thus, by introducing a microcontroller into the robot processing module to check the hardware heartbeat signal of the application processor, and by having the application processor partition each application function module into an isolated processing resource sandbox, deep self-checking and hardware-level isolation at the edge are achieved. Therefore, when the robot faces problems such as software crashes, hardware transient failures, or sensor failures, it can adopt targeted processing strategies based on the determined fault type, reducing the need for simple whole-machine resets or direct power cuts in traditional solutions. This effectively reduces maintenance costs, decreases the risk of secondary safety accidents, and improves the robot's robustness and autonomous recovery capability in complex operating environments. Attached Figure Description

[0108] Figure 1 This is a flowchart illustrating a robot fault handling method according to an exemplary embodiment. Figure 1 ;

[0109] Figure 2 This is a flowchart illustrating a robot fault handling method according to an exemplary embodiment. Figure 2 ;

[0110] Figure 3 This is a schematic diagram of the structure of an electronic device according to an exemplary embodiment. Detailed Implementation

[0111] To make the technical solution and beneficial effects of the present invention more apparent and understandable, a detailed description is provided below by listing specific embodiments. The accompanying drawings are not necessarily drawn to scale, and local features may be enlarged or reduced to more clearly show the details of the local features; unless otherwise defined, the technical and scientific terms used herein have the same meanings as those in the technical field to which this application pertains.

[0112] This disclosure is not exhaustive, but merely illustrative of some embodiments, and is not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment can be arbitrarily interchanged. Furthermore, the optional implementation methods in a particular embodiment can be arbitrarily combined; moreover, the embodiments can be arbitrarily combined, for example, some or all steps of different embodiments can be arbitrarily combined, and a particular embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0113] In each of the disclosed embodiments, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of the embodiments are consistent and can be referenced by each other. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.

[0114] The terminology used in the embodiments of this disclosure is for the purpose of describing particular embodiments only and is not intended to limit the scope of this disclosure.

[0115] In this disclosure, unless otherwise stated, elements expressed in the singular form, such as "a," "an," "the," "the," "the," "the," "the," "the," "this," etc., can mean "one and only one," or "one or more," "at least one," etc. For example, when using articles such as "a," "an," "the," etc. in translation, the noun following the article can be understood as either a singular or a plural expression.

[0116] In the embodiments of this disclosure, "multiple" can be two or more.

[0117] In some embodiments, the terms “at least one of”, “one or more”, “a plurality of”, “multiple”, etc., may be used interchangeably.

[0118] In some embodiments, the notation "at least one of A and B", "A and / or B", "A in one case, B in another", "A in one case, B in another", etc., may include the following technical solutions depending on the situation: in some embodiments, A (A is executed regardless of B); in some embodiments, B (B is executed regardless of A); in some embodiments, execution is selected from A and B (A and B are selectively executed); in some embodiments, both A and B are executed. The same applies when there are more branches such as A, B, C, etc.

[0119] In some embodiments, the notation "A or B" may include the following technical solutions, depending on the situation: in some embodiments, A (execution of A regardless of B); in some embodiments, B (execution of B regardless of A); in some embodiments, selective execution from A and B (A and B are selectively executed). The same applies when there are more branches such as A, B, and C.

[0120] The prefixes "first," "second," etc., used in the embodiments of this disclosure are merely for distinguishing different descriptive objects and do not impose restrictions on the position, order, priority, value, or content of the descriptive objects. The description of the descriptive objects should be found in the claims or the context of the embodiments, and the use of prefixes should not constitute unnecessary restrictions. For example, if the descriptive object is a "field," the ordinal numbers preceding "field" in "first field" and "second field" do not restrict the position or order of the "fields." "First" and "second" do not restrict whether the "fields" they modify are in the same message, nor do they restrict the order of "first field" and "second field." Similarly, if the descriptive object is a "level," the ordinal numbers preceding "level" in "first level" and "second level" do not restrict the priority between "levels." Furthermore, the value of the descriptive object is not limited by ordinal numbers and can be one or more. For example, in "first device," the value of "device" can be one or more. Furthermore, the objects modified by different prefixes can be the same or different. For example, if the object being described is "device", then "first device" and "second device" can be the same device or different devices, and their types can be the same or different. Similarly, if the object being described is "information", then "first information" and "second information" can be the same information or different information, and their content can be the same or different.

[0121] In some embodiments, “including A,” “containing A,” “for indicating A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0122] In some embodiments, terms such as “…”, “determine…”, “in the case of…”, “when…”, “when…”, “if…”, etc. can be used interchangeably.

[0123] In some embodiments, the terms “greater than,” “greater than or equal to,” “not less than,” “more than,” “more than or equal to,” “not less than,” “higher than,” “higher than or equal to,” “not lower than,” and “above” can be used interchangeably, as can the terms “less than,” “less than or equal to,” “not greater than,” “less than,” “less than or equal to,” “not more than,” “lower than,” “lower than or equal to,” “not higher than,” and “below”.

[0124] In some embodiments, devices, etc., can be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. Terms such as “device”, “equipment”, “circuit”, “network element”, “graph node”, “function”, “unit”, “section”, “system”, “network”, “chip”, “chip system”, “entity”, and “subject” can be used interchangeably.

[0125] Specifically, the failure modes that robots face include:

[0126] 1. Software Deadlock and Module Crash: The robot is equipped with a complex software stack, including application modules such as high-frequency LiDAR driver, camera driver, SLAM localization algorithm, and MASS Agent multimodal large model inference module. After running for a long time, the application modules are prone to crashing or deadlocking (false death) due to memory leaks, transient pointer abnormalities, and high power consumption and heat generation.

[0127] 2. Transient loosening and failure of sensors: Bumpy outdoor roads and mechanical vibrations may cause the LiDAR data line to loosen, the CAN bus to experience transient high load or electromagnetic interference, which may lead to transient frame loss of sensor data.

[0128] 3. Security and control risks: The robot faces security risks such as theft or forced removal. A highly secure remote control mechanism is urgently needed, capable of remotely freezing / locking the robot.

[0129] However, existing robot monitoring and self-inspection systems typically have the following shortcomings:

[0130] First, it lacks fine-grained fault isolation and autonomous recovery capabilities. Traditional fault diagnosis often employs a simple external hardware watchdog mechanism. When the robot detects a lack of heartbeat response, the watchdog directly cuts off the system's main power and performs a hard reset. This crude and simplistic reset method is extremely dangerous.

[0131] If a robot suddenly loses power while driving on a public road or downhill section, the electromagnetic brake may lock or the motor may lose control torque, which may cause the robot to slide due to inertia and collide with pedestrians or vehicles, resulting in a secondary safety disaster.

[0132] Because the entire machine is powered off and restarted, the robot loses its memory state before the failure, localization origin (SLAM MapCoordinate), and unfinished task logs. After restarting, it often needs to re-execute the mapping and relocalization process in the same place, which takes several minutes, and cannot achieve seamless recovery in seconds.

[0133] Secondly, insufficient remote communication guarantees can easily lead to communication blind spots. When the robot moves into basements, elevator lobbies, or narrow gaps in buildings with severe signal obstruction, wireless communication such as 5G / 4G is interrupted. If the system relies entirely on cloud commands for monitoring and troubleshooting, the robot will completely lose control once the network goes offline. In the event of a local failure, the robot will be paralyzed on-site, waiting for technicians to arrive for physical inspection, resulting in extremely high operation and maintenance costs.

[0134] Remote locking commands lack physical safety verification constraints. Once an operator clicks to lock the robot in the cloud or the commercial billing system automatically issues a lock command for overdue payments, the robot immediately cuts off the drive motor and locks the drive shaft, regardless of its current physical state (e.g., in the middle of a high-traffic bus lane or on a steep, accessible ramp). This safety vulnerability, stemming from a lack of spatial awareness and physical constraints, can easily lead to serious property damage or personal injury accidents.

[0135] Example 1

[0136] This disclosure provides a robot fault handling method applied to a robot. The robot includes a processing module, which comprises a microcontroller and an application processor. The microcontroller is used to check the hardware heartbeat signal of the application processor. The application processor is used to divide each application function module into mutually isolated processing resource sandboxes, such as... Figure 1 As shown, the method includes:

[0137] Step 101: Determine the fault type of the current fault;

[0138] Step 102: Based on the fault type, adopt the processing strategy corresponding to the fault type.

[0139] A robot can be an automated device capable of performing predetermined tasks autonomously or semi-autonomously. It typically integrates sensors, actuators, control systems, and communication modules, enabling it to perceive, make decisions, and act in a specific environment.

[0140] In one possible implementation, the robot may include a patrol robot.

[0141] The processing module can be the core control unit of the robot, responsible for coordinating and managing the robot's various functions. A processing module typically contains multiple processing units to perform control and data processing tasks at different levels.

[0142] In one possible implementation, the processing module may include a Robot Integrated Control Unit (RICU).

[0143] The processing module may include a heterogeneous dual-core control board that integrates an application processor (including a microprocessor unit, MPU / Neural Processing Unit NPU) and a real-time microcontroller unit (MCU), which is responsible for the robot's motion control, data acquisition, edge computing and system-level fault protection.

[0144] Microcontrollers are typically used to perform low-level control tasks that require high real-time performance and low resource consumption, such as motor driving, sensor data acquisition, and hardware status monitoring.

[0145] For example, the microcontroller can run a deterministic hard real-time operating system and exclusively control the secure communication bus of the robot chassis driver and the physical electromagnetic brake control pins. The microcontroller can be dedicated to managing the application processor hardware heartbeat and application processor status, ensuring the vehicle's power safety and physical braking at the physical level.

[0146] Application processors can have higher computing power and richer interfaces. In robotic systems, application processors can be responsible for running complex operating systems, executing advanced algorithms (such as SLAM, path planning, and artificial intelligence reasoning), and managing user interaction and communication functions.

[0147] A hardware heartbeat signal is a signal that is periodically sent by the application processor to the microcontroller to indicate the normal operating status of the application processor hardware. By detecting the presence or absence of this signal and its periodicity, the microcontroller can determine whether the application processor hardware is in a normal operating state.

[0148] Application function modules can be independent software components within a robot software system that implement specific functions (such as localization, navigation, perception, human-machine interaction, etc.). These modules typically have clearly defined input and output interfaces and can be deployed and run independently.

[0149] A processing resource sandbox can include at least one of computing resources and processing resources. It can be a software and / or hardware isolation mechanism used to provide a separate, restricted operating environment for a specific application or process. Within this environment, application modules are allocated independent computing and storage resources, thereby preventing a failure in one application module from affecting other modules or the entire system.

[0150] For example, the application processor runs an operating system with hardware memory isolation support (such as embedded Linux running a container runtime). Containerization isolation technology is used to create multiple independent hardware-secure isolation sandboxes:

[0151] Nav-Sandbox A: Independently operates SLAM positioning and laser navigation obstacle avoidance module;

[0152] Sandbox B (MASS-Sandbox): Independently runs the MASS Agent, multimodal large model, and video feature classification module; Sandbox C (Comm-Sandbox): Runs the 4G / 5G network manager and remote MQTT communication module.

[0153] The hardware memory management unit (MMU) can be used to hard limit the running memory quota of each sandbox, ensuring that even if the MASS large model experiences a kernel memory out-of-bounds failure due to overload, only sandbox B will be destroyed, while the chassis control, navigation and obstacle avoidance and network communication modules will continue to operate stably.

[0154] Fault types can be categorized based on the cause, manifestation, or scope of the fault in a robot system. Different fault types may correspond to different system states and potential risks.

[0155] Handling strategies can be a predefined set of countermeasures or operational procedures for a specific type of failure. These strategies are used to mitigate the impact of failures, improve the speed of robot recovery, restore system functionality, or ensure robot safety by taking appropriate actions.

[0156] Specifically, the robot can have a processing module, which is the core control unit of the robot. This processing module is designed to contain at least two main processor units: a microcontroller and an application processor. The microcontroller is typically responsible for performing low-level tasks with high real-time requirements, such as sensor data acquisition, sending motor control commands, and basic hardware status monitoring. The application processor is configured to handle more complex computational tasks, such as running the operating system, executing advanced algorithms, performing data analysis, and managing the user interface and communication protocols. The adoption of a dual-processor architecture enables the rational allocation of tasks, improving the overall response speed and processing efficiency of the system.

[0157] A microcontroller can be configured to continuously monitor the application processor's hardware heartbeat signal. This heartbeat signal can be periodically sent to the microcontroller by the application processor via a specific hardware line or interface. The microcontroller determines whether the application processor is functioning correctly by monitoring the periodicity or specific patterns of this signal. For example, the microcontroller can be set to wait to receive the heartbeat signal from the application processor at preset time intervals. If the microcontroller fails to detect the heartbeat signal for several consecutive time intervals, or if the detected signal pattern is abnormal, it can preliminarily determine that the application processor may have malfunctioned or entered an abnormal state. This monitoring mechanism provides a basic hardware-level health monitoring method.

[0158] The application processor is configured to partition isolated processing resource sandboxes for each application module running on the robot. When multiple application modules run on the application processor, the application processor can employ at least one of virtualization, memory protection mechanisms, or process isolation techniques to create an independent runtime environment for each module. For example, each application module can be allocated independent memory space and CPU processing resources. The isolation mechanism ensures that the operation of one application module does not interfere with other modules. Even if a module crashes or malfunctions, its impact is limited to the sandbox within that module, thereby reducing the risk of the entire system crashing.

[0159] Fault types can be categorized based on multiple dimensions, such as the source of the fault (hardware fault, software fault), the scope of the fault (single module fault, system-wide fault), the severity of the fault (minor anomaly, severe failure), and the duration of the fault (transient fault, persistent fault). Fault type determination can be achieved in various ways. For example, the system can collect diagnostic information from different sensors, processor units, or software modules, and then match it using a pre-defined rule set or a simple lookup table to identify the specific fault type.

[0160] For example, fault types can be categorized using simple serial numbers. For instance, they can be divided into Type 1, Type 2, and so on. Different handling methods can then be applied to different types.

[0161] This embodiment's method is based on the fault type and adopts a corresponding handling strategy, rather than applying a uniform approach to all faults. Instead, it selects the most appropriate response based on the nature and potential impact of the fault. For example, for one fault type, the system can be configured to simply log and notify the operator. For another fault type, the system can attempt to restart the relevant software service. The selection of the handling strategy can be based on a predefined mapping relationship, meaning each fault type corresponds to one or a set of specific handling actions. Type-based handling improves the targeting and effectiveness of fault handling.

[0162] Thus, by introducing a microcontroller into the robot's processing module to check the hardware heartbeat signal of the application processor, and by having the application processor divide each application function module into mutually isolated processing resource sandboxes, deep self-checking and hardware-level isolation at the edge are achieved. Consequently, when the robot faces problems such as software crashes, hardware transient failures, or sensor malfunctions, it can adopt targeted handling strategies based on the determined fault type. This reduces the need for simple whole-machine resets or direct power cuts in traditional solutions, effectively lowering maintenance costs, reducing the risk of secondary safety accidents, and improving the robot's robustness and autonomous recovery capabilities in complex operating environments.

[0163] In some embodiments, the step of adopting a processing strategy corresponding to the fault type includes:

[0164] In response to a fault type of Type 1, a first fault alert is sent to the user, and the robot continues to move.

[0165] In one possible implementation, the first type of fault can be a fault with a lower priority. For example, a first-type fault could be one that does not significantly affect the robot's current task.

[0166] For example, the first type of fault may include transient frame drops in the camera or gimbal motor blockage.

[0167] When the fault is determined to be Type 1, the robot will send a first fault alert to the user. This alert can be sent through various means, such as the robot's display screen, indicator lights, voice broadcast system, or through a mobile application associated with the robot, a remote monitoring platform, etc. The alert content is intended to concisely inform the user of a minor fault, but the robot can still continue to operate. For example, it may state that a sensor data is abnormal, and the user should observe the situation carefully; the robot will continue to perform its task.

[0168] In one possible implementation, for the first type of fault, the confidence threshold of the AI ​​module affected by the fault can be lowered without affecting the robot's main route.

[0169] The robot will maintain its movement. This means that even after detecting a Type I malfunction, the robot can still continue its movement according to the predetermined path or instructions without emergency stopping, deceleration, or alteration of the preset task. The processing module will assess the impact of the malfunction on its mobility; if it determines that there is no impact or the impact is negligible, it will maintain movement, allowing the robot to continue its navigation and operations.

[0170] In this way, when the robot detects a minor fault that does not affect its core functions or safe operation, it can send an initial fault alert to the user, informing them of the current status, while minimizing unnecessary downtime or service interruptions and maintaining the robot's normal movement. This reduces efficiency losses and task interruptions caused by minor faults, allowing the robot to continue performing its intended tasks while ensuring basic functionality.

[0171] In some embodiments, determining the fault type of the current fault includes:

[0172] In response to the current fault being a fault of at least one application function module, the fault type is determined to be a second type;

[0173] The step of adopting a processing strategy corresponding to the fault type includes:

[0174] In response to the fault type being the second type, the processing resource sandbox corresponding to the application function module that experienced the fault is reset.

[0175] When the robot system is running, the application processor in the processing module allocates isolated processing resource sandboxes for each application function module. These sandboxes are independent operating environments, ensuring that an anomaly in one module will not easily affect other modules.

[0176] When the system detects that the current fault is caused by an abnormality in one or more application function modules, such as a process crash, resource exhaustion, or data abnormality in a navigation module, vision module, or task execution module, the fault handling mechanism will identify and classify it as a second type of fault.

[0177] Once the fault type is determined to be Type II, the system immediately implements a targeted handling strategy, namely, resetting the processing resource sandbox corresponding to the faulty application module. The reset operation typically includes terminating all related processes within the sandbox, releasing the computing resources they occupy (such as CPU, memory, file handles, etc.), reinitializing the sandbox environment, and then attempting to restart the application module. This reset mechanism leverages the isolation characteristics of the sandbox, ensuring the locality of fault handling.

[0178] For example, the second type of fault may include: transient interruption of a single radar signal, or deadlock in the MASS large model calculation. When a second type of fault occurs, the robot system does not restart, communication is not interrupted, and the container loading engine can destroy and regenerate the fault sandbox within a short time (e.g., within 2 seconds). Navigation can still be maintained via the IMU / odometer without needing to re-find the origin.

[0179] In this way, when a certain application function module fails, the system can accurately classify it as a second type of failure and reset the processing resource sandbox corresponding to the failed module. This can minimize the impact of the failure on the overall operation of the robot, so that other normally operating application function modules are not disturbed, thereby improving the stability and availability of the robot system.

[0180] In some embodiments, determining the fault type of the current fault includes:

[0181] In response to a hardware failure in the robot's pose sensing, the failure type is determined to be the third type;

[0182] The step of adopting a processing strategy corresponding to the fault type includes:

[0183] In response to the fault type being type 3, perform at least one of the following:

[0184] The robot is controlled to move to a first safe position, which meets a predetermined safety requirement;

[0185] The robot is positioned in the first safe position, and the robot's driving power is cut off;

[0186] The robot is positioned in a first safe position, and a brake is used to brake the robot.

[0187] Send a second fault notification to the user.

[0188] Pose sensing is a technology used by robots to perceive their position and orientation in their environment. Pose sensing can include GPS, radar hardware, etc. When these sensor hardwares malfunction, the microcontroller or application processor in the processing module can detect these anomalies through pre-defined diagnostic logic. Once such a fault is detected, the system classifies it as a Type III fault to indicate its potentially serious impact on the safe operation of the robot.

[0189] The first safe position can be dynamically calculated as the location with the lowest risk to the robot itself and its surrounding environment. Predetermined safety requirements may include, but are not limited to: avoiding potential obstacles, being on flat and stable ground, being easily accessible for maintenance personnel to inspect and handle, or being near a charging station. In the event of a pose sensing hardware failure, the robot may be unable to navigate precisely. In this case, the robot can be moved to the first safe position in a very low-speed and height-controlled manner by utilizing limited, still-available sensor information (e.g., wheel speed encoders or simplified obstacle avoidance sensors) combined with a pre-set safe path or a coarse-localization-based strategy.

[0190] Once the robot has successfully reached the first safe position, the system will cut off the drive power to completely eliminate the risk of accidental movement. This is typically achieved by sending a stop command to the drive motor controller or by directly disconnecting the power circuit to the drive motor via a hardware relay, thus preventing the robot from moving autonomously.

[0191] After the drive power is cut off, the system activates a brake to physically lock the robot in place, further bringing it to a standstill. The brake can be a mechanical brake, an electromagnetic brake, or other device capable of physically securing the robot's walking parts. This prevents the robot from shifting under the influence of ramps, vibrations, or other external forces, providing additional safety.

[0192] Once a pose sensing hardware malfunction is identified and the aforementioned safety measures are implemented, the system will generate and send a second fault notification to the user. This notification should clearly state the type of malfunction (pose sensing hardware malfunction), its severity, and the safety measures already taken by the robot (e.g., it has been moved to a safe location and stopped). Notification methods may include, but are not limited to: issuing alarms via the robot's display screen, indicator lights, buzzers, or notifying the user via a linked mobile application, SMS, email, etc.

[0193] In this way, clearly identifying the robot's pose sensing hardware failure as a third type and triggering a series of targeted safety measures can effectively reduce the risk of loss of control that may occur when the critical sensing system fails. Guiding the robot to a preset first safe position, cutting off the drive power at this position, and physically locking the robot with brakes can maximize the safety of the robot itself, the surrounding environment, and personnel. At the same time, sending a second fault notification to the user allows the user to understand the fault situation in a timely manner and take subsequent actions, thereby improving the timeliness and safety of fault handling.

[0194] In some embodiments, determining the fault type of the current fault includes:

[0195] In response to determining that the fault type is a fourth type, the microcontroller fails to detect the hardware heartbeat signal of the application processor within a predetermined period of time, or the robot battery temperature exceeds a temperature threshold.

[0196] The step of adopting a processing strategy corresponding to the fault type includes:

[0197] In response to the fault type being type four, perform at least one of the following:

[0198] The robot is braked using a brake;

[0199] Power is cut off from the positioning module and the alarm module, wherein the positioning module is used to determine the position of the robot, and the alarm module is used to send a third fault prompt to the user.

[0200] The microcontroller can be configured with a timer that is reset whenever a heartbeat signal is received from the application processor. If the timer is not reset before a predetermined duration is reached, a no-heartbeat event is triggered. The predetermined duration should be set reasonably based on system response requirements and the frequency of heartbeat signal transmission to balance real-time performance and false alarm rate.

[0201] If the robot's battery temperature exceeds a certain threshold, it can be detected by a temperature sensor integrated within the robot (such as a thermistor or PTC sensor) monitoring the battery pack temperature in real time. When this temperature consistently or momentarily exceeds a preset safe temperature threshold, it is considered an abnormal battery temperature. Overheating can lead to performance degradation, shortened lifespan, and even serious safety incidents such as thermal runaway, fire, or explosion. The temperature threshold should be set according to the battery type, operating environment, and safety standards.

[0202] The robot can be braked using a brake; power supply to modules other than the positioning module and alarm module can be cut off.

[0203] Using brakes to stop a robot is an emergency measure to bring it to a rapid halt in case of a serious malfunction, preventing further collisions, falls, or other hazards and ensuring the safety of personnel and equipment. The brakes can be mechanical (such as clutch brakes or friction brakes), which directly lock the drive wheels or joints using mechanical force.

[0204] Disconnecting power to modules other than the positioning and alarm modules can be necessary in extreme failure scenarios to minimize risk and prevent the spread of the fault or further damage, requiring a power outage of most functional modules of the robot. Maintaining power to the positioning and alarm modules ensures that the robot's position can still be determined after a power outage, and necessary fault information can be sent to the user for subsequent rescue or maintenance. The processing module (microcontroller) can selectively disconnect the power supply to other functional modules (such as drive motors, sensors, or actuators) by controlling the power management unit or power switching devices such as relays and MOSFETs.

[0205] The positioning module is used to determine the robot's location. It is responsible for acquiring the robot's precise location information in the current environment. This location information is crucial for subsequent troubleshooting, rescue, and recovery when the robot malfunctions and requires an emergency stop.

[0206] The alarm module is used to send third-party fault alerts to users. When a serious robot malfunction occurs, the alarm module promptly and effectively sends alert information to the user or monitoring center, informing them of the fault type, time of occurrence, robot location, and other key information so that the user can take swift action.

[0207] Thus, by introducing monitoring for critical anomalies such as the microcontroller failing to detect the application processor's hardware heartbeat signal within a predetermined time period and the robot's battery temperature exceeding a temperature threshold, a fourth type of fault that could potentially lead to robot system crashes or serious safety accidents can be identified in a timely manner. Once such a fault is identified, the robot is immediately brought to an emergency stop by the brakes, quickly preventing unintended movement and effectively reducing secondary damage such as collisions caused by loss of control, thereby ensuring the safety of the robot itself and its surrounding environment. Simultaneously, selectively cutting off power to modules other than the positioning and alarm modules minimizes the risk of fault propagation and unnecessary energy consumption, ensuring system stability in emergency situations. Furthermore, maintaining power to the positioning module allows for accurate robot location acquisition even when most of the system is powered down, providing crucial information for subsequent troubleshooting, rescue, and maintenance. The alarm module promptly sends a third fault alert to the user, informing them of the severity of the fault and the emergency measures taken by the robot, thereby enhancing the robot's safety response capabilities and controllability in the face of severe system-level or environmental anomalies.

[0208] In some embodiments, the method further includes at least one of the following:

[0209] Receive the first-stage vehicle locking command sent by the robot's associated server and perform a safe pose adjustment;

[0210] In response to the completion of safe pose adjustment, a safe ready confirmation is sent to the server;

[0211] The robot receives a second-stage locking command from its server and executes a safe locking mechanism.

[0212] Here, the server side can include the robot's cloud server, etc.

[0213] The server will lock the robot if it determines at least one of the following: the customer has violated regulations (including: long-term overdue payment of service fees, malicious breach of contract; or the robot is forcibly removed on-site by criminals in an attempt to steal hardware assets, etc., which pose commercial and physical risks).

[0214] The locking operation can be achieved in two steps: first, put the robot in a safe position, and second, put the robot in a secure locked state.

[0215] The robot receives a first-stage locking command from its associated server (e.g., a remote control center, scheduling system, or maintenance platform). This first-stage locking command is the first step in initiating the phased locking process, indicating that the server has identified the need for a higher level of safety control or maintenance of the robot. The command may include a specific command word, parameter, or identifier to trigger the robot's internal safety pose adjustment process. Based on the received first-stage locking command, the robot initiates a series of actions to adjust itself to a preset safe posture or position (determined by checking the robot's current roll and pitch angles), such as a flat, obstacle-free area to ensure robot stability; or to move the robot to a location that meets safety conditions, such as away from people, equipment, or hazardous areas to reduce potential collisions or injuries; simultaneously, the robot's speed may be adjusted to a predetermined speed, such as reducing it to zero, to ensure safety during the adjustment process. This adjustment creates a safe and stable environment for subsequent full locking or maintenance operations.

[0216] Subsequently, the robot's internal control system monitors the progress and results of the safe pose adjustment. Once all predetermined safe pose adjustment actions have been successfully executed and the robot has reached the expected safe state, the robot will confirm the adjustment is complete. After confirming the adjustment is complete, the robot can send a safety-ready confirmation message to its associated server. This message indicates that the robot has successfully entered a safe pose and is ready to receive the next instruction. In this way, the server can understand the robot's status in real time and make subsequent decisions and issue instructions based on this status, forming a closed-loop collaborative control process.

[0217] After receiving confirmation of the robot's safety readiness, the server determines whether a deeper locking operation is needed. If so, the server sends a second-stage locking command to the robot. Upon receiving the second-stage locking command, the robot performs a series of operations to completely stop its operation and enter a locked state. These operations include disconnecting the drive circuit of the robot's walking components (e.g., the microcontroller disconnects the solid-state switch of the robot motor driver's three-phase output, putting the motor in a zero back EMF locked state) to completely cut off the power source; controlling the mechanical braking components to keep the robot's walking components in a locked state, such as by using a brake to prevent the robot from moving; and writing a lock character to the read-only physical partition of the associated memory managed by the processing module. This lock character indicates that a safety lock has been performed, preventing unauthorized start-up. The safety lock prevents the robot from being restarted or moved without authorization, ensuring maximum safety during maintenance, repair, or emergencies.

[0218] Thus, by receiving the first-stage locking command and performing safe posture adjustments, the robot can proactively adjust itself to a safe and stable state under the coordination of an external system. This lays the foundation for the subsequent complete locking operation and reduces the risks associated with directly stopping the robot in an unsafe state. The robot sends a safety-ready confirmation to the server, enabling the server to accurately grasp the robot's readiness status and issue the second-stage locking command at the appropriate time. The robot executes the safety locking, allowing it to be completely stopped and locked when necessary, preventing accidental start-up or movement. This significantly improves the robot's overall safety and controllability in case of malfunctions, maintenance, or emergencies.

[0219] In some embodiments, performing safe pose adjustment includes at least one of the following:

[0220] Control the robot to move to a position that meets the flatness requirements;

[0221] Control the robot to move to a position that meets safety requirements;

[0222] Adjust the robot's movement speed to a predetermined speed.

[0223] Controlling a robot to move to a location that meets flatness requirements can be achieved during safe pose adjustments. The robot uses its onboard sensors (e.g., inertial measurement unit, lidar, or vision system) to assess the flatness of the current ground or target area. Flatness requirements can be preset as parameters such as maximum permissible tilt angle and maximum local elevation difference. Based on the assessment results, the robot autonomously plans its path and moves to an area that meets these flatness requirements. This ensures structural stability during subsequent operations (such as prolonged parking, maintenance, or second-stage locking), reducing the risk of overturning, sliding, or uneven stress on components caused by uneven ground.

[0224] Controlling a robot to move to a location that meets safety conditions can involve the robot selecting and moving to an area where there is no potential danger to itself, the surrounding environment, or personnel, based on preset safety rules and environmental information. Safety conditions may include, but are not limited to: being away from densely populated areas, avoiding hazardous equipment or obstacles, being outside emergency exits, or entering a designated safe parking area. For example, it must be away from densely populated passageways, main roads, and fire exits, and the physical clearance distance from the nearest obstacle must be greater than 0.5 meters. The robot can use its positioning and navigation system and environmental perception capabilities to identify and plan a path to such a safe location, thereby minimizing the possibility of accidents in the event of a malfunction.

[0225] Adjusting the robot's movement speed to a predetermined speed can be done during safe pose adjustments by setting the robot's movement speed to a pre-determined, typically low and stable value. This predetermined speed can be set based on the severity of the fault, environmental conditions, or safety protocols; for example, the predetermined speed can be set to an extremely slow pace or even a complete stop. Precise control of the movement speed ensures smooth and controllable robot movements during pose adjustments, reducing the risk of loss of control due to high-speed movement, providing operators with sufficient reaction time, and helping the robot reach the target position more accurately.

[0226] In some embodiments, performing the safety locking of the vehicle includes at least one of the following:

[0227] Disconnect the circuit of the robot's walking component drive circuit;

[0228] The mechanical braking components are controlled to keep the robot's walking components in a locked state;

[0229] A lock character is written to the read-only physical partition of the associated memory managed by the processing module. The lock character is used to indicate the execution of the security lock.

[0230] Disconnecting the drive circuit of a robot's locomotion components can be achieved through electrical control means, cutting off or interrupting the circuit that provides power or control signals to the robot's locomotion components (such as wheel motors, track drives, etc.). This can be done in various ways, such as disconnecting the main power supply circuit via relays or contactors, or cutting off the drive current via power semiconductor devices (such as MOSFETs, IGBTs). Alternatively, the driver can be stopped by interrupting control signal lines (such as PWM signals, CAN bus communication). This measure fundamentally eliminates the power source for the robot's locomotion components, preventing them from moving by their own driving force.

[0231] Maintaining the robot's walking components in a locked state by controlling the mechanical braking components can be achieved by applying braking force to the robot's walking components through physical mechanical devices, keeping them in a fixed position. This can include, but is not limited to: activating an electromagnetic brake integrated into the motor or reducer to engage the brake; deploying a hydraulic or pneumatic braking device to apply pressure to the wheels or tracks; or physically locking the walking components using mechanical wedges, pins, etc., to prevent them from rotating or sliding.

[0232] A lock character is written to the read-only physical partition of the associated memory managed by the processing module. This lock character indicates that a safety lock should be executed. It can be a physical partition configured as read-only within the memory managed by the robot's internal processing module (e.g., a microcontroller or application processor), where a predefined specific data string (the lock character) is written. The read-only physical partition is typically a storage area that cannot be easily erased or modified under normal operation, such as a specific flash memory block, EEPROM area, or a memory cell with hardware write protection. Once the lock character is written, it serves as a persistent identifier that the robot is in a safety-locked state. Even if the robot experiences a power outage, restart, or software reset, the lock character will remain, continuously indicating that the robot is in a safety-locked state until it is cleared through a specific authorization mechanism.

[0233] Thus, when executing the safety lock, disconnecting the drive circuit of the robot's walking components completely cuts off the power source to the robot's walking components from an electrical perspective, effectively preventing its movement. Controlling the mechanical braking components to keep the robot's walking components in a locked state provides physical braking from a mechanical perspective, ensuring the robot remains stationary even if the electrical circuit unexpectedly recovers or fails, forming a double layer of protection. Writing a lock character to the read-only physical partition of the associated memory managed by the processing module indicates the execution of the safety lock, providing a persistent and tamper-proof software-level identifier for the safety lock state. This effectively prevents unauthorized unlocking via software operation, ensuring the lock state is continuously recognized and maintained even if the robot system restarts or encounters other software failures.

[0234] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0235] The pre-defined encryption method involves converting the lock character using a pre-agreed encryption algorithm and key before writing it to the read-only physical partition of the associated memory managed by the processing module. This encryption method can be M4 / AES128 encrypted signature to prevent tampering. When the robot locks, the robot processing module generates or receives an initial lock identifier, such as a specific boolean value or string. This initial lock identifier is then encrypted using the pre-defined encryption method to generate a ciphertext lock character. This encrypted lock character is then written to the read-only physical partition of the associated memory managed by the processing module. Because this partition is read-only and the written character is encrypted, even if an external party attempts to read or tamper with the partition's contents, it is difficult to directly understand or forge the true meaning of the lock character, thus effectively preventing unauthorized unlocking or destruction of the secure lock status.

[0236] Thus, encrypting the lock character using a predetermined encryption method enhances the security and reliability of the vehicle locking mechanism. When the robot locks the vehicle and writes the encrypted lock character to the read-only physical partition, even if the partition's contents are accessed illegally, the lock character, being in ciphertext, cannot be easily identified, tampered with, or forged by unauthorized entities. This effectively reduces the risk of the vehicle locking state being accidentally released due to lock character tampering, thereby ensuring the robot's locking state is stably maintained under emergency or specific security requirements.

[0237] In some embodiments, the method further includes: in response to receiving an authorization credential signed by the private key of the server's CA root certificate sent by the server, clearing the lock character to unlock the vehicle.

[0238] A Certificate Authority (CA) root certificate private key-signed authorization credential is a highly secure and trustworthy digital credential. The CA root certificate is the starting point of the digital certificate trust chain, and its private key is used to digitally sign the authorization credential. Signing with the CA root certificate private key ensures the authenticity of the authorization credential's origin and that its content has not been tampered with during transmission. The authorization credential itself is a digital file or data packet containing instructions to unlock the vehicle or authorization information; it serves as the sole valid credential for unlocking. Clearing the lock character involves deleting, overwriting, or invalidating the lock character stored in the read-only physical partition of the associated memory managed by the processing module. Once the lock character is cleared, the robot can reactivate its walking component drive circuits, release mechanical braking components, and resume normal movement and function.

[0239] In this way, the robot can receive authorization credentials sent by the server, signed by the CA root certificate's private key. This mechanism ensures that only highly trusted and authenticated commands can trigger the unlocking of the secure lock, greatly enhancing the security, reliability, and traceability of the unlocking process.

[0240] Example 2

[0241] This disclosure provides a robot fault handling method, applied to a server associated with a robot, the method comprising:

[0242] Send a first-stage vehicle locking command to the robot, the first-stage vehicle locking command being used to instruct the robot to perform a safe pose adjustment;

[0243] In response to receiving a safety readiness confirmation from the robot, a second-stage locking command is sent to the robot, which instructs the robot to perform a safety locking operation; wherein the safety readiness confirmation is sent by the robot after completing the safety pose adjustment.

[0244] Here, the server side can include the robot's cloud server, etc.

[0245] The server will lock the robot if it determines at least one of the following: the customer has violated regulations (including: long-term overdue payment of service fees, malicious breach of contract; or the robot is forcibly removed on-site by criminals in an attempt to steal hardware assets, etc., which pose commercial and physical risks).

[0246] The locking operation can be achieved in two steps: first, put the robot in a safe position, and second, put the robot in a secure locked state.

[0247] The robot receives a first-stage locking command from its associated server (e.g., a remote control center, scheduling system, or maintenance platform). This first-stage locking command is the first step in initiating the phased locking process, indicating that the server has identified the need for a higher level of safety control or maintenance of the robot. The command may include a specific command word, parameter, or identifier to trigger the robot's internal safety pose adjustment process. Based on the received first-stage locking command, the robot initiates a series of actions to adjust itself to a preset safe posture or position (determined by checking the robot's current roll and pitch angles), such as a flat, obstacle-free area to ensure robot stability; or to move the robot to a location that meets safety conditions, such as away from people, equipment, or hazardous areas to reduce potential collisions or injuries; simultaneously, the robot's speed may be adjusted to a predetermined speed, such as reducing it to zero, to ensure safety during the adjustment process. This adjustment creates a safe and stable environment for subsequent full locking or maintenance operations.

[0248] Subsequently, the robot's internal control system monitors the progress and results of the safe pose adjustment. Once all predetermined safe pose adjustment actions have been successfully executed and the robot has reached the expected safe state, the robot will confirm the adjustment is complete. After confirming the adjustment is complete, the robot can send a safety-ready confirmation message to its associated server. This message indicates that the robot has successfully entered a safe pose and is ready to receive the next instruction. In this way, the server can understand the robot's status in real time and make subsequent decisions and issue instructions based on this status, forming a closed-loop collaborative control process.

[0249] After receiving confirmation of the robot's safety readiness, the server determines whether a deeper locking operation is needed. If so, the server sends a second-stage locking command to the robot. Upon receiving the second-stage locking command, the robot performs a series of operations to completely stop its operation and enter a locked state. These operations include disconnecting the drive circuit of the robot's walking components (e.g., the microcontroller disconnects the solid-state switch of the robot motor driver's three-phase output, putting the motor in a zero back EMF locked state) to completely cut off the power source; controlling the mechanical braking components to keep the robot's walking components in a locked state, such as by using a brake to prevent the robot from moving; and writing a lock character to the read-only physical partition of the associated memory managed by the processing module. This lock character indicates that a safety lock has been performed, preventing unauthorized start-up. The safety lock prevents the robot from being restarted or moved without authorization, ensuring maximum safety during maintenance, repair, or emergencies.

[0250] Thus, by receiving the first-stage locking command and performing safe posture adjustments, the robot can proactively adjust itself to a safe and stable state under the coordination of an external system. This lays the foundation for the subsequent complete locking operation and reduces the risks associated with directly stopping the robot in an unsafe state. The robot sends a safety-ready confirmation to the server, enabling the server to accurately grasp the robot's readiness status and issue the second-stage locking command at the appropriate time. The robot executes the safety locking, allowing it to be completely stopped and locked when necessary, preventing accidental start-up or movement. This significantly improves the robot's overall safety and controllability in case of malfunctions, maintenance, or emergencies.

[0251] In some embodiments, the robot performs a safety locking operation, including at least one of the following:

[0252] The robot moves to a position that meets the flatness requirements;

[0253] The robot moves to a position that meets safety requirements;

[0254] The robot adjusts its movement speed to a predetermined speed.

[0255] Controlling a robot to move to a location that meets flatness requirements can be achieved during safe pose adjustments. The robot uses its onboard sensors (e.g., inertial measurement unit, lidar, or vision system) to assess the flatness of the current ground or target area. Flatness requirements can be preset as parameters such as maximum permissible tilt angle and maximum local elevation difference. Based on the assessment results, the robot autonomously plans its path and moves to an area that meets these flatness requirements. This ensures structural stability during subsequent operations (such as prolonged parking, maintenance, or second-stage locking), reducing the risk of overturning, sliding, or uneven stress on components caused by uneven ground.

[0256] Controlling a robot to move to a location that meets safety conditions can involve the robot selecting and moving to an area where there is no potential danger to itself, the surrounding environment, or personnel, based on preset safety rules and environmental information. Safety conditions may include, but are not limited to: being away from densely populated areas, avoiding hazardous equipment or obstacles, being outside emergency exits, or entering a designated safe parking area. For example, it must be away from densely populated passageways, main roads, and fire exits, and the physical clearance distance from the nearest obstacle must be greater than 0.5 meters. The robot can use its positioning and navigation system and environmental perception capabilities to identify and plan a path to such a safe location, thereby minimizing the possibility of accidents in the event of a malfunction.

[0257] Adjusting the robot's movement speed to a predetermined speed can be done during safe pose adjustments by setting the robot's movement speed to a pre-determined, typically low and stable value. This predetermined speed can be set based on the severity of the fault, environmental conditions, or safety protocols; for example, the predetermined speed can be set to an extremely slow pace or even a complete stop. Precise control of the movement speed ensures smooth and controllable robot movements during pose adjustments, reducing the risk of loss of control due to high-speed movement, providing operators with sufficient reaction time, and helping the robot reach the target position more accurately.

[0258] In some embodiments, the robot performing the safety locking of the vehicle includes at least one of the following:

[0259] The robot disconnects the circuit of the walking component drive circuit;

[0260] The robot control mechanical braking component keeps the robot walking component in a locked state;

[0261] A lock character is written to the read-only physical partition of the associated memory managed by the robot's processing module. The lock character is used to indicate the execution of the safety lock.

[0262] Disconnecting the drive circuit of a robot's locomotion components can be achieved through electrical control means, cutting off or interrupting the circuit that provides power or control signals to the robot's locomotion components (such as wheel motors, track drives, etc.). This can be done in various ways, such as disconnecting the main power supply circuit via relays or contactors, or cutting off the drive current via power semiconductor devices (such as MOSFETs, IGBTs). Alternatively, the driver can be stopped by interrupting control signal lines (such as PWM signals, CAN bus communication). This measure fundamentally eliminates the power source for the robot's locomotion components, preventing them from moving by their own driving force.

[0263] Maintaining the robot's walking components in a locked state by controlling the mechanical braking components can be achieved by applying braking force to the robot's walking components through physical mechanical devices, keeping them in a fixed position. This can include, but is not limited to: activating an electromagnetic brake integrated into the motor or reducer to engage the brake; deploying a hydraulic or pneumatic braking device to apply pressure to the wheels or tracks; or physically locking the walking components using mechanical wedges, pins, etc., to prevent them from rotating or sliding.

[0264] A lock character is written to the read-only physical partition of the associated memory managed by the processing module. This lock character indicates that a safety lock should be executed. It can be a physical partition configured as read-only within the memory managed by the robot's internal processing module (e.g., a microcontroller or application processor), where a predefined specific data string (the lock character) is written. The read-only physical partition is typically a storage area that cannot be easily erased or modified under normal operation, such as a specific flash memory block, EEPROM area, or a memory cell with hardware write protection. Once the lock character is written, it serves as a persistent identifier that the robot is in a safety-locked state. Even if the robot experiences a power outage, restart, or software reset, the lock character will remain, continuously indicating that the robot is in a safety-locked state until it is cleared through a specific authorization mechanism.

[0265] Thus, when executing the safety lock, disconnecting the drive circuit of the robot's walking components completely cuts off the power source to the robot's walking components from an electrical perspective, effectively preventing its movement. Controlling the mechanical braking components to keep the robot's walking components in a locked state provides physical braking from a mechanical perspective, ensuring the robot remains stationary even if the electrical circuit unexpectedly recovers or fails, forming a double layer of protection. Writing a lock character to the read-only physical partition of the associated memory managed by the processing module indicates the execution of the safety lock, providing a persistent and tamper-proof software-level identifier for the safety lock state. This effectively prevents unauthorized unlocking via software operation, ensuring the lock state is continuously recognized and maintained even if the robot system restarts or encounters other software failures.

[0266] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0267] The pre-defined encryption method involves converting the lock character using a pre-agreed encryption algorithm and key before writing it to the read-only physical partition of the associated memory managed by the processing module. This encryption method can be M4 / AES128 encrypted signature to prevent tampering. When the robot locks, the robot processing module generates or receives an initial lock identifier, such as a specific boolean value or string. This initial lock identifier is then encrypted using the pre-defined encryption method to generate a ciphertext lock character. This encrypted lock character is then written to the read-only physical partition of the associated memory managed by the processing module. Because this partition is read-only and the written character is encrypted, even if an external party attempts to read or tamper with the partition's contents, it is difficult to directly understand or forge the true meaning of the lock character, thus effectively preventing unauthorized unlocking or destruction of the secure lock status.

[0268] Thus, encrypting the lock character using a predetermined encryption method enhances the security and reliability of the vehicle locking mechanism. When the robot locks the vehicle and writes the encrypted lock character to the read-only physical partition, even if the partition's contents are accessed illegally, the lock character, being in ciphertext, cannot be easily identified, tampered with, or forged by unauthorized entities. This effectively reduces the risk of the vehicle locking state being accidentally released due to lock character tampering, thereby ensuring the robot's locking state is stably maintained under emergency or specific security requirements.

[0269] In some embodiments, the method further includes:

[0270] An authorization credential signed by the private key of the server's CA root certificate is sent to the robot, wherein the authorization credential is used to clear the lock character to unlock the vehicle.

[0271] A CA (Certificate Authority) root certificate-signed authorization credential is a highly secure and trustworthy digital credential. The CA root certificate is the starting point of the digital certificate trust chain, and its private key is used to digitally sign the authorization credential. Signing with the CA root certificate private key ensures the authenticity of the authorization credential's origin and that its content has not been tampered with during transmission. The authorization credential itself is a digital file or data packet containing instructions to unlock the vehicle or authorization information; it serves as the sole valid credential for unlocking. Clearing the lock character involves deleting, overwriting, or invalidating the lock character stored in the read-only physical partition of the associated memory managed by the processing module. Once the lock character is cleared, the robot can reactivate its walking component drive circuits, release mechanical braking components, and resume normal movement and function.

[0272] In this way, the robot can receive authorization credentials sent by the server, signed by the CA root certificate's private key. This mechanism ensures that only highly trusted and authenticated commands can trigger the unlocking of the secure lock, greatly enhancing the security, reliability, and traceability of the unlocking process.

[0273] A specific example is provided in conjunction with the above embodiments for illustration.

[0274] The method for remote monitoring and fault self-diagnosis of a robot described in this invention has the following core execution flow: Figure 2 The specific steps are described in detail below:

[0275] Step S201: High-frequency acquisition of remote telemetry data at the edge.

[0276] The Robot Integrated Controller (RICU) collects its own multi-dimensional telemetry data at high frequency in the background. Specifically, it directly reads the data from each physical sensor chip (IMU, wheel speed sensor, CAN communication status) through the MCU and transmits this low-level physical data to the MPU side via a dual-core physical SPI bus and DMA channel. The diagnostic module within the MPU is responsible for collecting information on the operating system kernel load, CPU / memory usage quotas for each container sandbox, disk I / O, and the running status of core AI applications (such as SLAM and MASSAgent).

[0277] Step S202: Multi-level analysis of the diagnostic matrix and local heartbeat verification.

[0278] The multi-level hierarchical fault self-check and diagnosis matrix performs a joint comparison of the multi-dimensional state variables collected in step S201.

[0279] Local dual-core skip check: A hardware watchdog mechanism is maintained between the MCU and MPU, and a handshake is performed once per second.

[0280] Shared memory heartbeat verification: Inside the MPU, the diagnostic matrix polls the timed incrementing sequence number written by each algorithm container through the shared memory area of ​​the cross-sandbox shared context management unit.

[0281] If it is determined that the serial number of a specific container (such as the MASS Agent container) has not changed within 3 consecutive periods (such as 6 seconds), and the diagnostic interface response times out, the corresponding judgment mechanism is triggered.

[0282] Step S203: State decision branch logic judgment.

[0283] Based on the fault level, the system executes the corresponding local self-healing decision path:

[0284] If an event level of Level 2 (minor fault) is detected, proceed to step S204 (perform a software-free hot restart).

[0285] If an event level of Level 3 (major fault) is detected, proceed to step S205 (execute local degradation risk avoidance);

[0286] If the local system receives a RaaS commercial locking / active anti-theft vehicle locking command from the cloud, it proceeds to step S206.

[0287] Step S204: Sandbox-level, second-level container hot restart mechanism.

[0288] The MPU's internal dynamic scheduler and container loading engine perform partial cold restarts on containers that have deadlocked (such as sandbox B, MASS Agent):

[0289] 1. The container loading engine issues a forced restart command to the Linux kernel container runtime, destroying the abnormal sandbox and reclaiming the occupied resources within 300 milliseconds.

[0290] 2. The engine reads the algorithm image from the local non-volatile storage repository (such as the protected image area of ​​the local EMMC), and starts and loads it into memory within seconds (reinitializing the VLM inference process, which takes less than 1.5 seconds).

[0291] 3. During the restart of sandbox B, navigation and obstacle avoidance sandbox A continues to read the IMU and chassis motor wheel speed from the real-time microcontroller through the shared memory management unit, and maintains bias-maintaining driving with small steps, so that the robot does not have obvious physical stops.

[0292] 4. After sandbox B is rebuilt, communication and telemetry are restored normally. Proceed to step S201 to continue routine polling.

[0293] Step S205: Local risk avoidance and navigation degradation processing.

[0294] In case of Level 3 faults such as loss of radar communication or failure of global positioning:

[0295] 1. The robot autonomous task manager interrupts the current patrol operation and hands over the robot motion control to the redundant safety and avoidance module (using only local ultrasonic waves and IMU inertial navigation for local control).

[0296] 2. The task manager uses ultrasonic waves to detect the boundaries of surrounding obstacles, enabling the vehicle to move to the nearest edge at a very low speed (less than 0.2 m / s) and find a clear and flat location (slope angle less than 3 degrees, avoiding the center of the road network).

[0297] 3. The MCU sends a control command to cut off the power supply to the power drive and pull up the mechanical parking brake solenoid valve.

[0298] 4. If the signal is still available, report to the cloud that "the robot has suspended its operation to take nearby safety precautions due to a Level 3 physical fault".

[0299] Step S206: Two-stage physical security vehicle locking control.

[0300] When the cloud control platform detects contract termination, physical loss, or a major security vulnerability requiring forced vehicle locking:

[0301] 1. The cloud platform issues the first phase of pre-authorized data packet: containing a lock command signature encrypted with DES3 or SM2, as well as the estimated latitude and longitude of the vehicle to be locked.

[0302] 2. Local physical verification initiated: The robot task manager receives the instruction and enters the "Autonomous Sidewalk Stop Verification" process. This includes:

[0303] Read the IMU attitude angle sensor to determine the pitch and roll angles. (Verify the vehicle's gravity to ensure there is no possibility of slippage or loss of control due to downhill slopes or severe tilting).

[0304] After driving to a flat, safe area (not in an emergency zone), gradually reduce the duty cycle of the PWM waveform to control the vehicle's smooth deceleration and ensure the vehicle speed is maintained.

[0305] The electromechanical parking system is engaged.

[0306] 3. Send a readiness confirmation. The robot sends a confirmation message to the cloud via the network.

[0307] Step S207: Deploy physical hardware lock and non-volatile secure storage.

[0308] 1. After receiving confirmation, the cloud server sends out the second-stage encryption lock packet.

[0309] 2. The edge-side real-time microcontroller (MCU) implements a hardware lock mechanism at the physical layer:

[0310] Set the physical I / O pin to low level to cut off the enable logic of the high-power chassis motor drive MOSFET and the high-voltage relay;

[0311] Completely lock the mechanical brake holding logic;

[0312] The onboard non-volatile secure memory (EEPROM) secure write mechanism is activated to write the encrypted Immobilize Token sent from the cloud to a specific write-protected partition.

[0313] 3. The data in this memory can only be unlocked and rewritten using a decryption algorithm after authentication with the cloud private key. Even if there is a power outage and restart, disconnection of the network cable, replacement of the vehicle peripheral system, or forced removal of the chassis, as long as the vehicle lock flag in the EEPROM is not cleared, the MCU will still lock the driver enable during the self-test upon restart, completely eliminating the risk of the hardware being resold or used illegally again, perfectly protecting the legal and physical rights of the RaaS asset owner.

[0314] This disclosure provides a robot, which includes a processing module comprising a microcontroller and an application processor. The microcontroller is used to check the hardware heartbeat signal of the application processor. The application processor is used to partition mutually isolated processing resource sandboxes for each application function module. The processing module is used for:

[0315] Determine the type of the current fault;

[0316] Based on the fault type, a processing strategy corresponding to the fault type is adopted.

[0317] In some embodiments, the processing module is specifically configured to: in response to a fault type of a first type, send a first fault notification to the user and maintain robot movement.

[0318] In some embodiments, the processing module is specifically configured to: in response to the current fault being a fault of at least one application function module, determine the fault type as a second type;

[0319] In response to the fault type being the second type, the processing resource sandbox corresponding to the application function module that experienced the fault is reset.

[0320] In some embodiments, the processing module is specifically used for:

[0321] In response to a hardware failure in the robot's pose sensing, the failure type is determined to be the third type;

[0322] In response to the fault type being type 3, perform at least one of the following:

[0323] The robot is controlled to move to a first safe position, which meets a predetermined safety requirement;

[0324] The robot is positioned in the first safe position, and the robot's driving power is cut off;

[0325] The robot is positioned in a first safe position, and a brake is used to brake the robot.

[0326] Send a second fault notification to the user.

[0327] In some embodiments, the processing module is specifically configured to: determine the fault type as a fourth type in response to determining at least one of the following: the microcontroller has not detected the hardware heartbeat signal of the application processor within a predetermined period of time, or the robot battery temperature exceeds a temperature threshold;

[0328] In response to the fault type being type four, perform at least one of the following:

[0329] The robot is braked using a brake;

[0330] Power is cut off from the positioning module and the alarm module, wherein the positioning module is used to determine the position of the robot, and the alarm module is used to send a third fault prompt to the user.

[0331] In some embodiments, the robot further includes a transceiver module.

[0332] The transceiver module is used to: receive the first-stage vehicle locking command sent by the robot's associated server;

[0333] The processing module is also used to perform a safe posture adjustment in response to the first-stage vehicle locking command;

[0334] The transceiver module is also configured to: send a safety ready confirmation to the server in response to completing the safety pose adjustment;

[0335] The transceiver module is also used to: receive the second-stage vehicle locking command sent by the robot's server;

[0336] The processing module is also used to execute a secure vehicle lock in response to the second-stage vehicle lock command.

[0337] In some embodiments, the processing module specifically includes at least one of the following:

[0338] Control the robot to move to a position that meets the flatness requirements;

[0339] Control the robot to move to a position that meets safety requirements;

[0340] Adjust the robot's movement speed to a predetermined speed.

[0341] In some embodiments, the processing module specifically includes at least one of the following:

[0342] Disconnect the circuit of the robot's walking component drive circuit;

[0343] The mechanical braking components are controlled to keep the robot's walking components in a locked state;

[0344] A lock character is written to the read-only physical partition of the associated memory managed by the processing module. The lock character is used to indicate the execution of the security lock.

[0345] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0346] In some embodiments, the processing module is further configured to:

[0347] Upon receiving an authorization credential signed by the server's CA root certificate private key, the response should clear the lock character to unlock the vehicle.

[0348] This disclosure provides a robot-associated server, which includes a processing module and a transceiver module, wherein:

[0349] The transceiver module is used to: send a first-stage vehicle locking command to the robot, the first-stage vehicle locking command being used to instruct the robot to perform a safe posture adjustment;

[0350] The processing module is configured to: in response to the transceiver module receiving a safety readiness confirmation sent by the robot, send a second-stage locking command to the robot, the second-stage locking command being used to instruct the robot to perform a safety locking operation; wherein the safety readiness confirmation is sent when the robot completes the safety pose adjustment.

[0351] In some embodiments, the robot performs a safety locking operation, including at least one of the following:

[0352] The robot moves to a position that meets the flatness requirements;

[0353] The robot moves to a position that meets safety requirements;

[0354] The robot adjusts its movement speed to a predetermined speed.

[0355] In some embodiments, the robot performing the safety locking of the vehicle includes at least one of the following:

[0356] The robot disconnects the circuit of the walking component drive circuit;

[0357] The robot control mechanical braking component keeps the robot walking component in a locked state;

[0358] A lock character is written to the read-only physical partition of the associated memory managed by the robot's processing module. The lock character is used to indicate the execution of the safety lock.

[0359] In some embodiments, the locking character includes a character encrypted using a predetermined encryption method.

[0360] In some embodiments, the transceiver module is further configured to: send an authorization credential signed by the private key of the server's CA root certificate to the robot, wherein the authorization credential is used to clear the lock character to unlock the vehicle.

[0361] This disclosure provides an electronic device, the electronic device comprising:

[0362] One or more processors;

[0363] The processor is used to invoke instructions to cause the electronic device to execute the robot fault handling method described in any of the above embodiments.

[0364] This disclosure provides a storage medium storing instructions that, when executed on an electronic device, cause the electronic device to perform the robot fault handling method described in any of the above embodiments.

[0365] It should be understood that the division of units or modules in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units or modules in the device can be implemented by a processor calling software: for example, the device includes a processor connected to a memory containing instructions. The processor calls the instructions stored in the memory to implement any of the above methods or to implement the functions of the units or modules in the above device. The processor can be, for example, a general-purpose processor, such as a Central Processing Unit (CPU) or a microprocessor, and the memory can be internal or external to the device. Alternatively, the units or modules in the device can be implemented in the form of hardware circuits. The functionality of some or all of the units or modules can be achieved through the design of these hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an application-specific integrated circuit (ASIC), and the functionality of some or all of the units or modules is achieved through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a programmable logic device (PLD), such as a field-programmable gate array (FPGA), which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby achieving the functionality of some or all of the units or modules. All units or modules of the above device can be implemented entirely through processor-called software, entirely through hardware circuits, or partially through processor-called software with the remaining parts implemented through hardware circuits.

[0366] In this disclosure, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a Central Processing Unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a type of microprocessor), or a digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. The logical relationships of the aforementioned hardware circuits are fixed or reconfigurable. For example, the processor is a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units or modules. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a Neural Network Processing Unit (NPU), a Tensor Processing Unit (TPU), a Deep Learning Processing Unit (DPU), etc.

[0367] Figure 3 This is a schematic diagram of the structure of the electronic device 9100 provided in this embodiment. The electronic device 9100 can be a computer terminal, a server, a chip, chip system, or processor that supports any of the above methods, or a chip, chip system, or processor that supports the terminal in implementing any of the above information transmission methods. The electronic device 9100 can be used to implement the robot fault handling method described in the above method embodiments; please refer to the description in the above method embodiments for details.

[0368] like Figure 3 As shown, the electronic device 9100 includes one or more processors 9101. The processor 9101 can be a general-purpose processor or a special-purpose processor, etc. The processor 9101 is used to invoke instructions to cause the electronic device 9100 to execute any of the above-mentioned robot fault handling methods.

[0369] In some embodiments, the electronic device 9100 further includes one or more memories 9102 for storing instructions. Optionally, all or part of the memories 9102 may also be located outside the electronic device 9100.

[0370] In some embodiments, the electronic device 9100 further includes one or more transceivers 9103. When the electronic device 9100 includes one or more transceivers 9103, the steps of sending, receiving and / or acquiring in the above method are performed by the transceivers 9103, and the other steps are performed by the processor 9101.

[0371] In some embodiments, the acquisition steps in the above method can also be executed by the processor 9101, for example, acquiring information from the memory 9102.

[0372] Optionally, the electronic device 9100 further includes one or more interface circuits 9104 connected to the memory 9102. The interface circuits 9104 can be used to receive signals from the memory 9102 or other devices, and can be used to send signals to the memory 9102 or other devices. For example, the interface circuits 9104 can read instructions stored in the memory 9102 and send the instructions to the processor 9101.

[0373] The electronic device 9100 described in the above embodiments may be a network device or a terminal, but the scope of the electronic device 9100 described in this disclosure is not limited thereto, and the structure of the electronic device 9100 may vary. Figure 3 There are limitations. Electronic devices can be standalone devices or part of a larger device.

[0374] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program commands. The aforementioned program can be stored in a storage medium, including various media capable of storing program code such as mobile storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks or optical disks.

[0375] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several commands to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, RAM, magnetic disks, or optical disks.

[0376] It should be understood that the above embodiments are exemplary and are not intended to encompass all possible implementations included in the claims. Various modifications and changes can be made to the above embodiments without departing from the scope of this disclosure. Similarly, the various technical features of the above embodiments can be arbitrarily combined to form other embodiments of the present invention that may not be explicitly described. Therefore, the above embodiments only illustrate several implementations of the present invention and do not limit the scope of protection of this patent.

Claims

1. A robot fault handling method, characterized in that, The invention is applied to a robot, which includes a processing module comprising a microcontroller and an application processor, wherein the microcontroller is used to check the hardware heartbeat signal of the application processor. The application processor is used to partition isolated processing resource sandboxes for each application functional module, and the method includes: Determine the type of the current fault; Based on the fault type, a processing strategy corresponding to the fault type is adopted.

2. The robot fault handling method according to claim 1, characterized in that, The step of adopting a processing strategy corresponding to the fault type based on the fault type includes: in response to the fault type being a first type, sending a first fault prompt to the user and maintaining robot movement; or, The step of determining the fault type of the current fault includes: in response to the current fault being a fault of at least one application function module, determining the fault type as a second type; the step of adopting a processing strategy corresponding to the fault type based on the fault type includes: in response to the fault type being the second type, resetting the processing resource sandbox corresponding to the application function module that has malfunctioned; or, The step of determining the fault type of the current fault includes: in response to a hardware fault in the robot's pose sensor, determining the fault type as a third type; the step of adopting a processing strategy corresponding to the fault type includes: in response to the fault type being a third type, performing at least one of the following: controlling the robot to move to a first safe position, the first safe position meeting predetermined safety requirements; when the robot is in the first safe position, cutting off the robot's drive power; when the robot is in the first safe position, using a brake to brake the robot; sending a second fault prompt to the user; or, The step of determining the fault type of the current fault includes: determining the fault type as a fourth type in response to determining at least one of the following: the microcontroller does not detect the hardware heartbeat signal of the application processor within a predetermined period of time, or the robot battery temperature exceeds a temperature threshold; the step of adopting a processing strategy corresponding to the fault type based on the fault type includes: in response to the fault type being a fourth type, performing at least one of the following: braking the robot with a brake; cutting off the power supply except for the positioning module and the alarm module, wherein the positioning module is used to determine the position of the robot, and the alarm module is used to send a third fault prompt to the user.

3. The robot fault handling method according to any one of claims 1 to 2, characterized in that, The method further includes at least one of the following: Receive the first-stage vehicle locking command sent by the robot's associated server and perform a safe pose adjustment; In response to the completion of safe pose adjustment, a safe ready confirmation is sent to the server; The robot receives a second-stage locking command from its server and executes a safe locking mechanism.

4. The robot fault handling method according to claim 3, characterized in that, The execution of safe pose adjustment includes at least one of the following: Control the robot to move to a position that meets the flatness requirements; Control the robot to move to a position that meets safety requirements; Adjust the robot's movement speed to the predetermined speed; or, The execution of the vehicle safety lock includes at least one of the following: Disconnect the circuit of the robot's walking component drive circuit; The mechanical braking components are controlled to keep the robot's walking components in a locked state; A lock character is written to the read-only physical partition of the associated memory managed by the processing module. The lock character is used to indicate the execution of the security lock.

5. The robot fault handling method according to claim 4, characterized in that, The locked characters include: characters encrypted using a predetermined encryption method; The method further includes: in response to receiving an authorization credential signed by the private key of the server's CA root certificate sent by the server, clearing the lock character to unlock the vehicle.

6. A robot fault handling method, characterized in that, The method, applied to a server-side application for robot association, includes: Send a first-stage vehicle locking command to the robot, the first-stage vehicle locking command being used to instruct the robot to perform a safe pose adjustment; In response to receiving a safety readiness confirmation from the robot, a second-stage locking command is sent to the robot, which instructs the robot to perform a safety locking operation; wherein the safety readiness confirmation is sent by the robot after completing the safety pose adjustment.

7. The robot fault handling method according to claim 6, characterized in that, The robot performs a safety locking operation, including at least one of the following: The robot moves to a position that meets the flatness requirements; The robot moves to a position that meets safety requirements; The robot adjusts its movement speed to a predetermined speed; or, The robot performing the safety locking of the vehicle includes at least one of the following: The robot disconnects the circuit of the walking component drive circuit; The robot control mechanical braking component keeps the robot walking component in a locked state; A lock character is written to the read-only physical partition of the associated memory managed by the robot's processing module. The lock character is used to indicate the execution of the safety lock.

8. The robot fault handling method according to claim 7, characterized in that, The locked characters include: characters encrypted using a predetermined encryption method; The method further includes sending an authorization credential signed by the private key of the server's CA root certificate to the robot, wherein the authorization credential is used to clear the lock character to unlock the vehicle.

9. A robot, characterized in that, Applied to robots, the robot includes a processing module, which comprises a microcontroller and an application processor. The microcontroller is used to check the hardware heartbeat signal of the application processor. The application processor is used to partition mutually isolated processing resource sandboxes for each application function module. The processing module is used for: Determine the type of the current fault; Based on the fault type, a processing strategy corresponding to the fault type is adopted.

10. A server-side application for robot association, characterized in that, The server includes a processing module and a send / receive module, wherein... The transceiver module is used to: send a first-stage vehicle locking command to the robot, the first-stage vehicle locking command being used to instruct the robot to perform a safe posture adjustment; The processing module is configured to: in response to the transceiver module receiving a safety readiness confirmation sent by the robot, send a second-stage locking command to the robot, the second-stage locking command being used to instruct the robot to perform a safety locking operation; wherein the safety readiness confirmation is sent when the robot completes the safety pose adjustment.

Images