Robot anomaly handling methods, devices, robots and media

Abstract

This invention discloses a robot anomaly handling method, device, robot, and medium. The method includes: when a robot performing a cleaning task in a defined target area experiences a cleaning anomaly, acquiring the robot's anomaly log and determining the anomaly type based on the log; if the anomaly type is a hardware anomaly, acquiring the hardware status information of all the robot's hardware; identifying the faulty hardware from all the hardware based on the hardware status information, and determining the recoverability of the faulty hardware according to a first preset rule; if the faulty hardware is recoverable, determining whether the robot is trapped according to a second preset rule; if the robot is not trapped, and if the hardware status information of the faulty hardware contains false alarm data, indicating that the hardware anomaly is a false alarm, and continuing the cleaning task. This invention reduces excessive consumption of manual resources and improves the ease of use of the robot vacuum cleaner.

Description

Technical Field

[0001] This invention relates to the field of robotics, and in particular to a method, apparatus, robot, and medium for handling robot anomalies. Background Technology

[0002] Robots (such as robotic vacuum cleaners) are a type of smart home appliance that can automatically clean floors both indoors and outdoors using a certain level of artificial intelligence. In current technology, robotic vacuum cleaners are prone to failing to complete cleaning tasks in complex environments. When this happens, they often remain in standby mode, and because the cause of the failure cannot be determined, manual intervention is usually required. However, this manual intervention leads to excessive consumption of human resources and reduces the ease of use of the robotic vacuum cleaner. Summary of the Invention

[0003] Therefore, it is necessary to provide a robot anomaly handling method, device, robot, and medium to address the aforementioned technical problems, in order to solve the problems of excessive consumption of human resources and reduced ease of use of sweeping robots.

[0004] A robot anomaly handling method, comprising:

[0005] When a cleaning abnormality occurs while a robot performing a cleaning task in a defined target area, the robot's abnormality log is retrieved, and the abnormality type is determined based on the abnormality log.

[0006] When the anomaly type is hardware anomaly, obtain the hardware status information of all hardware of the robot;

[0007] Based on the hardware status information, identify abnormal hardware from all the hardware and determine the recoverability of the abnormal hardware according to a first preset rule.

[0008] When the recoverability of the abnormal hardware is recoverable, it is determined whether the robot is in a trapped state according to the second preset rule;

[0009] If the robot is not trapped, and it is determined that there is false alarm data in the hardware status information of the abnormal hardware, then the robot is prompted that the hardware abnormality is a false alarm, and the cleaning task continues to be executed.

[0010] An anomaly handling device includes:

[0011] The first determining module is used to obtain the robot's abnormality log when a cleaning abnormality occurs in a determined target area, and to determine the abnormality type based on the abnormality log;

[0012] The acquisition module is used to acquire the hardware status information of all hardware of the robot when the exception type is hardware exception;

[0013] The second determining module is used to determine the abnormal hardware that is abnormal from all the hardware based on the hardware status information, and to determine the recoverability of the abnormal hardware according to the first preset rule.

[0014] The third determining module is used to determine whether the robot is in a trapped state according to a second preset rule when the recoverability of the abnormal hardware is recoverable.

[0015] The processing module is configured to, when the robot is not in a trapped state, if it is determined that there is false alarm data in the hardware status information of the abnormal hardware, indicate that the hardware abnormality of the robot is a false alarm, and continue to execute the cleaning task.

[0016] A robot includes a control module, the control module being used to execute the steps of the above-described robot anomaly handling method.

[0017] A computer-readable storage medium storing a computer program, characterized in that, when executed by a processor, the computer program implements the steps of the above-described robot anomaly handling method.

[0018] In this invention, when a cleaning malfunction occurs in the robot, and the malfunction type is determined to be a hardware malfunction through the malfunction log and hardware status information, and it is confirmed that the hardware malfunction is recoverable and the robot is not stuck, if it is determined that there is false alarm data in the hardware status information of the malfunctioning hardware, then the robot is prompted that the hardware malfunction is a false alarm, and the controller continues to execute the cleaning task. In this invention, after analyzing the robot's malfunction log and hardware status information, the cause of the cleaning failure can be clearly identified. Furthermore, with a clear cause of failure, manual intervention is not always necessary, and the robot can restart the cleaning task without manual troubleshooting. This reduces excessive consumption of human resources and improves the ease of use of the robot vacuum cleaner. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating a robot anomaly handling method according to an embodiment of the present invention.

[0021] Figure 2 This is a flowchart illustrating step S300 of a robot anomaly handling method in one embodiment of the present invention.

[0022] Figure 3 This is a flowchart illustrating step S400 of a robot anomaly handling method in one embodiment of the present invention.

[0023] Figure 4 This is a flowchart illustrating a robot anomaly handling method in another embodiment of the present invention.

[0024] Figure 5 This is a flowchart illustrating a robot anomaly handling method in another embodiment of the present invention.

[0025] Figure 6 This is a flowchart illustrating a robot anomaly handling method in another embodiment of the present invention.

[0026] Figure 7 This is a schematic diagram of the structure of an anomaly handling device in one embodiment of the present invention. Detailed Implementation

[0027] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] like Figure 1 As shown, in one embodiment, a robot anomaly handling method is provided, including the following steps:

[0029] S100: When a cleaning abnormality occurs while the robot performing a cleaning task in the target area, the robot's abnormality log is obtained, and the abnormality type is determined based on the abnormality log. The target area refers to the area where the robot is currently performing a cleaning task. The cleaning abnormality includes hardware abnormalities and software abnormalities, etc. The software abnormality includes communication abnormalities, etc. Understandably, the cleaning abnormality is essentially an exception that can cause the robot's cleaning task to fail.

[0030] In one embodiment, step S100, which involves obtaining the robot's exception log and determining the exception type based on the exception log, includes:

[0031] S110: After removing map data transmission logs from all log data of the robot, extract the abnormal logs from the remaining log data, and determine the abnormal type of the robot based on the last entry in the abnormal logs. The robot's log data includes cleaning map data transmission logs and other types of logs, such as hardware-related logs and software-related logs. Specifically, in this embodiment, to reduce data processing volume, the abnormal type (hardware or communication) is determined only based on the last log entry. If the last log entry is cleaning map data, it's impossible to determine whether the abnormal type is hardware or communication. Therefore, it's necessary to first remove map data transmission logs from all log data, and then identify the remaining log data as abnormal logs. In this case, hardware-related logs are hardware abnormal logs, and software-related logs are software abnormal logs (such as communication abnormal logs).

[0032] In one embodiment, the hardware anomaly log includes, but is not limited to, log information recorded by the robot when a hardware current or voltage abnormality occurs; the communication anomaly log includes, but is not limited to, log information regarding access timeouts caused by network problems when the robot interacts with the cloud server. Understandably, if the last entry in the anomaly log is a hardware anomaly log, the robot's anomaly type is determined to be a hardware anomaly; if the last entry in the anomaly log is a software anomaly log, the robot's anomaly type is determined to be a software anomaly; and if the last entry in the anomaly log is a communication anomaly log, the robot's anomaly type is determined to be a communication anomaly.

[0033] S200, when the anomaly type is hardware anomaly, acquire the hardware status information of all hardware of the robot. Understandably, when the anomaly type is hardware anomaly, the faulty hardware may be recoverable. Therefore, it is necessary to acquire the hardware status information of all hardware of the robot. The hardware status information of all hardware is used to determine the recoverability of the faulty hardware and can be directly acquired by the robot's control module during operation.

[0034] S300: Based on the hardware status information, identify the faulty hardware from all the hardware, and determine the recoverability of the faulty hardware according to a first preset rule. Understandably, the faulty hardware may be recoverable by restarting; therefore, it is necessary to determine the recoverability of the faulty hardware according to the first preset rule, which may refer to further judgment by restarting the faulty hardware.

[0035] like Figure 2As shown, in one embodiment, step S300, determining the recoverability of the faulty hardware according to a first preset rule, includes:

[0036] S310, control the robot to restart the faulty hardware, and determine whether the faulty hardware has returned to normal. That is, the first preset rule mentioned above is to further determine its recoverability by restarting the faulty hardware.

[0037] S320, if the faulty hardware returns to normal, then the recoverability of the faulty hardware is determined to be recoverable. Understandably, if the faulty hardware returns to normal after restarting, then the recoverability of the faulty hardware is determined to be recoverable. For example: Due to external environmental factors, the robot's wheelset may become stuck, causing the wheelet motor to generate low current, thus generating a low current hardware fault log; after restarting the wheelet motor, if the hardware status information shows that the wheelet motor has returned to normal, then the recoverability of the wheelet motor can be determined to be recoverable.

[0038] S330, if the faulty hardware does not return to normal, then the recoverability of the faulty hardware is determined to be unrecoverable. Understandably, if the faulty hardware does not return to normal after restarting, then the recoverability of the faulty hardware is determined to be unrecoverable. For example: if a robot's fan is damaged, resulting in no current in the fan, a hardware fault log of no current is generated; after restarting the fan, if the hardware status information shows that the fan still cannot be started, then the recoverability of the fan can be determined to be unrecoverable.

[0039] S400, when the recoverability of the abnormal hardware is recoverable, determine whether the robot is in a trapped state according to a second preset rule. Understandably, since the recoverability of the abnormal hardware is recoverable, it is necessary to determine whether the robot is in a trapped state according to the second preset rule. The second preset rule may refer to further judgment based on the robot's abnormal log and / or the relationship between the cleaning map and the current position.

[0040] like Figure 3 As shown, in one embodiment, step S400, determining whether the robot is trapped according to a second preset rule, includes:

[0041] S410, determine whether the robot's current coordinates belong to a prohibited area marked on the cleaning map, and simultaneously determine whether there are any entanglement or jamming logs in the robot's error log. Understandably, the prohibited area includes tangible obstacles (e.g., walls, tables, or sofas) or intangible obstacles (e.g., user-set electronic fences) marked on the cleaning map. When the robot is in such a prohibited area, it is easily trapped and unable to continue cleaning. That is, the second preset rule refers to determining whether the robot is trapped within a prohibited area by checking whether its current coordinates belong to one, and simultaneously determining whether it is trapped by checking whether there are any entanglement or jamming logs in the robot's error log.

[0042] S420: If the robot's current coordinates fall within a prohibited area marked on the cleaning map, or if the robot's error log contains entries indicating entanglement or jamming, the robot is determined to be in a trapped state. If the robot's current coordinates fall within a prohibited area marked on the cleaning map, the robot is determined to be trapped by that prohibited area. Furthermore, if the robot's error log contains entries indicating entanglement or jamming, the robot is also determined to be trapped by an entangled or jammed object.

[0043] S430, if the robot's current coordinates do not belong to the prohibited area marked in the cleaning map, and there are no entanglement or jamming logs in the robot's anomaly log, it is determined that the robot is not in a trapped state. Understandably, if the recoverability of the faulty hardware is recoverable, meaning that the faulty hardware returns to normal after restarting, and the robot's current coordinates do not belong to the prohibited area marked in the cleaning map, and there are no entanglement or jamming logs in the robot's anomaly log, then it can be determined that the robot is not in a trapped state. That is, the hardware anomaly report corresponding to the faulty hardware may be a false alarm. In this case, it can be further determined whether the hardware anomaly is a false alarm based on whether there is false alarm data in the hardware status information of the faulty hardware. If so, the cleaning task can continue; if not, it may be necessary to report to a preset reporting party for further processing.

[0044] S500: If, when the robot is not trapped, it is determined that there is false alarm data in the hardware status information of the abnormal hardware, then the robot's hardware abnormality is indicated as a false alarm, and the cleaning task continues to be executed. It can be understood that if the robot is not trapped, meaning its current coordinates are not within a prohibited area marked on the cleaning map, and it is not entangled or stuck, and the hardware status information of the abnormal hardware contains false alarm data, then the robot's hardware abnormality is a false alarm. In this case, the robot has not actually experienced a hardware abnormality, so the cleaning task can continue to be executed. Furthermore, the false alarm warning for the robot can be lifted (i.e., the warning about the hardware abnormality can be lifted, and the robot's hardware abnormality can be further indicated as a false alarm), and the robot's working state can be restored (i.e., the robot can be controlled to continue executing the cleaning task).

[0045] The robot anomaly handling method provided by this invention, when a cleaning anomaly occurs in the robot, determines the anomaly type to be a hardware anomaly through anomaly logs and hardware status information. If it is confirmed that the hardware anomaly is recoverable and the robot is not stuck, and if false alarm data is found in the hardware status information of the faulty hardware, the robot is alerted that the hardware anomaly is a false alarm, and the controller continues to execute the cleaning task. In this process, after analyzing the robot's anomaly logs and hardware status information, the cause of the cleaning failure can be clearly identified. With a clear cause, manual intervention is not always necessary, and the robot can restart the cleaning task without manual investigation. This reduces excessive consumption of human resources and improves the ease of use of the robot vacuum cleaner.

[0046] like Figure 4 As shown, in one embodiment, after determining the exception type based on the exception log in step S100, the method further includes:

[0047] S600, when the exception type is a communication exception, the robot is controlled to standby in place and save the current cleaning data, while simultaneously performing a network communication recovery operation. Understandably, a robot communication exception can lead to the loss of cleaning map data, thus causing the robot to fail to clean. In this case, the robot will standby in place and save the current cleaning data, while simultaneously performing a network communication recovery operation, such as re-initiating a communication connection request.

[0048] S700, when the robot regains network communication, the cleaning task is updated based on the current cleaning data. It can be understood that if the robot regains network communication, it can re-acquire the cleaning map data via the network; therefore, the robot can update the cleaning task based on the current cleaning data.

[0049] like Figure 5 As shown, in one embodiment, after determining the recoverability of the abnormal hardware according to the first preset rule in step S300, the method further includes:

[0050] S800: When the recoverability of the faulty hardware is deemed unrecoverable, the robot is controlled to remain in standby mode and a hardware repair request for the faulty hardware is sent to a preset recipient. Understandably, if the recoverability of the faulty hardware is deemed unrecoverable, meaning the faulty hardware does not return to normal after restarting, the robot cannot continue performing the cleaning task and needs to remain in standby mode while sending a hardware repair request for the faulty hardware to a preset recipient. The preset recipient includes, but is not limited to, the client terminal corresponding to the operator.

[0051] like Figure 6 As shown, in one embodiment, after determining whether the robot is trapped according to the second preset rule in step S400, the method further includes:

[0052] S900, when the robot is in a stuck state, the robot is controlled to remain in standby mode and send abnormal information containing abnormal coordinates to a preset reporting party. The preset reporting party then marks the abnormal coordinates on the cleaning map based on the abnormal information and performs abnormal handling. The cleaning map refers to a map containing the target area; the abnormal coordinates refer to the current position coordinates of the robot when the hardware malfunction occurs. It is understood that when the robot is in a stuck state, even if the abnormal hardware restarts and returns to normal, the robot still cannot continue performing the cleaning task. Therefore, it is necessary to make the robot remain in standby mode and send abnormal information containing abnormal coordinates to a preset reporting party. This allows the preset reporting party to mark the abnormal coordinates on the cleaning map based on the abnormal information and perform abnormal handling. The preset reporting party includes, but is not limited to, modules used to store and process cleaning map data, such as cloud servers, base stations, data modules inside the robot, or client terminals corresponding to the operator. After marking the abnormal coordinates on the cleaning map, the robot can avoid the abnormal coordinate locations when performing subsequent cleaning tasks. The abnormality handling includes, but is not limited to, sending a prompt message to the user indicating that the robot is stuck, thereby reminding the operator to go to the location where the robot is stuck to handle the situation.

[0053] In one embodiment, step S900, the execution of exception handling, includes:

[0054] S910, a prompt message indicating the robot's trapped status is sent to a preset recipient, and the cleaning map containing the abnormal coordinates is displayed to the preset recipient. Understandably, the trapped status prompt message includes abnormal coordinates so that the preset recipient knows the specific location where the robot is trapped and can then proceed to that location to handle the situation. The preset recipient includes, but is not limited to, the client terminal corresponding to the operator; the cleaning map can be displayed on the display interface of the preset recipient's client terminal (e.g., a mobile app) to show the abnormal coordinates marked on the cleaning map.

[0055] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0056] like Figure 7 As shown, in one embodiment, an anomaly handling device is also provided, which corresponds one-to-one with the robot anomaly handling methods in the above embodiments. Specific limitations of the anomaly handling device can be found in the limitations of the robot anomaly handling methods above, and will not be repeated here. The anomaly handling device includes:

[0057] The first determining module 100 is used to obtain the robot's abnormal log when a cleaning abnormality occurs in a robot performing a cleaning task in a determined target area, and to determine the abnormality type based on the abnormal log.

[0058] The acquisition module 200 is used to acquire the hardware status information of all hardware of the robot when the exception type is hardware exception;

[0059] The second determining module 300 is used to determine the abnormal hardware that is abnormal from all the hardware according to the hardware status information, and to determine the recoverability of the abnormal hardware according to the first preset rule.

[0060] The third determining module 400 is used to determine whether the robot is in a trapped state according to a second preset rule when the recoverability of the abnormal hardware is recoverable.

[0061] The processing module 500 is configured to, when the robot is not in a trapped state, if it is determined that there is false alarm data in the hardware status information of the abnormal hardware, indicate that the hardware abnormality of the robot is a false alarm, and continue to execute the cleaning task.

[0062] In one embodiment, the exception handling device further includes:

[0063] The execution module is used to control the robot to standby in place and save the current cleaning data when the abnormality type is communication abnormality, and at the same time perform network communication recovery operation;

[0064] An update module is used to update the cleaning task based on the current cleaning data when the robot regains network communication.

[0065] In one embodiment, the exception handling device further includes:

[0066] The first sending module is used to control the robot to standby in place and send a hardware repair request for the abnormal hardware to a preset receiver when the recoverability of the abnormal hardware is unrecoverable.

[0067] In one embodiment, the exception handling device further includes:

[0068] The second sending module is used to control the robot to standby in place when the robot is in a trapped state, and to send abnormal information containing abnormal coordinates to a preset reporting party, so that the preset reporting party can mark the abnormal coordinates in the cleaning map and perform abnormal processing according to the abnormal information; the cleaning map refers to a map containing the target area; the abnormal coordinates refer to the current position coordinates of the robot when the hardware abnormality occurs.

[0069] In one embodiment, the second determining module 300 includes:

[0070] The control submodule is used to control the restart of the abnormal hardware of the robot and determine whether the abnormal hardware has returned to normal.

[0071] The first determining submodule is used to determine the recoverability of the abnormal hardware as recoverable if the abnormal hardware recovers to normal.

[0072] The second determining submodule is used to determine that the recoverability of the abnormal hardware is unrecoverable if the abnormal hardware fails to recover to normal.

[0073] In one embodiment, the third determining module 400 includes:

[0074] The judgment submodule is used to determine whether the current coordinate position of the robot belongs to the prohibited area marked in the cleaning map, and at the same time determine whether there are entanglement or jamming logs in the robot's abnormal log.

[0075] The third determination submodule is used to determine that the robot is in a trapped state when the robot's current coordinate position belongs to a prohibited area marked in the cleaning map, or when there is an entanglement or jamming log in the robot's abnormal log.

[0076] The fourth determination submodule is used to determine that the robot is not in a trapped state when the robot's current coordinate position does not belong to the prohibited area marked in the cleaning map and there are no entanglement or jamming logs in the robot's abnormal log.

[0077] In one embodiment, the first determining module 100 includes:

[0078] The extraction submodule is used to extract abnormal logs from the remaining log data after removing map data transmission logs from all log data of the robot, and to determine the abnormal type of the robot based on the last entry in the abnormal log.

[0079] In one embodiment, a robot is also provided, the robot including a control module, the control module being used to perform the steps of the above-described robot anomaly handling method.

[0080] The execution functions of this control module correspond one-to-one with the robot anomaly handling methods in the above embodiments. Specific limitations of the control module can be found in the limitations of the robot anomaly handling methods described above, and will not be repeated here. Each submodule in the above control module can be implemented entirely or partially through software, hardware, or a combination thereof. Each submodule can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each submodule.

[0081] In one embodiment, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of the robot anomaly handling method described above.

[0082] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When executed, these computer-readable instructions can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0083] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above.

[0084] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A robot exception handling method characterized by, The method comprises: When a robot performing a cleaning task in a target area has a cleaning abnormality, obtaining an abnormality log of the robot, and determining an abnormality type according to the abnormality log; When the abnormality type is a hardware abnormality, obtaining hardware state information of all hardware of the robot; According to the hardware state information, determining an abnormal hardware existing from all the hardware, and determining recoverability of the abnormal hardware according to a first preset rule; When the recoverability of the abnormal hardware is recoverable, determining whether the robot is in a trapped state according to a second preset rule; When the robot is not in the trapped state, if it is determined that there is false data in the hardware state information of the abnormal hardware, prompting that the hardware abnormality of the robot is false, and continuing to perform the cleaning task; After determining whether the robot is in the trapped state according to the second preset rule, the method further comprises: When the robot is in the trapped state, controlling the robot to standby in place, and sending abnormality information containing abnormal coordinates to a preset reporting party, so that the preset reporting party marks the abnormal coordinates in a cleaning map and performs abnormality processing according to the abnormality information; the cleaning map refers to a map containing the target area; the abnormal coordinates refer to current position coordinates of the robot having the hardware abnormality; Determining whether the current coordinate position of the robot belongs to a forbidden area marked in the cleaning map, and determining whether there is a winding or jamming log in the abnormality log of the robot; When the current coordinate position of the robot belongs to the forbidden area marked in the cleaning map, or there is a winding or jamming log in the abnormality log of the robot, it is determined that the robot is in the trapped state; When the current coordinate position of the robot does not belong to the forbidden area marked in the cleaning map, and there is no winding or jamming log in the abnormality log of the robot, it is determined that the robot is not in the trapped state. After determining the abnormality type according to the abnormality log, the method further comprises:

2. The robot exception handling method of claim 1, wherein, When the abnormality type is a communication abnormality, controlling the robot to standby in place and saving current cleaning data, and performing a network communication recovery operation; When the robot re-recoveries network communication, updating the cleaning task according to the current cleaning data. After determining the recoverability of the abnormal hardware according to the first preset rule, the method further comprises:

3. The robot exception handling method of claim 1, wherein, When the recoverability of the abnormal hardware is unrecoverable, controlling the robot to standby in place, and sending a hardware maintenance request of the abnormal hardware to a preset receiving party. Determining the recoverability of the abnormal hardware according to the first preset rule comprises:

4. The robot exception handling method of claim 1, wherein, Controlling the abnormal hardware of the robot to restart, and determining whether the abnormal hardware is normal; If the abnormal hardware is normal, it is determined that the recoverability of the abnormal hardware is recoverable; If the abnormal hardware is not normal, it is determined that the recoverability of the abnormal hardware is unrecoverable. ​ 5. The robotic exception handling method of claim 1, wherein, The acquisition of the abnormal log of the robot comprises: After removing the map data transmission log from all log data of the robot, the abnormal log in the remaining log data is extracted, and the abnormal type of the robot is determined according to the last log in the abnormal log.

6. An abnormality processing apparatus characterized by comprising: Comprise: The first determination module is configured to acquire an abnormal log of the robot when the robot performing a cleaning task in a target area has a cleaning abnormality, and determine an abnormal type according to the abnormal log; The acquisition module is configured to acquire hardware state information of all hardware of the robot when the abnormal type is a hardware abnormality; The second determination module is configured to determine an abnormal hardware existing from all the hardware according to the hardware state information, and determine the recoverability of the abnormal hardware according to a first preset rule; The third determination module is configured to determine whether the robot is in a trapped state according to a second preset rule when the recoverability of the abnormal hardware is recoverable; The processing module is configured to, when the robot is not in the trapped state, if it is determined that there is false data in the hardware state information of the abnormal hardware, prompt that the hardware abnormality of the robot is false, and continue to perform the cleaning task; After the determination of whether the robot is in the trapped state according to the second preset rule, the method further comprises: When the robot is in the trapped state, the robot is controlled to stay in place, and abnormal information containing abnormal coordinates is sent to a preset reporting party, so that the reporting party marks the abnormal coordinates in a cleaning map and performs abnormal processing according to the abnormal information; the cleaning map refers to a map containing the target area; the abnormal coordinates refer to the current position coordinates of the robot when the hardware abnormality occurs; The determination of whether the robot is in the trapped state according to the second preset rule comprises: Determine whether the current coordinate position of the robot belongs to a forbidden area marked in the cleaning map, and determine whether there is a winding or jamming log in the abnormal log of the robot; When the current coordinate position of the robot belongs to the forbidden area marked in the cleaning map, or there is a winding or jamming log in the abnormal log of the robot, it is determined that the robot is in the trapped state; When the current coordinate position of the robot does not belong to the forbidden area marked in the cleaning map, and there is no winding or jamming log in the abnormal log of the robot, it is determined that the robot is not in the trapped state.

7. A robot, characterized in that The control module is configured to perform the steps of the robot abnormal processing method according to any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 7. The computer program is executed by the processor to realize the steps of the robot abnormal processing method according to any one of claims 1 to 5.

Images